Hacker News new | past | comments | ask | show | jobs | submit login
Next.js 9.4 – Fast Refresh, Incremental Static Regeneration (nextjs.org)
300 points by STRiDEX 26 days ago | hide | past | web | favorite | 169 comments



you guys might be interested in a current Reddit thread (also on HN: https://news.ycombinator.com/item?id=23136688):

https://old.reddit.com/r/javascript/comments/ghfyd2/secondgu...

specifically this sub-thread of Mithril's author and myself doing a "Hello World" Next.js perf assessment vs a full-blown ecommerce page:

https://old.reddit.com/r/javascript/comments/ghfyd2/secondgu...


Whether or not JS-SSR with hydration is performant is an interesting topic, but sort of misses the forest for the trees, no? The thread you link to is about a post which speaks about whether that extra level of complexity is even necessary for many use cases (it isn't).

HTML + JQuery, which the hydration approach is compared with, is not used for performance reasons per se. It's used because its easier to reason about and the incremental interactivity that something like JQuery brings to HTML is better than writing your entire frontend in React for something as simple as a blog, for example.


it does not take much complexity to start feeling the pain of jquery-style imperative DOM sync & manip. you don't need to go too far past "simple blog" for this to become obvious.

FWIW, the linked site is built with a 300 line custom build script, Rollup, Buble & Terser - even the dev dependencies are extremely minimal. no, it doesnt have the latest HMR hotness, so the DX could be a bit better if i wanted more bloat.


This kind of progressive enhancement but with the latest JS frontend component models is where Vue shines. Vue 3.0 will be making it even better and faster.


You don't need jquery in most situations unless you are supporting old browsers. Modern js is good enough. At best, you will end up writing a few lines to abstract what jQuery abstracts away from you.


if you still want jquery in 2020 (and that's ok because raw DOM apis still need sugar), for the love of god please use https://umbrellajs.com/ instead.

it's like 1/10th the size, api-compatible and well-architectured.




This is pretty neat! I was just looking around for a "modern, smaller" JQuery equivalent and did not come across this. The older equivalents in this space I saw were Zepto and Cash.

Out of curiosity, what do you think of Alpine.js and Stimulus.js, which come to mind when I think of smaller utility libraries for adding "sprinkles" of JS?


> Out of curiosity, what do you think of Alpine.js and Stimulus.js

no experience with those, but if you're feeling masochistic, try these:

https://github.com/finom/balalaika

https://github.com/finom/bala


I have been using Alpine and enjoying it. Stimulus is too much like Rails—convention over configuration—for me to get into. Alpine feels like a nice middle ground between Vue and Vanilla.


Does it support bubbling event handling? In the form of: $(".outer").on("click", ".inner", function(){ ... } )

Without bubbling event handling, it's a no go for handling event on dynamically generated inner content.



I mean, sure, I can use the lower level API to check in a separate step. The point of a library is to provide the functionality to reduce the boiler plate checking.


alright then. sounds like you're able to make an informed decision for yourself. when i was doing jquery dev i never needed so much event delegation that avoiding an occasional 1-liner for event filtering* justified using a lib that's 10x larger.

* in limited cases like tabular data or large lists


Or AlpineJS


Later in the thread, the author links to this site as a real world example using domvm* -- even anecdotally it feels very fast!

https://us.thermosoft.com/floor-heating/systems/thermotile-m...

* Edit -- initially i incorrectly claimed that this site uses mithril -- (it uses domvm w/SSR, not Mithril)


dammit, it's still pre launch, plz don't hug it to death too much! oh well, here we go!

the link above disables Google Analytics on that page, which would otherwise add an extra 50ms of js time (and would account for the majority of the js on the page).

(it uses domvm w/SSR, not Mithril)


I'm really interested in your comment about how Gastsby, Next et. al. are doing SSR wrong. For context, I'm an SSR newbie, currently trying to migrate a site I started away from Gatsby (realized it's not the right tool for the job).

To me, it seems like Incremental Static Regeneration is the best of both worlds - you get a static site without huge build overhead and SSR niceness.

However, peeking in dev tools, sure enough your site is a bit faster in nearly every lighthouse metric compared to static-tweet.now.sh despite being decidedly more complex.

Could you expand on how Gatsby and Next are doing SSR wrong and what it takes to do it right (i.e. what is DOMVM doing instead).

I'm sorry if you've answered this elsewhere in the thread, I looked around and didn't find anything.


> I'm really interested in your comment about how Gastsby, Next et. al. are doing SSR wrong. For context, I'm an SSR newbie, currently trying to migrate a site I started away from Gatsby (realized it's not the right tool for the job).

please read through the whole Reddit thread i linked. i compare a minimal Next.js hello-world page to domvm-rendered e-commerce page. what specifically they do to produce such a sub-optimal result will remain a mystery to me because i don't particularly care to investigate. no one has given me a bare-minimum Gatsby site to evaluate so i have no idea how it compares besides looking at one of their slow showcased apps in the reddit thread: https://airbnb.io/

i think a lot of your questions may be answered by reading the Reddit thread.


I looked through it earlier but missed the "continue this thread"

> SSR can be done correctly, even with React

This stands out to me, and I agree completely.

I dug around in devtools and found a few interesting things looking at the static-tweet.now.sh (Next w/ Incremental Static Regeneration). It seems like the performance is more or less on par with domvm as far as network usage EXCEPT for the initial bundle (which is mostly react & dependencies). For subsequent visits, this is cached and performance is great, but devtools tests with a clean cache so this is hidden.

Admittedly, that's a huge qualifier. It doesn't seem like Next is doing anything wrong with SSR other than using a framework with a huge bundle. As a result, the huge bundle ends up getting sent even for a page (or entire site) with no interactivity.

In theory, it might be possible to avoid sending the bundle for routes that don't need it, but this ends up being a fundamental limitation of react afaik.

Vercel (the folks behind Next) put it really well

> React at Facebook is… > …unlike React at ${anywhereElse}

The large initial bundle pays off for a site like facebook or a web app which really takes advantage of all React has to offer (wether that's performance, tooling, or dx), but definitely deserves more second guessing than it recieves.


right.

perhaps it's possible with Preact|Inferno + SSR, i dunno. but this [1] seems to use babel/webpack and a bunch of other stuff. it's not clear to me from that post how minimal the end result can actually be.

the thing is, React's ecosystem is also to blame, it is so full of ready-to-go-do-everything popular components with inefficient code that cannot be tree-shaken, that lack of care in bundle evaluation is absolutely rampant. every imaginable feature is just some burned-out dev's `npm i` away, node_modules be damned.

[1] https://www.digitalocean.com/community/tutorials/build-a-ssr...


That’s speedy! I was quite surprised to not even see the loading bar on Safari haha.


That page is fast but it's all static content, data changing at request time it's a whole other ballpark and the hard case, or what I'm missing?


nothing there is static or cached. each request pulls products from the db and everything is regenerated in real-time. it looks static, but it is not.

if you add to the cart and reload the page, it pulls the live cart from the db.


Nice, going to study this, thank you.

Just a heads up, there is a NaN showing at the end of the page.


yep, thanks!

that "Chat Now" needs to be position: fixed, and styled, too. WIP!


Sorry for over-sharing! i'll try to correct my note to clarify about domvm


no worries :p


That's using domvm, not mithril. If you want to see a non-trivial mithril example, there's lichess.org


Didn't lichess switch to snabbdom?


I still see references to mithril in lila and lichobile


hey, long time no see ;)


The largest business I know of on Next.js is verishop.com, which feels very snappy.


I'm on a 500mbps connection and an overpowered PC and it doesn't feel all that snappy compared to the other examples given here. Each navigation takes >1s, multiple skeleton loaders. Good enough, but far from what we should be seeing with current tech.


on page load it does 772 ms of js execution and powers through 2.1 MB of js (min).

of course, everything will feel snappy if you just defer it, but your battery does not feel the same way :D


Those metrics are useless in 2020, they do not capture perceived load to the user adequately.


Every time I see metrics being dismissed in response to someone pointing out perceived bloat, I'd love to see what _other_ metrics they are using instead.


Bloat != perceived load time.

The only thing I've found these metrics useful for are baselines for regressions over time.


"Perceived load time" is not a panacea, and not a substitute for actual metrics. Do you actually go interview users on what they perceive? If one doesn't, and is instead just looking at the code _they_ wrote and thinking "yeah my code feels fast", that's biased, unscientific, and objectively an inferior quality assessment strategy than just looking at TTFB/TTI/etc and deriving conclusions from those hard numbers.


The only people I see obsess over these metrics have either their ego or pay tied to them.

> Do you actually go interview users on what they perceive?

Yes, regularly, because that's what effective teams do. I also limit bandwidth to 3G and record the sessions so that everyone can share in the learnings, which very rarely circle back to things like TTFB/TTI.


Interesting! How do you iterate / keep track of regressions?


Speedcurve.com - download the data and then use basic outlier detection on the time series as well as individual observations looking for anything out of the ordinary. Most of the time it was marketing uploading a 20MB PNG to the CMS, other times it's some 3rd party JavaScript (looking at your Criteo) doing something questionable.


there is more to "load" than "perceived load".


No, there isn't. Nothing is more important than perceived load, everything else is just filler.

Time to fist byte? Last byte? First paint? Interactive? These are great, but do not always capture the entire picture of what's actually important - do your users perceive the experience as fast?


what i'm showing is objectively better in both perceived load and actual/real load. so i'm not sure what your argument is.


Just because a Ferrari is faster than a Corvette, does not make the Corvette slow.


> Just because a Ferrari is faster than a Corvette

to quote Rick & Morty: "Must be nice!"


ThermoTile is really fast - like 2001 site on 2020 bandwidth fast. Great work.


larger than jcrew.com?


IIUC you both were just talking past each other? one was talking about SSR to a full hydrated SPA, the other about a MPA with some hydration here and there.

I have been doing the latter for some time with https://github.com/airbnb/hypernova for a rails API.


> the other about a MPA with some hydration here and there

except it's not "here-and-there". everything down from `<html>` is re-SSR'd and fully re-hydrated on each page load.

here-and-there is what jquery does.


That's fast hydration. How much will the performance suffer if no hydration was done but you kept the multi page aspect? ex: As if you took out SSR from Thermasoft and did client rendering witg domvm but doing page reloads for main pages as it does now.

I ask because my server app is not a nodejs process and don't want to add one for now but do want to avoid heavy state management and client side routing as you did.


domvm is pretty fast:

https://krausest.github.io/js-framework-benchmark/current.ht...

but re-hydration is much faster than actually building the dom from scratch in js. instead of 20ms, it might be 60ms + some extra for render/layout time.

however, unless you have very DOM-heavy pages, the perf should still be great from a user's perspective. you may get some flashing between page navigation since when you build the DOM in JS with domvm it's not streamed, but when the browser is parsing server-sent html, it is. the only way to know is to try it for your specific case.

if you need SEO, it's probably sub-optimal and may take longer to for Google & Bing to index, from everything i've read.


No SEO needed, web app behind a login. Will try to write a PoC with domvm, thanks. My goal is <300ms including 60ms network latency.


Nice discussion on Reddit.

So I loaded up this Next hello world: https://hello-world-app-eight.now.sh/

I can see it downloaded 65kB of compressed JavaScript which is _a lot_.

I worked on a small Mithril SPA and the compressed JS bundle (which includes the CSS) is 41kB. Granted it's not a complex app, but it's certainly not a hello world.

https://oceanhotelsimages.com/


Can someone explain why 65kb is “a lot?” Even in 2001 on a “56k modem,” that would download in a little over one second.

It’s not like the 65kb here is 1kb for every N characters of text. It’s an overly simplified “hello world” example. The point is that you’ll still see sizes of around 65kb even with much more complexity than “hello world.”


There was another article here recently that is relevant[1]

One takeaway was that given a large sample of sites, the baseline size correlates fairly well with how the bundle size scales as projects grow. So if you have a 65kb baseline, you're more likely to end up with a larger bundle size in a "real world" project than if you used a framework with a 5kb baseline. The reasons are not clear (they could be anywhere from direct causation to indirect causes like incidental complexity due to some communities' higher likelihood of using libraries without auditing them), but the results are what they are, nonetheless.

Also, 65kb gzipped means you're running the uncompressed amount of JS. As a rule of thumb, the more JS you're running, the slower the site is going to be. This matters a lot for mobile, where JS execution speed can be absolutely abysmal (on top of slow network speeds, higher chance of resource timeouts, etc).

[1] https://timkadlec.com/remembers/2020-04-21-the-cost-of-javas...


Sorry to be pedantic as I agree with your wider point :) but a 56k modem was actually 56 kilobits per second so a theoretical max of 56/8=7 kilobytes/second. If memory serves correctly real speeds were more around the 4-5kb/s mark


Ah you’re right :) I guess I was misremembering just how slow things were back then! I remember when forum threads would include “56k warning!” if they had a bunch of images.


Seems crazy to think that it was that slow eh? And these days I get annoyed when I get below 2 megabytes a second, lol


It's all relative of course but wouldn't you agree that 65kB of JS for a page that displays 1 line of text is a lot?

It's also 65kB of compressed and minified JS which ends up being about 185kB for doing absolutely _nothing_.

For comparison the complete jQuery library weights about 30kB compressed and minified.


Because 65 kB is 65 kilobytes, not 65 kilobits.


I have nothing but good things to say about Next.js, one of the few web libraries that I'm really excited about. Great developer experience, the API is simple and very stable and the feature set is really powerful.


If you've had a chance to look at nuxt.js and/or gatsby.js, how'd you compare those with next.js?


We built https://indieshops.co on nuxt.js and then used next.js for https://vimota.me (my personal site) and https://referrist.com/:

Our experience was that nextjs was way more reliable (had to restart the nuxtjs local server every couple page loads), had much much better support for typescript, and had a more active community and ecosystem which led to questions being answered more easily and things improving at a quicker rate as well.

That being said, I think it's great to have competition and hope Nuxtjs continues to do their thing! I'm particularly excited about the new frameworks being built on top of or adjacent to nextjs (Blitzjs, Redwood, Remix).


I haven't used Nuxt, but I've used both Next and Gatsby a bit.

The biggest difference is that Gatsby is exclusively static, whereas Next can do static pages, server-rendered pages, or a hybrid of the two approaches.

Gatsby has a GraphQL-based data-fetching system, while Next is much less opinionated. Next gives you a place to do your data fetching, but doesn't dictate how you fetch it. Personally I find Gatsby's GraphQL stuff confusing, but YMMV.


I've been using Nuxt for about 18 months and on the whole it is fine, but I've had constant issues with pages trying to load out of date build files. Haven't ever experienced this with Next.

I've also found some of the libraries to be fairly flakey - PWA support breaks my app every-time I've tried to implement it. Lazy Hydration works for a while and then (without any changes) starts dropping random JS errors.

I've noticed a lot of valid Github issues being closed automatically with no attempt by the team to address them - they're simply opened up as questions on a forum that never gets looked at.


Every time I see someone on this site complain about the build setup complexity of modern frontend and having to fiddle with webpack/babel for ages I'm thinking of all the times I have done:

yarn create next-app my-app & cd my-app & yarn dev

and be up and running in 2 minutes.


I sometimes develop javascript things. And indeed it is a complex system. I only do it once or twice a month. I have build a few react native and web apps. All them are hard to work on because i didnt touch it for a while. Anyways, i am not familiar with next js.

-Is it the same thing as nuxt js but different?

- Yarn? I thought that npm was the thing to use again.

- How does yarn know that “create next-app” command? Perhaps some yarn install globally thing?

- Does it include typescript support or is it javascript only?

- Which node version is needed? And if I switch, is that create next app still available then?

- How many things are transpiled? Are there any other concepts i need to understand?

- What is the testing framework of choice these days?

- How long will this framework be hip? Am i talking about months, a few months, a year, two years? Hip is important, i (or new employees) dont want to work with software which is considered old fashioned.

- Apparently i need this layer on top of react client side rendering. Another concept.

- Full control over babel or webpack is exactly the thing which makes it complex. It is probably easy to get started and then you have to make that little tweak on a changed babel plugin to make “it” work.

- Is frontend and backend react the same? As in: will it share the same babel config and will every node function be available on the client side and vice versa?

Even if every answer is positive, it is such a huge amount of stacked concepts and technologies.

Dont get me wrong, i like programming in javascript / typescript. I think the programming is fun, but fixing the damn tooling and having debates about it sucks.


> Is it the same thing as nuxt js but different?

NextJS is a library for doing server-side rendering in your React app. I've never touched Vue, so I don't know if that's what nuxt js does

> Yarn? I thought that npm was the thing to use again.

They're fairly interchangeable and it doesn't matter much these days.

> How does yarn know that “create next-app” command? Perhaps some yarn install globally thing?

Yeah it checks the registry of create-* packages and installs the relevant ones.

> Does it include typescript support or is it javascript only?

Yep, by default can use TS with NextJS. I only use TS when possible. Going back to vanilla JS is a horrifying thought!

> How long will this framework be hip?

React is probably the most popular front-end framework and pretty beloved. It's used seemingly everywhere these days. Since SSR is such an important use-case for websites, I'd wager that combined with how prevalent React is, NextJS will be around for a long, long time.

> Full control over babel or webpack is exactly the thing which makes it complex. It is probably easy to get started and then you have to make that little tweak on a changed babel plugin to make “it” work.

Anecdotally, I've used the default configs for create-react-app starters, NextJS, or Electron Forge starters and haven't needed to modify anything.


> Is it the same thing as nuxt js but different?

Yes.

> Yarn? I thought that npm was the thing to use again.

Yarn has many features that npm doesn't - plugins, constraints, PNP, zero installs, workspaces, etc.

> How does yarn know that “create next-app” command? Perhaps some yarn install globally thing?

You can do yarn dlx or npx create-next-app. It will temporarily install and run the package or command.

> Does it include typescript support or is it javascript only?

Typescript support is as easy as changing your file names, installing typescript, and adding a tsconfig. You don't need to set up anything. Next does it for you on the first run.

> Which node version is needed? And if I switch, is that create next app still available then?

You are cool with current LTS and previous LTS (from my testing).

> How long will this framework be hip? Am i talking about months, a few months, a year, two years? Hip is important, i (or new employees) dont want to work with software which is considered old fashioned.

Next has been supported for years. Vercel is the company backing next for their platform so I would say about the same time as vercel. Given they got funding this year, don't think they will die soon.

> What is the testing framework of choice these days?

jest

> How many things are transpiled? Are there any other concepts i need to understand?

SSR. There are few concepts you will have to learn to actually take benefit of it (getServerSide props, getStaticSideProps, etc) but out of the box, you don't need to do anything different. The routing is already included so that's one less thing to worry about. Next does automatic static optimization (unless you do something stupid with your root app). You are benefiting without doing any work.

> Full control over babel or webpack is exactly the thing which makes it complex. It is probably easy to get started and then you have to make that little tweak on a changed babel plugin to make “it” work.

Most things will work via the next plugins. It will be a rare case where you have to set up your own server. You can take full control when you want.

> Is frontend and backend react the same? As in: will it share the same babel config and will every node function be available on the client side and vice versa?

Next builds your app and responds with either fully static views or via pre-hydrated views hydrating on the client-side. Look up hydration in react.


Sure for hello world app works fine. The same for Java or C, but when you have a real world project you always have to understand all the abstractions otherwise you see a "link error" and you will say "What the hell is a link?" or "something error classpath" and you think "I have no class named path".

The project I work on uses gulp(probably is ancient already and I have to use soemthing cooler). With gulp sometimes when I switch branches of my project it will crash , I understand how it works and why it happens so I restart it , but someone that does not understand the "magic under the hood" will not know what to search for, what to google for etc. Same for react or angular, if you do not know what is happening under the hood you will eventually cause performance issues(similar if you don't understand how CPU/memory works)

My point is that if the abstractions are not perfect you will sooner or later (probably sooner) have to understand them , read the code etc.


The next.js PI is beautifully simple. I completely agree with what you’re saying with regard to tradeoffs, but I’ve been remarkably impressed with the simplicity of the NextJS api and it’s clear, concise documentation.


Working through their docs recently my first thought was: huh, I was under the impression that it would do more for me.

But then I realised that it actually does do a lot for me, but they really managed to package it all up in a relatively (and deceptively) simple API that so far still does not seem leaky at all.


Usually the leaky abstraction will appear later, I remember years ago I was implementing a react component and for some reason the focus was lost from an input when an update was happening. So eventually you are forced to understand what is happening and to apply workarounds. I have experienced a number of issues where some bug suddenly appears and until I read the source code of the abstraction I could not fix it(not only JS frameworks).


Sure, all the usual caveats for React and server- vs. client-side rendering still apply - but those aren't abstracted over.


It was a client side thing, I did not used recent version of React but at that time from my memory the abstraction was not perfect, you had the idea that you have some html then your render function generates some new html and react using magic updates the old with the new. What was missing is the focus is not html (probably the same for selection and other document properties) so you could have problems and you had to understand what is happening under the abstraction.

From my experience though are bad abstraction that are not consistent, like we had a web project working untouched in 1 full year and some feature stopped working one day (nobody touched anything) but I could not reproduce it on my machine. I still have no idea what triggered it but the problem was that for some reason the PHP autoloader "searching" found a different file then before (maybe it was some caching/filesystem or other low level update on the VPS that triggered this)... anyway I had to read the code and understand how the magic happens so I can elucidate the bug.


Right, my point was that that's a React abstraction, not a Next.js abstraction.


this is a bit narrow minded view of things. let's start adding the complexity shall we? need to use sass? let's start adding a scss loader. should we use modules in the JS files or compile everything into 1 file? what if we compile different css into another css file for our admin only layouts? should we use the "fiber" module to speed things up? how about images? let's add another loader, should we use svg/png/jpg file types? now, if all those files are included in JS, how do i access them in the CSS? in the HTML? in the JS? it's not as trivial is it? just imagine a person coming from bootcamp trying to learn all those things.


No one is stopping you from using an asset folder and doing it like you did before. You want to pre-optimize images that's why you are hopefully doing it.

Support for others is inbuilt.

Why transpile to single files? It will be faster to have many smaller files for http2 speed up.

Bootcamp also teaches those concepts nowadays. They are different than what they used to be. Check frontend masters, egghead etc.


You don't need to add a loader for any of that.


Have you watched Rich Hickey's Simple Made Easy talk?


Why don't you list all the command you have to issue before the project hits the production?

I can do this too: without the "modern frontend" all I had to do is open my code editor.


Uh, "git push"? With netlify or vercel you're up and running in about 60 seconds. I don't see how you get from your code editor to production without a few commands in between.


That's the point: I don't. So bragging how it is easy to have an initial setup with a command or to makes no sense. It's what you do till the project reaches the production state.


'yarn build' then copy build directory to web server


tbh, yarn deploy.


and nothing in between? No dependencies? No plugins? No changes to webpack config? Who are you trying to deceive, me or yourself?


Nope nothing. Just use create-react-app everything is pre-configured for you

It's as simple as `create-react-app my-app`, then `yarn start` for development, and `yarn build` to spit out production ready code into build folder


yarn build & cp build /var/www


now --prod


Shameless plug, but if you plan to pair Next with an headless CMS, we (DatoCMS) make it super easy to handle responsive, progressive, lazy-loaded images with blur-up thumbs, as our edge CDN takes care of everything for you, without paying any cost at build time.

https://www.datocms.com/blog/offer-responsive-progressive-lq...



so happy for this, been using canary `nextjs` + `now` for all my non work projects

my favorite feature of `now` is environment variables, and `next.js` 9.4 has even better support. so if using `now`, you store your env vars / secrets in your project on https://vercel.com/ in separate buckets for prod, dev, etc

then on your local environment run `now env pull` and get the latest dev env vars populated in `.env` of your project. this is super great for remote teams where you don't have to share .env files via communication channels / ask someone for the latest variable value


How do you make sure the secret env vars are only used in server side JS and never in the client bundle? I was working on a Nuxt app and got really nervous about this and never found a good answer.


Just read TFA and it looks like the Next team has a good answer for this! Glad they made it simpler.


"Fast and reliable HMR". I had to look this one up. It means "Hot Module Replacement".


HMR may be the best advancemenet in web developer experience since the original Firebug.


No wonder given that it's a TLA.


Totally lame acronym


Temporary Lodging Allowance?


For a simple static site, is this a better option than Gatsby?


Definitely, compared to Gatsby, Next is much simpler. At least every time I tried Gatsby, I just had to give up after a few hours because of the complexity and massive amount of boiler plate that you had to stitch up yourself from examples.


I can only second this. Next just works with minimal (or in fact no) config. And their documentation is great.

Bonus: Next's built-in API support makes building quick APIs for your project (and its static/hybrid/dynamic) data loading a breeze. While not suited for everything, at the very least, Next and Airtable can get your POC/MVC/prototype running in a day.

The few times I tried to build something in Gatsby I was bogged down in mediocre documentation and a mountain of (maybe?) necessary plugins. I don't know.

Not sure how to feel about Gatsby's GraphQL-first approach either.


I made a gatsby site about 2 years ago and it has been a nightmare to maintain, the build breaks for random reasons every time I come back to it.

Forcing everything to go through graphql is also a pain and adds an unnecessary indirection that requires a million extra dependencies.


Interesting, just yesterday I migrated a site from react-static to Gatsby (because of a nasty bug that’s been open in react-static for ages, seems to be struggling somewhat for maintenance) because I thought Gatsby looked simpler than next.js, haha.

Perhaps it was just that Gatsby felt closer to react-static’s model and it was more readily apparent how to adapt a react-static site to Gatsby with as few changes as possible, using their createPage api to replace the route config in react-static and bypassing all the GraphQL as described in https://www.gatsbyjs.org/docs/using-gatsby-without-graphql/ - I didn’t have time to do a detailed comparison of frameworks or rebuild large parts of the site.

I was pleasantly surprised how quick and easy the migration was, took me about 90 mins for a site with about six templates and Gatsby seems to build faster and has a much better ecosystem of plugins etc. I wrote up the process at a high level at https://github.com/react-static/react-static/issues/1203#iss... if anyone is interested in the specifics

Did I understand correctly that next.js isn’t just a static site generator and ideally you have a server side component too? This was what started confusing me in their docs, but perhaps I got the wrong end of the stick.

I’ll have to give next.js a proper look next time I’m building a site from scratch anyway!


OK, ended up migrating another site I manage to next.js as the preview feature is a killer for the site admin, and I have to say I do like it more. It's a bit more work to migrate but I think worth it. Thanks for the recommendation!


Yeah, not everyone needs to play with GraphQL.


If you want simple, you can give Charge a try: https://charge.js.org

It's a dead-simple MD -> HTML generator that uses React for templating. No JS code on the client, unless you import your own scripts.


Oh this is neat, thanks.


In my (quite small) experience, developing with NextJS has been a breeze.

Some time ago I've decided to rewrite a landing page, written in Node + EJS templates + JQuery, using some kind of static generator. I have always heard good things about NextJS as well as Gatsby, but after some exploration I decided to go with NextJS, since Gatsby seemed more complex and better suited for CMS/other complex websites rather than a simple, light landing page.

The developer experience has been amazing. Plus, I've found an awesome library[0] for dealing with i18n, which completely absorbed the pain of dealing with multiple languages: getting SEO right, make links work, and so on.

Plus, pairing NextJS with PReact, brought my pages first-load size down to ~40KB (external resources excluded), which I didn't think it was possible for something built with React.

The only things that I missed from CRA-like apps were environment variables, which have been added with this release, and a good integration with third-party tools like eslint, typescript and prettier. I did not use typescript because it was just overkill for a simple landing, and I'm launching eslint by hand and in the CI, so I really miss how good the integration is when developing a normal React App bootstrapped with CRA (which has all of this awesomeness out of the box).

[0] https://github.com/vinissimus/next-translate


I started building my partner's portfolio with Next and was very pleased with its simplicity.

However I had to switch to Gatsby because of its superior support for responsive images.

With Next I couldn't find a way to cache all the generated variants of images between builds, which made the site take more than 5 minutes to build.

Gatsby ecosystem seems more mature also.


Also check out - https://www.11ty.dev/

Imo, simpler if you don't require dynamic views.


I tried and gave up after an hour or two. If you're a js developer it might be easy, for regular developers I didn't find it simple at all. Would be great if someone had instructions on how to create a simple blog with a nice template.


I'm a React developer and I still found Gatsby to be a massive pain. I looked it at for a day and just moved away to next.js.


Gatsby is a massive pain compared to next.js. I couldn't understand how to do the simplest things in Gatsby. I went from reading next.js docs to deploying my personal blog in 2 days.


Both are overkill for that imo. If you don't do fancy stuff and don't want to be outdated in a year, better use something like Jekyll.


Yes.


Having absolute imports and aliases built-in is huge. This was a pain to set up before, so I'm really excited to try this out.


Incremental Static Regeneration sounds awesome for pages where you don't mind the data being a request behind but you don't want it completely static at build time. Seems like a really nice middle ground that lets you keep the backend simple and get the speed of serving static pages.


Next.js teamed with SWR[1] means I could totally remove redux from my app

[1] https://swr.now.sh/


What does that have to do with redux?

How does it replace a client side state management solution?


I have used react-query which does the same thing. The server responses can be cached like a redux store. The same query can then be reused elsewhere. You have setting to not cache at all, cache for some time or cache infinity. I have used it on redux project and replaced many with react-query. It does feel better for server data. Not much boilerplate.


Depends on your approach but for me most state in redux was remote data which SWR now caches for me. Other shared local state, such as which project a user is currently viewing, just goes into react context. This removed so much boilerplate for me, adding new calls to the backend is now much simpler.


Awesome! This is how we use Next.js at Vercel.

For those interested, I recently put together these slides https://jamstack-toronto.now.sh/ for Jamstack Toronto that goes more in-depth into this.

tl;DR: static pages for landing pages, static site generation for content like our blog, static dashboard with SWR against our REST API.

Video should be out soon!


Cool, do the slides work on mobile?!


Since I started to combine React context + useReducer, I never felt the need to set up a Redux config. It's much simple with the same power.


Why SWR as opposed to React Query?


They're both awesome and I think have borrowed ideas from each-other. I went with React Query because I like the query key format (object instead of a string with SWR).

https://github.com/tannerlinsley/react-query#query-keys


It’s made by Vercel, probably.


Yep


I love static site generators but I often feel they are geared towards one type of site (like Jekyll or Hugo for blogs etc.)

We have a huge web based “operating system” and constantly adding more stuff. I spent a couple months architecting and implementing i18n and translations, for example. I looked at GNU language files and other formats and made our own JSON based one.

I tried my hand at static site generation, and it basically takes an existing site and renders certain URLs from the config (including looping through variable values) as a specific browser would fetch them. If you serve different versions of a resource to different browsers (eg mobile browser or css vendor prefixes) you’d have to generate different directories for each one, which can be cleanly chosen by a web server based on the user agent string.

This led to a whole host of issues that made us refactor our framework’s server->client data exports into two parts: session data and regular config data. So a static page would not have any session data. Any experience of being logged-in would have to be added via Javascript or widgets hosted in iframes.

We also have scripts like “combine.php” and “update.php” which minify and combine files, or look at file modification times and set up metadata with timestamps and hashes to use for subresource integrity.

Actually, I would say that the idea of “static site generation” can be a special case of CACHING. To achieve 90% of the benefits, just host your site through a CDN and set your web app server as an origin server. Pages can be rendered on demand and then cached on a CDN. You will have to separate out your session stuff, though! And any dynamicall generated content will need to go under that.

Finally... I would say that all this is actually pointless :) Because you should be building client-first apps. Assume Javascript is available and do all your routing, layouts, header, footer, locally.

There are TONS OF REASONS WHY THAT IS THE FUTURE. The rabbit hole goes much deeper:

https://qbix.com/blog/2020/01/02/the-case-for-building-clien...


If I want some requests resolved at runtime with Next, what are my choices of a production-ready server? I assume `npm start` does not scale very well. What are production practices with Next?

Do you just build your static website and then fetch the data from the browser like React would? Because if so, why would I use Next and not pure React?

SSR frameworks sound very attractive to me due to Kubernetes and hitting internal resources that shouldn't need to be exposed to the world, but I find myself again and again creating gateway services exposing backend services for Ingress.


`npm start` is just whatever you tell it to do - eg `node ./src/index.js`, and yes that is plenty production-ready - you don't need any special thing, it's not like Ruby etc

However, regardless, you should really put it behind a load balancer of some kind, and it's generally best to do your TLS termination in that too.

And you'll want something to manage the application and make sure it's running etc as normal. Usually the cleanest option is to have it wrapped up in a Docker image being managed by an orchestrator, but there's also options like pm2


React runs webpack by default. Are you telling me there are large prod websites running on a dev server in kubernetes somewhere? Because I'd definitely not feel confident putting that into production. (I am genuinely curious how is FE run nowadays with cloud-native stacks)

And of course TLS termination and load balancing aside, you do that in your orchestration platform (so, Kubernetes typically).


In Next.js there are only four commands:

- `next dev` starts the dev server with unoptimized code and webpack hot-reload

- `next build` compiles all your code to be ready for production (optimizations enabled and not hot-reloading, pages that aren't dynamic server-side get turned into regular HTML, etc)

- `next start` serves that production-ready bundle, with a bare-bones (but production-ready) server

- `next export` forces every page to compile down to HTML and gives you a folder of static markup and js you can upload to any static host

So yeah, `next start` is indeed production-ready, and similar to what major websites already do. (Also there's no soft, hard, or default dependency between webpack and react, but the starter template uses it to make life easier for devs)


What's the difference between `next build` and `next export`? I couldn't tell from reading your comment.


`next build` makes a server that needs to be run with nodejs. Dynamic pages keep being JS code. the fact that some pages are optimized down to html is an internal implementation detail.

`next export` makes a folder of static resources (HTML, packages client JS code, CSS). It also forces every page (even dynamic ones) to compile down to HTML.


Within create-react-app, the local dev server does indeed use Webpack. For deploying into prod, the recommend approach is to use the `build` script which will output the static files to be deployed to a host e.g. S3 or Zeit Now.

If you require server-side rendering, Next.js can be run just as any other Node server so will be fine in Docker. Alternatively, Next has support for running in AWS Lambda/Lambda@Edge do you don't need to have infra running 24/7.


Dumb question, but what is the benefit of something like Nextjs over react/redux? So many things to learn...


It’s not a replacement for react. It’s built on top of react and gives you all the best practices for SSR and development setup out of the box. It’s been highly optimized (including with help from the Chrome team), and is in use at some very large websites.

I can’t recommend it enough. Although if you’re doing anything with moderate complexity, it is still important to understand what’s going on under the hood. At least, you should know the difference between client side routing and server side routing, and any implications of when you might need to treat one differently than the other. I could see a total noob potentially getting hung up on that aspect of it. But the rest of the ease-of-use outweighs any complexity stemming from SSR, IMO.


It provides pages/routing, JS/CSS compiling/bundling, and even optional static site bundling. It's basically the missing pieces for a deployable react app.


If I don't need anything fancy (not even SSR), Parcel does it for me out of the box:

    parcel build *.html --public-url https://domain/
It's great to use my dev/build tool for static site generation.


We're blessed with many great and free options.


Anecdotal, but it's an incredibly satisfying development loop for anyone with a limited staff. Deploying to Vercel gets you so many convenient tools out of the box, and I haven't even left the free plan. Very helpful in a startup environment.


Nextjs is an opinionated stack that specializes in SSR, routing, and bundling.

React/Redux are building blocks to your own "React Stack".

You can use other state libraries (like xState, MobX, etc) depending on your programming style (reactive, state machines, etc.)

It depends what you want to build. You choose how you stack it.


Let's say I wanna build a multiplayer board game, which one would you recommend react or nextjs?


React


I rerender pages on demand like this, but also rerender the entire site every 6 hours. There's some computer science theorem that says tracking the dependency of which outputs are sensitive to which inputs is actually identical to solving the halting problem... i.e, no framework can actually track which pages are affected by which pieces of data. (This is true if you run custom code. If you are running in some type of limited non-Turing complete language it could be done.)


It's true that there will be a limit to what dependency tracking can do, because if you rename the nickname of an author of a blog post that is in 1,000,000 pages, then we'll fire 1,000,000 function invocations preemptively to recompute all pages.

That's why Next.js is focused on enabling both eager and lazy pre-rendering behaviors (AOT and JIT). There is no silver bullet :)


As long you as you track the data coming into the custom code, you can make it deterministic.


I'm going to shill my own product https://www.prerender.cloud because it's (mostly) solved this since Chrome headless was finally released in fall 2016.

If you can be patient enough to cache any state you might have in a special global var that gets serialized during the "server side render", then it works for any JavaScript framework that can rehydrate/reattach to SSR'd HTML.


Environment variables being exposed to the client is great assuming this means they can be configured at runtime and available on the client


You‘d have to assume that they are only read during SSG/SSR.


Anyone managed to get latest next.js to work with reasonMl? There is an excellent tutorial on yt, but it is a bit outdated


This is pretty up to date: https://github.com/ryyppy/nextjs-default


Thanks, I will check it out


Can I use nextjs or ssr react with websockets? Does that go against the pattern of server side rendering?

If I have a large app that has a few pages which use websockets so I'm not sure if nextjs is something that makes sense for me or if I should just start with create-react-app and go from there.


Sure, why not? SSR just creates the first version of the page, the web sockets can kick in once the page is rendered.


Ok that makes sense. Thanks


I've been waiting for aliases to come out canary!


Love NextJS, it just keeps getting better at each new release...

Fast Refresh seemed impressive in some GIF's in tweets a couple weeks ago.


Good work! Was very happy with 9.3s new SSG functions. Excited to see further development in this space.


So Vercel is like Netlify but with their own web site development framework (NextJS), and Netlify is like Vercel but with their own CMS (Netlify CMS), and together they have raised about $120MM.


the only reason I use Nextjs is to avoid going through setting up the router, I found Gatsby complex to learn in 10 mins.


Gatsby definitely requires at least a couple weekends, but I really liked developing with it. As a backend person, it feels very "backend-y" if that's a word.

What complexities are you running into with router in React? (I'm genuinely curious, I had to use it a few weeks ago for a simple app and found it surprisingly simple).


no complexities in particular, but with next I just don't have to think about it.


Have you tried react-router v6 alpha ? The API is minimal and easy to understand.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: