Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next.js 9.5

nextjs.org

Post reply on HN
Print view View original

11–20 of 40 posts

Re: Next.js 9.5

#11

Post by azangru »

ss3000 wrote: post #5
tunesmith wrote: post #4

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 s…

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 techn…

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

Re: Next.js 9.5

#12

Post by leerob »

azangru wrote: post #10

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.

I'd imagine the hard part with that approach would be cache invalidation. I'm curious to see how they try and address it.

Re: Next.js 9.5

#13

Post by leerob »

gremlinsinc wrote: post #2

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.

Not exactly the same, but the Vercel team made a demo using Twitter with static generation.

https://static-tweet.now.sh/

Re: Next.js 9.5

#14

Post by ianwalter »

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.

Re: Next.js 9.5

#15

Post by bionhoward »

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

Re: Next.js 9.5

#16

Post by luisrudge »

bionhoward wrote: post #15

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 y…

I guess you’re talking about Vercel.com instead of Next.JS, right?

Re: Next.js 9.5

#18

Post by manigandham »

switz wrote: post #9
silviogutierrez wrote: post #6

Earlier quoted context omitted.

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 bypas…

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…

Hosting is separate from the framework, and the static site hosts you mentioned are just webserver + CDN packaged together with optional build/CI layer and some extra APIs to handle form submissions and user logins. Considering the number of CDNs and 1-click hosting, and the ease of putting them together, it's all pretty much the same.

The big difference is that these static site frameworks are using React/Vue/etc for the frontend templating and interactivity instead of a server-side language that has it's own templating and might require complex JS integration. But the trade-off is that you give up that server-side ability or have to use 3rd-party services like a headless CMS instead.

Re: Next.js 9.5

#20

Post by [deleted] »

silviogutierrez wrote: post #6
tunesmith wrote: post #4

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 s…

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 bypas…

[deleted]
Post reply on HN