I continue to be be amazed at how a vastly superior architectural pattern – generate HTML on the server, then optionally add to it on the client – became something other than the default choice
Replying to @slightlylate
To be super clear, I mean "SSR" in the way it's practiced in the JS world today. Specifically "run the JS on the server, ship a snapshot, then ship the JS". I'm *not* dunking on PHP-era "output HTML, the end". That pattern is *fast*. "SSR" can be good if we omit the cilent JS

Oct 31, 2019 · 10:33 PM UTC

12
48
3
111
Vastly superior, really? If you want to implement an application, would you implement it by generating a bunch of PDFs each linking to another PDF?
2
1
Yes, vastly superior, and the PDF analogy is completely broken.
1
4
Blame that on the (now literal) script kiddies, with their #TC39, #WHATWG and, mostly, the uncontrolled bigface madness at Google, and, to a lesser extent, Facebook and Airbnb, among others.
Replying to @stilkov
It’s pure economics. Instead of app operators paying for HTML processing on the back end, they use “free” processors on the client, and benefitting from CDN and caching.
1
1
Replying to @stilkov
I continue to be skeptical of any approach that requires 1000s of dependencies to successfully come together to work.
1
2
Replying to @stilkov
The most important downside of having SSR is Tha fact that it doesn't mandate you to build any kind of API. Most SSRs directly work on DBs etc, with no scripting or integration facility.
Replying to @stilkov
I see it as a confirmation of conways law. I always experienced a strong division of front- and backend, to the point where companies ordered the FE from one agency and the BE from another...
1
6