We recently used Next.js to build out an MVP. It was a pleasure to work with.<p>For those wondering what this is, it's basically a slightly more opinionated Create React App [1].<p>Here are some of the benefits:<p>- No need to setup complicated tooling<p>- Server and client (SPA-style) rendering out of the box<p>- Filesystem for routing using the `pages` directory<p>- `getInitialProps` component lifecycle to encapsulate data requirements per component<p>- Automatic code splitting for each route<p>- If it works with React, it works with Next.js<p>Here are some of the issues we encountered:<p>- Importing non-JS files from `node_modules` (like normalize.css) was not as simple as it could be (#1245 [2])<p>- Animation transition between pages is still being worked on (#88 [3])<p>- There are still some inconsistencies between server and client that could improve, like running Webpack on the server (#1245 [2])<p>- Doing proper scroll restoration when routing (#1309 [4])<p>We will continue to use it as long as it keeps letting us move fast without having to worry about spending hours setting up React tooling.<p>[1] <a href="https://github.com/facebookincubator/create-react-app" rel="nofollow">https://github.com/facebookincubator/create-react-app</a><p>[2] <a href="https://github.com/zeit/next.js/issues/1245" rel="nofollow">https://github.com/zeit/next.js/issues/1245</a><p>[3] <a href="https://github.com/zeit/next.js/issues/88" rel="nofollow">https://github.com/zeit/next.js/issues/88</a><p>[4] <a href="https://github.com/zeit/next.js/issues/1309" rel="nofollow">https://github.com/zeit/next.js/issues/1309</a>
This page has some huge issues loading resources. I kept it open as a tab to dive into later and noticed it was still spinning after a long time... I refreshed with Developer Tools open and after 2 minutes over 100MB had been transferred!<p>It appears the screencast video is to blame, it is not only huge (~70MB), but it keeps getting downloaded instead of just replaying. I just checked the console again and the page is now up over 300MB downloaded. Glad I wasn't on mobile data!<p>Update: I downloaded the video and ran it through ffmpeg to see how much space could be saved... Original size 72.2MB, new size 1.7MB. Screencasts obviously compress very well, but this was pretty surprising. You could easily optimize this down further and probably half the size yet again.<p><pre><code> ffmpeg -i hello-world_2.mp4 -vcodec libx264 -preset veryfast smaller.mp4</code></pre>
Vue.js ecosystem has alternative as well. It is Nuxt.js (<a href="https://nuxtjs.org/" rel="nofollow">https://nuxtjs.org/</a>)
Next is great. I would love to deprecate my SSR starter kit - Sambell - <a href="https://github.com/humblespark/sambell" rel="nofollow">https://github.com/humblespark/sambell</a> - once it supports a layout file, for animated transitions, etc. Right now, React Router seems fundamentally more powerful as a SPA framework.
I don't understand why people here are comparing Next.js to create-react-app.<p>I see Next.js primarily focusing on server-rendered React and then it also supports client-rendering. I see create-react-app is primarily focused on client-javascript. Am I missing something?
Ah, so close.<p>I really just want something like Handlebars, with a generic adapter for any language for compilation.<p>Then you can load with javascript a client-side controller if you want to add in interactivity.<p>---<p>To expand, I think the idea solution would be the following:<p>1. Server side view, let's call it "Bars"<p>2. Bars can be written on the front-end or back-end, does't matter. It'll compile to BarsHTML.<p>3. If you write Bars on the back-end, then when you serve your page it'll compile Bars into BarsHTML.<p>3a. If you want to sprinkle JS onto Bars, you'll use BarsControllerJS, an adapter to whatever framework of your choice, to manipulate it. The main difference between this and manipulating the DOM is that the interface to do this is not DOM centric.<p>4. If you write Bars on the front-end, it's the same as (3), but you get (3a). If you decide you'd rather do server side rendering, you literally just move your views to the server. The controller is already abstracted, so you wouldn't need to do anything else.
It would be great to see TypeScript support with NextJS out of the box. It can be done with some work today.<p>Inspired by an earlier(probably first release) of NextJS, I had attempted TypeScript and server-rendered react here:<p><a href="http://www.anupshinde.com/posts/react-typescript-server-render/" rel="nofollow">http://www.anupshinde.com/posts/react-typescript-server-rend...</a>
I wonder how hard it would be to programatically cache a Next.js app with a ServiceWorker to make it also work offline. I guess one could copy the logic from the prefetch script as it makes network requests like this: <a href="http://i.imgur.com/c3H176u.png" rel="nofollow">http://i.imgur.com/c3H176u.png</a>
The link is wrong for the Koa server example. It points to the Hapi example, it should point here: <a href="https://github.com/zeit/next.js/tree/master/examples/custom-server-koa" rel="nofollow">https://github.com/zeit/next.js/tree/master/examples/custom-...</a>
If anyone wants to see, we are using next.js 2.0 on <a href="https://kimmel.com" rel="nofollow">https://kimmel.com</a>. Yes, the designer added way too many fonts, but overall it's a really nice static site thanks to next and the programmatic api allowed me to generate blog post pages!
I'm curious: Where do these anti-React (anti-spa?) people come from, technologically? Rails? Php? Some .Net stack? Do you think the web Peaked with Perl-based CGI-scripts?
I've been in this game for many years, and to me, any technology that speeds up development cycle time is an improvement. There's a reason React is so popular.
Awesome stuff. Just a quick question that doesn't click with me: how would you use Redux to manage application state for multiple users, server-side? If someone could drop me some examples or articles on this, I'd be really thankful!
I rebuilt <a href="https://www.emailprivacytester.com" rel="nofollow">https://www.emailprivacytester.com</a> in NextJS v1 - <a href="https://gitlab.com/mikecardwell/ept3/tree/master" rel="nofollow">https://gitlab.com/mikecardwell/ept3/tree/master</a> - Was a pleasure to use. My main problem though was that I couldn't add custom routes for API end-points, so had to split the application into a frontend (in Next) and backend express app. Looks like v2 fixes this. I will definitely be updating to take advantage.
Next looks very interesting and feels very much like the PHP of old where stuff just works with sane defaults. Very cool stuff.<p>My one criticism of this is: Component CSS is cancer. I've worked on a large scale javascript project and it was riddled with duplicated CSS in every component, all in the name of being conflict-free.<p>You know what I call that? Not knowing how to scope your styles properly with something like BEM. <a href="http://getbem.com/" rel="nofollow">http://getbem.com/</a>
The MP4 included in the page causes graphics corruption and locks my MBP in Safari 10.1. Anyone else seeing this?<p>Save your work before trying, though.
Looks cool. But everybody who thinks of building a webapp, try todo it without react if you don't need it. For example <a href="https://next-news.now.sh/" rel="nofollow">https://next-news.now.sh/</a> is MUCH MUCH slower than normal hacker news. And its also much more difficult to maintain, and less future proof.<p>Greetings
Not to toot our own horn, but I wanted remark on how similar the issues we have had to deal with in our own framework (<a href="https://qbix.com/platform" rel="nofollow">https://qbix.com/platform</a>), since 2011.<p>When we built it, we had out of the box:<p>+ Tools (our name for components)<p>+ Pages (to support all web standards)<p>You place tools on pages, the framework does the rest:<p>+ It loads JS and CSS on demand<p>+ It adds/removes tools from pages automatically as you navigate<p>+ Support for web standards, HTML5 history w fallbacks, etc.<p>+ Tools can contain other tools<p>+ You have events for when all parent tools have activated (onActivate) and when all child tools activated (onInit)<p>+ JS and CSS had to be namespaced by convention from day 1, by module and tool name.<p>We use events instead of virtual DOM. We didn't use fancy JSX or preprocessors to do it. It's all written in ES4 JS and runs on every modern browser and IE8.<p>But the problems are very similar in scope.
>> "More than 3.1 million developers read our announcement post of Next.js. "<p>Really? 3.1 million developers? I'm not saying I don't believe, but wow, how?<p>edit: actually I am saying either I don't believe or you've miscalculated somehow.
If I'm understanding correctly, seems like this is back to the old days when routes mapped directly to pages. From experience with ASP, it is not a good thing. You need to separate the routing from the presentation ala MVC. I can see the benefit if next.js is intended to be create-react-app++.
I want to use this but I'm hesitant to do so for a project that's backed specifically by a single company<i>. Can someone help alleviate my concerns?<p></i> I had to verify my email address and accept the TOS before I could use their command line tool.
I have recently migrated my boilerplate code to Next.js and it's awesome to work in. Previously I had my own code-splitted/server-side rendering setup but next does it better!
I guess I became way too cynical.<p>I though it was a satire, based on its name. Maybe there is some hidden self deprecating joke that went over my head, but Next + JS + 2.0 seemed too buzzwordy to be true.<p>The tech looks interesting. Still looks to me like a lot of stuff that I don't understand why I would need, but that's an old rant I have with the curent js ecosystem.
i know this is a tangent and not directly related to next.js, but the react ecosystem's insistence on coming up with increasingly convoluted and self-defeating stories around how to handle CSS instead of just using the tool the way it's intended is pure insanity. the emphasis with styled-jsx favors encapsulation with no real thought put into external overrides or customization, which makes this a non-starter for creating vendor components that are actually usable. compare <a href="https://github.com/zeit/styled-jsx" rel="nofollow">https://github.com/zeit/styled-jsx</a>, which can only euphemistically be called a naive implementation, with the documentation around custom properties, with the styling documentation at <a href="https://developers.google.com/web/fundamentals/getting-started/primers/shadowdom" rel="nofollow">https://developers.google.com/web/fundamentals/getting-start...</a>.