@gschwepp@chaos.social

> I think the point made by gabe is that only serverside JS is allowing some improvements and additions.
> And it is not intended to work with different path.

Yes, but I think its important to acknowledge that there is a reason for this: We are stuck with JS or something that compiles to JS when we want to interact with the DOM or other browser APIs. I feel like that should be treated as a given.

So if you want to do that DOM interaction on the server using the same code that you use in the browser, of course you need to run JS and a DOM implementation on your server!

Whenever someone expresses disgust or frustration with something, I feel compelled to try to "fix it" to understand why it's a problem and try to create a solution.

However sometimes the world just is frustrating, the human condition is frustrating, its not something that we can "fix" (well, maybe some religions disagree but whatever)

I feel like this is one of those times. If you want to run your browser code on the server, you have to run your browser code on the server! It seems clear cut to me. I don't think it's that way because of some intentional effort to create a web monoculture. I think it's just a natural consequence of the evolution of common practices in web design.

Obviously I'm missing something here, and it's probably related to why you would want to run your browser code on the server in the first place.

To optimize for clients with slower CPUs? To support users who have disabled JS?

Ultimately I don't think its really necessary most of the time. How many sites both require JS to render the page AND have to work in browsers that have JS disabled? It seems paradoxical.