I used Next.js to build http://user-agent.io/ over a weekend and I'm really happy with the results so far. Dynamic url routing is a bit awkward, but not onerously so. (It also uses Express to handle WebSockets and dynamic routing for the share/host pages.)
Just a heads up you're using the development version of React which is very very slow. You'd want to switch to the production version, not sure how that works in next but you generally build your React with NODE_ENV set to `production` for this to happen.
Update: with some serious help from Arunoda, I've learned that it was due to the react-google-ad component I was using bundling it's own copy of react. So, while the rest of the site was using production-mode React, that one component wasn't and that was enough to trigger the warning in the Chrome extension.
I'm afraid it won't reduce the impact, your server takes the initial load of rendering instead of the browser, and the browser takes over for each re-render.
Not sure how Next.js does it but you should probably try putting NODE_ENV=production in the "build" script in package.json like in "start"?
I had a quick glance over Next.js's docs and it looks like they should handle this automatically just by `next build`. ¯\_(ツ)_/¯
"Very very slow" might be a bit of an overstatement. The initial React render for that page takes 200ms on a MacBook. A release build will speed that up slightly, and cut down the bundle a little, but in the scheme of things it's not going to be noticeable to the end user.
If you actually wanted the page to feel fast you would probably do something like <script>document.write(window.navigator.userAgent)</script>
I did not expect to argue in HN of all places whether it's OK or not to run the development mode of a library in production when it's so simple not to and the authors are trying so hard to prevent people from doing that.
LOL, that's prettymuch what the previous version of the site did. The new one is fancy partially to learn some new things, and partially to enable the host/share feature.
On GitHub, it seems like the javascript sources behind your pages is throwing their syntax highlighting off. Seems like when you embed HTML it hiccups. Any idea how one would fix this?
Oh, hah, it's getting bit by lone single quotes, (AKA apostrophes). I think it's something GitHub would have to fix, although perhaps a .jsx extension would help.
- The same transpiled code is used both server-side and client-side. Code which should be strictly server-only, e.g. getInitialProps(), is visible client-side as well.
I can only comment about `getInitialProps()`. Of course it's should be on client-side as well, that's the whole point of universal rendering. In combination with isomorphic-fetch you can use your (Rest) API and have nothing to change on the code. I think it's an excellent design decision to makes components actually independent and easily composable.
Still, using the same transpiled code both client-side and server-side is suboptimal at least. E.g. if I target Node 7.x on the server, I don't need to transpile async functions for example (and screw stacktraces in the process).
Also, I might still want to do some things differently server-side in getInitialProps(), despite most of the code being shared. For example, clients might access the API through a load-balanced frontend, while on the server I might want to prefer talking to an API process on the same machine. Authentication might also be different. Of course these things (e.g. the API endpoint) shouldn't be hardcoded, but even then you need to get them somewhere, most likely a configuration file or an environment variable. And sharing these details (names of environment variables for example) with the client is not something I particularly like.
1. We have plenty of examples with interoperation with Redux. Check out the `./examples` folder :)
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.
I tried to do a project with next.js but their router was just too awkward and limiting. Unless you're doing straight 1:1 route to code, you're basically on your own.
I am wondering why server-side rendering? I thought that stage was passed and everyone was doing client-side stuff? Please forgive a web n00b for asking.
You can get a faster initial load going with SSR since you're basically skipping a round trip. The really smart SSR's like Redfin's react-server (https://github.com/redfin/react-server) give you faster "above the fold" rendering too.
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.
1. Embraces React exclusively[1]. We at ZEIT think the React Component model is the de-facto component model of the web and mobile.
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.
That made me laugh. But, really, it's true. Adding a new page is as simple as adding a new file. No importing, routing, etc. required. That's one thing that I think PHP got right.
To answer my own question to those that stumble upon this via google or whatever. It doesn't appear to be. However this example was pretty helpful (as of 20170518):
As it previously said it's two different projects. Meteor is a full stack framework where it does everything from data to 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.
Meteor is (to my understanding) an all-in-one framework with database access and realtime stuff built in.
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.
AMD was a handy workaround, but better solutions exist now.
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.)
These are all valid points... but I'm curious what you mean by "better solutions exist now." Basically everybody's agreed to use a transpiler for the foreseeable future [0]. How is that not a workaround?
Source is at https://github.com/nfriedly/user-agent.io if anyone is interested.
I'm thinking about switching some of my work projects over to it sometime soon.