Am fairly certain the move back to the server has more to do with the development of heavy AI data modelling that can't be offloaded to the client.
Don't believe the tech itself is Anything but a sign of where the utilities are moving
The future (and the past) of the web is server side rendering
281–290 of 371 posts
Re: The future (and the past) of the web is server side rendering
#282The future of the web is most web developers losing their jobs for failing to be good stewards of their platform.
How can there be a future if nobody develops it anymore? I think it's clear the opposite is happening.
Do you mean frontend-only devs losing their jobs? That's also unlikely since web dev went full stack over a decade ago. People don't build SPAs just because they don't know how else to build a web app. If you have specific examples of crappy SPAs you should blame that shop for sucking, not the concept.
Re: The future (and the past) of the web is server side rendering
#283Much more prefer the htmx way of SSR parts of the page dynamically. Also, totally server-side agnostic, so we can use what we prefer. Clojure in our case. https://htmx.org/
[deleted]
Re: The future (and the past) of the web is server side rendering
#284Earlier quoted context omitted.
The number of devices is very small. I’m sure you get a number of different window sizes, but within a range, you can very slightly scale.
Are you suggesting we give up on rendering layouts that respond to different window sizes, display resolutions, and zoom levels? I think what you’re suggesting is that clients requesting websites should receive essentially an image of the website with limited interactivity, but that’s not going to make anyone that’s ever used a website satisfies in C.E. 2023.
You can make web pages responsive to "different window sizes, display resolutions, and zoom levels" with no JavaScript at all, so that's clearly not what they're suggesting.
Re: The future (and the past) of the web is server side rendering
#285Is SSR still much better for seo?
Not if the html actually has content instead of just being a sad blank page with a magic div entrypoint.
Re: The future (and the past) of the web is server side rendering
#286Earlier quoted context omitted.
Web page design will have to fundamentally change to accommodate surgically updating web pages, for the large overhead to disappear.
It already exists for several popular frameworks/languages. One example is [1] Laravel livewire. [1] https://laravel-livewire.com/
Also see Blazor. We've been using it for a few years now.
Here is some specific documentation pertaining to how it manages incremental DOM updates: https://blazor-university.com/components/render-trees/
Re: The future (and the past) of the web is server side rendering
#287If you are looking for server-side rendering that enables rich, react-like user experiences, check out LiveViewJS (http://liveviewjs.com). Supports both Deno and Node runtimes.
(Full disclosure: am author)
Re: The future (and the past) of the web is server side rendering
#288Earlier quoted context omitted.
So any change in the UI means sending a request to the server, waiting for it to render, and waiting for that response with the new markup?
Yes, this is how Elixir Phoenix works. The caveat is that only returns exactly what needs to be changed, so it's a small diff. It's not suitable to everything, but it works really well. I'm not advocating switching to it right now, but it's looking very promising.
htmx glosses over the difficult part, which would be keeping track of the relationship between all these hx-post and hx-target attributes, when they're all just strings in markup. That glossing over is why you don't see any well-established backend libraries on the server integrations page. (https://htmx.org/server-examples/)
Elixir solves this in a much smarter way, because the bindings to reactive values can be validated at compile time, inside the HEEx templates. It's all located together, but you still get the diff passing behavior. (https://hexdocs.pm/phoenix_live_view/assigns-eex.html)
Re: The future (and the past) of the web is server side rendering
#289The future of the web is most web developers losing their jobs for failing to be good stewards of their platform.
The future of the web is web developers creating more work and thus more jobs for web developers.
It's the same reason Java, with all its boilerplate, is so widely used.
Re: The future (and the past) of the web is server side rendering
#290Earlier quoted context omitted.
All of the environments you describe there sound to me like they would benefit from web apps that become responsive after an initial page load of less than 100KB, followed by ~10KB round trips to the server to fetch additional data. As opposed to the >2MB initial page loads that have become so common with heavy React SPAs in exchange for the theoretical benefits of avoiding more page loads for further interactions.
They benefit from a .exe (or a .tar.gz or a .apk) downloaded when convenient and run locally
Any app with dynamic data would still need to make some sort of HTTP request before rendering some view with that new data. I don’t really get your point.