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)?<p>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.<p>That said, these are next steps; the first release is all about showcasing the fundamental architecture, and it's looking gooood :D
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 <a href="https://zeit.co/blog/next#data-fetching-is-up-to-the-developer" rel="nofollow">https://zeit.co/blog/next#data-fetching-is-up-to-the-develop...</a><p>But what if my component looks like this:<p><pre><code> 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 }
}
}</code></pre>
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!
I like how they use the tags <details> and <summary> in their FAQ!<p><a href="https://github.com/zeit/next.js#faq" rel="nofollow">https://github.com/zeit/next.js#faq</a>
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.<p>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.
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!
I'm very impressed that middle-click/ctrl-click works flawlessly. That's increasingly becoming a rare thing on the web these days.<p>Forward and backward navigation only works up to one level. Is that a limitation of the framework or an intentional design choice?
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.<p><a href="http://intercoolerjs.org/" rel="nofollow">http://intercoolerjs.org/</a><p><a href="https://news.ycombinator.com/item?id=12657565" rel="nofollow">https://news.ycombinator.com/item?id=12657565</a>
This looks very nice indeed. I've also just discovered glamor[1] via the Readme, which looks similarly nice.<p><a href="https://github.com/threepointone/glamor" rel="nofollow">https://github.com/threepointone/glamor</a>
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
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.<p>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.<p>I think it should be replaced to just a filename that gets required.
Very intriguing concepts.<p>Especially for quickly prototyping an idea.<p>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 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.<p>Thank you for making this.
How is this different from Meatier <a href="https://github.com/mattkrick/meatier" rel="nofollow">https://github.com/mattkrick/meatier</a>?<p>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...
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:<p>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?<p>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.<p>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?<p>Then there is the latency issue...<p>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?<p>I haven't used it yet so please correct me if I'm misunderstanding something.<p>Next.js sounds great for building static websites... But so does PHP!
I love the addition of async `getInitialProps` (more for being async than getting props, would be as fine for me as getInitialState).<p>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.
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?<p>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?
Airbnb blog post from 2013 how they share code between client and server: <a href="http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/" rel="nofollow">http://nerds.airbnb.com/isomorphic-javascript-future-web-app...</a>
Is there a reason the files are ".js" rather than ".jsx"?<p>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.
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.
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.<p>Why try to outsmart the browser?
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?<p>Performance better on Node? Feedback from the trenches would be appreciated.
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?
I left <a href="https://zeit.co/blog/next" rel="nofollow">https://zeit.co/blog/next</a> 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++
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.