Comment by datastack | Hacker News Reader

Comment by datastack | Hacker News Reader

Lot of bashing of this idea, not sure why. The entire industry has shifted from "web developer" to frontend/backend developers. What used to be a web developer is now called full stack.

It seems like a big deal to me and the entire shift is an indicator of how much the IT community is behind front end clients talking to a separate back end. Server side rendering is no longer considered normal. Server site rendering now means something entirely different. It is about running your frontend code on the back end, So you still have the separation, but instead running it on the same machine. Now the same ui code has to be compatible with two different run times. This is much, much more complex than traditional server side rendering.

I'm glad we now have things like single page apps and client site interactive applications, because some apps were really not possible with server side rendering unless with a lot of Jquery hackery that quickly becomes unmaintainable...

However, I do think that front end technologies are overused, so I agree with the author, And I also think this is objectively a contrarian opinion, considering my initial point.

I wouldn't say server side rendering is a "Thiel Truth," because it's a thing that is already popular and uncontroversial and agreed upon by millions.

There is an echo chamber where this happened:

* Facing massive datacenter costs, Google and Meta realized that if they could hand off rendering to the client, they could have smaller datacenters and save a lot of money. Things like React and Angular were born. Other companies with large datacenter costs followed suit, many monies were saved.

* This is when things started to get a little crazy. VCs started pushing heavy client-side SPA this and that because if anyone knows how to cargo cult, it's VCs. Devs started pushing it because it was a hard way to do things and if anything improves your salary, it's being involved with the hard bleeding edge stuff. Also inventing another JS framework turned out to be a great way to pad your resume. Design and UX people realized this was a whole new can of worms they could get paid to open, and dug right in. (In all cases note that the original point, saving money on compute at massive scale, was totally lost, and people just made up new reasons.)

* Outside of this echo chamber which is utterly convinced it's filled with the smartest people in tech, life has actually gone on pretty normally for the rest of us, we're still doing stuff on the server whenever we can, and caching the hell out of everything we can, and being judicious with fancy client side frosting because complexity is generally the enemy. That said, it's definitely true that an entire generation of young web developers has been lost to madness because young web developers also like to cargo cult a lot, and the damage will take years to repair.

But yeah, not really a Thiel truth

> Facing massive datacenter costs, ...Other companies with large datacenter costs followed suit, many monies were saved.

I can't think of anyone who doesn't want to save money on servers. Seems like a pretty good general win to me for using the client.

> complexity is generally the enemy

Agreed. But minimizing complexity doesn't require not using a heavy client. You can go fully the other way and make the backend a relatively simple permissions and validation mask on top of a database and let the front end hold all the relevant state.

Use client side rendering and have simplicity too.

I will admit that an SPA turns out to be easier to mess up and design really poorly, but I believe that this is a tooling maturity issue rather than fundamental to the platform. SSR frameworks have had over a decade longer to mature.

Interesting take. Haven't heard the argument before that it saves server costs. Not convinced that this is the case, but perhaps, for a google.

Reflecting, I suppose that businesses relying on Php/Laravel or Ruby are probably still enjoying simple SSR development. I've personally transitioned to Java and then .NET, and haven't seen SSR since. Which corner of software are you in, where you see SSR still being dominant?

It does sound like a classic cargo cult.

This is very wrong.

For one thing, I don't think the motivation of Google and Meta was datacenter costs, though I could be wrong about that.

But it's not that "VCs were pushing client-side SPA", it's that lots of the companies that wanted to build applications, found that they had a set of problems that was best solved by things like Angular. The state of the art before that for highly interactive client-side apps was JQuery, and for a few years, things like Backbone.

Angular solved a real problem - people wanted to build more complex and more interactive client applications in a browser, but just using regular JS (or JS with Jquery) led to really messy applications and was very hard on development.

You can try and handwave all that away as an echochamber, but I think the majority of the industry moved to SPA frameworks as solutions for building client-side apps.

> I don't think the motivation of Google and Meta was datacenter costs, though I could be wrong about that.

Have you forgotten that these are profit-maximizing companies? Why do you think they do anything? To maximize profits. That is always the answer. If it doesn't maximize profits it's a mistake and they will back away from it.

So for example Facebook either thought that React would increase sales, or reduce costs, otherwise they wouldn't have created it. React hasn't moved the sales needle for them (why would it - they are an advertising company - React has precious little to do with selling more advertising). Ergo it was created to reduce costs. The cost benefit of moving all that compute out to the client is easy to demonstrate and significant for a company of that size.

Is there any evidence, even anecdotally, that reducing datacenter costs had any significant relevance to the development and rise in popularity of single-page apps and JavaScript UI libraries like React and Angular?

My own memory of the history of the web is that early web sites with a lot of client-side interactivity benefited greatly from the huge leap in interactivity, and came out several years before JavaScript libraries were widely available for ordinary developers to build web sites with similar functionality. (I'm not counting arguably "non-web" technologies like Flash and Java applets.) The earliest such web sites I can remember are e-mail, calendar, and mapping apps.

That doesn't match what I saw. What I saw was people hammering on latency because of its effect on conversion and other forms of engagement, and believing that the best way to control latency when consumers often had slow, unreliable connections was to avoid round trips and/or push them into the background. I.e., avoid page loads. SPAs allowed developers (at a cost, granted) to control how a web page's functionality degraded when dealing with slow or spotty connections, and that was seen as having immense ROI for anything consumer-facing.

Naturally after years of investment in building consumer-facing sites like this, the skills and tools became ubiquitous and arguably overused.

> I'm glad we now have things like single page apps and client site interactive applications, because some apps were really not possible with server side rendering

And maybe server side rendering is just the right answer for websites which are not the two you mentioned.

that's the point, glad you understood

Reply on news.ycombinator.com