Can 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?
[deleted]
The future (and the past) of the web is server side rendering
111–120 of 371 posts
Re: The future (and the past) of the web is server side rendering
#112The 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.
>when a website pushes computation to me for simple things like displaying text and images I close the tab
How will you even know without looking at the source or blocking JS across the web? Like, sure, if they've fancy animations across all elements from the moment you open the page should be obvious. But what about something like https://rhodey.org/? It opens instantaneously in my ancient laptop connected to a terrible internet line. Check source. Only a single empty div in body. Everything is rendered with JS.
Re: The future (and the past) of the web is server side rendering
#113It's obviously nonsense. The lowest latency cache and state storage is clientside. You can piss around with multi regions and SSR to minimize latency but that's just placing a lot of regional caches near your users. The nearest place is in their actual browser -> offline first is the future
Client-side storage sucks, especially if you want to visit the same site from multiple devices. Without more code to sync this data, it's not great.
Re: The future (and the past) of the web is server side rendering
#114> 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…
[deleted]
[deleted]
Re: The future (and the past) of the web is server side rendering
#115This 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. [1] https://htmx.org/
[deleted]
Re: The future (and the past) of the web is server side rendering
#116Client-side rendering needs to rebrand as local-first. Then the cycle will start anew.
[deleted]
Re: The future (and the past) of the web is server side rendering
#117I really don’t like server side rendering. I like my react apps to be static files served from a plain HTML server.
Server-side rendering is so much simpler from platforms that were designed to do it.
As a user, I despise seeing a white screen with a spinner.
Re: The future (and the past) of the web is server side rendering
#118Shoutout to Sveltekit which does SSR and client-side navigation by default! https://kit.svelte.dev/
Re: The future (and the past) of the web is server side rendering
#119In 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…
> In practice, they are wildly overused, largely (IMHO) because front-end developers have forgotten how to build without them.
I've been a "back-end" developer who sometimes does "front-end" stuff for a long time. Both with web tech going back to classic asp, web-forms and those Java beans for JSF or whatever it was called, and, with various gui-tools for C#, Java and Python, and I think one of the reasons people use the "front-end" tools you're talking about in 2023 is because all those other tools really sucked.
I guess NextJS can also be server side rendering, but even when you just use it for React (with Typescript and organisation-wide linting and formating rules that can't be circumvented) it's just sooooo much easier than what came before it.
Really, can you think of a nice application? Maybe it's because I've mostly worked in Enterprise organisations, but my oh my am I happy that I didn't have to work with any of the things people who aren't in digitalisation have to put up with. I think Excel is about the only non-web-based application that I've ever seen score well when they've been ranked. So there is also that to keep in mind.
Re: The future (and the past) of the web is server side rendering
#120This 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. [1] https://htmx.org/
I just started playing around with it after fumbling around with Vue for a bit. I really like that there is so much less magic involved, no getting lost in a twisty maze of proxies. A real breath of fresh air. But then I haven't done real frontend development since JSPs were hot, so I'm not sure my liking it is a good thing.