zlacker

There is a certain category of developers (a category that multiplied in size many times over around the same time as the boom in coding bootcamps, take that for what you will) who believe that there's virtue in running the same code on the client and the server, despite them being totally different paradigms with different needs. This kind of thing is the predictable result.

>>mvdtnz+(OP)
to be fair to bootcamp developers, i don't think they ever did "believe that there's virtue" in the setup, they were just told this is what you use and how you use it.

>>mvdtnz+(OP)
It's just the latest take on what we had 20 years ago with .NET's WebForms and Java's JSF. Both of which tried to hide the network separation between client and server and were not fun to work with.

Those who don't learn history are bound to repeat it, and all that.

>>mvdtnz+(OP)
"You can run JavaScript on the frontend and the backend!" always struck me as the weakest marketing ever. I've been around the block, and which language the web application uses is hardly any sort of limiting factor in ease of development. (And ideally, your frontend has as little JavaScript as possible anyway.) There is very little that can't be programmed in a more web-friendly way, like POSTing forms and rendering HTML templates. Sure, I guess Google Maps can just be a fat application, but like... every eCommerce site doesn't need to be some big ball of React mud, I promise.

>>ventur+6O
I think the main problem was that 'the standard' wasn't evolving fast enough to solve the bulk of the issues around input validation and UI building so we got this crap language that is powerful enough to hide a thousand footguns in a few lines of code. It will never be perfect so it will generate this kind of issue for the next century or so.

If instead, we would have gradually expanded the HTML standard without adding a fully functional programming language into the content stream we would have had better consistency between websites and applications and we would treat the browser like what it is: a content delivery mechanism, not an application programming platform. That's the core mistake as far as I'm concerned.

>>mvdtnz+(OP)
> There is a certain category of developers (a category that multiplied in size many times over around the same time as the boom in coding bootcamps, take that for what you will) who believe that there's virtue in running the same code on the client and the server, despite them being totally different paradigms with different needs.

First, "same code on the client and the serve" is wrong. Since when do RSC's run on both the client and the server?

Also, you honestly believe that wanting to use the same language across paradigms is a "coding bootcamp" thing lol? That something like Blazor was born out of a coding bootcamp?

Have you ever built a web app? Both front and back end? Have you ever had to deal with the tension of duplicating code? Models, validation, ideas?

If you answered yes to those questions but still don't see how de-duplicating code like that can be important, than I'm 100% positive you're still in the boot camp.