Next.js 11(nextjs.org)
nextjs.org
Next.js 11
https://nextjs.org/blog/next-11
123 comments
Also disappointed by this. Vercel has increasingly been putting out more features that are tucked behind a vendor-lock.
- `next export` when using `next/image` doesn't have a sane default
- Running a custom server means no deploying to Vercel. I understand that one the most, since Vercel has decided to lean on serverless
- Next.js Live can only run on Vercel
I still reach for Next.js + React first when starting a new web project, but have since replaced Vercel with Render because more times than not, I need to run something that just doesn't work on serverless. Been a user and fan since v1.0.0, and have only just started noticing some features that go against the "sane defaults, config available" ethos that seems to be core to the team.
No hate, just observations.
- `next export` when using `next/image` doesn't have a sane default
- Running a custom server means no deploying to Vercel. I understand that one the most, since Vercel has decided to lean on serverless
- Next.js Live can only run on Vercel
I still reach for Next.js + React first when starting a new web project, but have since replaced Vercel with Render because more times than not, I need to run something that just doesn't work on serverless. Been a user and fan since v1.0.0, and have only just started noticing some features that go against the "sane defaults, config available" ethos that seems to be core to the team.
No hate, just observations.
>Running a custom server means no deploying to Vercel. I understand that one the most, since Vercel has decided to lean on serverless
For those who want simple serverless deployment, but don't want to vendor lock in with Vercel, checkout serverless-next.js, it makes deploying to aws lambda@edge directly a breeze, it's awesome![1].
1: https://github.com/serverless-nextjs/serverless-next.js
For those who want simple serverless deployment, but don't want to vendor lock in with Vercel, checkout serverless-next.js, it makes deploying to aws lambda@edge directly a breeze, it's awesome![1].
1: https://github.com/serverless-nextjs/serverless-next.js
Does it work with Amplify?
This is not entirely accurate. First, we are working on build-time image optimization, it just wasn't our first priority (https://twitter.com/rauchg/status/1402613436081528836). Second, the vast majority of Next.js applications do not need a custom server.
Finally, Next.js Live is two parts – the soon open-source dev engine, and the collaboration features. The first will be open-source, always. The second can be any platform (like Vercel) with the ability to sync and store your code edits.
Finally, Next.js Live is two parts – the soon open-source dev engine, and the collaboration features. The first will be open-source, always. The second can be any platform (like Vercel) with the ability to sync and store your code edits.
This is all fair and good. I was just pointing out the beginnings of a trend.
To me, build-time image optimization would’ve been a prerequisite for next/image even launching in the past. Something in the tune of “…and Vercel does all of this for you, automatically, by default when deployed to Vercel”. Instead, we get a build-time error on export.
I agree that the vast majority don’t need a custom server. If I could go without one, I would. Unfortunately I can’t, and this one’s not a criticism. It was clear to me once “Develop. Preview. Ship.” became the tagline that things like Docker support would go away. Fair.
Glad to hear Next.js Live will be open source, and I’m assuming it’ll be easy to deploy given the quality of Vercel’s work. I personally don’t understand the use-case but can see how it adds to Vercel’s value add.
Appreciate the reply! I just wish Vercel looked into immutable database provisioning, continued Docker support, alongside the stellar React work.
To me, build-time image optimization would’ve been a prerequisite for next/image even launching in the past. Something in the tune of “…and Vercel does all of this for you, automatically, by default when deployed to Vercel”. Instead, we get a build-time error on export.
I agree that the vast majority don’t need a custom server. If I could go without one, I would. Unfortunately I can’t, and this one’s not a criticism. It was clear to me once “Develop. Preview. Ship.” became the tagline that things like Docker support would go away. Fair.
Glad to hear Next.js Live will be open source, and I’m assuming it’ll be easy to deploy given the quality of Vercel’s work. I personally don’t understand the use-case but can see how it adds to Vercel’s value add.
Appreciate the reply! I just wish Vercel looked into immutable database provisioning, continued Docker support, alongside the stellar React work.
[deleted]
That's why I removed next/image and ended up using https://github.com/cyrilwanner/next-optimized-images
That lets you export the images pre-optimized for different sizes/etc. You can then do a normal next export.
That lets you export the images pre-optimized for different sizes/etc. You can then do a normal next export.
This works well for us too. It doesn't have all the conveniences of next/image, but it lets you get closer to more reliable and better performance in our experience. Yes you need to understand what you're doing a little better, but it isn't rocket science.
Unfortunately it doesn't seem to be maintained anymore.
We're working on this! https://twitter.com/rauchg/status/1402613436081528836
Not sure if this would fit into your use case, but in my use case, I have custom js code which runs at the build time and downloads/compresses/resizes all the required images into node.js file system. Then, next/image serves them as it would from local static image source. The drawback is I have really long build/export times.
The lack of official solution eventually made me ditch in favor of Gatsby. Granted it was a large change but I found that the way Gatsby handled images was just better than how Next.js handled them.
Partial hydration would have been a game changer in performance of nextJS based websites.
I am a bit perplexed about the new "live" feature. Its just so far away from the framework business (poof, now its an IDE), I have no words for it...
I am a bit perplexed about the new "live" feature. Its just so far away from the framework business (poof, now its an IDE), I have no words for it...
I agree. I was a little disappointed to see resources going towards this. It feels like they're seeking ways to create vendor lock-in, which my team fairly aggressively avoids. Next has generally been great about this, and part of the initial appeal. It's just React components inside of an easy-to-understand framework.
This, though - my instinct is to stay away from it, personally. It doesn't seem to be their wheelhouse and it doesn't necessarily make Next.js better.
This, though - my instinct is to stay away from it, personally. It doesn't seem to be their wheelhouse and it doesn't necessarily make Next.js better.
I had this same reaction to next/image. I see where they're going with it though. They're obviously prioritizing e-commerce publishers because they tend to have high traffic, semi-static content, and a clear business use case for fast websites. They are also the most likely to pay Vercel to host their sites.
As long as features like next/image and "live" remain opt-in and don't otherwise affect build/dev times, I have no problem with Vercel targeting a lucrative market. Anyone who relies on Next should want Vercel to be a long-lasting company.
Besides, this is the first release of "live" – I can see this workflow becoming appealing to marketing and design teams. It's good practice to separate your marketing website from your application, so why not use "live" to enable non-devs to edit it? That's what Jamstack is all about – empowering the marketing/copywriting/product teams to edit content in real time. Maybe "live" is simply the next logical step of Jamstack – teams of non-devs editing the code and design of websites as easily as they can edit their content.
Developers should be all for that, even if they aren't the target audience of the live features. Reducing friction between dev and non-dev is a win for everybody. Marketers are happy because they can edit content without waiting on devs/deploys, and devs are happy because they talked the non-devs out of using WordPress, and got to build a new site with a hot technology.
I wonder if Vercel considers Automattic a competitor. The "percent of the web" stat is a juicy KPI to compete for.
As long as features like next/image and "live" remain opt-in and don't otherwise affect build/dev times, I have no problem with Vercel targeting a lucrative market. Anyone who relies on Next should want Vercel to be a long-lasting company.
Besides, this is the first release of "live" – I can see this workflow becoming appealing to marketing and design teams. It's good practice to separate your marketing website from your application, so why not use "live" to enable non-devs to edit it? That's what Jamstack is all about – empowering the marketing/copywriting/product teams to edit content in real time. Maybe "live" is simply the next logical step of Jamstack – teams of non-devs editing the code and design of websites as easily as they can edit their content.
Developers should be all for that, even if they aren't the target audience of the live features. Reducing friction between dev and non-dev is a win for everybody. Marketers are happy because they can edit content without waiting on devs/deploys, and devs are happy because they talked the non-devs out of using WordPress, and got to build a new site with a hot technology.
I wonder if Vercel considers Automattic a competitor. The "percent of the web" stat is a juicy KPI to compete for.
I personally can’t see any benefit of allowing non-devs near code. Personally, any time I’ve seen clients / non-devs near code (or non-content / admin / HTML / CSS type things) that’s when things go bad and I have have to fix things.
I’d be interested to see how this would work in practice but I’m skeptical at the moment.
I’d be interested to see how this would work in practice but I’m skeptical at the moment.
> Anyone who relies on Next should want Vercel to be a long-lasting company.
Well said, +1. A feature that gets people excited about a product you use, even when you're not the intended audience, is a good thing.
Well said, +1. A feature that gets people excited about a product you use, even when you're not the intended audience, is a good thing.
Next.js Live will have a completely redesigned open-source dev server, which anyone can use to create collaboration features on top – no lock in.
This server has been overhauled to run entirely in the browser, using technology like ES Modules, Service Workers, and WebAssembly.
This server has been overhauled to run entirely in the browser, using technology like ES Modules, Service Workers, and WebAssembly.
It sounds like it's removing Webpack from the equation, but how would that work if you have a custom setup with loaders etc?
Vercel being a profitable entity is what encourages them to continue supporting Next.js. It's a fine line. The product has to be built in a way for free users to easily pick it up without any immediate, tightly-coupled unavoidable lock-in. Safe to say, if you're depending on Next, you do want Vercel to win.
Great point, and you’re right – I do want to see them succeed. I suppose I just hope success doesn’t end up impeding the framework. As it is we happily pay for staging on their infrastructure, so we don’t have any issues with supporting their efforts monetarily. Hopefully that clarifies my concern better.
I think the real lock in is with serverless deployments. Its currently pretty hard to deploy nextjs to aws lambda on your own.
I thought they would announce a vercel@edge product since they made everything work with webassembly. Maybe later?
I thought they would announce a vercel@edge product since they made everything work with webassembly. Maybe later?
I haven't tried deploying it to a serverless platform personally, but surely it's no harder than anything else to spin up on a normal Node server on eg Heroku?
For partial hydration, take a look at:
- Astro[1]
- Microsite[2] (disclosure: I was just added as an owner/maintainer today! But Astro is definitely currently more mature)
- next-super-performance[3]
- Marko[4]
1: https://astro.build
2: https://github.com/natemoo-re/microsite
3: https://github.com/LukasBombach/next-super-performance
4: https://markojs.com/
- Astro[1]
- Microsite[2] (disclosure: I was just added as an owner/maintainer today! But Astro is definitely currently more mature)
- next-super-performance[3]
- Marko[4]
1: https://astro.build
2: https://github.com/natemoo-re/microsite
3: https://github.com/LukasBombach/next-super-performance
4: https://markojs.com/
To me this is just the conflict of interest just kicking in. Next is not built as rails, Django, Vue, etc... Next is a part of their business.
Don't believe it? Just look at the telemetry "feature". Try to disable it...something that should be just a config in next.config.js is a convoluted trap which will only disable it on your machine and you need to remember to disable it everywhere, etc...
As with Facebook (well, not that bad, but still...).Next isn't free.
Don't believe it? Just look at the telemetry "feature". Try to disable it...something that should be just a config in next.config.js is a convoluted trap which will only disable it on your machine and you need to remember to disable it everywhere, etc...
As with Facebook (well, not that bad, but still...).Next isn't free.
https://nextjs.org/telemetry
What's the catch here? You can opt out if set an environment variable. You can surely do that on CI as well, if that's your concern.
What's the catch here? You can opt out if set an environment variable. You can surely do that on CI as well, if that's your concern.
The catch is that this is intentionally made inconvenient. If it were a config setting I could just put it there,commit, and forget about it.
By making me setting an environment variable you are forcing me to remember to set it up in my infrastructure, on each environment, on each developer laptop, for each project independently, and if my project is open source, good luck with any user remembering/caring to set the env var.
And this is pretty intentional so that people forget or just don't care to disable it.
That's the catch.
https://github.com/vercel/next.js/issues/8851
By making me setting an environment variable you are forcing me to remember to set it up in my infrastructure, on each environment, on each developer laptop, for each project independently, and if my project is open source, good luck with any user remembering/caring to set the env var.
And this is pretty intentional so that people forget or just don't care to disable it.
That's the catch.
https://github.com/vercel/next.js/issues/8851
Next supports loading env variables from files, and as far as I can see, telemetry respects this. Add this line to a `.env` file, and it's done.
As far as I know, it looks like an experiment with Vercel more than anything. It seems the majority of the IDE development has interest beyond this, and this is a framework that wants to be first-class (I could be off on the latter part)
Great to see reduced cumulative layout shift in image tags! Next.js seems to be the only modern JS framework with accessibility by default. Still wishing i18n would work with `next export`, though.
I see Next.js being pushed into areas where is shouldn't be used. And I mean like data heavy enterprise web apps. Probably in a year or two these projects will collapse under the heavy maintenance burden and will start seeing a lot of unearned negativity towards Next.JS
I use it without SSR, just because it's a well-known and very well-maintained set of configs. Having to upgrade webpack et al. up major versions sucks.
I’m doing the same, it is the easiest out of the box react setup I’ve encountered.
The nice thing is on a current project I found there was one view where SSR made my life a lot easier and since everything was in place for it all I had to do was chuck in an extra function.
The nice thing is on a current project I found there was one view where SSR made my life a lot easier and since everything was in place for it all I had to do was chuck in an extra function.
+1 for this. The great thing is you still have the option to incrementally opt for SSR and/or enriching statically generated pages with build-time data.
Tell me about it.
Some of my colleagues are pushing hard for it. It seems like nice tech, but when you build an enterprise web app behind a login page, I see no need for server side rendering.
Our users open up the app in the morning, work on it a whole day, and do the same thing the next day.
I absolutely see no point in trying to optimize this with server side rendering.
But it seems some front-enders want to use the latest best thing, even when it's not really necessary.
But what do you do? Do you make these developers unhappy because they are not using the latest cool thing, or do you make them happy but end up with an inferior solution?
Oh boy, these youngsters... ;)
Some of my colleagues are pushing hard for it. It seems like nice tech, but when you build an enterprise web app behind a login page, I see no need for server side rendering.
Our users open up the app in the morning, work on it a whole day, and do the same thing the next day.
I absolutely see no point in trying to optimize this with server side rendering.
But it seems some front-enders want to use the latest best thing, even when it's not really necessary.
But what do you do? Do you make these developers unhappy because they are not using the latest cool thing, or do you make them happy but end up with an inferior solution?
Oh boy, these youngsters... ;)
You can disable SSR and still use Next.js. Most people don't use Next.js because of SSR, they use it because it's easy to use and has an amazing developer environment. SSR works out of the box usually so it's a nice perk.
If you're using React, Next.js is a pretty excellent choice for pretty much any website.
Appeal to Tradition is just as much a logical fallacy as Appeal to Novelty.
If you're using React, Next.js is a pretty excellent choice for pretty much any website.
Appeal to Tradition is just as much a logical fallacy as Appeal to Novelty.
"Next.js has two forms of pre-rendering: Static Generation and Server-side Rendering. The difference is in when it generates the HTML for a page."
https://nextjs.org/docs/basic-features/pages
https://nextjs.org/docs/basic-features/pages
Yeah, so why would you need a custom web server when you do CSR?
Edit: next.js is a web server, right? Because how else can it do SSR?
Edit: next.js is a web server, right? Because how else can it do SSR?
Why would you need a custom web server to run Next.js in CSR mode?
Edit: Unintentional sarcastic reply from my side, it was a good question.
Edit: Unintentional sarcastic reply from my side, it was a good question.
I'd argue most Next sites use only client side rendering.
So using the export function? Or do they still run the next.js server without having the real benefit of it?
In other words: what is the benefit of next.js when you only do CSR?
In other words: what is the benefit of next.js when you only do CSR?
It's easier, faster, and has more default features than setting up Webpack by yourself.
Great question! If you're interested, I'd recommend reading up a bit on all the different rendering and deployment modes Next offers with and without Vercel/Netlify.
If you use Next.js only for CSR, as I'm sure most people do, the benefits are great defaults, easy upgrades, fantastic routing, page prefetching, and easy upgrading to any of the other rendering modes if you ever need them.
You don't run any kind of server if you just use CSR - you bundle your code and push it to anywhere you'd push your normal React SPA (CDN, Vercel, Netlify, etc). I you decide you need to server side render or pre render a page, you can of course run a full node server - but the far easier route is to use the Vercel/Netlify lambda functions(which work out of the box with Next).
I find thinking of Next pages as separate little apps composing the same layout component to be far more maintainable than the more traditional SPA single layout swapping the contents to simulate a page transition.
If you use Next.js only for CSR, as I'm sure most people do, the benefits are great defaults, easy upgrades, fantastic routing, page prefetching, and easy upgrading to any of the other rendering modes if you ever need them.
You don't run any kind of server if you just use CSR - you bundle your code and push it to anywhere you'd push your normal React SPA (CDN, Vercel, Netlify, etc). I you decide you need to server side render or pre render a page, you can of course run a full node server - but the far easier route is to use the Vercel/Netlify lambda functions(which work out of the box with Next).
I find thinking of Next pages as separate little apps composing the same layout component to be far more maintainable than the more traditional SPA single layout swapping the contents to simulate a page transition.
You hire non hipsters.
Why shouldn't Next.js be used in "data heavy enterprise web apps?" Keep in mind that it's trivial to write code that only executes during CSR: if (typeof window !== "undefined") { fetchExpensiveExternalData(); }
Not OP but i'll take a stab at this. Many frameworks struggle to allow you to utilize a small subset of their features at full utility without producing additional overhead from features you aren't even using.
Further frameworks can be deceptive by making complex problem sets seem easy to deal with but later involve complex refactoring over time as the problem set is better understood and evidently less trivial for your organizations particular wants and needs.
These problems aren't highlighting any implicit fault of next.js. Just predicting incorrect ways developers will use it and suffer from. There is an argument to be made these problems would be made less severe if they were approached from the ground up without a framework and what opinions it brings.
Also FWIW I like next.js the project a lot. Hopefully Vercel proves a good steward for it.
Further frameworks can be deceptive by making complex problem sets seem easy to deal with but later involve complex refactoring over time as the problem set is better understood and evidently less trivial for your organizations particular wants and needs.
These problems aren't highlighting any implicit fault of next.js. Just predicting incorrect ways developers will use it and suffer from. There is an argument to be made these problems would be made less severe if they were approached from the ground up without a framework and what opinions it brings.
Also FWIW I like next.js the project a lot. Hopefully Vercel proves a good steward for it.
Some people here seem confused why SSR is not the optimal solution for heavy web apps, so let me explain.
Such web apps can be downloaded to the client the first time you open the page, and after that (basically every day), caching strategy makes sure you don't have to download that thing again.
Which means you only need to transfer pure data at that point, and you can have a very responsive web page.
SSR rendering on the other hand, you will get some kind of PHP website (OK, this is exaggerated, but you get the point). Requests go back to the server, and the server renders the page. Totally ludicrous.
SSR: for landing pages, SEO optimization, showing the same page to a lot of users, etc.
CSR: for heavy apps that you use regularly, basically "real" applications, not web pages.
Such web apps can be downloaded to the client the first time you open the page, and after that (basically every day), caching strategy makes sure you don't have to download that thing again.
Which means you only need to transfer pure data at that point, and you can have a very responsive web page.
SSR rendering on the other hand, you will get some kind of PHP website (OK, this is exaggerated, but you get the point). Requests go back to the server, and the server renders the page. Totally ludicrous.
SSR: for landing pages, SEO optimization, showing the same page to a lot of users, etc.
CSR: for heavy apps that you use regularly, basically "real" applications, not web pages.
> SSR rendering on the other hand, you will get some kind of PHP website (OK, this is exaggerated, but you get the point). Requests go back to the server, and the server renders the page. Totally ludicrous.
NextJS only renders (or gets the static HTML) and sends you the HTML for the first page you navigate to. When you click a link on that page, it just sends you the data (and JS if needed).
NextJS only renders (or gets the static HTML) and sends you the HTML for the first page you navigate to. When you click a link on that page, it just sends you the data (and JS if needed).
In theory, yes. But is anyone actually effectively writing apps in that way? I can't think of a single good example I've seen in the wild.
Most of the time the app is either large and sprawling, updated frequently, or XHR fetches are written in an inefficient way. All of these nullify the benefits from the model of having cached application code. For example if you're waiting for your JS app to initialise, then fetching XHR in a serial way you're probably slower than an SSR page that is sending a data blob down inline.
I'd say SSR is a good rule of thumb, and the few people who build SPAs who can make use of this will know when to break that rule.
Most of the time the app is either large and sprawling, updated frequently, or XHR fetches are written in an inefficient way. All of these nullify the benefits from the model of having cached application code. For example if you're waiting for your JS app to initialise, then fetching XHR in a serial way you're probably slower than an SSR page that is sending a data blob down inline.
I'd say SSR is a good rule of thumb, and the few people who build SPAs who can make use of this will know when to break that rule.
[deleted]
This comment is highly misleading. It implies that SSR vs CSR is an “either or” proposition:
> SSR rendering on the other hand... Requests go back to the server... Totally ludicrous.
For Next.js, this description of routing and rendering is “Totally” incorrect. I don’t know about other SSR frameworks (except maybe PHP, which does actually work as the parent comment describes), but with Next.js, you get SSR on first page load and CSR on subsequent clicks.
Thats the whole point of next/router and the <Link> component. Hovering a <Link> will download (“pre-load”) the tiny JS file required to render the next page. Clicking it will trigger client side rendering, without any new server side page load.
The complexity that causes this kind of misunderstanding is the best argument against SSR.
> SSR rendering on the other hand... Requests go back to the server... Totally ludicrous.
For Next.js, this description of routing and rendering is “Totally” incorrect. I don’t know about other SSR frameworks (except maybe PHP, which does actually work as the parent comment describes), but with Next.js, you get SSR on first page load and CSR on subsequent clicks.
Thats the whole point of next/router and the <Link> component. Hovering a <Link> will download (“pre-load”) the tiny JS file required to render the next page. Clicking it will trigger client side rendering, without any new server side page load.
The complexity that causes this kind of misunderstanding is the best argument against SSR.
in our teams experience NextJS is pretty much a silver bullet for data heavy enterprise apps
Can you elaborate?
My understanding is that SSR and NextJS are good for SEO and low powered devices with a slow connection. You load the content before the interactive js ...etc.
Why would enterprise apps care about SEO, slow connection speeds.
If it's data heavy, it means you still need to fetch data from db before you return html, so SSR is pointless.
> If it's data heavy, it means you still need to fetch data from db before you return html, so SSR is pointless.
I'm very confused by this statement. Maybe I'm just being slow. If you want to fetch data from the db before returning html, then SSR is exactly what you want.
I'm very confused by this statement. Maybe I'm just being slow. If you want to fetch data from the db before returning html, then SSR is exactly what you want.
He's not wrong in some cases. If bandwidth cost from Next->Client exceeds cost from DataSource->Client, then you want to opt out of SSR, to avoid DataSource->Next->Client in favor of direct DataSource->Client during CSR.
Example: Next deployed to AWS (metered bandwidth), with DataSource deployed to colocation (unmetered bandwidth). Page fetches 1GB CSV from DataSource in order to render an HTML Table. In this case, you likely prefer the client to fetch directly from DataSource and render the HTML table during CSR. An exception might be if you care about the table for SEO purposes (e.g. structured data) – but in that case, you should find a way to fetch the first 10 rows instead of 1GB.
It's a fairly niche use-case, though, and it's easy to opt out of SSR for specific code/requests (check if window is defined) or pages (use Next getServerProps vs. getStaticProps).
As an aside... this convoluted scenario highlights one criticism I have with Next.js: It is NOT a friendly mental model for junior engineers. You cannot write a robust Next app without a thorough understanding of the HTTP request lifecycle, network architectures, closures, database/HTTP pools, caching, cookies, etc. If you stay within the lines, you can avoid worrying about most of this stuff, but it's impossible to fully grok Next without a strong background in web fundamentals. If I were advising a beginner on the best stack for practicing React, I would suggest starting with create-react-app, even though I think Next is ultimately the best production framework.
Example: Next deployed to AWS (metered bandwidth), with DataSource deployed to colocation (unmetered bandwidth). Page fetches 1GB CSV from DataSource in order to render an HTML Table. In this case, you likely prefer the client to fetch directly from DataSource and render the HTML table during CSR. An exception might be if you care about the table for SEO purposes (e.g. structured data) – but in that case, you should find a way to fetch the first 10 rows instead of 1GB.
It's a fairly niche use-case, though, and it's easy to opt out of SSR for specific code/requests (check if window is defined) or pages (use Next getServerProps vs. getStaticProps).
As an aside... this convoluted scenario highlights one criticism I have with Next.js: It is NOT a friendly mental model for junior engineers. You cannot write a robust Next app without a thorough understanding of the HTTP request lifecycle, network architectures, closures, database/HTTP pools, caching, cookies, etc. If you stay within the lines, you can avoid worrying about most of this stuff, but it's impossible to fully grok Next without a strong background in web fundamentals. If I were advising a beginner on the best stack for practicing React, I would suggest starting with create-react-app, even though I think Next is ultimately the best production framework.
When you do a proper REST call, your data is always going to be smaller than your html+data.
If you don't show it, you don't need to query it.
If you don't show it, you don't need to query it.
> low powered devices with a slow connection
Some would argue that React in general isn't a good fit for low-powered devices with a slow connection, because of its bundle size, long first input delay and a rather high cost of heavy javascript usage during re-rendering.
Some would argue that React in general isn't a good fit for low-powered devices with a slow connection, because of its bundle size, long first input delay and a rather high cost of heavy javascript usage during re-rendering.
In many cases SSR is automatically better, including the ones you're talking about, because page rendering errors get thrown in an environment you have more control over, as well as faster devices rendering your already fast pages even faster. In my experience, enterprise work stations are clunky abominations, and if you can save someone some ram and battery why not? It also gives you a platform for building other kinds of non-gated apps that inherit the same benefits.
You might think you have control over the environment someone accesses the app in, but you don't, at least not entirely, and why not just make it as easy as possible to get their work done however they want?
Of course, this doesn't make your thing automatically better all around. That's a design and implementation problem. But you do potentially help everyone by starting at the bottom
You might think you have control over the environment someone accesses the app in, but you don't, at least not entirely, and why not just make it as easy as possible to get their work done however they want?
Of course, this doesn't make your thing automatically better all around. That's a design and implementation problem. But you do potentially help everyone by starting at the bottom
Round trip to the server to compose your HTML feels less responsive. Else you could just do it in PHP anyway.
Surely you wouldn't just be server side rendering though. Nobody needs a page load for every route change necessarily. These are implementation details.
> you could just do it in PHP
That's two languages: javascript and php. Many frontend developers would prefer to just work with one — javascript.
That's two languages: javascript and php. Many frontend developers would prefer to just work with one — javascript.
Why should Next.js not be used for this use case?
Isnt that what happened to Gatsby oO
isn't that what happened with every js framework ?
99% of all js project would have been better with an old school framework (Rails/Symfony/Django/laravel, and any other framework I forgot the name)
99% of all js project would have been better with an old school framework (Rails/Symfony/Django/laravel, and any other framework I forgot the name)
Next excels in frontend grease, a place where the ssr frameworks do not venture.
I so agree that next is not the ultimate answer. Still waiting for the absolute best of both worlds.
I so agree that next is not the ultimate answer. Still waiting for the absolute best of both worlds.
Maybe something like Phoenix liveview? (or htmx / livewire / hotwire/ etc.)
Write SSR, but have the ability to render partials and swap html chunks into the DOM directly rather than running json through a CSR library.
You still get client originated events (user clicks a button) or server originated events, e.g. server wants to proactively push a change - at least for liveview and htmx.
Write SSR, but have the ability to render partials and swap html chunks into the DOM directly rather than running json through a CSR library.
You still get client originated events (user clicks a button) or server originated events, e.g. server wants to proactively push a change - at least for liveview and htmx.
Phoenix Liveview shows great idea, but I prefer to develop in typed environment so I'm working on ts-liveview (TSX+SSR+live-update)
The great thing about Next.js is that it’s simple to choose exactly how much of a page is ssr. You can have 0% to 100%.
This whole conference could have been an email.
Well to be fair at least it was only 20 minutes. But yes, I don't really see the point in the whole Apple-like video production.
The interesting and useful part of the conference (to me) was the live video chat and Q/A with the 7 devs after the polished video, which is still going on right now.
That sounds cool! But on their YouTube I only see the 24 minute keynote. Do you have a link to this Q/A?
Really happy to see blur placeholders and automatic dimension detection of local sources being added to the Image component.
I've only very recently heard of Next.js, what is the ideal use case for it?
As Next ambiguously puts it: "The React Framework for Production" [0]
It's excellent for building page-based sites and apps and comes with lots of nifty features that just seem to work. And, the most part, it's just out of your way.
Regarding the ideal use, I'd say any project that benefits greatly from (partially) pre-rendered content and statically generated pages is best served by Next and its data fetching [1]. I can't think of a FE-based solution that is anywhere near as good. It's also the only sane way to work with the insanity that is JAM stack [2].
Whatever you do, it's a safe bet.
0 - https://nextjs.org
1 - https://nextjs.org/docs/basic-features/data-fetching
2 - https://jamstack.org
It's excellent for building page-based sites and apps and comes with lots of nifty features that just seem to work. And, the most part, it's just out of your way.
Regarding the ideal use, I'd say any project that benefits greatly from (partially) pre-rendered content and statically generated pages is best served by Next and its data fetching [1]. I can't think of a FE-based solution that is anywhere near as good. It's also the only sane way to work with the insanity that is JAM stack [2].
Whatever you do, it's a safe bet.
0 - https://nextjs.org
1 - https://nextjs.org/docs/basic-features/data-fetching
2 - https://jamstack.org
sounds similar to aspnet razor pages. is it?
Looking at the razor pages overview & that seems a very reasonable comparison (now you mention that, see PHP, in the form of "just chuck a few files on a server that understands them and off you go, dynamic website")
It's a fairly guard-railed, easy to deploy, React-based static site generator with dynamic content capabilities as well. It's generally great software. My team uses it for https://instantdomainsearch.com and we get good performance and developer experience overall.
To me it feels like the React "happy path" at the moment if you need a static or partially dynamic site/web application. I suppose the ideal use case is essentially any site you want to serve statically but maintain with React. This could be a blog, graphic design portfolio, or even a small store. It makes it easy for us to embed our React-based search application inside of a site with static content beside it that's easy to maintain and create.
Yeah, we could do this without next, but it provides some convention and well-made tools that generally make the job easier.
To me it feels like the React "happy path" at the moment if you need a static or partially dynamic site/web application. I suppose the ideal use case is essentially any site you want to serve statically but maintain with React. This could be a blog, graphic design portfolio, or even a small store. It makes it easy for us to embed our React-based search application inside of a site with static content beside it that's easy to maintain and create.
Yeah, we could do this without next, but it provides some convention and well-made tools that generally make the job easier.
Cool, I'm a big fan of instantdomainsearch (it's my goto domain search tool) and had no idea how you can lookup the domains that fast. Is it fair to say that Next.js is a big part of that performance?
Next.js isn't a significant part of the run time performance of actual searching – that's fast because of a lot of custom infrastructure, data pre-processing, and client side code.
Next mostly makes it so pulling the site down and loading the page is snappier without us having to try particularly hard to get it that way. It isn't totally effortless - we've got some tailored pieces in our pipeline, but Next "off the shelf" does an excellent job already, and the work they've done makes customizations easy to implement and maintain.
I'm glad to hear you like it! Seriously, it makes it way more interesting knowing people are enjoying it. Every little tweak and improvement to performance is worth it when people are getting something out of it.
Next mostly makes it so pulling the site down and loading the page is snappier without us having to try particularly hard to get it that way. It isn't totally effortless - we've got some tailored pieces in our pipeline, but Next "off the shelf" does an excellent job already, and the work they've done makes customizations easy to implement and maintain.
I'm glad to hear you like it! Seriously, it makes it way more interesting knowing people are enjoying it. Every little tweak and improvement to performance is worth it when people are getting something out of it.
I also really like instantdomainsearch.com. I don't have any specific feedback, but thank you for your team's work!
You’re welcome!
I've only ever used Gatsby with this, how does it compare?
Good question.
Our migration was fairly direct. We did it in around a week with some cleanup in the following week. There were analogous conventions throughout just about the entire migration, so they're very similar.
One thing we liked was better TypeScript support. We're big on types and proper support, and most of our company is based on TypeScript and Rust. Gatsby can use TS, but you need to set it up and we came across the odd hiccup in the tooling. Next supports this off the shelf and so far, it shows. We haven't had any issues with compilation anywhere in the pipeline or other tooling.
The way Next handles dynamic pages is different, and in my opinion nicer. It also supports something they call incremental static generation which allows pages to be served statically, but incrementally updated as dependent data changes. For example, you know the team in the lead will be the same for thousands of requests, so you might as well serve that statically until the leading team changes. Next will manage that content update for you while serving the content statically for as long as possible. When we migrated, Gatsby didn't support this feature.
Next handles pages differently in general. It maps your directory structure under /src/pages, so that /src/pages/hello-world.tsx will be yourwebsite.com/hello-world. It allows for dynamic content using a convention in which file names can represent a variable, where src/pages/foo/[bar].tsx will make it so [bar] is a variable in the query intercepted by getServerSideProps when you visit yourwebsite.com/foo/whatever.
Otherwise I think the main snag we had with Gatsby was that the team was slower to address issues, introduced bugs more frequently, and we began to see that it was impeding our progress. Our software was working independently of Gatsby and wasn't the issue, and no matter how closely we worked with the maintainers, we couldn't move the needle on any blocking issues. With Next it has been a much different story. Issues are unblocked routinely and the maintainers seem much more engaged and productive.
There's more, but those are the main differences that come to mind.
Our migration was fairly direct. We did it in around a week with some cleanup in the following week. There were analogous conventions throughout just about the entire migration, so they're very similar.
One thing we liked was better TypeScript support. We're big on types and proper support, and most of our company is based on TypeScript and Rust. Gatsby can use TS, but you need to set it up and we came across the odd hiccup in the tooling. Next supports this off the shelf and so far, it shows. We haven't had any issues with compilation anywhere in the pipeline or other tooling.
The way Next handles dynamic pages is different, and in my opinion nicer. It also supports something they call incremental static generation which allows pages to be served statically, but incrementally updated as dependent data changes. For example, you know the team in the lead will be the same for thousands of requests, so you might as well serve that statically until the leading team changes. Next will manage that content update for you while serving the content statically for as long as possible. When we migrated, Gatsby didn't support this feature.
Next handles pages differently in general. It maps your directory structure under /src/pages, so that /src/pages/hello-world.tsx will be yourwebsite.com/hello-world. It allows for dynamic content using a convention in which file names can represent a variable, where src/pages/foo/[bar].tsx will make it so [bar] is a variable in the query intercepted by getServerSideProps when you visit yourwebsite.com/foo/whatever.
Otherwise I think the main snag we had with Gatsby was that the team was slower to address issues, introduced bugs more frequently, and we began to see that it was impeding our progress. Our software was working independently of Gatsby and wasn't the issue, and no matter how closely we worked with the maintainers, we couldn't move the needle on any blocking issues. With Next it has been a much different story. Issues are unblocked routinely and the maintainers seem much more engaged and productive.
There's more, but those are the main differences that come to mind.
> Gatsby can use TS, but you need to set it up
I'm not sure how long ago you tried Gatsby, but TypeScript doesn't require setup anymore. Just change the file extensions to .tsx/.ts and it works. It also does incremental builds.
Gatsby handles pages in src/pages the same way except it doesn't use placeholders in the filenames. You generate dynamic pages by writing a function. Check out these videos.
https://egghead.io/courses/why-gatsby-uses-graphql-1c319a1c
I'm not sure how long ago you tried Gatsby, but TypeScript doesn't require setup anymore. Just change the file extensions to .tsx/.ts and it works. It also does incremental builds.
Gatsby handles pages in src/pages the same way except it doesn't use placeholders in the filenames. You generate dynamic pages by writing a function. Check out these videos.
https://egghead.io/courses/why-gatsby-uses-graphql-1c319a1c
Right, graphql - I'm not sure how I forgot about that. We really disliked this part of Gatsby, but I know some people really like it. I can't criticize it really - it probably comes down to preference.
I guess it's been longer than I thought! Incremental builds wasn't even on the roadmap when we migrated.
I guess it's been longer than I thought! Incremental builds wasn't even on the roadmap when we migrated.
I guess it depends on what you're building. For me the graphql is one of the most useful features. I've only used Next a little, but much prefer Gatsby. I don't think Next is bad though.
This is a hell of an answer for a small question, I really appreciate your write-up!
We're using it to build a headless Jamstack (headless CMS backend, React frontend).
Next.js makes the frontend a lot nicer to work with, especially if you want to deploy to a serverless config. Out of the box, it handles things like:
* Data pre-fetching (Next talks to the CMS during build instead of via a clientside request during load), then inlines the JSON response into the page so the React components have access to their initial load data (like the first page in a gallery, or the first set of blog posts) as soon as the page loads. No AJAX required. It's FAST for visitors.
* Handles page routing (like /blog/my-post or /products/24453) by mapping CMS entries into page templates
* Makes the developer experience a lot nicer, with preconfigured but extensible webpack, sass, tailwinds etc. support. Also extends the create-react-app dev server to support all the next features so you can get a good preview of how something works before you build for production
* Adds a bunch of optimizations (CSS, web fonts, tree-shaking) for faster performance
* Has optional modules you can use (authentication, ecommerce, AMP, etc.)
* It renders React + the data into straight HTML+CSS (again, fast) and that means some React components also work without Javascript enabled
Additionally, if you host on Vercel*, you get some additional features:
* Automatic image optimizations (auto-generated srcsets, webp, blurry lazy loads, etc. on the CDN)
* Incremental static regeneration: A backend server monitors the CMS for changes every X seconds, then rebuilds only the affected page (in a few seconds) instead of the whole project
* Complex rewrite rules that would normally be difficult with a static site. Not as powerful as .htaccess or Varnish rules, but good enough for simple cases
In general, the upside is that it turns React from a feature library to a more fully-featured web app framework. Still not as powerful as Angular, but hits that sweet spot where you can easily spin up a website with Next.js in a few minutes, and not have to worry about scaffolding or be overwhelmed by having to get a PhD in Angular before you can start using it.
The downside is that its primary maintainer, Vercel, also runs a hosting service. There is an inherent conflict of interest there because some Next.js are Vercel-only, and these are NOT clearly labeled in the docs. You just have to find out, upon deployment, that some features just invisibly break with no error or warning if you try to self-host or host elsewhere. Everything magically works on Vercel, but it's a crapshoot anywhere else. And it's only getting worse as they keep iterating features like next/image or Next Live but only with Vercel support.
Edit: Sorry about the formatting. I don't know what formatting engine HackerNews uses but it's awkward.
Next.js makes the frontend a lot nicer to work with, especially if you want to deploy to a serverless config. Out of the box, it handles things like:
* Data pre-fetching (Next talks to the CMS during build instead of via a clientside request during load), then inlines the JSON response into the page so the React components have access to their initial load data (like the first page in a gallery, or the first set of blog posts) as soon as the page loads. No AJAX required. It's FAST for visitors.
* Handles page routing (like /blog/my-post or /products/24453) by mapping CMS entries into page templates
* Makes the developer experience a lot nicer, with preconfigured but extensible webpack, sass, tailwinds etc. support. Also extends the create-react-app dev server to support all the next features so you can get a good preview of how something works before you build for production
* Adds a bunch of optimizations (CSS, web fonts, tree-shaking) for faster performance
* Has optional modules you can use (authentication, ecommerce, AMP, etc.)
* It renders React + the data into straight HTML+CSS (again, fast) and that means some React components also work without Javascript enabled
Additionally, if you host on Vercel*, you get some additional features:
* Automatic image optimizations (auto-generated srcsets, webp, blurry lazy loads, etc. on the CDN)
* Incremental static regeneration: A backend server monitors the CMS for changes every X seconds, then rebuilds only the affected page (in a few seconds) instead of the whole project
* Complex rewrite rules that would normally be difficult with a static site. Not as powerful as .htaccess or Varnish rules, but good enough for simple cases
In general, the upside is that it turns React from a feature library to a more fully-featured web app framework. Still not as powerful as Angular, but hits that sweet spot where you can easily spin up a website with Next.js in a few minutes, and not have to worry about scaffolding or be overwhelmed by having to get a PhD in Angular before you can start using it.
The downside is that its primary maintainer, Vercel, also runs a hosting service. There is an inherent conflict of interest there because some Next.js are Vercel-only, and these are NOT clearly labeled in the docs. You just have to find out, upon deployment, that some features just invisibly break with no error or warning if you try to self-host or host elsewhere. Everything magically works on Vercel, but it's a crapshoot anywhere else. And it's only getting worse as they keep iterating features like next/image or Next Live but only with Vercel support.
Edit: Sorry about the formatting. I don't know what formatting engine HackerNews uses but it's awkward.
If you have a simple marketing or brochure site, and want to use React, it’s pretty much a no brainer.
Anything more complicated eg a dashboard app, you’re going to be fighting it a lot.
Anything more complicated eg a dashboard app, you’re going to be fighting it a lot.
I do not agree with that assessment at all. Next.js is great for making SPAs and full web apps. I've made three (profitable) projects with Next.js and never felt like I had to fight it
Likewise, I've found it great at allowing you to embed complex logic into dumb content.
What we needed was convention to deliver static content easily without needing to build it ourselves. But we also needed it to stay out of the way of our business logic. Overall, Next has done a stellar job of that. It allows us to build the stuff that matters to us while leaving what Next is great at to Next and its maintainers.
The vercel platform has also been great for us when staging deployments. It's a little slow, but the integration and ease of use again lets us focus on our own business. I don't care to build out staging infrastructure for mostly static content. It's well within everyone's ability on this team, but it's time consuming in investment and maintenance. Recouping that cost is what Next has been great for, from end to end.
What we needed was convention to deliver static content easily without needing to build it ourselves. But we also needed it to stay out of the way of our business logic. Overall, Next has done a stellar job of that. It allows us to build the stuff that matters to us while leaving what Next is great at to Next and its maintainers.
The vercel platform has also been great for us when staging deployments. It's a little slow, but the integration and ease of use again lets us focus on our own business. I don't care to build out staging infrastructure for mostly static content. It's well within everyone's ability on this team, but it's time consuming in investment and maintenance. Recouping that cost is what Next has been great for, from end to end.
The key is being page-based. If you can use the browser and URLs as a state machine for your application, Next is excellent. Its dynamic routing is a breeze to work with.
However, if you build an application where that browser-as-state-machine doesn't hold up, you're better off somewhere else.
However, if you build an application where that browser-as-state-machine doesn't hold up, you're better off somewhere else.
Yeah, you have to follow their design pattern / scaffolding very closely. The tradeoff is less flexibility for faster dev cycles.
Really? I've made multiple attempts and always get stuck as soon as you have nested layouts or routes, which dashboards nearly always do (with master/detail views for instance).
"Nested layouts" just sounds like nested React components.
React is kinda weird… you have to do subcomponents the "React way" and I think a lot of folks struggle with that; it can feel like fighting. But I don't think Next makes that any easier or harder.
I don't know what you mean by "nested routes." Routes are just URLs that map to files. You can create a directory with files, and, uh, subdirectories with files, if you want…?
React is kinda weird… you have to do subcomponents the "React way" and I think a lot of folks struggle with that; it can feel like fighting. But I don't think Next makes that any easier or harder.
I don't know what you mean by "nested routes." Routes are just URLs that map to files. You can create a directory with files, and, uh, subdirectories with files, if you want…?
In Next, every route blows away the DOM and starts over. You can’t have nested routes like you can in React Router, where say you have different layout shells for logged out / logged in views, and then master/detail views where you navigate down a hierarchical navigation.
Well you sort of can. Just have a [view].js file, where the view variable will be the component. So you can have {view === 'details' && <Details />}
I’m guessing they mean pieces of state based on urls, like which tab is active here or is a modal open or closed kind of thing.
Do you have any public project template repos?
For the interested they are having a conference right now [1].
1: https://www.youtube.com/watch?v=ze8ycxc1UzE
1: https://www.youtube.com/watch?v=ze8ycxc1UzE
Really solid release, congrats to the team and contributors!
P.S. I have noticed that you put a markdown link as `src` prop value in the first `Script` example.
P.S. I have noticed that you put a markdown link as `src` prop value in the first `Script` example.
Related ongoing thread:
Next.js Live: Code in the Browser with ESM, ServiceWorkers, Replicache, and WASM - https://news.ycombinator.com/item?id=27517440 - June 2021 (23 comments)
Next.js Live: Code in the Browser with ESM, ServiceWorkers, Replicache, and WASM - https://news.ycombinator.com/item?id=27517440 - June 2021 (23 comments)
Amazing work on these built-in/opt-in performance, accessibility, UX and DX features!
Do they maintain old releases? for how long?
can't find any information about it
can't find any information about it
They don’t. Next.js uses the same release methods of React.js. If the previous major version doesn’t give you any warnings, you can upgrade without any modifications.
You can check upgrade guide here: https://nextjs.org/docs/upgrading
No one maintains anything in JS world. You just upgrade or hop to the next framework. The ES spec I believe discusses backwards compatibility but that only applies at the language level.
It wouldn’t be the cool hip framework if it had to commit resources to older versions.
It wouldn’t be the cool hip framework if it had to commit resources to older versions.
Nodejs, arguably a big part of the "JS-world", has LTS https://nodejs.org/en/about/releases/
This is node itself, not libraries or frameworks.
You’re downvoted because Node is considered a framework. So while you’re not technically correct, I think your response is still valid as “I caught your drift”.
You're not wrong but there's probably a nicer way to say it.
Honestly it’s the last line that gets me the downvotes (oh no downvotes!) and this was intended. I think being brash about it is a good way to take a look at where the world can improve.
what is the next.js sanctioned way to handle css in js?
I think it's explained here: https://nextjs.org/docs/basic-features/built-in-css-support
Basically strong encouragement and support for CSS modules, but some other escape hatches and approaches are supported.
Basically strong encouragement and support for CSS modules, but some other escape hatches and approaches are supported.
> Since Next.js 10, we've been obsessed with further improving the developer experience of Next.js. In 10.1 and 10.2 we improved startup time by up to 24% and shaved off another 40% of processing time for changes through React Fast Refresh. You've been getting these amazing speed improvements just by keeping Next.js updated.
I know they think this is good marketing, but it absolutely does not inspire confidence. Why was it so slow to begin with? Why would someone who’s never used Next.js want to use it after reading this?
Too many JavaScript projects talk about how much faster they’re getting or how “blazing” fast they are. I don’t think these people know what “fast” is.
I know they think this is good marketing, but it absolutely does not inspire confidence. Why was it so slow to begin with? Why would someone who’s never used Next.js want to use it after reading this?
Too many JavaScript projects talk about how much faster they’re getting or how “blazing” fast they are. I don’t think these people know what “fast” is.
So basically your argument is:
- JavaScript is too slow
- Too many JavaScript projects try to not be slow
Am I getting this right?
- JavaScript is too slow
- Too many JavaScript projects try to not be slow
Am I getting this right?
Do you feel the same way when Apple releases a new chip that is X% faster? For many people: complete + iteration > optimized with less functionality
Most of the time savings of a modern JS framework are in thinking/coding/researching phases, not "waiting for my build to finish". Even for a big site, startup time is not important at all if you have hot reloading.
I disagree, start up time is still very useful to improve if developers only interact with your project maybe once a week. It’s also very handy if you’re doing CD, as your entire build pipeline will finish more quickly, which makes reverts and deploys faster. It’s also good for quick bug fixes, where something needs to be fixed as quickly as possible. It can make a big difference on big sites, from like 10 minutes to 1 or 2 minutes.
The only option that comes to my mind is using Vercel to host the site but then every image is transformed on demand which results in horrendous loading times.
Is this really how „everyone“ uses Next when exporting static sites?