11–20 of 371 posts
If web sites have to so dynamic, I much prefer that the computation involved is done on their machine than on mine. I simply don't trust random web sites enough to let them run code on my machines.
And the future beyond that will be client-side rendering. In the beginning everything was rendered on the mainframe; then CICS allowed partial screen updates and even dynamic green screen design. Then the early web where everything was server which made the job of web indexing much easier. Then we moved back to rich client apps -- applets, flash, eventually SPAs -- with no way for search engines to easily index thing…
"eventually SPAs -- with no way for search engines to easily index things." It's funny Google can't index a SPA, given the tie to Angular (2500 apps in use in-house). Wouldn't be so hard to build something that could.
And the future beyond that will be client-side rendering. In the beginning everything was rendered on the mainframe; then CICS allowed partial screen updates and even dynamic green screen design. Then the early web where everything was server which made the job of web indexing much easier. Then we moved back to rich client apps -- applets, flash, eventually SPAs -- with no way for search engines to easily index thing…
"eventually SPAs -- with no way for search engines to easily index things." It's funny Google can't index a SPA, given the tie to Angular (2500 apps in use in-house). Wouldn't be so hard to build something that could.
Earlier quoted context omitted.
"eventually SPAs -- with no way for search engines to easily index things." It's funny Google can't index a SPA, given the tie to Angular (2500 apps in use in-house). Wouldn't be so hard to build something that could.
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.
An alternative approach is to retain the statelessness of the first option they outline (I don't understand why it isn't "true" SSR): use normal, server-rendered HTML, but improve the experience by using htmx (which I made) so that you don't need to do a full page refresh.
This keeps things simple and stateless, so no server side replication of UI state, but improves the user experience. From what I understand of the isomorphic solution, it appears much simpler. And, since your server side doesn't need to be isomorphic, you can use whatever language you'd like to produce the HTML.
If web sites have to so dynamic, I much prefer that the computation involved is done on their machine than on mine. I simply don't trust random web sites enough to let them run code on my machines.
What is it you dont trust? This Fear Uncertainty & Doubt clashes heavily with the excellent security sandbox the web browser is. What is the harm you are afraid of? What are you supposing the risk is/what's in jeapordy here?
As to what harm I'm avoiding, it's mostly around tracking -- which is something that browsers have a very difficult time preventing, especially if sites are allowed to run code in them.
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.
npm install common-sense
Earlier quoted context omitted.
"eventually SPAs -- with no way for search engines to easily index things." It's funny Google can't index a SPA, given the tie to Angular (2500 apps in use in-house). Wouldn't be so hard to build something that could.
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.
“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.