
Next.js – A small framework for server-rendered universal JavaScript apps - montogeek
https://zeit.co/blog/next
======
matchu
Interesting! I really like the architecture here. I think the next major
opportunity for abstraction is all the server/client detection you still have
to do. Do I want `request.headers['Cookie']` (server), or `document.cookie`
(client)? Do I want to create a fresh Redux store (server), or hook into a
global one (client)?

It's definitely not hard for community members to build these abstractions
themselves (`cookies = (req) => req ? req.headers['Cookie'] :
document.cookie`), but some of these are going to play into major use cases
like authentication, so, as Next matures, it'll start to make sense to provide
these especially common abstractions out of the box.

That said, these are next steps; the first release is all about showcasing the
fundamental architecture, and it's looking gooood :D

~~~
sillysaurus3
If someone wants to solve this problem and wants inspiration, look into how
Unreal Engine's scripting/networking architecture works. Gamedev and webdev
can be very similar at times.

~~~
greyskull
Interesting! Might you be able to elaborate?

------
idbehold
One thing that is never explained in these universal/isomorphic react
frameworks/boilerplates is how to make a fetch() against your own server (e.g.
a relative route). There's this [https://zeit.co/blog/next#data-fetching-is-
up-to-the-develop...](https://zeit.co/blog/next#data-fetching-is-up-to-the-
developer)

But what if my component looks like this:

    
    
      import React from 'react'
      export class exports React.Component {
        static async getInitialProps () {
          const res = await fetch('/api/user/123')
          const data = await res.json()
          return { username: data.profile.username }
        }
      }

~~~
girvo
I like how react-server[0] deals with it; by having the `when` and `listen`
callbacks expecting a promise, it becomes simple to `fetch()` any data you
want server-side, including relative routes

[0] [http://react-server.io/](http://react-server.io/)

~~~
leshow
is this your project or something? you seem to be name dropping it a few times
in this thread.

~~~
girvo
Nope! It's just been an excellent tool that I'm a pretty big fan of, and
relevant to a couple comments in this thread

------
tyingq
The split screen demo on the linked page does an outstanding job of showing
how this works. Nice work.

~~~
ivan_ah
Yeah, it's like the best 30 seconds demo I have ever seen.

------
matt2000
I'm a little confused about the benefits of server side rendering. I thought
the point of these js UI frameworks was to make the client do a bunch of the
work? Can anyone give me some of the upsides? Thanks!

~~~
z3t4
We will eventually go full server rendering and just stream every frame to a
thin client. We have good enough network now with gbe consumer bandwith and
less then 1ms latency up to 50km. But we need more powerful, smaller and
cheaper servers.

~~~
_puk
How does that make economical sense?

I can pay to render everything for my user, essentially streaming their
webpage to them. Or for the potential cost of a slightly slower page load I
can offset the cost of all that rendering to their xGHz multi core CPU that's
likely sitting idle.

Not to mention the cacheability of the data.

~~~
jjnoakes
Because bloating your client's experience has negative effects too: lower
battery life, lower performance, higher memory usage, ...

------
johns
Here's a sample app:
[https://github.com/zeit/nextgram](https://github.com/zeit/nextgram)

------
Walkman
[http://dayssincelastjavascriptframework.com/](http://dayssincelastjavascriptframework.com/)

------
ggregoire
I like how they use the tags <details> and <summary> in their FAQ!

[https://github.com/zeit/next.js#faq](https://github.com/zeit/next.js#faq)

~~~
cdubzzz
What do you like about it? It wasn't immediately obvious to me that those were
even clickable and the <details> text does not differ from the <summary> text
so it all kind of rolls together in a weird way as your click around.

~~~
cpmsmith
I think they mean the unexpected usage of semantic markup in the wild. It's an
ongoing battle to get it used more broadly, so it's nice to see it popping up
unannounced and working so nicely. Your (valid) gripes are mostly out of the
repo's control, as all styling appears to be GitHub.

~~~
cdubzzz
Ah, that's fair. But GitHub does provide quite a few styling options[0].

[0] [http://primercss.io/](http://primercss.io/)

~~~
nilliams
Those aren't 'options for styling Github', that's just a framework/lib they
provide for your own projects.

~~~
cdubzzz
Oh yeah, limited options with Markdown. Hence the original comment (:

------
ruffrey
Very cool. I can't wait to try it after five years in Node land. The people
behind zeit.co are great minds in the community.

It is funny how concepts come and go in circles. ASP.NET offered unified
client and server development, though mostly in C#. It had the nuget package
manager and VS store or something, but it was never amazing and packed like
npm. Partial page postbacks and page state in encrypted strings..yikes. Now we
have that in redux I suppose. It is all so familiar, yet so much better now.

------
Mizza
I love how ambitious Zeit is being, but I've found that their apps are not
quite as polished as their shiny-packaging makes out. I certainly wish them
lots of luck though!

~~~
Rauchg
Anything specifically comes to mind? We are constantly iterating and
improving.

------
desdiv
I'm very impressed that middle-click/ctrl-click works flawlessly. That's
increasingly becoming a rare thing on the web these days.

Forward and backward navigation only works up to one level. Is that a
limitation of the framework or an intentional design choice?

~~~
Aldo_MX
I tried the demo here, and middle click or ctrl+click is not working, quite
the contrary, it is treated like a regular click :/

[https://nextgram.now.sh/](https://nextgram.now.sh/)

~~~
simonlc
in the event handler you have to manually check if ctrl is being held or if
the lmb was pressed or not. Most people forget this which is a shame.

------
j_s
Surprised to see after 10 hours no one has mentioned intercooler.js which is a
stepping-stone in the direction developers focused on the "server" part of
"server-rendered" might head without going as far as Next.js.

[http://intercoolerjs.org/](http://intercoolerjs.org/)

[https://news.ycombinator.com/item?id=12657565](https://news.ycombinator.com/item?id=12657565)

------
lucideer
This looks very nice indeed. I've also just discovered glamor[1] via the
Readme, which looks similarly nice.

[https://github.com/threepointone/glamor](https://github.com/threepointone/glamor)

------
BilalBudhani
This is amazing! totally reminds me of PHP days.

------
alasano
Oh you're still rendering JavaScript client side, how mid-2016.

~~~
merrickread
It's almost November 2016 man, you can't do that anymore. Just Redux your Flux
and make sure you transpile and compile your TypeScript before you deploy that
micro service with a Makefile

------
anupshinde
Awesome, took me like less than 10 minutes to create a basic server side
newsreader app with React. Simplicity of PHP and power of React combined and
brought to Node. I also like how the consolelog statements are shown in dev
console

------
partycoder
Having to put your program in a string makes it hard to edit. Syntax
highlighting, static analysis and tooling in general that helps you filter
problems might not work there.

To me, tooling is very important since software is more
consistent/reliable/productive at simple repetitive tasks like matching
parenthesis, braces, quotes... and in my case I take it further like
documenting types via documentation tags and verifying that function
signatures and return types match. That alone helps me save a lot of time once
the code has grown over 1 kSLOC.

I think it should be replaced to just a filename that gets required.

------
NickLamp
Can someone explain to me why this page uses 2 GB of memory on my machine?

------
jonny_eh
This looks so incredibly well thought out and designed. I can't wait to start
using it!

------
the_duke
Very intriguing concepts.

Especially for quickly prototyping an idea.

Getting a React project in place (webpack config, code structure, all the
boilerplate, redux,...) swallows quite some time. And I haven't found a
bootstrapper yet that I liked.

~~~
i__believe
Have you looked into electrode.io? It's the total package with testing, server
side rendering, optional above-the-fold rendering, profiling, etc.

It took about half a day to get used to it, but I enjoyed not having to make
the decisions over and over again and handles the basics as well as advanced
use cases.

~~~
alexgrigoryan
Thanks for the support! I'm glad you like it! :D

~~~
i__believe
It's been really great, and reporting issues and small pull requests has been
super easy so far. Not really what I expected from a company like walmart so I
was pleasantly surprised.

The only fundamental disagreement I have with it is how the "client" folder is
organized by default. I think it's a mistake to organize by the type of file
(component, reducers, etc). Instead, the organization should be centered
around the real use (pages, resources, etc.) Explained in more detail here,
[https://medium.com/@alexmngn/how-to-better-organize-your-
rea...](https://medium.com/@alexmngn/how-to-better-organize-your-react-
applications-2fd3ea1920f1#.b5kwopbho)

I understand that's personal preference, and my preference is born out of
seeing more than one react app become a tangled mess because isolation was
hard to understand based upon file structure.

------
cerved
[Placeholder for complaint about JS fatigue]

------
desireco42
I am really not into new frameworks, quite the opposite, but this is cool and
I can see immediate value of this approach thanks to gif movie on the
homepage.

Thank you for making this.

------
applepple
How is this different from Meatier
[https://github.com/mattkrick/meatier](https://github.com/mattkrick/meatier)?

Meatier also uses Babel, React and Node.js except that it has been around for
almost a year and is already stable. They've already solved all the difficult
issues like realtime pagination, authentication, GraphQL, etc...

~~~
lucideer
I haven't really looked into meatier in great depth, so correct me if anything
I say is a false assumption.

Meatier, as the name suggests, seems to be fundamentally "meatier" than
next.js. It's coming from the same monolithic mindset as Meteor, and despite
leading with the intro "... but without the monolithic structure", the general
architectural thinking still appears to reflect that.

It makes a lot of decisions for you (express, rethinkdb, graphql, redux, etc.
- it's production dependency list is gargantuan). You've phrased this as
"they've already solved all the difficult issues", but many may see it as
"they've removed a lot of choice and flexibility". It's a matter of
perspective: the meatier docs do admit it's "overkill" for certain
applications.

Next.js, apart from the inclusion of glamor, seems to pretty much largely
leave you to your own architectural and library preferences.

~~~
applepple
Every component in Meatier is replaceable. The defaults are for convenience.
It sounds like Next.js also makes a lot of decisions for you.

------
jondubois
This sounds great for static websites but I'm not sure if it's a good idea for
a dynamic web app where data needs to update on the screen in realtime. Some
questions which come to mind:

What if you had a 'chatbox' component which updated every time a user wrote a
message; would Next.js have to resend the entire HTML for the 'chatbox'
component (containing the full message log) every time a message is added to
that chatbox? Am I right to assume that only the affected component will be
rerendered? Or the entire page has to be re-rendered (and the entire HTML of
the page resent over the wire) for every change in data?

It sounds like a nightmare for caching: If data is updated dynamically and you
constantly have to rerender components in realtime on the serverside; you
can't really cache every permutation of every component's HTML for every data
change and for every user... That's insane.

Regarding CPU, it sounds like it's going to eat up server-side performance and
increase hosting costs massively! What, like 10 times 100 times? Are there any
benchmarks done on performance for a typical single page app built with
Next.js?

Then there is the latency issue...

Finally; if we move back to full server rendering and get rid of the need for
client-side code; why would we want to stick to JavaScript?

I haven't used it yet so please correct me if I'm misunderstanding something.

Next.js sounds great for building static websites... But so does PHP!

~~~
rockmeamedee
The way it would work with your chat example is that Next.js would initially
render the chatbox component on the server, then hand it over to the user's
browser running the React component. Then the user's browser would subscribe
to data updates, and would create/update/destroy components as needed as chat
messages come in.

The server only sends rendered components once, then the client handles the
re-rendering afterwards.

It's still a javascript client-side SPA, except the initial rendering is done
by the server. You don't see a loading screen, google can crawl your page, and
users can see an initial page with JS turned off).

I hope that cleared things up a bit.

------
oelmekki
I love the addition of async `getInitialProps` (more for being async than
getting props, would be as fine for me as getInitialState).

The logic for rendering loading screen in a component can quickly get tedious
and annoying, such a pattern helps having a global loading screen and still
allow the component to be responsible of how to fetch its data.

------
alistproducer2
Am I wrong in saying the appeal of this tool is it allows you to process your
React app (with little or no changes to accommodate it) on the server?

I've been reading a lot about SSR lately. Correct me if I'm wrong, but wasn't
one of the points of thick clients to offload processing to the client?

~~~
lucideer
I don't believe so, though I guess some do. The purpose of (well-written)
"thick clients" is to provide real-time interactivity and reduce bandwidth.
Beyond this, if something can be done on the server without degrading the app
experience, it probably should be.

Added bonus if the site works fine without client-side JS at all (which
Next.js does)

------
avodonosov
Airbnb blog post from 2013 how they share code between client and server:
[http://nerds.airbnb.com/isomorphic-javascript-future-web-
app...](http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/)

~~~
gt2
While that article may be relevant, I think the OP is noteworthy is because it
is a framework, rather than a novel idea.

~~~
avodonosov
Sure. I just wanted to share this real-world example of the "isomorphic js"
benefits.

------
sametmax
Using the filesystem as the API has been done before, and there is a reason we
stopped doing it.

~~~
rdrey
Your comment would be more useful if you gave us that reason.

"Filesystem as the API" in this case looks more like "convention over
configuration" (which has worked fine for other frameworks like Rails), it
doesn't actually seem to be using the filesystem as the only storage backend.

~~~
nilliams
Don't really agree - what they're doing is very different compared to what,
for example Ember does (which they call 'convention over configuration').

Next's routing is much more similar to Jekyll's which quite literally is based
on your filesystem file-organisation.

~~~
rdrey
Ah, I see what you're saying. I didn't consider deeper/complex routes with
parameters.

This scheme seems to force route parameters into query parameters.
Disadvantage: It's not RESTful. Advantage: Your route parameters are now named
query parameters. You only handle one dict of parameters...

I'm not sure how I feel about this.

------
Raphael
Is there a reason the files are ".js" rather than ".jsx"?

As it stands, my text editor defaults to the JS syntax highlighting. I suppose
one could make JSX their default JS syntax, but then JSX would incorrectly
appear to be correct in non-React files.

~~~
nilliams
I don't think many have embraced the .jsx extension.

And arguably it doesn't make a lot of sense, because when working with most
modern frameworks/libs, JSX is not the only non-standard-js element in the
file. Should we call it .es6, .es2015, .es2015+jsx ?

So yeah, sticking with .js is common.

~~~
TazeTSchnitzel
ES2015 is standard JS. Maybe not widely deployed, but it's standard.

JSX is not.

------
johnhenry
Similar: [https://medium.com/@pierceydylan/isomorphic-javascript-it-
ju...](https://medium.com/@pierceydylan/isomorphic-javascript-it-just-has-to-
work-b9da5b0c8035#.6ugq1n2eo)

------
ranyefet
This looks absolutely great! Looking forward to try it out soon

------
ivan_ah
I like this uses the filesystem for the website structure. It reminds me a bit
of dokuwiki. Very usable + easy to understand compared to configuring routes.

------
robertmwm
Very nice, definitely excited to try this out!

------
ej_campbell
I don't understand why you need any client side framework. Couldn't this all
be accomplish server side with the HTML pre-fetched on the client if needed
for performance? There isn't anything dynamic about the website so it could
run with zero javascript and then things like the back button after scrolling
through the blog would work.

Why try to outsmart the browser?

~~~
izym
Sure it could. But this is also about providing a better user experience.
Being able to automatically split the bundle into parts, the most needed of
which is loaded at first and the rest then loaded afterwards in the background
using a service worker, means that navigation will be far more snappy and
provide better feedback to the user. Rather than waiting for the HTML to be
downloaded when a link is clicked, most of the UI can be displayed while a
smaller payload is downloaded. Obviously if your content is 100% static and
your target group is people who only have 2G available, this might not be the
best choice.

> then things like the back button after scrolling through the blog would
> work.

What do you mean?

> Why try to outsmart the browser?

Not sure how this is outsmarting the browser.

~~~
ifdefdebug
>But this is also about providing a better user experience.

Breaking the behavior of my back button is one of the worst user experiences I
get these days. Usually it makes me so angry that I just leave the site right
away.

> Rather than waiting for the HTML to be downloaded when a link is clicked,
> most of the UI can be displayed while a smaller payload is downloaded.

Browsers can do that on their own since forever, given a carefully crafted
HTML page. Of course there are use cases where that is not enough, needing
some load-on-scroll mechanism or something like that, but it gets abused all
the time for things a browser could handle so much better (with proper HTM of
course) - blobs, newspaper articles etc.

~~~
cerved
How do you leave the site if the back button doesn't work??

~~~
ifdefdebug
I press home, of course. At least sites can't break that button.

------
kelvin0
So if I understand correctly, this would 'transform' Node into a web framework
à la Django? Please correct me if I misunderstood. If that's the case, how
Node-Server-Render will compare to Django,Flask and other Python web
frameworks?

Performance better on Node? Feedback from the trenches would be appreciated.

------
antarrah
It loads pretty fast but the source code is not search engine friendly.

~~~
cschep
huh?

~~~
antarrah
view-source:[https://zeit.co/blog/next](https://zeit.co/blog/next)

Google bots do not view this rubbish favourably.

~~~
dinedal
[https://search.google.com/structured-data/testing-
tool/u/0/#...](https://search.google.com/structured-data/testing-
tool/u/0/#url=https%3A%2F%2Fzeit.co%2Fblog%2Fnext)

The Structured Data Testing Tool doesn't complain.

We'd need someone to try it out and get the results of the other Google Search
Console tools to know for sure, however.

------
Kiro
glamor looks interesting. Has anyone used it?

------
john111
Off-topic, but what process are people using to make these animated demos? The
command-line and browser demo on this page is so clean and crisp. Is it just a
screen cap with a ton of post-processing, or is there more to it?

~~~
tolmasky
We released DemoKit last week to do precisely this (be able to script demos
and record them, that way you can easily re-record them if your product
changes, or if there's a typo, etc):
[http://blog.runkit.com/2016/10/18/introducing-
demokit.html](http://blog.runkit.com/2016/10/18/introducing-demokit.html)

------
jgalloway___
I left [https://zeit.co/blog/next](https://zeit.co/blog/next) open in Chrome
over lunch and when I came back the tab was out of memory .. so you guys will
probably want to look into that. But otherwise A++

~~~
Rauchg
I wonder if it's related to the animated gif? I've had it open for many hours
as well, and it looks like this:
[http://i.imgur.com/E05vChB.png](http://i.imgur.com/E05vChB.png)

~~~
dredds
Process of elimination and a dozen restarts.

It's not the gif OR the svg (individually) but somehow both together are
causing it. I'm on Win7 with 2 gig ram and scrolling this (see pastebin) up
from the bottom causes cpu to jump and memory near 1 gig with hdd looping
endlessly, so i have to hard power off just to recover any function.

[http://pastebin.com/AMdhpWcn](http://pastebin.com/AMdhpWcn)

~

------
TeeWEE
Javascript development on the web has become such a mess... Web apps are
totally bloated, tons of javascript loaded, server side rendering for search
engines. Mixing css HTML and javascript together to have a component framework
that actually is run within javascript... Not within the browser engine... Its
library on top of library on top of library.... Really..? W3C should come up
with alternatives, that also work as mobile apps... The web has become an
overengineered mess.

