9 ms·

Next.js 9.5

174 points by leerob 6y ago

gremlinsinc 6y ago
Curious, anyone know how this would compare performance wise for something like Reddit verses livewire/liveview. I know those would be more reactive, but I like the idea of static pages that are dynamic as well.
- deleted 6y ago
  [deleted]
- leerob 6y ago
  Not exactly the same, but the Vercel team made a demo using Twitter with static generation. https://static-tweet.now.sh/ https://static-tweet.now.sh/
tunesmith 6y ago
Incremental Static Site Regeneration is really compelling, I wonder what the gotchas are. For instance, I have a project where the front page gets server-side-rendered for logged out users. We can't do client-side-rendering because we care about SEO. And we can't do static-generation at build time because the content of the front page regularly changes (it summarizes activities of other users). But with incremental static site generation... even if we care about the community always having up-to-date data on that front page, we could presumably set the timeout to like five seconds. That's a heck of a savings compared to generating it on every request.
- ss3000 6y ago
  I haven't really kept up to date in this area so would love to hear some experts weigh in here: Do search engines (or really just Google) still penalize sites that are pure SPAs on that fact alone? Or does it have more do do with properties generally associated with SPAs like large bundle sizes or slow time to first interaction? I'm mainly wondering if you can build a SEO-friendly SPA marketing page today using techniques like dynamic imports and code splitting to lazy load just the scripts and content needed for the initial render instead of going all the way to static generation or server side rendering.
  - azangru 6y ago
    > Do search engines (or really just Google) still penalize sites that are pure SPAs on that fact alone? Google says that they don't. They use an evergreen googlebot, which is the latest (or thereabouts) release of headless Chrome browser; and it waits for the scripts to load and executes them. You can watch Martin Splitt's talk from the recent web.dev live event for the latest updates. Server-side rendering is still important if you care for other search bots or if you want to share your site's pages on social media (with page preview).
    - bitten 6y ago
      do you have a link to the talk?
      - azangru 6y ago
        Yes: https://youtu.be/himvKu12YCY https://youtu.be/himvKu12YCY
  - siquick 6y ago
    If its important that your sites content will be shared on social media then SSR is a must due to meta tags Facebook/Twitter use to create the posts preview.
- silviogutierrez 6y ago
  Maybe I'm missing something, but ultimately, isn't this just a re-invention of a site-wide cache? Back in the day, in Django/Drupal/any CMS, for anonymous users, you'd just dump each page into memcached with a path URL. Then when a new anonymous visitor comes, you load it right up from – extremely fast – memory. Maybe even faster than loading from the file system? Nginx can actually ask memcached directly, even bypassing the app server. It feels like we've gone full circle.
  - dmartinez 6y ago
    My take is that it implements the benefits you describe for simple sites that might have less infrastructure at their disposal. It seems like you still need a node runtime to rebuild the files when the cache needs to be regenerated, however.
  - switz 6y ago
    You're not totally wrong, but think of it this way. You have native support in your application stack for this static 'caching' along with one-click edge distribution. Which means you can write extremely complex, interactive markup (it's just React) on top of this very simple distribution system. And you don't have to build a whole magic caching system or deal with web servers at all. I've worked with similar systems to the one you've laid out -- tell me you've never had to jump into the cache to clear it because a client wasn't seeing their updates. Or a page was getting improperly cached. Even if it was simple and effective, it was often a pain. These days, there are a number of services that will store your html and other static files on their edge CDN servers (cloudflare workers, vercel, netlify, among others) leading to your users downloading the files at remarkably fast speeds. You can reach a pretty amazing TTI while maintaining nigh infinite scalability. I will say that while I personally use next.js, I stick entirely with server-side rendering. I find it to be a better all-around user-experience for my use-case with several distinct advantages. But I only serve ~150,000 users a month, who are all relatively close to my server and I don't have much static content. A modest ec2 instance handles it with ease. But if I was building an application that targeted many regions and needed infinite scalability, or one that heavily utilized static data, I'd definitely consider pursuing the approach laid out above. We've gone 'full circle', sure. Because React offered a way to write web applications in a much more consistent, interactive way than anything before it. But we spent a few years growing our bundle sizes out of control, and improperly structuring our applications which led to TTI growing and everything being slow and clunky. Companies that cared and had good engineering were able to navigate these problems, but your average developer couldn't. Now with a system like this, they can not only match the performance of classic applications, but in many cases exceed it.
- penagwin 6y ago
  I don't know what archetecture your website uses, but our site for example we just cache the view into redis for however long. It's built into a lot of webframeworks, but shouldn't be too crazy to implement by hand.
- dbbk 6y ago
  Can’t you just stick a Cloudflare cache in front of it and call it a day?
  - tunesmith 6y ago
    I'm still exploring this, but my sense is that with Next.JS, the cached version is still deposited on the edge cache at build time, so you don't have that first expensive query. Not sure if you can do something like that with Cloudflare alone. Second is that with Next.JS, expiration means that it gets built and re-deposited onto the edge cache in the background, without ever needing that expensive query. Again, not sure if you can do something like that with Cloudflare alone.
azangru 6y ago
It's interesting that the React Router team, which is building the competing Remix framework (similar to Next but based on React Router) is arguing that instead of supporting static page generation, they will just urge their users to use CDNs with aggressive caching rules.
- leerob 6y ago
  I'd imagine the hard part with that approach would be cache invalidation. I'm curious to see how they try and address it.
  - dbbk 6y ago
    You could use webhooks on deploy to call your CDN's API to purge the cache. Otherwise, I guess just keep it time-based.
- dbbk 6y ago
  This instinctively makes more sense to me. Still, good to have options. It will be interesting to see how Remix is received once it launches. Next is currently peerless for DX-friendly React frameworks.
ianwalter 6y ago
Developing a Next.js app is a really nice experience. I admit when it first came out I didn't pay that much attention to it because I thought how it did routing was weird and I don't think the server was as extensible. Fast forward to 9.5 and there's pretty much no real reason for me to build a custom Webpack-based setup for my next project.
bionhoward 6y ago
i love vercel and use it for all my projects, right up until i need to add auth/api, at which point I switch off of it immediately for security reasons because there are no static IPs unless you're an "enterprise" customer it's unclear why they're rolling out performance features while this critical security hole persists. no doubt i'll get flamed for it, but, it's a really bad idea to use dynamic IPs to connect to your database with only a password...
- luisrudge 6y ago
  I guess you’re talking about Vercel.com instead of Next.JS, right?
  - bionhoward 6y ago
    Yep
- djstein 6y ago
  Can you expand on what the static IPs give you?
  - wereHamster 6y ago
    For use in firewall rules
- maxast 6y ago
  oh yeah, I remember running into that problem when I was using a database on Digital Ocean and wanted to add vercel api routes as a trusted source. I had also switched off of it because of that. However, I had a look at their blog the other day and apparently they have an Anycast IP range now, which probably solves this issue https://vercel.com/blog/new-edge-dev-infrastructure#vercel's-own-anycast-ip-range https://vercel.com/blog/new-edge-dev-infrastructure#vercel's.... I haven't tried it yet though
deleted 6y ago
[deleted]
droptablemain 6y ago
This is great -- can't wait to update and try this out.
huangbong 6y ago
Great product. Them deciding to rebrand from Zeit to Vercel was one of the worst branding decisions ever made.
- leerob 6y ago
  Curious, why do you think that? Any rebranding will have backlash. It solved the issue of ZEIT Now being one _product_ whereas Vercel is the _platform_. It also brought a new focus on Jamstack and front-end developers. I'll admit I'm biased though, as I'm a Vercel customer.
  - huangbong 6y ago
    They could’ve just used ZEIT as the platform then. Vercel sounds like some generic VC created tech name. Their customer base is literally the exact opposite. Indie developers, people with Github accounts, technical engineers, engineering leaders. Not some Salesforce CRM enterprise selling to CEO’s marketing bs “Vercel” lol.
dmitryminkovsky 6y ago
Beautiful release!

174 points by leerob 6y ago

Curious, anyone know how this would compare performance wise for something like Reddit verses livewire/liveview. I know those would be more reactive, but I like the idea of static pages that are dynamic as well.

deleted 6y ago
[deleted]
leerob 6y ago
Not exactly the same, but the Vercel team made a demo using Twitter with static generation. https://static-tweet.now.sh/ https://static-tweet.now.sh/

tunesmith 6y ago

Incremental Static Site Regeneration is really compelling, I wonder what the gotchas are. For instance, I have a project where the front page gets server-side-rendered for logged out users. We can't do client-side-rendering because we care about SEO. And we can't do static-generation at build time because the content of the front page regularly changes (it summarizes activities of other users). But with incremental static site generation... even if we care about the community always having up-to-date data on that front page, we could presumably set the timeout to like five seconds. That's a heck of a savings compared to generating it on every request.

ss3000 6y ago
I haven't really kept up to date in this area so would love to hear some experts weigh in here: Do search engines (or really just Google) still penalize sites that are pure SPAs on that fact alone? Or does it have more do do with properties generally associated with SPAs like large bundle sizes or slow time to first interaction? I'm mainly wondering if you can build a SEO-friendly SPA marketing page today using techniques like dynamic imports and code splitting to lazy load just the scripts and content needed for the initial render instead of going all the way to static generation or server side rendering.
- azangru 6y ago
  > Do search engines (or really just Google) still penalize sites that are pure SPAs on that fact alone? Google says that they don't. They use an evergreen googlebot, which is the latest (or thereabouts) release of headless Chrome browser; and it waits for the scripts to load and executes them. You can watch Martin Splitt's talk from the recent web.dev live event for the latest updates. Server-side rendering is still important if you care for other search bots or if you want to share your site's pages on social media (with page preview).
  - bitten 6y ago
    do you have a link to the talk?
    - azangru 6y ago
      Yes: https://youtu.be/himvKu12YCY https://youtu.be/himvKu12YCY
- siquick 6y ago
  If its important that your sites content will be shared on social media then SSR is a must due to meta tags Facebook/Twitter use to create the posts preview.
silviogutierrez 6y ago
Maybe I'm missing something, but ultimately, isn't this just a re-invention of a site-wide cache? Back in the day, in Django/Drupal/any CMS, for anonymous users, you'd just dump each page into memcached with a path URL. Then when a new anonymous visitor comes, you load it right up from – extremely fast – memory. Maybe even faster than loading from the file system? Nginx can actually ask memcached directly, even bypassing the app server. It feels like we've gone full circle.
- dmartinez 6y ago
  My take is that it implements the benefits you describe for simple sites that might have less infrastructure at their disposal. It seems like you still need a node runtime to rebuild the files when the cache needs to be regenerated, however.
- switz 6y ago
  You're not totally wrong, but think of it this way. You have native support in your application stack for this static 'caching' along with one-click edge distribution. Which means you can write extremely complex, interactive markup (it's just React) on top of this very simple distribution system. And you don't have to build a whole magic caching system or deal with web servers at all. I've worked with similar systems to the one you've laid out -- tell me you've never had to jump into the cache to clear it because a client wasn't seeing their updates. Or a page was getting improperly cached. Even if it was simple and effective, it was often a pain. These days, there are a number of services that will store your html and other static files on their edge CDN servers (cloudflare workers, vercel, netlify, among others) leading to your users downloading the files at remarkably fast speeds. You can reach a pretty amazing TTI while maintaining nigh infinite scalability. I will say that while I personally use next.js, I stick entirely with server-side rendering. I find it to be a better all-around user-experience for my use-case with several distinct advantages. But I only serve ~150,000 users a month, who are all relatively close to my server and I don't have much static content. A modest ec2 instance handles it with ease. But if I was building an application that targeted many regions and needed infinite scalability, or one that heavily utilized static data, I'd definitely consider pursuing the approach laid out above. We've gone 'full circle', sure. Because React offered a way to write web applications in a much more consistent, interactive way than anything before it. But we spent a few years growing our bundle sizes out of control, and improperly structuring our applications which led to TTI growing and everything being slow and clunky. Companies that cared and had good engineering were able to navigate these problems, but your average developer couldn't. Now with a system like this, they can not only match the performance of classic applications, but in many cases exceed it.
penagwin 6y ago
I don't know what archetecture your website uses, but our site for example we just cache the view into redis for however long. It's built into a lot of webframeworks, but shouldn't be too crazy to implement by hand.
dbbk 6y ago
Can’t you just stick a Cloudflare cache in front of it and call it a day?
- tunesmith 6y ago
  I'm still exploring this, but my sense is that with Next.JS, the cached version is still deposited on the edge cache at build time, so you don't have that first expensive query. Not sure if you can do something like that with Cloudflare alone. Second is that with Next.JS, expiration means that it gets built and re-deposited onto the edge cache in the background, without ever needing that expensive query. Again, not sure if you can do something like that with Cloudflare alone.

azangru 6y ago

It's interesting that the React Router team, which is building the competing Remix framework (similar to Next but based on React Router) is arguing that instead of supporting static page generation, they will just urge their users to use CDNs with aggressive caching rules.

leerob 6y ago
I'd imagine the hard part with that approach would be cache invalidation. I'm curious to see how they try and address it.
- dbbk 6y ago
  You could use webhooks on deploy to call your CDN's API to purge the cache. Otherwise, I guess just keep it time-based.
dbbk 6y ago
This instinctively makes more sense to me. Still, good to have options. It will be interesting to see how Remix is received once it launches. Next is currently peerless for DX-friendly React frameworks.

ianwalter 6y ago

Developing a Next.js app is a really nice experience. I admit when it first came out I didn't pay that much attention to it because I thought how it did routing was weird and I don't think the server was as extensible. Fast forward to 9.5 and there's pretty much no real reason for me to build a custom Webpack-based setup for my next project.

bionhoward 6y ago

i love vercel and use it for all my projects, right up until i need to add auth/api, at which point I switch off of it immediately for security reasons because there are no static IPs unless you're an "enterprise" customer it's unclear why they're rolling out performance features while this critical security hole persists. no doubt i'll get flamed for it, but, it's a really bad idea to use dynamic IPs to connect to your database with only a password...

luisrudge 6y ago
I guess you’re talking about Vercel.com instead of Next.JS, right?
- bionhoward 6y ago
  Yep
djstein 6y ago
Can you expand on what the static IPs give you?
- wereHamster 6y ago
  For use in firewall rules
maxast 6y ago
oh yeah, I remember running into that problem when I was using a database on Digital Ocean and wanted to add vercel api routes as a trusted source. I had also switched off of it because of that. However, I had a look at their blog the other day and apparently they have an Anycast IP range now, which probably solves this issue https://vercel.com/blog/new-edge-dev-infrastructure#vercel's-own-anycast-ip-range https://vercel.com/blog/new-edge-dev-infrastructure#vercel's.... I haven't tried it yet though

deleted 6y ago

[deleted]

droptablemain 6y ago

This is great -- can't wait to update and try this out.

huangbong 6y ago

Great product. Them deciding to rebrand from Zeit to Vercel was one of the worst branding decisions ever made.

leerob 6y ago
Curious, why do you think that? Any rebranding will have backlash. It solved the issue of ZEIT Now being one _product_ whereas Vercel is the _platform_. It also brought a new focus on Jamstack and front-end developers. I'll admit I'm biased though, as I'm a Vercel customer.
- huangbong 6y ago
  They could’ve just used ZEIT as the platform then. Vercel sounds like some generic VC created tech name. Their customer base is literally the exact opposite. Indie developers, people with Github accounts, technical engineers, engineering leaders. Not some Salesforce CRM enterprise selling to CEO’s marketing bs “Vercel” lol.

dmitryminkovsky 6y ago

Beautiful release!