Next.js 2.0 | Hacker News Reader

Next.js 2.0

zeit.co

627 pointstbassetto217 comments

Open articleView on HN

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

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

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

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

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

I wouldn't say it's the top benefit but it is a benefit indeed! You don't have to worry about setting any of those up unless you want to customize them. You shouldn't have to because they come with sane defaults (i.e., Babel has support for latest ES and the Webpack config takes care of everything for you).

For example, the only custom change we had to make was to add Webpack's `DefinePlugin` to expose `.env` variables in the client. It was extremely easy though (3 LOC) and we didn't need a full Webpack config.

See: https://github.com/zeit/next.js#custom-configuration

It's why I use it. I can build my own Webpack configs just fine and have done for a long time, but I just don't want to do it anymore.

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

Does this require node.js as a server?

How does the page-based router deal with routes like /things/123/subthings/456?

Typescript?

> Does this require node.js as a server?

Yes

> How does the page-based router deal with routes like /things/123/subthings/456?

It doesn't, you have to use the programmatic router for that.

> Typescript?

Don't believe so, see this comment in this thread: https://news.ycombinator.com/item?id=13968723

There is a typescript example on their page:

https://github.com/zeit/next.js/tree/master/examples/with-ty...

>Animation transition between pages is still being worked on

check out react-overdrive[1], which is also referenced in issue#88 but deserves to be mentioned here imo. The author provides an example[2] what overdrive looks like based on the instagram example[3] from next.js.

[1] https://github.com/berzniz/react-overdrive

[2] https://nextgram-overdrive.now.sh/

[3] https://nextgram.now.sh/

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

I confirm, the video is too big

We're on it, thanks!

The size is much smaller.

As for downloading multiple times: I don't think it's happening though it looks like it.

The server is sending 206 Partial Content for the video. This is why the file downloads multiple ranges if the page is left open for a while. The first response if for a chunk of the file. The next few are for different chunks. Then it repeats.

~8 Mins on the page and I have 5 downloads of the hello-world_2.mp4 that went to the server. I have 4 that were able to be served from the disk cache.

It really is a sad state of affairs that this is unsurprising.

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

Devtool doesn't impact caching.

Unless, of course, you have the "Disable cache" checkbox enabled.

It does when you click "Disable cache" (and maybe forget to turn it off). But it doesn't appear to affect this, at least.

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

Not just that, also rather large fetch (AJAX) requests to get all of the JavaScript, or so it seems: https://urlscan.io/result/36f1ada1-a7d1-4b4f-8e65-8269135e10... (gotta be a new record for initial page load size)

Thank you @jonknee.

https://twitter.com/rauchg/status/846474015178866689

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

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.

It is most excellent. Great little intuitive routing convention, plus plays well with express

nuxt is great but I'd wait until the 1.0, which I would guess is coming in a couple of months. it doesn't support response streaming yet, and a few other things that may have been addressed since I last looked..

Next is great. I would love to deprecate my SSR starter kit - 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.

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

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?

Yeah, to me it reminds me more of a react-only Meteor without the baked-in DB

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.

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

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.

You can use Next.js to do server-side only rendering. It uses React idioms for rendering in favor of vanilla templating

Not exactly the same, but what you describe is similar to the concept of components in Pragma (a project I'm working on).

I will write a more detailed post when it's ready for release. Meanwhile you can check the "How Pragma works" in the intro blog post http://www.laktek.com/2016/11/29/introducing-pragma/

I think you miss the point of having Next.js being based on React. Although I think handlebars/htmlbars are great (I'm a big ember user), the cool thing about React is it's component based. So pretty much everything you mentioned above, replace BarsHtml to react components, you have Next. However, the react components though in my opinion is much better than handlebars. It is more powerful, more flexible and at the same time more disciplined.

Take a look at http://markojs.com/ and 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.

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

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

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

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

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

If anyone wants to see, we are using next.js 2.0 on 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!

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.

In the 2000s we used ASP.NET webform user controls and java struts in a VERY similar approach to what react calls a "component" which is great because concepts such as composition and event percolation come naturally and make a great amount of sense (to me).

There were many developers who were raised to strive for segregating logic from display (keep your js away from your HTML) and that MVC was a universal solution to front-end development. From what I've seen angular does these things very well and feels more natural to teams where this mindset is well-established.

> any technology that speeds up development cycle time is an improvement.

The problem is that for many, react does not do that – because you need npm, webpack, babel, systemjs, and so on and so on.

We come from a world where you have a simple .gradle config file, and you press one command, and it installs and everything just works.

No need to configure thousands of transpilers, no need to handle constantly breaking dependencies, because people keep their API stable for years, some even decades (see Bouncycastle, e.g.), etc.

Coming from this style of development where tech actually works well, and is stable, to the JS world of React where everything constantly breaks, is very complicated and over enterprise-ified, etc is quite annoying.

Obviously, on the other hand, the React world provides other massive advantages, such as quick iteration, innovation, etc – but the work to get something working with constant quality for years is entirely different. Because you’ll have to fork all your dependencies, because those won’t be stable.

So if you want your product to be included in Debian Stable, you don’t want to use React. Because you’ll end up forking and maintaining every single of your dependencies-.

> The problem is that for many, react does not do that – because you need npm, webpack, babel, systemjs, and so on and so on.

This couldn't be further from the truth. And besides, create-react-app solves that.

> No need to configure thousands of transpilers, no need to handle constantly breaking dependencies, because people keep their API stable for years, some even decades

I have been using react since early 2014, back when it was still very early pre-release. I have had to change exactly one thing w.r.t to the react API. When we decided to add in webpack, again, I had to change exactly one thing there as well -- I switched to a .babelrc file and they included the react transpiler by default.

> And besides, create-react-app solves that.

Until something breaks, and you have to go through all the configs and try to fix it.

I’ve seen https://kukuruku.co/post/hello-real-world-in-php-in-2017/ far too often.

I think your comment is touching on two different points, in my view.

> Until something breaks, and you have to go through all the configs and try to fix it.

This is solved by understanding the language and the tools you are using. I see so many people screw up a react app because they don't know javascript. They take the same smorgasbord approach to languages and tools they have used in the past (like jQuery) and apply it to react. React is really a frontend framework for javascript developers, not a frontend framework for creative types (like Misko originally slated angular to be) If people would just take the time to learn the actual language they are using, it would make these other tools easier to grok. This is software development. It is suppose to be hard. Take the time to learn your tools.

> I’ve seen https://kukuruku.co/post/hello-real-world-in-php-in-2017/ far too often.

I always wonder why people elect to use a heavy set of opinionated tools to solve simple problems. I understand the point the blog post is trying to make, but again, it's like taking a highly set of specialized tools and complaining when it is difficult to do the simple things, when all you needed was a hammer. React is a UI library first and foremost. You can take it, inject it into your page, and use it. You shouldn't add the bells and whistles until your complexity grows to the point where it makes sense to use it. I tell people to ask themselves this question all the time, "Are you sure you need flux?" Stop and ask that question. Can this be solved by just maintaining state on a top level component and passing down props? Do you need codesplitting and chunking and the advanced features of webpack? Or do you still operate in a traditional way where designers hand of their templates to coders to create the html and css and you are just tasked with writing the javascript? Then don't use webpack loaders. Use your coder's classnames on your components.

This is people making things harder than they have to be. But again, all of this is really not that difficult if you take the time to fundamentally understand javascript.

One of the big issues I see with JS is a bit of an abstraction problem.

See, in the Java world, lambdas were introduced, and I can write code with them using RetroLambda, and it will run on old JVMs, too.

But Java 8 has them natively.

And I can write a modern Java8 project with nano and javac. No transpilers, nothing.

While in the JS world, even now that browsers are starting to support ES6, everyone just adds more and more steps to the build process, instead of trying to simplify them.

Ideally, if I write code, I want it to be simple, without any such tools.

I want to be able to write one file containing dependencies, my code in a few files, execute one command, maybe two, and have a fully working product. And have it work for years, even while dependencies update.

One config, one command, and my code. Not any single LOC or invocation more.

That’s doable with JS – you just need a dependency format where dependencies can define macros over the language, and they’re handled by a transpiler or compiler, and you can import them normally. And just like that, a lot of this stuff would go away. TypeScript would just use its own frontend to the transpiler, and in your config you’d just define a different plugin.

In the gradle and java world, all that exists, with language-plugins, and annotation processors.

Yet in the JS world, it’s not like that, you have dozens of abstractions on top of another.

> This is solved by understanding the language and the tools you are using.

The problem is that the JS world is simply more complex than the Java world.

A helloworld JavaFX app is about 30LOC of config, and 20LOC of code and imports. And compared to a production JavaFX app, no more config will be added. It’s just that. That’s all you need. And easy to understand.

For React, it’s an entirely different beast (see the mentioned link)

> While in the JS world, even now that browsers are starting to support ES6, everyone just adds more and more steps to the build process, instead of trying to simplify them.

To build on your Java comparison -- this is would be akin to using a new feature that is still in the JSR approval process, and then downloading an edgey JVM platform (maybe OpenJDK nightly, or something like that) and then complaining when your app gets more complicated. The solution to that problem is to stick to the stable syntax until the new becomes fully supported. Admittedly, this is a problem with browsers where instead of 1 environment, there are 8 with some 1 offs, but again, there is IBM JDK, OpenJDK, Oracle JDK, Android Java (whatever that's called, Dalvik or something?)

> The problem is that the JS world is simply more complex than the Java world.

I strongly disagree. Have you seen "enterprise fizzbuzz"?* I don't mean disrespect but you are kidding yourself if you think Java isn't as complex (if not more) than the current JavaScript ecosystem. I spent 6 years programming in Java and never felt I scratched 10% of the surface.

* https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

> I strongly disagree. Have you seen "enterprise fizzbuzz"?* I don't mean disrespect but you are kidding yourself if you think Java isn't as complex (if not more) than the current JavaScript ecosystem. I spent 6 years programming in Java and never felt I scratched 10% of the surface.

But that’s the point. That’s all just code. Just normal code. Not additional command line utilities. Even Enterprise FizzBuzz can be compiled simply with gradle or maven. No processors. No transpilers.

> To build on your Java comparison -- this is would be akin to using a new feature that is still in the JSR approval process, and then downloading an edgey JVM platform (maybe OpenJDK nightly, or something like that) and then complaining when your app gets more complicated.

But I can do that. And I just have to import one single plugin – https://github.com/evant/gradle-retrolambda, and never configure it! Nothing to configure, nothing else. One import, and I’m done.

Look at that fizzbuzz enterprise build.gradle, it’s 29LOC!

The problem of "good defaults" was never even considered in the JS world, it seems.

Again, this is not a good example of why the javascript ecosystem is worse / java is better.

> But that’s the point. That’s all just code. Just normal code. Not additional command line utilities.

First, Maven does not come standard with java. Second, in a previous reply, I mentioned that if you are not comfortable with the latest and greatest, then stick to the current standard. There is nothing wrong with that, and you can be productive. If transpilers and babel seems too scary to you, which given you mention maven and gradle I assume not, then don't use them, use polyfil, which is just like that retrolambda you linked. Most all of ES6's features are sugar anyways.

Your intimate knowledge of tools and frameworks for the Java ecosystem will not equal another. What's a plugin? Ohhh you mean OSGI? No? Oh well I am lost.

What is gradle? Oh it's a new build tool? Well sorry I only know ant, and my coworker uses sbt. He's hipster like that.

> The problem of "good defaults" was never even considered in the JS world, it seems.

touché for java.

Which is why both the Ember.js project and Angular 2.0 have a cli now that provide standard commands for development and a standardized structure. Of course, both are much larger frameworks than React and attempt to provide a complete solution for web applications while React is just a popular view layer.

I think you're over simplifying the gradle solution though. I know when I did java in school, it was not easy. There was a fair bit of configuration. Getting glassfish or tomcat to work with eclipse was a challenge. Gradle has definitely helped this a lot, but you still need to know how to configure the gradle script if you need to change something.

You're right in that JS tools do need to get stronger, and over even the last 2-3 years they have. I haven't had mine "constantly breaking", generally once you build a new application and set it up with your standard dependencies. Like an ORM, what ever server middleware, test frameworks, utility libraries, etc. It tends to be pretty stable, unless you try to upgrade something years down the road.

Not a React guy, but there is lot's of hyperbole in here. Not sure how npm, webpack, babel, "thousands of transpilers" et al slow you down. They're tools that do things so you don't have to... Are you seriously saying that hand converting ES6/7+ to running ES5 would be faster than babel? Hand bundling/splitting of code would be faster than browserify, webpack? Hand finding, curating, tracking of dependencies would be faster than NPM? mmk.

> Are you seriously saying that hand converting ES6/7+ to running ES5 would be faster than babel?

No, that shouldn’t even be a thing. All runtimes, worst case, should be maybe 6 months behind the standard, otherwise I’d want to use a single transpiler.

Going TypeScript -> ES7 -> ES6 -> ES5 is insanity.

> Hand bundling/splitting of code would be faster than browserify, webpack?

Why should that even be necessary? Upload your code file by file, and actually use the browser’s required, or have one single script implementing this as polyfill. Why should I even have to do this?

> Hand finding, curating, tracking of dependencies would be faster than NPM? mmk.

No, but NPM’s tracking is useless when dependencies constantly change their API with every release.

I’ve got so many dependencies via NPM that even change their name and API constantly that many of my projects have been broken after just a year, but all after max 2 years.

I’ve got Java projects that are 5 years old and every dependency is still update, with a stable API.

I'll be completely honest. I was anti-react when it initially (this is pre-create-react-app generator) came out and I'll tell you why.

I tried to learn it and struggled understanding the new concepts react was bringing in all while people were saying "It's easy! Everything's a components. HTML,CSS,JS all in one place!" whilst I was struggling to get a simple hello world example to run.

Just recently at my University we were forced to learn React as a part of our course and damn after I finally understood it I fell in love! It's a huge improvement over the normal web-app design work flow.

So, I would urge anyone whose anti-react to honestly give it a good go and force yourself a little to get over the initial learning curve and trust me you'll love it!

Any tips for getting over the first hump?

Be forced to learn it evidently.

I could write a long list of things you should probably do but if I could recommend just one thing it would be to watch this video https://www.youtube.com/watch?v=xsKYAa1ZXpQ it really helped me to understand how react works.

Think of it as a way to create your own complex HTML controls like the combobox/select. And just like those, try to give all information it needs to work via attributes or sub-elements.

If you like component approach, take a look at Polymer, I'm right now working with react, and while it is OK, I've found that web standards based approache to components is better. And web components can be used in react or other solutions nicely.

Being "anti-react" doesn't mean anti-component approach. You can do same with angular 1.5+, vue, aurelia or others.

That's a good point. I don't think many people actually dislike React. There are people like me who might be mildly frustrated that React is getting so much attention when Vue.js and Polymer might be better, simpler solutions.

I like React (especially with all the new setup and debugging tooling) but whenever I use it, I feel that it is a small step down from Polymer.

I think that unfortunately Polymer 0.5 was launched too early and its reputation has been tainted even though Polymer 2.0 is amazing.

I do know that there are also developers in the Vue.js camp who would never use React out of principle. I spoke with HR people from Facebook in the past and they've told me that there are developers who simply refuse to use React but I think it's more a matter of stubbornness because, all things considered, it is roughly comparable to Polymer and Vue.js.

Is polymer really a Web standard? Seems like something Google is pushing down. The implementation is quite fragmented.

I'd love browser makers to focus on the basics like rendering, js and asm.js and leave the rest to libs.

No - Polymer is not a web standard - Web components are (https://www.webcomponents.org/specs) - and are implemented as a standard (its not fragmented all vendors agreed on v1.0, chrome, safari, opera already ship with them, MS and FX are close to follow) - polymer is just 30kb on top of that to make your life easier. This is exactly what you described with asm.js.

It just happens that out of all libraries that help you create web components, polymer is probably most widely used - well, angular 2.x can technically output web components too, but I don't want to compare a framework with library. But you can mix those components with other solutions (like x-tags, skatejs, bosonic, "pure components" etc.), they are interoperable, I even have them cooperate with legacy jquery application.

In the context of Next.js's serverside-rendering approach, Polymer has an open ticket about providing support for SSR: https://github.com/Polymer/polymer/issues/3955.

In my experience, a LOT of developers learn that React is a good framework because (a) it's component-based, and (b) the virtual DOM. So my guess is that a lot of developers hear the lines "React is the V in MVC, it has components, it has virtual DOM," and since those words don't really mean anything, they just dismiss it right away.

In my personal opinion, these reasons are superficial: the reason to use React is that programming UIs declaratively is easier to reason about than imperative UIs. That point can be subtle. It helps to have worked on (and struggled with) an imperatively-programmed UI before you can see how much of a pain it is. And it didn't help that out of the gate, React was pitched with "components" and "virtual DOM," and it took a while for even Facebook to be able to communicate what was so compelling about it.

I have writtern imperative UI in iOS, jQuery with server templates. I love react for its declarative UI, but when people ask how it differs from angular 2 or ember, I don't have an answer. I tried angular 1 ages ago, and left it.

Any concise answer on how react's declarative UI differs from a 2 way binding approach in angular (or if they have changed it that)?

Same, the people who are crazy about react are often the people who never understood MVC originally, writing terrible apps in older frameworks like Backbone with jquery code shoved into the render() function and the model event system used as a global pub-sub for everything.

React's virtual DOM is a hands off implementation detail that forces understanding of MVC. People can't asks= "How do I put the thing in the place", b/c that's automated by the virtual DOM. Instead, they are forced to understand that they need to describe the end state. Which is something that even an older framework like Backbone tried to do, with the end state being you only having to care about your models with the rendering automated.

Progression of (frontend) MVC started with Backbone, with manually wiring up models and view render functions so that the model changes could drive the UI. It's a specific implementation of pub/sub with the published events being a certain set of model changes. (add/change/delete/...)

(Redux is pub/sub with a security guard logging your actions and only giving you specific vetted actions to combine. Also, functional goodness.)

Angular 1 went with a polling approach that negated much of the boilerplate in backbone but was not performant (and bad docs, new things to learn, etc..) but also showed many people a cleaner paradigm of writing UI code. The trap with angular was putting everything in the controller just like the trap with backbone was putting everything in the render function.

React uses a virtual DOM so the thing to render doesn't need developer input. It's automatically inferred from the DOM diffs so the developer can focus purely on describing the UI. This is the forcing function that forces people to put down jquery and actually learn MVC.

Once this is understood, you can get into managing more complex models that actually mutually affect each other that may necessitate something like Redux. (Also, somewhere along the way, OOP become unpopular and functional stuff became hip)

JSX btw, is just an extension of javascript to create DOM elements in a less ugly way. Angular and Vue went from the other direction and extended HTML to support javascript functions. It's "<div v-for="a in apples">{{a}}</div>" vs apples.map(() => <div>red apple</div>)" It's personal preference in many ways. (You'd actually need to know a fair bit of functional js though to write concise non-ugly JSX that doesn't bury the meaning of your UI description)

The main issue I have with react is that it seems much more like a lifestyle than a tool that gets out of the way. When people list out their reasons for liking react I'm mostly just hearing "because facebook, facebook, cool, cool, facebook" just like angular was driven by google before the angular 2 marketing fiasco.

And there IS truth in it. The background philosophy driving React is actually a philosophy of functional programming which has real merit. In the real world though, with many people knowing only how to use jquery, React may help you explain to them how to understand MVC, but you're going to have a much more difficult time shoving the functional lifestyle that comes with it down their throat. But hey, if you're in the facebook sphere of influence or want to be a part of it, go for React. (Also, if you're a new grad who doesn't have the baggage of jquery)

Paradigm shifts often take a much longer time horizon than expected and often require an "earthquake" for newcomers to upset the established ideas. React and Typescript were in background mode for quite a while. The non-backwards compatibility of angular2 drove people to React, and I think Java programmers getting into web development and Satya Nadella being cooler than Balmer gave typescript a good boost.

In the end though, I don't really want to be comparing hundreds of different hammers to build my house. I just want to build a house. And hey, hopefully I have more skills than being a builder so that when entire houses are 3D printed I can still find a way to justify my existence.

Also, don't dive in with Redux at first. A Redux-like tool is useful, almost vital to a web app built with React, but I had to build an app without state management to understand why I should have had used it.

> Where do these anti-React (anti-spa?) people come from

Are you implying that react-way is the only way of doing SPA-s?

> Do you think the web Peaked with Perl-based CGI-scripts

I think your comment is just rude. There are plenty of other options in the JS world - react is just one of them.

> Are you implying that react-way is the only way of doing SPA-s?

Pretty sure he's generalizing; i.e. "anti-banana? (anti-fruit?)"

I'd expect someone who is "in this game for many years" to know better.

It was meant as a polemic question, since the comments here seemed to be critical in a way that wasn't specific to next.js but more to the general space of spa's or even javascript. I see this a lot on HN, so I wanted to know if there were some constructive thoughts behind it. I sure didn't mean to be rude or anything! :)

The main reason that React is popular is because it is popular. I do not know where others come from, but I can tell where I come from: Web Standards Movement. There was such a thing some 15 years ago. People who cared about semantics, standards, accessibility. React is not bad. SPAs are not bad. That's bad is not having the understanding what should be SPA and what should not. Loading a couple of hundreds KB of scripts to show 1KB (ir you are lucky) of content is not OK. Alas, if you think that static (horror) or server-side generated (shock, horror) pages still have a place you will be brushed aside as someone who thinks that web peaked with Perl-based CGI scripts. Alas, a lot of what happens in web space now looks like inventing new solutions to the invented problems.

I know one anti-spa guy and his argument is that's basically reimplementing poorly things that were well implemented in rails without any obvious bemefit.

One data point :

Their Hackernews clone based on their own SPA framework is much slower than the plain old HTML site.

I was wondering about this too, but doesn't it have to get the data from the original site? The total network download is also many times the original at 233KB versus 11KB for Hacker News.

Also, we don't know what kind of server resources they use vs. HN. The initial weight of SPA is typically much more than "plain html" site, but that's the price you pay for client-side functionality. Also, there exist more lightweight alternatives for React, e.g. Preact.

It's a bad example and not representative as far as performance is concerned.

Those are two separate questions really.

React is another in a long line of Backbone, Angular, Durandal, etc. that ultimately just make stuff a lot more complicated for fairly trivial benefits. It dictates fairly complicated ways of doing simple things with long complicated tool chains that regularly break for obscure reasons that you can debug but ultimately it feels like you're simply wasting your life dealing with it. It's easy for juniors to make ridiculously complicated messes in them. They remind me of the good old days of RAD dev tools. "Oh so easy" they claimed.

And if you're any good, you can enhance traditional web forms and add the same sort of functionality without all the overhead, or complexity. Perhaps I simply have the benefit of over a decade of front-end dev.

As for SPAs, they still live firmly in the uncanny valley. They're poor versions of desktop apps, even desktop apps from the 1990s. Anyone claiming otherwise is simply delusional. Because of javascript and the DOM, they also tend to complexity, so that anything past a glorified to-do app becomes an absolute nightmare to code in.

I use Trello, Asana, Toggl, SendWithUs, etc., etc. They're all, well, a bit shit. All of them have really annoying niggles, fields you click and then might auto-save but might not. Poor desktop interfaces because "mobile first". Tabbing that doesn't work properly. Data that gets out of sync. Or they're sllllooooowwwwwwwwwww.

As for the reason React became so popular? This happened before with terrible frameworks. I may be a cynic, but it feels front end devs have got into some sort of mega-echo chamber where a new framework comes along and everyone jumps on to it because they don't want to seem out-of-date. The front-end world feels like it's in a strange kind of culture at the moment, a type of Emperor's New Clothes, where if you're not using The Latest Framework, you're obviously not worth employing.

Not because it makes you get a product to market quicker. It's a new form of bike shedding.

As someone who works a lot with React — and have previously worked with things like Rails and Backbone — I adamantly disagree that the benefits are trivial or that it's more complicated. The functional component architecture makes it considerably easier to create less buggy UIs with less messy codebases.

You sound like you don't really know or understand React. Which is fine, but it doesn't put you in a good position to criticize it intelligently. React isn't popular because of any kind of echo chamber phenomenon. It's popular because of its design; it managed hit a particular very sweet spot combining the various principles of composition, modularity, functional purity and internally consistent state management.

I do agree that web apps aren't as good as desktop apps. But that's not the fault of SPAs.

I feel I'm in the same camp as the comment you're responding to, so I do want to chime in. Most of the applications I've had to develop require a database of some sort, rails makes this incredibly easy to do. I can simply generate a model and migrate. There are very few applications (that I've needed to develop) that don't require a reliable database. This is where I've yet been able to truly utilize anything like react, vue, etc. The best situations been some form storing json data objects but that's not scalable and I rather be able to backup a sql database to query from (especially with thousands of records). And I know facebook uses it and has one the biggest databases on the planet but I'm talking about easy of use in spinning up full stack applications as a small shop and understand what's going on.

I know you can use react on top of rails (with postgres, mysql, etc), but then I start feeling too many weird abstractions going on and have a hard time following the bouncing ball. React claims to be just the V part of MVC which is fine, but when I'm trying to quickly build up a full stack application rails just felt the simplest way to do so.

Bringing this up not because I think there is anything wrong with React and I know they are solving a pure front end problem, but this is more of a question to what's the most elegant full stack solution that would be comparable to RoR solution with any of these new hot js frameworks? If there is I think I'd be more than happy to startup some projects that way.

Easy: Write your backend as an API, and let the UI be a thin client that talks to it.

You can write your backend in Rails (or Sinatra, which we've used a lot) and use the same workflows to wire up models and so forth.

I wouldn't want to write database stuff in JavaScript. The frameworks are all terrible. Nobody has managed to replicate the ActiveRecord story for Node.js.

Except for legacy stuff (which use Ruby + Sinatra), we write our backends in Go. But that might not be your cup of tea.

We must just make different types of apps.

I work on a couple of startups at the moment, one of which that has an admin interface in a SPA, one doesn't. I can throw in new reports, functionality, etc. in the non-SPA one with less than 1/2 day's worth of work, sometimes even in minutes. The SPA one takes days to do similar functionality.

It's just all so bloody complicated getting it working together. Make a new end point, create a new DTO, make sure you're not leaking anything from the end-point, duplicate validation logic, wire up view models, have it not work completely for an hour or two of debugging because you forget to add one line to some gulp file or something equally ridiculous.

And then you throw in something like React and they want you to do it X way with Y thinking and Z plugin doesn't like you're returning the wrong content type or data structure or something but doesn't throw an error about it, logs it as some sort of warning, or if there is an error it's deep in the guts of 10 nested 1 line self-referential call in the library.

It just adds so many moving parts, functionality ends up sprawled over 10 different files, it's hard to grok or reason about, hard to know if you've done everything you need to.

I find it simply unpleasant to work in that way. I just want to write the UI and the logic and be gone, not dealing with frameworks barfing out bizarre warnings or mysteriously broken builds.

Actually, nothing fills me with more dread in a SPA than when I click a button or something and nothing happens. The worst problem programming in SPAs is when things simply just don't work and there's no error at all because you didn't quite invoke the magic framework in quite the correct way. Yay SPAs.

Having done both classical Rails apps and React, I still disagree that the classical way is somehow superior. You still have to do the same amount of work — wire up models, routes and such.

There are annoyances — occasionally we have to wrestle with NPM (though now that we use Yarn, the problems are generally gone), low-quality third-party libs, browser compatibility issues, etc. But it's just exchanging one set of problems for another. The React world isn't any worse than the Rails world there.

I get that some people get JavaScript fatigue and don't understand/are able to keep up with the new technologies. For those of us who are comfortable with the React way of doing things, it's fantastic. I have no difficulties reasoning about the code, nor with correctly organizing code into separate files (you don't always need "10 different files"; you have a choice!). React + WebPack + NPM modules beats the old way by a mile; I couldn't be happier. I have things to complain about, to be sure, but they're less about frameworks and more about the challenges that arise in a browser-based environment. Again, a different set of problems.

> Actually, nothing fills me with more dread in a SPA than when I click a button or something and nothing happens.

Something is definitely wrong here. This is not a problem I've ever had.

    > Something is definitely wrong here.
    > This is not a problem I've ever had.

Guess you always have good internet. If you truly can't identify with the parent comment or SPAs acting up, you might want to explore your own applications on slower internet.

I'd say most SPAs are clearly built with the latency of localhost in mind during development. Even Slack.

Even Google Translate is terrible on a suboptimal connection. It just seems to hang and rarely recovers when the internet comes back.

At least with server-rendered apps, when you click submit, you either timeout or hit a DNS resolution error, and the back button will restore your <textarea> from page cache.

It's never ambiguous. But SPAs usually require some more thought, like more deliberate "waiting..." UI between the time the user does something and the response comes back from the server. I know I have to.

I thought the parent poster was referring to his own apps, not others'?

It's trivial to provide progress and retry capabilities, especially if you're using Redux where you can build retrying into the reducer pipeline itself instead of reimplementing it for every use case. With React/Redux I recommend integrating it into a reusable component such as this:

    <ProgressStatus task={this.props.save}>
      <Button
        label="Save"
        onClick={this.props.dispatch(save())}/>
    </ProgressStatus>

Here, ProgressStatus is a high-level component that renders a progress spinner or similar if it's "task" is busy, otherwise displays its children. So the moment anyone clicks the save button, the save button will be replaced with a spinner. You can also build this directly into the button component and make it disabled while it's busy.

Of course a lot of SPAs are less great at dealing with slow/bad connections. I find Google's apps to be particularly bad at this.

It is "trivial", "easy", "simple". I've become increasingly distrustful of your view point as you've simply just kept replying to a load of different replies saying otherwise that everything's so easy, when it's not.

It's all adding extra complexity.

It's absolutely laughable for you tell people that a great solution is adding an API. Boom, extra layers of complexity. Connection problems? Add progress spinners! Progress spinners are yet another complication you have to constantly think around and with deal in SPAs, not something to be celebrated. And what do they actually do? Apparently you don't split your code up? I deal with 1500 line files in a project because of what came before, not splitting it up would be an even greater disaster.

It's beginning to sound like either you work on trivial month or two projects, or you don't work with other people.

There's no need to get nasty and personal. Of course I work with other people. I've been working on multiple (I'm counting at least 6) complex React apps for about 4 years now. Our largest React UI app is about 40kloc lines. Before that most of the apps I worked on were large Rails or Sinatra apps.

1500-line files are not desirable. My point was that you have to choice whether to split up files or not, exactly the same way that you would do in a non-SPA app.

The reason for using words like "trivial" isn't to belittle problems, but because these are solved problems. You describe them as though they're painful hurdles, and I simply disgaree.

Describing a component as "adding an API" is disingenuous, considering that it solves a problem and is — yes — trivial and completely reusable. You would have to do the same thing in a non-SPA application if you're submitting data to an API via XHR, of course; you also have to handle connection errors there.

If you're doing a "web 1.0" form that submits to a new page, it turns out modern browsers aren't particularly good as display progress or recovering from errors, either. I'd say the XHR/SPA approach gives a better UX here: In my SPA I can store a "draft" object to localstorage, display a nice progress spinner, show an error message and a "retry" button on connection errors, and recover the draft again in case the user accidentally lost the page.

If you put development cycle time over user experience you're doing it wrong.

Personally, I dislike that React is 100+KB file size, when Preact or Inferno can do 95% of what I want at with 3KB.

(Yes, I know gzipping exists but it's still huge by comparison, and JS parse time is a real issue on underpowered mobile devices)

In my experience, user experience suffers when performance considerations play too big a part early in projects. Like when forcing a server rendering tech on frontend developers and designers.

In my experience, many anti-spa people have seen too many poorly implemented single page apps (web fundamentals broken such as links and uris) and/or have out-of-date information that spa cannot properly support such things.

Cannot blame them, althought the situation is better nowadays, it's still not uncommon to find a spa site where the said things are broken.

I think you make a good point, even if indirectly. That is, the technology keeps changing but the products and experiences seem to remain subpar, frustrating, wonky, etc. Perhaps these technologies are progress from a pure technology POV, but if real end users were to judge what would they say? Are we drinking too much of our own Kool Aid? Still? Again?

I think the experiences are getting better. My first SPA projects were with Angular 1.x and for the whole duration that I was using it, I found that I could point out an Angular 1.x based site off of gut feeling / familiarity with certain pain points (hi Seamless).

I feel like there was a huge reduction in bug-prone madness when React + the Flux pattern started gaining steam. We are still collectively working toward an end (reliable software in the browser) but it's impossible for me not to feel the difference in the past few years, as a dev and a user.

SPAs are sort of a hack. The web was designed for documents that link to each other. Maybe they'll never be perfect until we reach some sort of impossible isomorphic framework utopia, but there is real progress being made

You might think that. As might I :)

What I'm suggesting is you ask your mother, father, grandparents,other developers, the person working the counter at the cafe, etc. Listen closely. I'm not so sure there's massive support to believe UXs are improving noticably.

Speeding up development cycle is not the only goal. Its not a good thing when it causes the user experience of the application to be worse. I think SPAs have come a long way in this regard, but it was definitely quite rocky for a while.

I'm one of the core-contributors of Next.js. We are not anit-React or anti-spa.

And we are pretty closely work with JS stuff. But Next.js is inspired by the simplicity of PHP.

### Anti SPA

The whole idea of Next.js is to build a SPA easily. But it's also server rendered by default.

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.

I very strongly agree with this. There are certainly web apps that can only reasonably be done mainly-client-side. I'd give Office 365 as a baseline example.

But what drives me crazy is sites like Medium [0][1]. It's a shared blog site. To read a one sentence essay on Medium requires downloading over a megabyte of data. And their comment system is still inscrutably terrible.

Content-focused sites should absolutely not be done as SPAs. Server rendered HTML and client-side enhancement will deliver a better experience to the customer and IMO a better developer experience as well.

[0]: http://idlewords.com/talks/website_obesity.htm [1]: https://medium.com/@mceglowski/chickenshit-minimalism-846fc1...

The page you link to on Medium renders after less than 100KB have been downloaded with an unprimed cache.

Javascript is not required to read it. Javascript is used to provide extra functionality outside of the download / render cycle, to speed the experience of the page up, and to make future navigation faster.

I understand where you are coming from, but you picked a bad example.

> Javascript is used to (...) speed the experience of the page up

That is one thing I'm totally not buying. How does JavaScript speed anything up over simple staticly rendered text, (which is what Medium should be)?

Optimistic loading / prefetching / etc -- the list goes on if you take the time to think about it for more than a second.

Used correctly, it can hugely speed up the experience by preloading things.

In an ideal case you could have a fast initial page load with static HTML. Then an async script tag quietly loads a script in the background while the user is reading (done properly, this can be imperceptible). Then when the user clicks a link, JS handles it and instantly updates the DOM and location bar, faster than would be possible with a static page load.

That's not usually the reality but it's definitely possible.

How is that faster than loading a single HTML template with the "dom" already rendered correctly by the server?

I think you missed this part

>Then when the user clicks a link, JS handles it and instantly updates the DOM and location bar, faster than would be possible with a static page load.

In the GP's example, the first page load is already rendered by the server. It's subsequent page loads that are rendered in JS.

..so you want to preload the content of every link on the page?

Because if it's just to display comments or something, I stand by my original statement.

That's a big revision of your original comment ;)

Speeds up subsequent pages accessed at least.

The related articles and comments are not rendered until after the page is readable. If they had to be rendered on the server, it would cause the article to take longer to be readable.

There's a lot of different caching and persisting strategies you could put in place to load comments or related articles quickly that don't involve entire HTTP round trips. There's a definite trade-off there (and a not insignificant one, especially on mobile)

Not to mention, HTTP2 mitigates a lot of this, without the downside of huge upfront downloads.

Yes, sources are packed pretty well, but there's still a lot going on for a blog article:

* 10 XHR requests on page load

* 3 downloaded fonts

* Continuous XHR requests as you scroll through the article

* ~400ms time spent executing javascript (according to timeline benchmark)

I'm not really sure why all those things need to happen to load some text in a blog article.

Does it stop downloading after that initial 100K? If not, then I think the original claim is a reasonable description. Reading one sentence will cause one megabyte of data to be transferred.

I second this. If you spend a lot of time on HN and other tech-minded forums (fori?), I think you could get the impression that just because you setup a web site, you must use MVC or some other JavaScript-heavy SPA stack, because such projects are of course interesting and intellectually challenging, and get lots of airtime when established, basic Web techniques are boring.

Of course MVC (React, Angular, ...) has its place for web apps and is great when it fits, but I think it's crazy and counter-productive to use complex and costly MVC frameworks for mere content-driven sites (like what most public websites are about).

React isn't MVC, it's component based, and even then it's just a view library. Also when I think MVC I think of non SPA web stacks like Rails or Django.

Fair point. Seems like you're not alone in understanding the term "MVC" like this ([1]).

[1]: https://medium.freecodecamp.com/is-mvc-dead-for-the-frontend...

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?

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.

Facebook is not a single page app. Most functionality is still powered by Hack (PHP).

SPA is certainly wrong for many things. Projects fail because people underestimate their implementation and something that could've been a web application without much state is a buggy mess that can't achieve liftoff.

Even when your application is not an SPA, some areas could still be SPA: editors, etc.

As a minor response, I actually think that the web app approach can be right for some blogs and "boring" content based websites -- if your goal is to lower user wait time or GUI latency, and if you're okay with making tradeoffs elsewhere (more data requested, heavier initial payload).

Why? Because after the problem of initial load, I think that further web requests are among the most expensive things you can do in terms of user wait time or latency, and that if you only start moving at the very time of user request, then it's too late to prevent a moment user waiting.

> a forum, why make it an SPA?

A forum is actually a pretty solid choice for an SPA, specifically the isomorphic react kind next.js sponsors. If you disagree or don't need the benefits, most existing forum software is already not an SPA, so no big deal. But a forum as an SPA can enable some more high tech forum solutions that may blur the distinction between forum community and slack community. Once the groundwork is laid out, who knows what kind of alternative architectures or plugins we'll see for it.

Also, when JS is disabled, the server will take you to the intended page and render it for you. Literally the best of both worlds.

Have a look at the D lang forums - which is written in D - statically rendered with very little JS and loads at _light speed_ to see why a forum shouldn't be a SPA. https://forum.dlang.org/

That's a big standard forum. Implementing it as an SPA would be silly.

Parent comment's point was that you could create different experiences that bring it closer to Slack.

I've been a heavy forum connoisseur for a very long time, I'm talking about interactive and application-level possibilities, not "fast because fast backend language". That forum looks like any other forum.

My biggest issue is that SPAs have a lot of overhead for your typical CRUD.

The canonical example: a CRUD page with a dropdown of choices based on entitlement.

Server rendered: in your template somewhere, {for choice in limited_choices} and so on.

SPA: you need to coordinate a REST endpoint that has options for entitlement of just this dropdown, etc. You now need a route for REST, a route for the SPA page, and view code for both.

Don't get me wrong, with unlimited time, build everything as REST services with a client that consumes it. But sometimes server-side rendering is just simpler.

SPA shines if you are building lots of CRUD. Rest end points are simpler and simply mush data out of the db. No templating crap.

It's a lot faster to load template once and re-render on client with different data.

Do you think the web Peaked with Perl-based CGI-scripts?

In some very important ways, yes. Specifically, it was still within the contraints of what HTTP and HTML were designed for: the transfer and rendering of marked up documents. Obviously all technology is x steps forward, y steps back, and you aim for some workable linear combination of x and y, but there have definitely been several regressions since the days of Perl-based CGI scripts, and I personally haven't found them worth the advances.

I very much like SPA's. It is mostly React that I have a problem with.

I don't trust their License Agreement when it states they can revoke your License for any reason. Basically, if I get on the wrong side of Facebook, they can pull my License for React without a warning.

Unless they have amended their license since the last time I read it. In which case, I would like to see the updated version. Until then, I will continue to use InfernoJS.

The React ecosystem's take on performance is really immature. Generally the server's job stops at isomorphic rendering which is a brute force and imperfect way of improving performance.

Next.js and React Server are making steps towards solving this by bringing concepts like incremental loading and data hydration by default.

I've talked about some of the approaches Facebook used to improve startup performance in the past: https://www.youtube.com/watch?v=b875VAC6r-w

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!

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

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!

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.

I rebuilt https://www.emailprivacytester.com in NextJS v1 - 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.

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/

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.

Yeah, I'm still not sure what the "best" solution is but I'm pretty sure it will allow for better composition and static analysis than "global" CSS.

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.

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

[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

The end result of CSS in components is literally the same as BEM. BEM is the gateway drug, the most vocal advocates of CSS-in-JS came via BEM (or similar).

It's just as easy to duplicate CSS in BEM as it is with encapsulated components, it's simply an indication you haven't reached the right granularity of components yet. Finding the right unit of reuse for any project is hard, it's not something that's magically solved just by saying "use X".

> very much like the PHP of old where stuff just works with sane defaults

'sane defaults' and 'PHP of old' are not things that go in a sentence together cough magic quotes cough

Dude, you FTP'd a php file to a server and it ran automagically. It was really beautiful and turned so many people to programming. World-changing!

Needing WAMP just to do some local development was definitely not beautiful. That stuff was opaque and confusing to me as a beginner.

The modern embedded server is what's beautiful.

It sucks that you didn't get a local PHP env working easily, but I think you're an outlier there. The ease to get up and running with PHP is widely credited as a big factor in its success.

I used a thing called 'easyphp' (executable that just gave you a wamp stack and just told you which dir to stick your php files in).

Well, I'm talking about easy vs simple. I never got a local PHP(+Apache+MySQL) env working simply back then.

easyphp.exe and wamp.exe are two good examples of what I mean.

I'm not saying that it was difficult to get up and running, my point of contention was sane defaults.

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.

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/ is MUCH MUCH slower than normal hacker news. And its also much more difficult to maintain, and less future proof.

Greetings

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

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

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

Sure. Here is a full app built on it: https://customizemypic.com - it has a GITHUB link

Here is a showcase of what is possible: https://vimeo.com/208438090

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

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

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

Even so, 3.1 million page views?

Over a few months? Plausible.

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

Yes, JSX considers that valid syntax.

it uses JSX which allows you to use HTML in JS :-)

babel, typescript, and bublé can convert jsx into javascript.

Take a look here https://facebook.github.io/react/docs/react-without-jsx.html

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

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.

Awesome -- thanks! This looks fun to play around with.

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.

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 used next on a side project, zero boilerplate is refreshing.

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

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.

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.

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

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

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

In 3 years, we'll go back to square one! :-)

I would rather favor libraries over frameworks - more freedom, less worries.

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.

Very promising!

nice, thx!

Nice work.

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

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

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.

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.

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.

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

I have to say I dislike that aspect of using React as well. So many fine libraries (say https://github.com/dc-js/dc.js) that I now have to "make it work with React".

If you don't want to use React there's no point in using this framework. You can use other frameworks, the superpower of this one is the React integration.

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

Reply on news.ycombinator.com