One of the authors of Next.js here. I want to clarify that all the points against Next.js are virtues! They probably just arise from Rich not being so familiar

One of the authors of Next.js here. I want to clarify that all the points against Next.js are virtues! They probably just arise from Rich not being so familiar with it (or not having looked at the examples/ directory extensively: https://github.com/zeit/next.js/tree/canary/examples https://github.com/zeit/next.js/tree/canary/examples) 1. I think this point is trying to say that we don't have special "mask files" inside `pages/`, which is an idea worth exploring. Right now, Next.js instead gives you full flexibility on how you want to match the routes on your server (as it should be). For example, `your-domain.com/xyz` can even first perform a database query before deciding what page to render it with (if any). 2. What the author points out as a weakness here is that you can handle server things directly in your server code (`server.js` using micro or express for example). That sounds like the right thing to do to me, and if you don't want that, you still can do something like: // pages/my-server-page-only.js export default ({ req, res }) => res.end('hi') 3. "To use the client-side router, links can't be standard <a> tags." This is by design. Magically overloading `<a>` to add client-specific behavior sounds like the days of jQuery or TurboLinks. If you want client-side behavior, wrap `<a>` in the higher-order `<Link>` component. There also very important properties of the `<Link>` like `<Link prefetch>` that are simply not part of the `<a>` standard definition. Also noteworthy: the entire ZEIT Documentation is written in Markdown with React components. It's open source: https://github.com/zeit/docs https://github.com/zeit/docs On size: the Next.js and React teams are both working towards really interesting solutions to ship only the code that's necessary, without resorting to templating as the main strategy. Our team actually spends more time on the 'compiler' parts of Next.js than the 'framework API' parts. (the API has barely changed since the initial 0.1 release in fact). Additionally, since Next.js uses React as peer dependencies, you'll also get to do `yarn add next react react-dom-lite` https://github.com/jquense/react-dom-lite https://github.com/jquense/react-dom-lite in the future. Overall, I think Sapper is an excellent framework for Svelte users. I'm looking forward to seeing more Next.js-like frameworks. For Vue users: check out https://nuxtjs.org/ https://nuxtjs.org/!