Anyone remember There? It's still around[0], but I don't know how active it is.
I'm pretty sure it relied on in-browser XSLT to do a lot of its magic.
The future (and the past) of the web is server side rendering
51–60 of 371 posts
Re: The future (and the past) of the web is server side rendering
#52Earlier quoted context omitted.
Googlebot has been able to index SPAs since 2019. They use a Headless Chrome instance and allow a number of seconds for things to render after each interaction.
With the caveat that server-generated HTML is indexed immediately, while pages that need client-side rendering get put into a render queue that takes Google a while to get to (days?).
That's why you write down your use case for every project. Have a news site which needs to be indexed by Google immediately? SSR.
Have some Jira or whatever? CSR.
Most CSR applications are behind a login wall anyway. Thinking of the core applications of services like WhatsApp, Discord, Gmail, Dropbox, Google Docs etc.
Bottom line, whether SSR really being “the future”: “it depends”.
Re: The future (and the past) of the web is server side rendering
#53> Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded. but the page is loaded later because you have to wait for the server to perform this work. There is no reduction in total work, probably an absolute increase because some logic is duplicated. If there is a speed improvement it is because the server has more clock cycles available than the c…
> There is no reduction in total work, probably an absolute increase because some logic is duplicated
The server is either building a JSON (or some other message format) response, or, it could just build the relevant HTML fragment. In many cases, there is no real increase in actual work on the server.
Conversely, the client side doesn't need to parse JSON and convert it to a DOM fragment.
There's solid reasons for both approaches, depending upon the context.
Re: The future (and the past) of the web is server side rendering
#54Can someone explain me: Deno is becoming such a confusing framework, initially NodeJS alternative now it seems to me that is trying to compete with NextJs?
It's not trying to compete with Next, but advertising how Deno's similarity to the browser and being able to run on CDN-like networks (which i refuse to call "the e*ge") can let you build a better version of Next's features yourself.
Re: The future (and the past) of the web is server side rendering
#55“Server side rendering” is such a terrible term. The server isn’t doing rendering, the browser is. The server is sending a complete well-formed DOM for the client to render. Well done, modern devs! A plain .html file does that. I really hope some of the heavy front-end frameworks die a death, some common sense prevails, and we get a lighter, faster loading, more responsive web. I can dream.
Server can render HTML code. Browser renders visual representation of HTML code.
Re: The future (and the past) of the web is server side rendering
#56“Server side rendering” is such a terrible term. The server isn’t doing rendering, the browser is. The server is sending a complete well-formed DOM for the client to render. Well done, modern devs! A plain .html file does that. I really hope some of the heavy front-end frameworks die a death, some common sense prevails, and we get a lighter, faster loading, more responsive web. I can dream.
> Well done, modern devs! A plain .html file does that And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item__quantity") all over the place. HN has some weird hate for this new server side rendering, when it's really the smart thing to do and equivalent to what any app is doing: the "frame" of the app is downloade…
There is nothing wrong with parseInt(document.getQuerySelector(".item > .item__quantity"), except for it not being parseInt(document.getElementById("uniqueAutogeneratedId")).
Developers just shouldn't write that kind of fragile code by hand. But there's nothing wrong at all with the code being there.
Re: The future (and the past) of the web is server side rendering
#57I think it's a bit ridiculous to call it "server side rendering". It is called HTTP
Depends on what exactly it is. If you for example take a react app that was doing rendering on user side and change it so that it is "pre-rendered" on the server it makes sense to call it server side rendering..
Re: The future (and the past) of the web is server side rendering
#58This is why I'm really excited about htmx [1]. No need to write isomorphic javascript at all. You can still use server side templates but have interactive web pages.
Re: The future (and the past) of the web is server side rendering
#59[dead]
Re: The future (and the past) of the web is server side rendering
#60I think that biggest issue with page size is not due to client side rendering, but rather thanks to bundling and idea that you need to download the same minified Lo-Dash on each and every page. Why can’t we just use public CDNs is beyond my understanding.
I really like client side apps. They are so much more responsive. The only problem is with bundle sizes.