Next.js 3.0 Preview: Static Exports and Dynamic Imports

https://github.com/zeit/next.js#custom-server-and-routing

To answer your questions:

1) Because the router in next.js embeds really well into the model of pages, prefetching, etc. while still keeping the mechanisms simple, here's how to use with redux: https://github.com/zeit/next.js/tree/master/examples/with-re... 2) now.sh is in no way mandatory. To deploy anywhere, `next build` and `next start` will run the node.js server, so you're free to deploy it anywhere you'd like: https://github.com/zeit/next.js#production-deployment

We currently use global state at https://zeit.co to keep the authenticated user in memory without re-checking for every page transition.

You can think of Next.js's Router as a "strict subset" of RR. Definitely possible for us to simplify our codebase by switching to RR in the future.

2. Nothing about this framework is dependent on now.sh. We, however, did design now.sh to make deployment of applications as this as easy, fast and scalable as possible with collaboration in mind.

Also, while Google can deal with them, a lot of crawlers don't understand SPA's. So if someone links to you from Facebook for example, their auto content loading doesn't work.

Next.js is sort of a React project bootstrap/boilerplate that has some pre-selected configuration for things like styling components and server side rendering.

But Next.js is not like this. It's only for the UI (rendering) You can build server rendered React apps pretty easily. It supports dynamic imports, prefetching, preloading and you name it.

Now you can export any Next.js app into a static app too.

Recently, Meteor adds some new JS features into it's build setup too.

In practical terms, this means that every "page" or "entry point" to your app is just an exported component `function` or `class`. `export default () => <p>My component!</p>`.

At the expense of a storm of HN downvotes, it's "more PHP than Meteor" :)

2. No data layer built in, syncing, Models, etc. We added an extra lifecycle hook called `getInitialProps` (think of it as the counterpart to `getInitialState`) whose contract is returning data as a `Promise`.

This allows you to combine and compose different approaches to data retrieval. It works just as well with REST as it does with GraphQL or Socket.IO or server-sent-events or offline-only or…

3. It hides configuration details but allows you to tap into them.

It's powered by `Babel` and `webpack`, which are exposed as a single command (`next` and `next build`), but you can completely override and customize them.

These are just some ideas. We created it to power the team collaboration aspects of our Web UI (https://zeit.co). We are committed to supporting it because we use it and we love it.

[1] Also React alternatives like Inferno and Preact (https://github.com/zeit/next.js/tree/master/examples/using-p...)

For one thing, each and every little module doesn't need to be written with knowledge of AMD or how it's going to be imported at all. If you used AMD with this component example, every single component you write would need to be wrapped in a `define()`. This has no wrapping, just standard JS exports.

Secondly, each module doesn't need to know its own name (to pass to the `define()` call), or even have a static name at all, it can effectively be anonymous & truly dynamic.

And finally, AMD modules make assumptions about the environment – for example, that you have control over `window.define`. If you're a third-party script trying to load things on someone else's website, good luck – you either just told someone else's module handler that you loaded, and have no visibility into it, or you clobbered the existing `window.define` and broke other people's scripts. (My former company's product was a third-party JS widget, and co-existing with dozens of other scripts and module loaders was a huge problem.)