15 ms·

Next.js 9.4 – Fast Refresh, Incremental Static Regeneration

300 points by STRiDEX 6y ago

Antoninus 6y ago
I've been waiting for aliases to come out canary!
leerob 6y ago
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.
ggordan 6y ago
Environment variables being exposed to the client is great assuming this means they can be configured at runtime and available on the client
- dgb23 6y ago
  You‘d have to assume that they are only read during SSG/SSR.
moneywoes 6y ago
For a simple static site, is this a better option than Gatsby?
- Hurtak 6y ago
  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.
  - gherkinnn 6y ago
    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.
  - m_ke 6y ago
    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.
  - tomduncalf 6y ago
    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/ 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#issuecomment-626361725 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!
    - tomduncalf 6y ago
      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!
  - nobody0 6y ago
    Yeah, not everyone needs to play with GraphQL.
- gherkinnn 6y ago
  If you want simple, you can give Charge a try: https://charge.js.org 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.
  - zeusly 6y ago
    Oh this is neat, thanks.
- rglover 6y ago
  Yes.
- searchableguy 6y ago
  Also check out - https://www.11ty.dev/ https://www.11ty.dev/ Imo, simpler if you don't require dynamic views.
- deltron3030 6y ago
  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.
- neslinesli93 6y ago
  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 https://github.com/vinissimus/next-translate
- rb808 6y ago
  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.
  - greatwhitenorth 6y ago
    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.
- 4lejandrito 6y ago
  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.
- greatwhitenorth 6y ago
  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.
drekembe 6y ago
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.
- ignoramous 6y ago
  If you've had a chance to look at nuxt.js and/or gatsby.js, how'd you compare those with next.js?
  - vimota 6y ago
    We built https://indieshops.co https://indieshops.co on nuxt.js and then used next.js for https://vimota.me https://vimota.me (my personal site) and https://referrist.com/ 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).
  - Gaelan 6y ago
    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.
  - siquick 6y ago
    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.
gherkinnn 6y ago
Good work! Was very happy with 9.3s new SSG functions. Excited to see further development in this space.
leorio 6y ago
the only reason I use Nextjs is to avoid going through setting up the router, I found Gatsby complex to learn in 10 mins.
- BossingAround 6y ago
  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).
  - leorio 6y ago
    no complexities in particular, but with next I just don't have to think about it.
- revskill 6y ago
  Have you tried react-router v6 alpha ? The API is minimal and easy to understand.
leeoniya 6y ago
you guys might be interested in a current Reddit thread (also on HN: https://news.ycombinator.com/item?id=23136688 https://news.ycombinator.com/item?id=23136688): https://old.reddit.com/r/javascript/comments/ghfyd2/secondguessing_the_modern_web/ 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/secondguessing_the_modern_web/fq8th3k/ https://old.reddit.com/r/javascript/comments/ghfyd2/secondgu...
- pier25 6y ago
  Nice discussion on Reddit. So I loaded up this Next hello world: https://hello-world-app-eight.now.sh/ 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/ https://oceanhotelsimages.com/
  - searchableguy 6y ago
    Try svelte.
  - TechBro8615 6y ago
    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.”
    - pier25 6y ago
      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.
simonw 6y ago
"Fast and reliable HMR". I had to look this one up. It means "Hot Module Replacement".
- Tade0 6y ago
  No wonder given that it's a TLA.
  - mads 6y ago
    Temporary Lodging Allowance?
  - save_ferris 6y ago
    Totally lame acronym
- armandososa 6y ago
  HMR may be the best advancemenet in web developer experience since the original Firebug.
steffoz 6y ago
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-lqip-images-in-2020 https://www.datocms.com/blog/offer-responsive-progressive-lq...
- steffoz 6y ago
  Example here: https://cms-datocms.now.sh/ https://cms-datocms.now.sh/
janpot 6y ago
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.
- rimliu 6y ago
  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.
  - searchableguy 6y ago
    tbh, yarn deploy.
    - rimliu 6y ago
      and nothing in between? No dependencies? No plugins? No changes to webpack config? Who are you trying to deceive, me or yourself?
      - nullandvoid 6y ago
        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
  - nullandvoid 6y ago
    'yarn build' then copy build directory to web server
  - Kaze404 6y ago
    yarn build & cp build /var/www
  - muspimerol 6y ago
AzzieElbab 6y ago
Anyone managed to get latest next.js to work with reasonMl? There is an excellent tutorial on yt, but it is a bit outdated
- marcusr 6y ago
  This is pretty up to date: https://github.com/ryyppy/nextjs-default https://github.com/ryyppy/nextjs-default
  - AzzieElbab 6y ago
    Thanks, I will check it out
cjr 6y ago
Next.js teamed with SWR[1] means I could totally remove redux from my app [1] https://swr.now.sh/ https://swr.now.sh/
- Rauchg 6y ago
  Awesome! This is how we use Next.js at Vercel. For those interested, I recently put together these slides https://jamstack-toronto.now.sh/ 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!
  - cjr 6y ago
    Cool, do the slides work on mobile?!
- searchableguy 6y ago
  What does that have to do with redux? How does it replace a client side state management solution?
  - hesarenu 6y ago
    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.
  - cjr 6y ago
    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.
- pspeter3 6y ago
mcintyre1994 6y ago
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.
etaioinshrdlu 6y ago
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.)
- Rauchg 6y ago
  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 :)
- ec109685 6y ago
  As long you as you track the data coming into the custom code, you can make it deterministic.
agustif 6y ago
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.
EGreg 6y ago
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-client-first-web-apps/ https://qbix.com/blog/2020/01/02/the-case-for-building-clien...
djstein 6y ago
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/ 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
- earthboundkid 6y ago
  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.
  - earthboundkid 6y ago
    Just read TFA and it looks like the Next team has a good answer for this! Glad they made it simpler.
BossingAround 6y ago
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.
- BillinghamJ 6y ago
  `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
  - BossingAround 6y ago
    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).
    - jbourne 6y ago
      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.
sunsetSamurai 6y ago
Dumb question, but what is the benefit of something like Nextjs over react/redux? So many things to learn...
- jonny_eh 6y ago
  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.
  - developerdylan 6y ago
    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.
  - tiborsaas 6y ago
    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.
    - jonny_eh 6y ago
      We're blessed with many great and free options.
- TechBro8615 6y ago
  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.
tren-hard 6y ago
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.
- jonny_eh 6y ago
  Sure, why not? SSR just creates the first version of the page, the web sockets can kick in once the page is rendered.
  - tren-hard 6y ago
    Ok that makes sense. Thanks
  - throwbackThurs 6y ago
    Correct, the hot module reloader uses websockets to do this
jotto 6y ago
I'm going to shill my own product https://www.prerender.cloud 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.
subpixel 6y ago
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.

300 points by STRiDEX 6y ago

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

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.

ggordan 6y ago

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

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

moneywoes 6y ago

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

Hurtak 6y ago
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.
- gherkinnn 6y ago
  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.
- m_ke 6y ago
  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.
- tomduncalf 6y ago
  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/ 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#issuecomment-626361725 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!
  - tomduncalf 6y ago
    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!
- nobody0 6y ago
  Yeah, not everyone needs to play with GraphQL.
gherkinnn 6y ago
If you want simple, you can give Charge a try: https://charge.js.org 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.
- zeusly 6y ago
  Oh this is neat, thanks.
rglover 6y ago
Yes.
searchableguy 6y ago
Also check out - https://www.11ty.dev/ https://www.11ty.dev/ Imo, simpler if you don't require dynamic views.
deltron3030 6y ago
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.
neslinesli93 6y ago
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 https://github.com/vinissimus/next-translate
rb808 6y ago
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.
- greatwhitenorth 6y ago
  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.
4lejandrito 6y ago
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.
greatwhitenorth 6y ago
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.

drekembe 6y ago

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.

ignoramous 6y ago
If you've had a chance to look at nuxt.js and/or gatsby.js, how'd you compare those with next.js?
- vimota 6y ago
  We built https://indieshops.co https://indieshops.co on nuxt.js and then used next.js for https://vimota.me https://vimota.me (my personal site) and https://referrist.com/ 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).
- Gaelan 6y ago
  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.
- siquick 6y ago
  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.

gherkinnn 6y ago

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

leorio 6y ago

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

BossingAround 6y ago
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).
- leorio 6y ago
  no complexities in particular, but with next I just don't have to think about it.
revskill 6y ago
Have you tried react-router v6 alpha ? The API is minimal and easy to understand.

leeoniya 6y ago

you guys might be interested in a current Reddit thread (also on HN: https://news.ycombinator.com/item?id=23136688 https://news.ycombinator.com/item?id=23136688): https://old.reddit.com/r/javascript/comments/ghfyd2/secondguessing_the_modern_web/ 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/secondguessing_the_modern_web/fq8th3k/ https://old.reddit.com/r/javascript/comments/ghfyd2/secondgu...

pier25 6y ago
Nice discussion on Reddit. So I loaded up this Next hello world: https://hello-world-app-eight.now.sh/ 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/ https://oceanhotelsimages.com/
- searchableguy 6y ago
  Try svelte.
- TechBro8615 6y ago
  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.”
  - pier25 6y ago
    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.

simonw 6y ago

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

Tade0 6y ago
No wonder given that it's a TLA.
- mads 6y ago
  Temporary Lodging Allowance?
- save_ferris 6y ago
  Totally lame acronym
armandososa 6y ago
HMR may be the best advancemenet in web developer experience since the original Firebug.

steffoz 6y ago

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-lqip-images-in-2020 https://www.datocms.com/blog/offer-responsive-progressive-lq...

steffoz 6y ago
Example here: https://cms-datocms.now.sh/ https://cms-datocms.now.sh/

janpot 6y ago

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.

rimliu 6y ago
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.
- searchableguy 6y ago
  tbh, yarn deploy.
  - rimliu 6y ago
    and nothing in between? No dependencies? No plugins? No changes to webpack config? Who are you trying to deceive, me or yourself?
    - nullandvoid 6y ago
      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
- nullandvoid 6y ago
  'yarn build' then copy build directory to web server
- Kaze404 6y ago
  yarn build & cp build /var/www
- muspimerol 6y ago

AzzieElbab 6y ago

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

marcusr 6y ago
This is pretty up to date: https://github.com/ryyppy/nextjs-default https://github.com/ryyppy/nextjs-default
- AzzieElbab 6y ago
  Thanks, I will check it out

cjr 6y ago

Next.js teamed with SWR[1] means I could totally remove redux from my app [1] https://swr.now.sh/ https://swr.now.sh/

Rauchg 6y ago
Awesome! This is how we use Next.js at Vercel. For those interested, I recently put together these slides https://jamstack-toronto.now.sh/ 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!
- cjr 6y ago
  Cool, do the slides work on mobile?!
searchableguy 6y ago
What does that have to do with redux? How does it replace a client side state management solution?
- hesarenu 6y ago
  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.
- cjr 6y ago
  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.
pspeter3 6y ago

mcintyre1994 6y ago

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.

etaioinshrdlu 6y ago

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

Rauchg 6y ago
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 :)
ec109685 6y ago
As long you as you track the data coming into the custom code, you can make it deterministic.

agustif 6y ago

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.

EGreg 6y ago

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-client-first-web-apps/ https://qbix.com/blog/2020/01/02/the-case-for-building-clien...

djstein 6y ago

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

earthboundkid 6y ago
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.
- earthboundkid 6y ago
  Just read TFA and it looks like the Next team has a good answer for this! Glad they made it simpler.

BossingAround 6y ago

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.

BillinghamJ 6y ago
`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
- BossingAround 6y ago
  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).
  - jbourne 6y ago
    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.

sunsetSamurai 6y ago

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

jonny_eh 6y ago
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.
- developerdylan 6y ago
  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.
- tiborsaas 6y ago
  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.
  - jonny_eh 6y ago
    We're blessed with many great and free options.
TechBro8615 6y ago
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.

tren-hard 6y ago

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.

jonny_eh 6y ago
Sure, why not? SSR just creates the first version of the page, the web sockets can kick in once the page is rendered.
- tren-hard 6y ago
  Ok that makes sense. Thanks
- throwbackThurs 6y ago
  Correct, the hot module reloader uses websockets to do this

jotto 6y ago

I'm going to shill my own product https://www.prerender.cloud 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.

subpixel 6y ago

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.