Hacker News Reader

Comment by nfriedly | Hacker News Reader

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.)

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.

View on HN

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.

"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>

Possibility of 3x-5x perf impact according to Dan Abramov. https://github.com/facebook/react/issues/2608#issuecomment-2...

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.

200ms on your high end laptop is what on a mid-range mobile phone? Probably 5-6 seconds, users will notice 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.

Hum, that's interesting. I do have NODE_ENV=production set. I'll have to see if Next.js needs something additional.

Although, with server-side rendering (which is part of what I really like about Next.js), the impact should be reduced somewhat.

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`. ¯\_(ツ)_/¯

That's a good thought with the build script, but I tried it locally and it didn't seem to make a difference.

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 sent a pull request to fix it: https://github.com/lukehansell/react-google-ad/pull/5

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.

Update: Yep, GitHub highlights correctly with a .jsx extension - see https://github.com/nfriedly/user-agent.io/blob/jsx-test/page... - but then Next.js can't "see" the page :(

So, I'm going to have to stick with .js for now.

Reply on news.ycombinator.com