zlacker

>>rayhaa+(OP)
I'm not a javascript person so I was trying to understand this. if i get it right this is basically a way to avoid writing backend APIs and manually calling them with fetch or axios as someone traditionally would do. The closest comparison my basic java backend brain can make is dynamically generating APIs at runtime using reflection, which is something I would never do... I'm lazy but not dumb

>>javaki+lu
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+JS
"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+PG1
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.