Quoted post unavailable.
I've been brainwashed by consumers – they demand and expect a certain experience on the modern web. Also, you can run Next.js on a Raspberry Pi and free Cloudflare DNS+SSL. :shrug:
Hydration is pure overhead
21–30 of 84 posts
Re: Hydration is pure overhead
#22This is confusing to me. From the article it sounds like the javascript is run on the server producing markup. That markup is sent to the browser for rendering then the javascript is requested by the browser. When the javascript arrives it is run again on the browser to re-generate the DOM with event handlers attached. If that is correct then why is the javascript run on the server to begin with and not just sent dir…
I think most importantly the server can cache requests (cache the generated HTML). This is especially important for public, mostly static pages that one might want to do SEO optimizations for anyways. Servers are often weaker than many consumer computers anyways, so I don’t thin it’s because it can render faster than your own browser.
>Servers are often weaker than many consumer computers anyways, so I don’t thin it’s because it can render faster than your own browser.
I'm thinking about that Hacker News article, which had a laptop in the datacenter, because it was much faster on it.
Re: Hydration is pure overhead
#23Earlier quoted context omitted.
the reason we need all this is so that Netlify and Vercel can make money there’s no other explanation it’s a capitalist game and if you want to stay sane, you shouldn’t play it
> there’s no other explanation Faster initial load times for PWAs? No conspiracy theory or capitalism rant needed.
faster load times is achieved by not using javascript, (pre-) rendering content on server and caching with CDN
this is how Wikipedia does it for the last 20(?) years and they sure won’t be changing that any time soon
PWA is a whole different topic
Re: Hydration is pure overhead
#24Earlier quoted context omitted.
> there’s no other explanation Faster initial load times for PWAs? No conspiracy theory or capitalism rant needed.
faster load times is achieved by not using javascript, (pre-) rendering content on server and caching with CDN this is how Wikipedia does it for the last 20(?) years and they sure won’t be changing that any time soon PWA is a whole different topic
> PWA is a whole different topic
No it's not, as hydration is used to improve the initial load times for PWAs. Afterwards PWAs will load offline first.
> faster load times is achieved by not using javascript, (pre-) rendering content on server and caching with CDN
Yes you can make sites not using JS and should in certain scenarios, that's not relevant here.
> this is how Wikipedia does it for the last 20(?) years and they sure won’t be changing that any time soon
Wikipedia is a web site, not a web app. It works really well as a site and thus uses technologies meant for web sites.
Re: Hydration is pure overhead
#25Quoted post unavailable.
I've been brainwashed by consumers – they demand and expect a certain experience on the modern web. Also, you can run Next.js on a Raspberry Pi and free Cloudflare DNS+SSL. :shrug:
what are their demands?
pretty sure my Raspberry Pi will just give up after pulling 2000 npm packages and building native modules
Re: Hydration is pure overhead
#26Earlier quoted context omitted.
I think most importantly the server can cache requests (cache the generated HTML). This is especially important for public, mostly static pages that one might want to do SEO optimizations for anyways. Servers are often weaker than many consumer computers anyways, so I don’t thin it’s because it can render faster than your own browser.
>Servers are often weaker than many consumer computers anyways, so I don’t thin it’s because it can render faster than your own browser. Isn't this the other way around? I mean a server is supposed to be fast enough to handle a lot of requests.
Well, servers often come with more but slower cores.
Re: Hydration is pure overhead
#27Earlier quoted context omitted.
faster load times is achieved by not using javascript, (pre-) rendering content on server and caching with CDN this is how Wikipedia does it for the last 20(?) years and they sure won’t be changing that any time soon PWA is a whole different topic
> PWA is a whole different topic No it's not, as hydration is used to improve the initial load times for PWAs. Afterwards PWAs will load offline first. > faster load times is achieved by not using javascript, (pre-) rendering content on server and caching with CDN Yes you can make sites not using JS and should in certain scenarios, that's not relevant here. > this is how Wikipedia does it for the last 20(?) years and…
> hydration is used to improve the initial load times for PWAs
this very sentence sounds absurd
how many websites out there need to work offline?
Re: Hydration is pure overhead
#28Earlier quoted context omitted.
>Servers are often weaker than many consumer computers anyways, so I don’t thin it’s because it can render faster than your own browser. Isn't this the other way around? I mean a server is supposed to be fast enough to handle a lot of requests.
Well, servers often come with more but slower cores.
But servers have a much higher power budget compared to phones or most laptops. That's supposedly the target user base for SSR + hydration.
Re: Hydration is pure overhead
#29Earlier quoted context omitted.
> PWA is a whole different topic No it's not, as hydration is used to improve the initial load times for PWAs. Afterwards PWAs will load offline first. > faster load times is achieved by not using javascript, (pre-) rendering content on server and caching with CDN Yes you can make sites not using JS and should in certain scenarios, that's not relevant here. > this is how Wikipedia does it for the last 20(?) years and…
> hydration is used to improve the initial load times for PWAs this very sentence sounds absurd how many websites out there need to work offline?
You didn't address my last points but I'll still address this comment.
> this very sentence sounds absurd
Which part? "hydration", "improve the initial load times", or "PWAs"?
Let me rephrase if you are confused. It renders a snapshot of the app on the server so when you first load the web app it's rendered already. Then the client picks it up from there. It's completely optional to do this.
> how many websites out there need to work offline?
Are you asking if it's useful to have access to information and entertainment offline? For me the answer is yes.
It depends what you are making, but yes I think you should strive to make things work offline if you can.
Also websites can work offline without CSR. That's not really what this is about.
Hydration is about improving initial load times of CSR. I really don't know how to simplify this further.
Re: Hydration is pure overhead
#30This is confusing to me. From the article it sounds like the javascript is run on the server producing markup. That markup is sent to the browser for rendering then the javascript is requested by the browser. When the javascript arrives it is run again on the browser to re-generate the DOM with event handlers attached. If that is correct then why is the javascript run on the server to begin with and not just sent dir…
You get to at least see the content much faster, it's just not interactive for a bit. The benefit is clearest when rendering pages at build time and then serving the HTML over a CDN
But even then, it's definitely still a problem vs sites that don't have to be hydrated. Some people see this approach as a best-of-both-worlds, but in reality it's still a compromise that has costs