Perhaps "canonical" would be a better word, and as your links suggested, the canonical way to work on JavaScript-language capabilities is to use a JavaScript interpreter you can run outside the browser.
> JavaScript interpreter you can run outside the browser.
You're moving the fencepost.
This thread is about how to render composable HTML components. Why do you need to run a JavaScript interpreter to do that? You just need an HTML interpreter. We do have JavaScript and that interpreter is the web browser.
By your logic that the interpreter should be in the same language as the stuff being interpretted, why are we using JavaScript to interpret HTML?
My original criticism was also about the dependency hell/culture around the Node ecosystem, moreso than Node’s capabilities as an interpreter.
> This thread is about how to render composable HTML components
I quite literally joined the fray in response to a question that asked: "how do you add JavaScript to your web bundle?" To me, it would be appropriate to say: "the class of JavaScript we can easily support in this app must be exclusively browser-testable, and we ignore DX-style features JS devs expect as our app just rebuilds and reloads quickly"
> why are we using JavaScript to interpret HTML?
Who is doing that? We're using JavaScript to have dynamic HTML updates client-side, but calling that "interpreting" is hilarious.
> My original criticism was also about the dependency hell/culture around the Node ecosystem, moreso than Node’s capabilities as an interpreter.
Which makes it even more strange that you basically took a fat shit on Node.js with no expansion [0]
[0]:
> How do you plan to add JS to your Go web app?
This is what I mean by Node.js being a hammer and everything looks like a nail.
I didn't post any links and I seriously lost the thread of the conversation here. Why would you need to run a JS interpreter to be able to include JS in a website?... Confusing.
> I didn't post any links and I seriously lost the thread of the conversation here
Indeed, my mistake; I assumed such a response to a comment challenging "the idea that Go is the correct language to write web apps with JS in" with a response like "[i]f the project is live and is serving its purpose, and if that doesn't convince you that $INSERT_LANGUAGE is the correct language" could only come from the person upstream.
That user themselves acknowledged that there isn't meaningful JS in their Go web app, which means it's NOT "serving the purpose" that we were discussing in this subtree of the thread.
> Why would you need to run a JS interpreter to be able to include JS in a website?
You usually need a language interpreter to develop features in that language, no? Developing your bundle in the browser is not known to be a high-quality workflow from the perspective of DX.
Anyways, this is all silly, people building HTML reports from non-JS languages are arguing you don't need JS to make client interactivity, naive stuff.
Well, I still don't think you need JS interpreter to simply include JS in your project e.g. PHP Laravel, Elixir Phoenix et. al. serve JS assets just fine via integration with webpack, esbuild and the like.
Sure, but this is a far cry from a bespoke Go creation - these are production grade libraries with serious dev hours backing them that are generating JS for you.
Not sure Go has one of those wired.