@gabek Well, I think you should be specific, it means that if you want _your server to be able to run your front end code_ it means you need to run javascript on your server.
I think thats something more fundamental and categorical, not something we can do anything about. node.js is simply the most popular way to run JS on the server.. its not the only one! Just like V8 is the most popular way to run js on the client, its not the only one.
Is it more problematic than the site not loading at all for folks who have disabled javascript or manage it with a whitelist?
Or more problematic than maintaining a polyglot web application with noscript versions of everything and progressive enhancement versions of everything, with the entire app spanning something like 6 or 7 different languages?
I don't think its about making frontends "shiny". Not everyone has the luxury of designing sites that are JS-free by default. Server side JS is just one possible avenue we can pursue in search of a universal web platform that works for everyone. Code once, deploy to every internet connected device. That was the idea, at least... Honestly it's kinda amazing it still works at all, considering how much legacy the web stuff has accumulated over the years.
@forestjohnson We are drifting a little bit. NoScript and blocking frontend JS is a whole other rabbit hole. People are blocking JS for good reasons. We are not here close to have a solution for this problematic.
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. The "universal web platform" you mention would in my opinion be the death for the ecosystem you described as "amazing ...
@forestjohnson considering hot much legacy the web stuff has accumulated".
The vivid ecosystems of different "web" technology interacting with another gave you the opportunity to find your solution to a given task without dictating any tech stack. That's exactly the point why it is working as you described. Forcing serverside JS (which was never intended to run on server side. And is considered by _many_ backend people as a very bad idea,) does in my opinion contradict this idea.
> 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.
@forestjohnson Don't get me wrong. I do not feel frustrated in any way. This is no religious thing (at least for me).
The part of "you are missing something": I assume you are a frontend guy.(?!)
At this point in time JS does not really keep up with the tech stack that the backend people work with. There are requirements that the backend people learned over time (from perl, php, python to go ... and so on) which JS does not remotely fullfill (personal view).
I do web apps in general, front end and back end. I only worked with server side JS one time, and that was at my old job with React and express / node.js
I'm confused about what you are saying:
> JS does not really keep up with the tech stack that the backend people work with
I don't know what you mean specifically.
google translate says:
ich schäme mich, dass ich kein deutsch kann, weil es einfacher wäre zu kommunizieren, aber leider bin ich nur ein "podunk" amerikaner, ich spreche nur eine sprache😳
@forestjohnson You don't need to be ashamed. No worries, I was not very clear here.
To make my point a bit more clear let us just compare maybe go or python with js on serverside.
You have feature rich programming languages where it is easy to create powerful webserver even with concurrency, virtual env and all the 'good stuff' that makes the languages popular here.
In my js experience, js is missing most of these features. But I must admit, that I never worked with serverside js.
@forestjohnson Maybe I am just a grumpy old man who does not get the point why people want to use serverside js.
@forestjohnson @gabek Frontend and backend have significantly different requirements. Running a webserver is not 'language' specific. It is a whole stack behind that.
Javascript has been developed with frontend in mind. Forcing it to the backend environment just to make the frontends shiny is quite problematic.