The browser still runs XML with XSLT stylesheets. What if devs would generate XML view models from the server and use XSL AKA functional programming to render HTML? and then just use Javascript to update the XML or XSL stylesheets and let the browser do its magics? Did anybody ever attempted to write SPA like that?
Server Side Rendering at scale
11–20 of 67 posts
Re: Server Side Rendering at scale
#12> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…
> They could have built this in Java, .Net, Go, really any shared memory concurrency runtime and threading, and would not run into any of these issues.
Right, they'd have brand new issues because they were dealing with shared memory.
Re: Server Side Rendering at scale
#13Earlier quoted context omitted.
They did acknowledge that, albeit subtly, > After a string of production incidents in early 2021, we realized our existing SSR system was failing to scale as we migrated more pages from Python-based templates to React. Apparently their old server-rendered Python app (not called SSR though for obvious reasons) was scaling just fine before the migration.
Yeah... and then this: > We evaluated several languages when it came time to implement the SSR Service (SSRS), including Python and Rust. It would have been ideal from an internal ecosystem perspective to use Python, however, we found that the state of V8 bindings for Python were not production ready Wow, that is some convoluted architecture It seems like the problem here is React
Yeah, you have to do a lot to offset the problem that, out of the box, rendering React on the server is slow.
Re: Server Side Rendering at scale
#14> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…
There have been way too many such nonsense in front-end developments. Putting lots of efforts to build client rendered web apps is already weird enough. And now they want to server rendering apps supposed to be client rendered? Then here comes the question: why not simply choose traditional server rendered apps?
Re: Server Side Rendering at scale
#15The browser still runs XML with XSLT stylesheets. What if devs would generate XML view models from the server and use XSL AKA functional programming to render HTML? and then just use Javascript to update the XML or XSL stylesheets and let the browser do its magics? Did anybody ever attempted to write SPA like that?
Sounds like what Blizzard used to do [0]. And me, in my first dev job. I still like the idea, but Javascript, right?
[O] https://stackoverflow.com/questions/274290/any-big-sites-usi...
Re: Server Side Rendering at scale
#16> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…
Yes this this this this.
SSR ... you mean like PHP did it ... and most all of the tech did it before.
How did this even make it to Hnews...
Re: Server Side Rendering at scale
#17> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…
> They could have built this in Java, .Net, Go, really any shared memory concurrency runtime and threading, and would not run into any of these issues. It is funny how you can get away with using the wrong tool for the job in Software in a professional environment. Like imagine if you were hired to build a house, and you decided to build the foundation out of modeling clay because that's what you're used to working w…
Funny you should take this example. Unless you're building a skyscraper, for 1-2 floors clay is plenty good: in particular when mixed with wheat or other fibrous bodies (straw type), it's how many traditional houses have been built, and has many interesting properties:
- sourced from local material (use a different type of clay or straw if you need), no need for chemicals or for sand imports from depleted beaches on the other side of the world - recyclable to almost infinity (need a bigger/better house? just tear it down and reuse the materials) - cool in summer, warm in winter if you design it well - lasts for decades if your structure is designed well: i'm not aware of really old examples but it would be a surprise if the structure outlives us all (does someone have resources on this topic?)
So turns out your example was more interesting and less absurd than you originally thought. Just like server-side rendering uses an order of magnitude less resources (for n clients it's O(1) with caching, whereas client-side rendering is O(n)), it turns out clay is the perfect material to use an order of magnitude (or even more orders?) less resources to build your house than if you used concrete source from various polluting industries and endangered sand deposits.
Re: Server Side Rendering at scale
#18> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…
It's actually not how things worked just a few years ago.
How things worked a few years ago: you wrote SSR pages with one set of tools (like Django Template Language), then hooked into it with another set of tools. If your pages are complex enough, you end up with weird brittleness because the "initial page load" is not handled the same way as modifications of that page.
Now it's much closer to using the same set for the initial load and subsequent edits. This is a net win for people working on the frontend, in theory.
The more nuanced thing is that frontend tooling is so lacking in terms of performance, despite being something that theoretically should work very fast. In particular, having a bunch of language tooling written in Javascript is the JS ecosystem's billion dollar mistake IMO.
Re: Server Side Rendering at scale
#19> Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded. The fact that they don't make a reference like, "hey, ya know, how _everything_ worked just a few years ago" tells me they think this is somehow a novel idea they're just discovering. They the…
Client side rendering is needed for apps that work offline. SSR improves the user experience for first time use of those apps and enables SEO. What you say is subjective but I somewhat agree with your opinion, but only for web sites, not web apps. Overall I agree Yelp should have stuck with the existing system as their product functions as a site.
> Client side rendering is needed for apps that work offline.
Any .html page works offline. You don't need any JS or framework for that. If your JS-powered page doesn't work offline, it means either it requires online connectivity to solve problems, or its badly designed and does not respect "progressive enhancement" principles.
> SSR improves the user experience for first time use of those app
SSR improves UX for everyone. Seriously most "web" pages these days takes dozens of seconds to load and use a non-negligible percentage of our CPU/RAM. If you want to know what real-world conditions look like for literally over a billion people, run tests from a core2duo (or a similar VM) with 2GB RAM with simulated 10% packet loss and 1Mbit/s bandwidth.
Re: Server Side Rendering at scale
#20Earlier quoted context omitted.
> They could have built this in Java, .Net, Go, really any shared memory concurrency runtime and threading, and would not run into any of these issues. It is funny how you can get away with using the wrong tool for the job in Software in a professional environment. Like imagine if you were hired to build a house, and you decided to build the foundation out of modeling clay because that's what you're used to working w…
Funny you should take this example. Unless you're building a skyscraper, for 1-2 floors clay is plenty good: in particular when mixed with wheat or other fibrous bodies (straw type), it's how many traditional houses have been built, and has many interesting properties: - sourced from local material (use a different type of clay or straw if you need), no need for chemicals or for sand imports from depleted beaches on…
Fair point re clay foundations, but I was talking about the tooling choice for server-side rendering, not server-side rendering itself. For instance if they had implemented this in Erlang or Go they likely wouldn't have run into this GC bottleneck they had to engineer around to be able to exceed 50 requests per second.
I'm a big fan of server-side rendering and am sure it could be used way more often to great effect.