Live data from Hacker News

The future (and the past) of the web is server side rendering

deno.com

121–130 of 371 posts

Re: The future (and the past) of the web is server side rendering

#121
post #38

“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. Yes but a plain html file is static, so that's not going to work unless your site is purely static (i.e. a blog).

You can do both post and get. That is all you need really to make anything work unless your are doing spyware and like graphical applications such as maps and what not.

Static pages are easier on Mother Earth too.

Re: The future (and the past) of the web is server side rendering

#122
post #81

In theory, the "modern" frontend frameworks could be useful for a subset of applications. In practice, they are wildly overused, largely (IMHO) because front-end developers have forgotten how to build without them. If I gave this as an example, people would say I'm being unfair to the front-end folks. But since Deno posted it, I think it's fair say that it's overkill to use a front-end framework like React (mentioned…

I started my webdev time with Django and flask, switched to Spring boot at the next job with various templating languages, depending on the artefact and some laravel sprinkled in.

Finally, the employer decreed that moving forward all frontends had to be done in Angular (version 6 or 7 at that time) and I have to say... I don't understand the point you're trying to make.

The frontend stacks aren't particularly more complex then the equivalent application done with html templates and varying ways to update the DOM.

Personally I'd say they're easier, which is why UX also started to demand state changes to be animated etc, requests to be automatically retried and handle every potential error scenario, which was never even attempted with pure backend websites

Nowadays I prefer using Typescript for anything html related and would not use backend templates unless the website is not going to be interactive

Re: The future (and the past) of the web is server side rendering

#124
I love Deno, I hope it succeeds, but I'm disappointed to see them so confidently publishing a broad assertion like this that's very weakly argued, and heavily biased towards promoting their own position in the stack

> Compatibility is higher with server-side rendering because, again, the HTML is generated on the server, so it is not dependent on the end browser.

Excuse my bluntness, but this is complete nonsense. Browser incompatibility in 2023 is mostly limited, in my experience, to 1) dark corners of CSS behavior, and 2) newer, high-power features like WebRTC. #1 is going to be the same regardless of where your HTML is rendered, and if you're using #2, server-side rendering probably isn't an option for what you're trying to do anyway. I can confidently say browser compatibility has roughly zero effect on core app logic or HTML generation today.

> Complexity is lower because the server does most of the work of generating the HTML so can often be implemented with a simpler and smaller codebase.

This, again, is totally hand-wavy and mostly nonsensical. It's entirely dependent on what kind of app, what kind of features/logic it has, etc. Server-rendering certain apps can definitely be simpler than client-rendering them! And the opposite can just as easily be true.

> Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded.

This is only partly true, and it's really the only partly-valid point. Modern statically-rendered front-ends will show you the initial content very quickly, and then will update quickly as you navigate, but there is a JS loading + hydration delay between seeing the landing page content and being able to interact with it at the beginning. You certainly don't need "a desktop...with a wired internet connection" for that part of the experience to be good, but I'm sure it's less than ideal for people with limited bandwidth. It's something that can be optimized and minimized in various ways (splitting code to make the landing page bundle smaller, reducing the number of nested components that need to be hydrated, etc), but it's a recurring challenge for sure.

The tech being demonstrated here is interesting, but I wish they'd let it stand on its own instead of trying to make sweeping statements about the next "tock" of the web trend. As the senior dev trope goes, the answer to nearly everything is "it depends". It shows immaturity or bias to proclaim that the future is a single thing.

Re: The future (and the past) of the web is server side rendering

#125

The issue I have with SSR is that it offloads processing power onto the server. That means I have to pay more as the host instead of relying on user's browser to handle the compute "for free".

I'm probably not in your target demographic but when a website pushes computation to me for simple things like displaying text and images I close the tab.

If a website is just showing text and images it shouldn't really be dynamically rendering anything anywhere. Write the content to static files during deployment and serve them.

Re: The future (and the past) of the web is server side rendering

#128
"Server-side rendering" is destined to rule the future purely because of control. In the future consumer devices will be simplified, much more streamlined, and completely locked down. They will be used for the single purpose of displaying streamed, pre-packaged, pre-layed-out content from servers.

Re: The future (and the past) of the web is server side rendering

#129
post #36

Earlier quoted context omitted.

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

That is literally fragile code. You contradict yourself. I really want to see any of the people that hate on modern frameworks build any complex web app in a reasonable amount of time with the same level of stability as using i.e. SvelteKit

Re: The future (and the past) of the web is server side rendering

#130
post #81

In theory, the "modern" frontend frameworks could be useful for a subset of applications. In practice, they are wildly overused, largely (IMHO) because front-end developers have forgotten how to build without them. If I gave this as an example, people would say I'm being unfair to the front-end folks. But since Deno posted it, I think it's fair say that it's overkill to use a front-end framework like React (mentioned…

I started my webdev time with Django and flask, switched to Spring boot at the next job with various templating languages, depending on the artefact and some laravel sprinkled in. Finally, the employer decreed that moving forward all frontends had to be done in Angular (version 6 or 7 at that time) and I have to say... I don't understand the point you're trying to make. The frontend stacks aren't particularly more co…

> I don't understand the point you're trying to make.

> The frontend stacks aren't particularly more complex

I'm not making a point about programmer experience at all. I'm saying that for most uses of most sites, the fact that Angular (or similar) is running in the user's browser is making the user experience worse. Performance is worse, accessibility can be worse, and so forth. And (again, for most uses of most sites) there is no benefit to the end user.

Consider the blogs, brochureware sites, landing pages, and e-commerce product pages that absolutely don't need something like Angular that today nonetheless do include it. Most Web apps are much closer to those than to Google Earth, Facebook, or Spotify's Web player.

Post reply on HN