> 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/Turb

> 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. https://pjax.herokuapp.com/ 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.