Next.js: [Discussion] Comparison of next.js versus the new create-react-app 1.0 release?

[mikelnrd]

Regarding: https://facebook.github.io/react/blog/2017/05/18/whats-new-in-create-react-app.html

As a new next.js user this new blog post by facebook was of big interest. Just thought I'd start a discussion...

In particular:

• "Progressive Web Apps by Default" is very interesting indeed - is this something that's possible now or could be added to next.js?

• "Runtime Error Overlay" is something next.js has had for a while albeit with a different implementation. Are there features of the create-react-app implementation worth integrating into next.js? The editor integration looks very useful for example.

• As a new user to react.js I chose next.js after carefully considering alternatives, including create-react-app. Given the updates, I just thought I'd feedback that I'd love to read a blog post or something from Zeit or the next.js community comparing next.js with the 1.0 release of create-react-app.

[rauchg]

I'll answer each of your points.

PWA

We used to use ServiceWorker but we ditched it. Right now we accomplish permanent caching of assets via hash-named scripts served with Cache-Control: immutable and prefetching via <link rel="preload"> without them.

It introduces a lot of unexpected complexity that I'm almost entirely sure CRA is going to end up having to painfully deal with. That complexity sometimes is necessary, but I wouldn't make it a default at this point.

This decision is not final. In this case, I'd like to see how this decision turns out for CRA and we might revisit it in the future. The decision is also related to our mantra of only incorporating features that we know work well for us with real-world applications.

At the time, we're working on making a big part of the https://zeit.co experience offline-capable without any framework overhead, just by setting up the SW ourselves (@arunoda is working on that right now).

Once we learn enough about that, we might have really clever ideas for incorporating that into the framework!

Errors

One of our goals after major features land (dynamic components and static exports) is to actually not work on new API surfaces for a while.

There are three major things I want to focus on:

• HMR reliability and performance
• Error handling
• Compiler-level optimizations

I just read a great tweet that summarizes my views on this:

There's just a lot of work to be done here.

• Starting up Webpack can take several seconds even for a small React app with 1 component.
• A lot of compilation work is done over and over again for no reason
• Uglifying is painfully slow for large codebases
• A lot of unnecessary compilation is done for UAs devices that don't need it (specially during development!)

… and this is just a quick list off the top of my mind that I came up while composing this answer.

To your final point, I don't think a blog post comparing the two projects is necessary. I think they're philosophically and technically sufficiently different already.

I look forward to each project learning from one another and happily serving the entire JS community.

[rauchg]

Let me know if you have any other questions, I'll gladly respond!

[arunoda]

I want to add a bit on our asset caching and prefetching.
We don't use SW but we get the same behavior on all the browsers and it's fast and less error-prone.

There's only one service worker you can use in an app.
So, this gives users to use their own service worker for some other purpose.

As @rauchg mentioned, we'd like to use SW for offline support (but not for prefetching). We are testing it on zeit.co and once it's ready we'll port it to next.js

[prateekrastogi]

@arunoda Any estimate on timeline of offline first support?

[arunoda]

@prateekrastogi core support takes months.
But try these community integrations like this: https://github.com/ooade/NextSimpleStarter
I didn't try them. But should work.