The "modern" state of the web. I miss old school html with little to no javascript. It is all java in the browser all over again. Or flash. Same old same old. Very few websites need any of this stuff. It is just a bunch of junior devs wishing they worked for FB I guess ergo them guzzling react like there is no tomorrow.
The future (and the past) of the web is server side rendering
191–200 of 371 posts
Re: The future (and the past) of the web is server side rendering
#192The "modern" state of the web. I miss old school html with little to no javascript. It is all java in the browser all over again. Or flash. Same old same old. Very few websites need any of this stuff. It is just a bunch of junior devs wishing they worked for FB I guess ergo them guzzling react like there is no tomorrow.
[deleted]
Re: The future (and the past) of the web is server side rendering
#193I 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. Bro…
[deleted]
Re: The future (and the past) of the web is server side rendering
#194Earlier 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?
Versus the overwhelmingly common SPA counterexample where any change in the UI means sending a request to the server, waiting for it return your json response, parsing that json response, building html out of that json response, and updating the dom.
You don't need to wait for a response if you're sending data, or reorganizing data, or doing something that doesn't rely on data.
Re: The future (and the past) of the web is server side rendering
#195The 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.
so basically you only view plain text files in a browser? that sounds a little extreme to me.
Re: The future (and the past) of the web is server side rendering
#196The thing that went wrong with front-end frameworks imho was that instead of being what was promised: you could update UI elements with NO NEED to contact the server at all, only posting back when something needed persisting, instead it became an excuse that every action on the front-end needed to call an API or 3 so we've ended up with over-complicated apps that instead of not relying on the backend are relying on i…
[deleted]
Re: The future (and the past) of the web is server side rendering
#197If you don't do server side rendering, you don't (almost) automatically get a set of nice REST endpoints that return JSON/XML/ETC? I get that the abstraction might be nice for security, but at least for corporate intranet applications, a nicely structured, secured (e.g ODATA) webapi you query for client side rendering has the added benefit that it can be invoked programmatically with REST by other authorized parties.…
> Isn't it also nice from a computation cost standpoint to let the client do the rendering? Aside from all other implications, letting each client render the same stuff is a massive waste of energy and compute.
If it was truly the same computation then it could be a static site generator, but with typical server side rendering you are still doing a new render per user no?
Re: The future (and the past) of the web is server side rendering
#198Next step: server rendered PNGs. Browser not required.
[deleted]
Re: The future (and the past) of the web is server side rendering
#199I think it's a bit ridiculous to call it "server side rendering". It is called HTTP
[deleted]
Re: The future (and the past) of the web is server side rendering
#200Earlier quoted context omitted.
Versus the overwhelmingly common SPA counterexample where any change in the UI means sending a request to the server, waiting for it return your json response, parsing that json response, building html out of that json response, and updating the dom.
You don't need to wait for a response if you're sending data, or reorganizing data, or doing something that doesn't rely on data.
Yep. DOM manipulation can be done to server-rendered views to do that kind of thing, just fine. No SPA js framework required.