3 ms·

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 a

by mikece 4y ago

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 things. A best of all worlds scenario is a rich UI that only needs to make API calls to update the display, keeping performance fast and content flicker-free (and the server-side API could have an agreed upon standard for being indexed -- or submitting updates for indexing -- to search engines). There is no truly perfect scheme, only ways in which we think we can improve on the status quo by swinging the pendulum back and forth.

ErikAugust 4y ago
"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.
- mikece 4y ago
  I would have thought they could spin up headless Chrome instances to simply pull down, render, and then index websites. Apparently this is too resource intensive for them? I'm sure the idea has come up (there's no way I thought of this and they didn't).
- xemoka 4y ago
  You'd think right? There must be other reasons then... how does Google benefit from not building better SPA crawling infrastructure? It's certainly gotten _better_ over the last few years, but still seems lacking.
- npretto 4y ago
  It does indeed render and index them: https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics https://developers.google.com/search/docs/crawling-indexing/...
- csixty4 4y ago
  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.
  - deleted 4y ago
    [deleted]
  - spiffytech 4y ago
    With the caveat that server-generated HTML is indexed immediately, while pages that need client-side rendering get put into a render queue that takes Google a while to get to (days?).
    - super256 4y ago
      That's why you write down your use case for every project. Have a news site which needs to be indexed by Google immediately? SSR. Have some Jira or whatever? CSR. Most CSR applications are behind a login wall anyway. Thinking of the core applications of services like WhatsApp, Discord, Gmail, Dropbox, Google Docs etc. Bottom line, whether SSR really being “the future”: “it depends”.
    - capableweb 4y ago
      Hence you don't build documents with SPAs, they are meant for applications. And usually you don't care about indexing the inside of applications, only the landing pages and such, which are documents (should not be a part of the SPA). A blog built as a SPA? Sucks. A blog built as a collection of documents? Awesome.
OliverJones 4y ago
The client-server wheel of life just keeps turning, and turning, and turning. It's an eternal human truth: each generation yearns to improve on the previous generation's efforts. This server-client zeal to improve has been tremendously productive of good ideas over the last few decades. It will continue. Hopefully saving power and CO2 can be the focus of the next couple of turns of the great wheel.
- oakwhiz 4y ago
  Extracting money and creating walled gardens, while removing user choice, is also a focus of this server side cycle.
- makmanalp 4y ago
  Don't know why this comment was downvoted - it's the truest take here I can spot. The fact is that the factors that make one versus the other more preferable (the state and quality of frontend / backend tooling and environments, compute power and rendering capabilities of servers vs clients, round trip time cost vs responsiveness requirements etc etc) are continually changing over time and that's what's causing the back and forth swing, but lessons from previous iterations are generally learned. I wouldn't be shocked if we sooner or later saw language-level support (think of something like Elm, improved) for writing "just" code and then later marking up which parts execute where, and the communications and state synchronization crud and compiling down to the native language is just handled.
deleted 4y ago
[deleted]

by mikece 4y ago

ErikAugust 4y ago

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

mikece 4y ago
I would have thought they could spin up headless Chrome instances to simply pull down, render, and then index websites. Apparently this is too resource intensive for them? I'm sure the idea has come up (there's no way I thought of this and they didn't).
xemoka 4y ago
You'd think right? There must be other reasons then... how does Google benefit from not building better SPA crawling infrastructure? It's certainly gotten _better_ over the last few years, but still seems lacking.
npretto 4y ago
It does indeed render and index them: https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics https://developers.google.com/search/docs/crawling-indexing/...
csixty4 4y ago
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.
- deleted 4y ago
  [deleted]
- spiffytech 4y ago
  With the caveat that server-generated HTML is indexed immediately, while pages that need client-side rendering get put into a render queue that takes Google a while to get to (days?).
  - super256 4y ago
    That's why you write down your use case for every project. Have a news site which needs to be indexed by Google immediately? SSR. Have some Jira or whatever? CSR. Most CSR applications are behind a login wall anyway. Thinking of the core applications of services like WhatsApp, Discord, Gmail, Dropbox, Google Docs etc. Bottom line, whether SSR really being “the future”: “it depends”.
  - capableweb 4y ago
    Hence you don't build documents with SPAs, they are meant for applications. And usually you don't care about indexing the inside of applications, only the landing pages and such, which are documents (should not be a part of the SPA). A blog built as a SPA? Sucks. A blog built as a collection of documents? Awesome.

OliverJones 4y ago

The client-server wheel of life just keeps turning, and turning, and turning. It's an eternal human truth: each generation yearns to improve on the previous generation's efforts. This server-client zeal to improve has been tremendously productive of good ideas over the last few decades. It will continue. Hopefully saving power and CO2 can be the focus of the next couple of turns of the great wheel.

oakwhiz 4y ago
Extracting money and creating walled gardens, while removing user choice, is also a focus of this server side cycle.
makmanalp 4y ago
Don't know why this comment was downvoted - it's the truest take here I can spot. The fact is that the factors that make one versus the other more preferable (the state and quality of frontend / backend tooling and environments, compute power and rendering capabilities of servers vs clients, round trip time cost vs responsiveness requirements etc etc) are continually changing over time and that's what's causing the back and forth swing, but lessons from previous iterations are generally learned. I wouldn't be shocked if we sooner or later saw language-level support (think of something like Elm, improved) for writing "just" code and then later marking up which parts execute where, and the communications and state synchronization crud and compiling down to the native language is just handled.

deleted 4y ago

[deleted]