4 ms·

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

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.

DarkNova6 3y ago
> 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.
- datastack 3y ago
  that's the point, glad you understood
safety1st 3y ago
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
- BackBlast 3y ago
  > 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.
- datastack 3y ago
  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?
- MichaelZuo 3y ago
  It does sound like a classic cargo cult.
- systemvoltage 3y ago
  [flagged]
- edanm 3y ago
  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.
deleted 3y ago
[deleted]

DarkNova6 3y ago

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

datastack 3y ago
that's the point, glad you understood

safety1st 3y ago

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

BackBlast 3y ago
> 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.
datastack 3y ago
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?
MichaelZuo 3y ago
It does sound like a classic cargo cult.
systemvoltage 3y ago
[flagged]
edanm 3y ago
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.

deleted 3y ago

[deleted]