> client for progressive enhancement which is what your Go pitch does not do.
We have progressive enhancement in our Go app based on HTMX.
Also see Rails/Turbo and Pheonix/Elixir.
Also, before the era of JS devs who only know the hammer of React and React-inspired HTML rendering libraries, there was PJAX to do progressive enhancement. It's not that hard of a problem to motivate reinventing the wheel HTML rendering wheel with yet-another-JavaScript-framework. In that light, it's probably better to just stick to React which provides a superset of functionality and is battle-tested, but I digress. Most of the original complexity of PJAX was smoothing out browser inconsistencies. It's way easier to add progressive enhancement with standardized HTML5 libraries.
Observe how this JS library's source repo doesn't have a package.json and the vendor directory is rather shallow. The first commit was before Node.js even existed.
As for HTMX, it's a JavaScript library. It's 10kB with zero dependencies, and you can just drop-it in with a script tag.
I never criticized JS or a particular JS library. My original comment is about the dependency hell (and quality) of Node packages.
> framework that lets you write JS functions
Why is it important to have a framework and to write it is as JS function? That's an incidental detail if the goal is to compose HTML.
> rambling about your favorite language.
No, JavaScript is my favorite language. I just don't like NPM culture. We chose Go because it made sense for our use-case, as opposed to Node.js being an automatic default just because it's a frontend hammer.
NPM is just a package manager - I don't get why it's blamed for everything wrong with the world. You can find same issues / challenges / dependency "hell" with any other popular language and its packages or equivalent. Maven certainly comes to mind.
We have progressive enhancement in our Go app based on HTMX.
Also see Rails/Turbo and Pheonix/Elixir.
Also, before the era of JS devs who only know the hammer of React and React-inspired HTML rendering libraries, there was PJAX to do progressive enhancement. It's not that hard of a problem to motivate reinventing the wheel HTML rendering wheel with yet-another-JavaScript-framework. In that light, it's probably better to just stick to React which provides a superset of functionality and is battle-tested, but I digress. Most of the original complexity of PJAX was smoothing out browser inconsistencies. It's way easier to add progressive enhancement with standardized HTML5 libraries.
https://pjax.herokuapp.com/
Observe how this JS library's source repo doesn't have a package.json and the vendor directory is rather shallow. The first commit was before Node.js even existed.
As for HTMX, it's a JavaScript library. It's 10kB with zero dependencies, and you can just drop-it in with a script tag. I never criticized JS or a particular JS library. My original comment is about the dependency hell (and quality) of Node packages.
> framework that lets you write JS functions
Why is it important to have a framework and to write it is as JS function? That's an incidental detail if the goal is to compose HTML.
> rambling about your favorite language.
No, JavaScript is my favorite language. I just don't like NPM culture. We chose Go because it made sense for our use-case, as opposed to Node.js being an automatic default just because it's a frontend hammer.