
Next.js 2.0 - tbassetto
http://zeit.co/blog/next2
======
migueloller
We recently used Next.js to build out an MVP. It was a pleasure to work with.

For those wondering what this is, it's basically a slightly more opinionated
Create React App [1].

Here are some of the benefits:

\- No need to setup complicated tooling

\- Server and client (SPA-style) rendering out of the box

\- Filesystem for routing using the `pages` directory

\- `getInitialProps` component lifecycle to encapsulate data requirements per
component

\- Automatic code splitting for each route

\- If it works with React, it works with Next.js

Here are some of the issues we encountered:

\- Importing non-JS files from `node_modules` (like normalize.css) was not as
simple as it could be (#1245 [2])

\- Animation transition between pages is still being worked on (#88 [3])

\- There are still some inconsistencies between server and client that could
improve, like running Webpack on the server (#1245 [2])

\- Doing proper scroll restoration when routing (#1309 [4])

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.

[1] [https://github.com/facebookincubator/create-react-
app](https://github.com/facebookincubator/create-react-app)

[2]
[https://github.com/zeit/next.js/issues/1245](https://github.com/zeit/next.js/issues/1245)

[3]
[https://github.com/zeit/next.js/issues/88](https://github.com/zeit/next.js/issues/88)

[4]
[https://github.com/zeit/next.js/issues/1309](https://github.com/zeit/next.js/issues/1309)

~~~
threatofrain
> For those wondering what this is, it's basically a slightly more opinionated
> Create React App.

Does that mean the top benefit of next.js is to alleviate difficulties with
Webpack + Babel + etc?

~~~
geekjock
> Does that mean the top benefit of next.js is to alleviate difficulties with
> Webpack + Babel + etc?

And server-side rendering which solves common SEO and performance challenges
of SPAs. Here's an article showing where server-side rendering is especially
useful for SEO reasons:

[https://hackernoon.com/react-js-cms-blog-
tutorial-e090c69984...](https://hackernoon.com/react-js-cms-blog-
tutorial-e090c699845b)

------
jonknee
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!

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!

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.

    
    
       ffmpeg -i hello-world_2.mp4 -vcodec libx264 -preset veryfast smaller.mp4

~~~
BinaryIdiot
> It appears the screencast video is to blame, it is not only huge (~70MB),
> but it keeps getting downloaded instead of just replaying.

Question, do you have caching disabled when devtools is open? If so that'll
cause it to continually re-download. Looking at the markup it shouldn't
redownload but devtools will make that happen quite easily.

Completely agreed about the size though; geeze.

~~~
user5994461
Devtool doesn't impact caching.

~~~
Kiro
Why do you post about things you obviously have no clue about? Any web
developer knows that you use DevTools to disable caching.

------
Stamy
Vue.js ecosystem has alternative as well. It is Nuxt.js
([https://nuxtjs.org/](https://nuxtjs.org/))

~~~
marvindanig
Super! I love the way VueJS community plays its cards in this otherwise
corporate driven turf of open source-y stuff. Will take a look at nuxtjs next.

------
ndreckshage
Next is great. I would love to deprecate my SSR starter kit - Sambell -
[https://github.com/humblespark/sambell](https://github.com/humblespark/sambell)
\- once it supports a layout file, for animated transitions, etc. Right now,
React Router seems fundamentally more powerful as a SPA framework.

~~~
symboltoproc
just fyi it's possible to change the commit history, so no "proof" ;)

------
smdz
I don't understand why people here are comparing Next.js to create-react-app.

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?

~~~
codecurve
Because both are opinionated ways to get a React project going without having
to configure any tooling yourself.

Next.js also focuses on client side JavaScript, but happens to render at the
server first, so that there's something there for users before the client
bundles have downloaded, parsed and been executed.

You could think of it as a more configurable create-react-app that supports
server side rendering, with a convention over configuration approach to pages
and links.

~~~
williamle8300
> You could think of it as a more configurable create-react-app that supports
> server side rendering, with a convention over configuration approach to
> pages and links.

You are a poet, sir. Best answer.

------
tabeth
Ah, so close.

I really just want something like Handlebars, with a generic adapter for any
language for compilation.

Then you can load with javascript a client-side controller if you want to add
in interactivity.

\---

To expand, I think the idea solution would be the following:

1\. Server side view, let's call it "Bars"

2\. Bars can be written on the front-end or back-end, does't matter. It'll
compile to BarsHTML.

3\. If you write Bars on the back-end, then when you serve your page it'll
compile Bars into BarsHTML.

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.

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.

~~~
ramses0
Take a look at [http://markojs.com/](http://markojs.com/) and
[http://markojs.com/docs/installing/](http://markojs.com/docs/installing/)

test.marko: `<h1 on-click('callMyFunc')>${ input.hello }</h1>`

component.js: `class { callMyFunc(e) { console.log(e); } }`

...gets compiled to test.marko.js which can then be require'd or using a
special runtime loader or transformer. It hits a nice sweet spot for me, and
is worth checking out.

------
anupshinde
It would be great to see TypeScript support with NextJS out of the box. It can
be done with some work today.

Inspired by an earlier(probably first release) of NextJS, I had attempted
TypeScript and server-rendered react here:

[http://www.anupshinde.com/posts/react-typescript-server-
rend...](http://www.anupshinde.com/posts/react-typescript-server-render/)

~~~
styfle
Very cool. I wrote a SSR React + TypeScript boilerplate [0] and have been
trying to keep it updated, but I just found out next.js has a TS example[1] so
now I think I'll switch over.

[0]: [https://github.com/styfle/react-server-example-
tsx](https://github.com/styfle/react-server-example-tsx)

[1]: [https://github.com/zeit/next.js/tree/master/examples/with-
ty...](https://github.com/zeit/next.js/tree/master/examples/with-typescript)

------
egeozcan
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:
[http://i.imgur.com/c3H176u.png](http://i.imgur.com/c3H176u.png)

------
jorjordandan
The link is wrong for the Koa server example. It points to the Hapi example,
it should point here:
[https://github.com/zeit/next.js/tree/master/examples/custom-...](https://github.com/zeit/next.js/tree/master/examples/custom-
server-koa)

------
zackify
If anyone wants to see, we are using next.js 2.0 on
[https://kimmel.com](https://kimmel.com). 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!

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

~~~
Arcsech
I'm not anti-SPA (and in fact, I think of the tools out there react is a
pretty good one if you're going to do SPA), but I do think it's the wrong tool
for a lot of jobs. If your site is mainly content-based, like a blog or a
forum, why make it an SPA?

I feel like React/Angular/Vue/etc apps are becoming "the way the web is done"
when so many things would be simpler and more efficient as plain old web sites
with server-rendered HTML. It's like everyone decided that because
convertibles are cool, they should be used for everything, and are now
spending a ton of effort hitching trailers to their convertibles when it would
have been much simpler and more effective to just drive a boring minivan in
the first place.

~~~
muse900
I agree with you mostly, but isn't fb a forum? It most certainly has more
capabilities like playing games etc, but it still carries basic forum
principles. So is facebook wrongly designed?

~~~
holtalanm
look. a strawman.

Don't kid yourself, Facebook is much much more than just a forum. It might
have been little more than a forum initially, and the amount of javascript it
originally had kind of upholds the OP's original statement. It was a pretty
slim webapp originally.

------
beezischillin
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!

~~~
pierrehenrit
Check this: [https://github.com/kirill-konshin/next-redux-
wrapper](https://github.com/kirill-konshin/next-redux-wrapper) and usage here:
[https://github.com/zeit/next.js/blob/master/examples/with-
re...](https://github.com/zeit/next.js/blob/master/examples/with-redux)

~~~
beezischillin
Thank you, I've seen the clock one on the website, however the thing that
doesn't exactly click with me is how would you, for example handle multiple
users with server-side rendering, where each user only has access to their own
state data?

I'm pretty clear on how to use client-side react with redux, it's just the
server side part that would include stuff like user authentication seems
confusing to me so far, since I haven't seen a clear implementation of that
yet.

Thanks!

~~~
cstrat
I have been trying to work this out myself too. Would love to see some
examples on how to address this.

The challenge seems to be that while the server side rendered bit would work
fine - it could query a DB locally after authenticating a users cookie (for
example)...

If the client routed to a page (not using the server rendering) - you would
need to have duplicated code to handle how the client can fetch that data, as
it cannot query the DB directly.

------
mike-cardwell
I rebuilt
[https://www.emailprivacytester.com](https://www.emailprivacytester.com) in
NextJS v1 -
[https://gitlab.com/mikecardwell/ept3/tree/master](https://gitlab.com/mikecardwell/ept3/tree/master)
\- 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.

------
sergiotapia
Next looks very interesting and feels very much like the PHP of old where
stuff just works with sane defaults. Very cool stuff.

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.

You know what I call that? Not knowing how to scope your styles properly with
something like BEM. [http://getbem.com/](http://getbem.com/)

~~~
Kiro
I completely disagree. After working with component CSS I vomit when I see any
CSS not encapsulated to one single component. I don't want to change a global
CSS declaration and accidentally change something completely different. You
can always import the stuff you really want shared.

~~~
WA
Do you have some reading material on how to do this properly? Because I never
worked with component-based CSS yet, but want to have a look at it and
wondered about what your parent posted, too.

~~~
idreyn
There's a set of libraries like Aphrodite, Glitter, jsx-style, and JSS that
help you do this. I'd look at some benchmarks [1] and do some comparison
before you make a decision yourself.

I've worked extensively with Aphrodite (disclaimer, my employer maintains it)
and have found it works with React to make a pretty good workflow for SPAs. It
does require some buy-in from everyone involved with the codebase since you'll
have Aphrodite-defined styles clashing with stuff in external stylesheets, and
there are occasional edge cases where you'd like to use some crazy CSS
selector that Aphrodite doesn't support, but this is often a sign that you
should be restructuring your component in a more straightforward way.

The style reuse and composability story is very good, since all styles are
wrapped around bare JS objects which are super easy to manipulate and the ES6
spread syntax [2] makes it all look very elegant. If it's important to you to
keep styles and markup in different files, you can do that too as long as
you're happy giving them all .js/.jsx/.ts extensions.

In general it is frustrating to me that total buy-in into the React model
comes at the cost of support for actual standards like Web Components, but I
never want to write UI in a non-declarative way again so I'm hoping someone
smarter than I can figure out how to bring these two worlds together so we can
let the browser properly namespace our CSS rather than relying on randomly
generated class name infixes as Aphrodite does.

[1] [https://engineering.hellofresh.com/the-css-in-js-
battle-89c3...](https://engineering.hellofresh.com/the-css-in-js-
battle-89c34a7a83ea#.cae5q4lkd)

[2] [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Operators/Spread_operator)

------
andrewgleave
The MP4 included in the page causes graphics corruption and locks my MBP in
Safari 10.1. Anyone else seeing this?

Save your work before trying, though.

------
TeeWEE
Looks cool. But everybody who thinks of building a webapp, try todo it without
react if you don't need it. For example [https://next-
news.now.sh/](https://next-news.now.sh/) is MUCH MUCH slower than normal
hacker news. And its also much more difficult to maintain, and less future
proof.

Greetings

~~~
foxylion
It is so much slower because it uses another API which requires multiple
requests to get the same data.

------
EGreg
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
([https://qbix.com/platform](https://qbix.com/platform)), since 2011.

When we built it, we had out of the box:

\+ Tools (our name for components)

\+ Pages (to support all web standards)

You place tools on pages, the framework does the rest:

\+ It loads JS and CSS on demand

\+ It adds/removes tools from pages automatically as you navigate

\+ Support for web standards, HTML5 history w fallbacks, etc.

\+ Tools can contain other tools

\+ You have events for when all parent tools have activated (onActivate) and
when all child tools activated (onInit)

\+ JS and CSS had to be namespaced by convention from day 1, by module and
tool name.

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.

But the problems are very similar in scope.

~~~
laktek
Any links to sources of sample apps built with it? Interested to see how you
compose pages with Tools.

~~~
EGreg
Sure. Here is a full app built on it:
[https://customizemypic.com](https://customizemypic.com) \- it has a GITHUB
link

Here is a showcase of what is possible:
[https://vimeo.com/208438090](https://vimeo.com/208438090)

And here are some tutorial videos on pages and tools:
[https://qbix.com/platform/tutorials](https://qbix.com/platform/tutorials)

------
hoodoof
>> "More than 3.1 million developers read our announcement post of Next.js. "

Really? 3.1 million developers? I'm not saying I don't believe, but wow, how?

edit: actually I am saying either I don't believe or you've miscalculated
somehow.

~~~
stocktech
They're probably just reporting google analytic numbers. I don't think that's
unfair.

~~~
hoodoof
Even so, 3.1 million page views?

~~~
aioprisan
Over a few months? Plausible.

------
xutopia
There is something I do not understand. Why does `<div>` not create a syntax
error in the Javascript examples? Is there a pre-processor?

~~~
Hnus
Take a look here [https://facebook.github.io/react/docs/react-without-
jsx.html](https://facebook.github.io/react/docs/react-without-jsx.html)

------
mmgutz
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++.

------
fourstar
I want to use this but I'm hesitant to do so for a project that's backed
specifically by a single company _. Can someone help alleviate my concerns?

_ I had to verify my email address and accept the TOS before I could use their
command line tool.

~~~
migueloller
Next.js is entirely open source and is separate from the product the company
offers. Their command line tool is one of the interfaces they provide to use
their product but is not needed to use Next.js.

~~~
holtalanm
saying something is entirely open source is useless if their License Agreement
contains riders like Facebook's React license agreement does.

I just don't trust their modified License Agreement.

------
asadlionpk
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!

------
swlkr
I used next on a side project, zero boilerplate is refreshing.

------
n3bs
How does this compare to react-boilerplate? I've been using react-boilerplate
recently and it's been solid so far.

~~~
geniium
This seems to be totally another approach. More like an opinionated setup
where you can get a project set up and ready in a few line of codes.

Very interesting approach!

What are the pros and the cons? Someone that has used both should help us
here.

~~~
scottmf
I've used both and prefer next.js. Granted I'm using GraphQL but I'd prefer it
regardless.

RBP is actually more opinionated. It's "best* practices to the extreme" at the
cost of productivity and lots of boilerplate. It's also a little hostile
towards server-side rendering.

I enjoyed RBP and learned from it, but we switched to next.js (with styled-
components and apollo-client) and things have been far smoother. To be honest
I can't really think of a reason to use RBP over Next.js.

The creator @mxstbr has tweeted positively about Next.js, has other projects
to look after (e.g. styled-components), and hasn't updated it since January,
so I'm not sure RBP has much of a future anyway.

------
kbody
I would love and use this if it was using Riot instead of React.

------
tonetheman
Frameworks made of frameworks... frameworks all the way down

~~~
pweissbrod
The word framework is broad and I dont see this as the same kind of thing as
React. This marries set of frameworks which work well together and provides a
opinionated but clean approach to building larger apps more
efficiently/consistently. Similar to eiffel, MEAN, jHipster etc. There is
great value in this kind of bundling effort for those of us less-experienced
with the frameworks who need help getting a proper start

------
tambourine_man
I guess I became way too cynical.

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.

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.

------
geniium
Very promising!

------
Polarity
nice, thx!

------
vincivince
Nice work.

------
ergo14
Why in the world everything needs to be made with react that makes it
incompatible/hard to integrate with any other frameworks?

~~~
okket
IMHO because react is designed this way. It makes it easy to add to existing
content, it is not an "opinionated" framework. This is great for getting quick
results, but not for compatibility, easy source code navigation, etc.

You can add these constraints later, but you will be on your own island. Maybe
sometime a standard ("best current practices") emerges...

~~~
ergo14
At this point I have to use react more or less. It is a ghetto. React vs the
world. I'd like to have more than one option to use here.

~~~
bpizzi
Obvious solution to your problem: write your own js component library. And
don't forget to submit it to the HN crowd when you're done, you should get a
very positive feedback.

~~~
ergo14
There are other solutions out there: polymer, skatejs, x-tags, vue, angular,
aurelia. Some of them are more interoperable with others and can be use in
multiple projects using different frameworks - I'd like this to be the norm.

~~~
bpizzi
So, to go back to your original post ('Why in the world everything needs to be
made with react'): not everything is made for/with react, and you provided
really good counterarguments againts yourself (polymer, vue, angular, etc). I
still don't get the point you were trying to make (no offense really).

------
grumblestumble
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 [https://github.com/zeit/styled-
jsx](https://github.com/zeit/styled-jsx), which can only euphemistically be
called a naive implementation, with the documentation around custom
properties, with the styling documentation at
[https://developers.google.com/web/fundamentals/getting-
start...](https://developers.google.com/web/fundamentals/getting-
started/primers/shadowdom).

