We could go further and have a language written to run in a sandbox VM especially for that with a GUI library designed for the task instead of being derived from a document format.
Can you elaborate more on how this works? Do you mean JS loading server generated HTML into the DOM?
Note that with this approach you don't need to "render" anything, browser already done it for you. You merely attaching functionality to DOM elements in the form of Component instances.
I entirely agree. It is what I do when I have to - although I mostly do simple JS as I am a backend developer really, and if I do any front end its "HTML plus a bit of JS" and I just write JS loading stuff into divs by ID.
When i have worked with front end developers doing stuff in react it has been a horrible experience. In the very worst case they used next.js to write a second backend that sat between my existing Django backend (which had been done earlier) and the front end. Great for latency! It was an extreme example but it really soured my attitude to complex front ends. The project died.
Putting React with those two is a wild take.
> 99% percent of websites would work a lot better with SSR and a few lines of JavaScript here and there and there is zero reason to bring anything like React to the table.
Probably but as soon as you have a modicum of logic in your page the primitives of the web are a pain to use.
Also, I must be able to build stuff in the 1% space. I actually did it before: I built an app that's entirely client-side, with Vue, and "serverless" in the sense that it's distributed in the form of one single HTML file. Although we changed that in the last few months to host it on a proper server.
The level of psychological trauma that some back-end devs seem to endure is hilarious though. Like I get it, software sucks and it's sad but no need to be dramatic about it.
And btw, re forbidding stuff: no library, no process, no method can ever substitute to actually knowing what you're doing.
That's hilarious.
Casey Muratori truly is right when he says to "non-pessimize" software (= make it do what it should do and not more), before optimizing it.
The problem was that the front end developers involved decided to use Next.js to replace the front end of a mostly complete Django site. I think it was very much a case of someone just wanting to use what they knew regardless of whether it was a good fit - the "when all you have is a hammer, everything looks like a nail" effect.