The good news is that there wasn't much left in the article save a silly meme. Although perhaps this is worth pondering:
> We are fond of talking about the HOWL stack: Hypermedia On Whatever you'd Like. The idea is that, by returning to a (more powerful) Hypermedia Architecture, you can use whatever backend language you'd like: python, lisp, haskell, go, java, c#, whatever. Even javascript, if you like. There's no accounting for taste, after all. Since you are using hypermedia & HTML for your server interactions, you don't feel that pressure to adopt javascript on the backend that a huge javascript front end produces. You can still use javascript, of course, (perhaps in the form of alpine) but you use it in the manner it was originally intended: as a light, front end scripting language for enhancing your application. Or, if you are brave, perhaps you can try hyperscript for these needs.
> This is a world we would prefer live in: many programming language options, each with their own strengths, technical cultures and thriving communities, all able to participate in the web development world through the magic of more powerful hypermedia, rather than a monolith of SPAs-talking-to-Node-in-JSON. Diversity, after all, is our strength.
With JS or TS, it's really easy to have all the same IDEs, CI, testing frameworks — and of course libraries, programming idioms, and the general way of thinking both on backend and frontend.
This makes hiring easier, and hiring engineers is one of the tougher problems in tech companies.
There is a reason why folks writing Haskell on the backend try to compile it to JS for frontend, or go for PureScript. The same reason lies beneath other attempts to write non-JS and compile it to JS for client-side execution. Switching between languages for major components, and between different approaches these languages offer, has a real cost.
With JS being the only game in town for client side, the playing field is heavily tilted towards JS for everything.
(Yes, I know about WASM and about Dart. It's still not it, because they can't directly operate on DOM. It's like using a game engine to write a native Windows or MacOS app: most OS-wide affordances don't work.)
This probably feels like a big advantage if you’re in the JS world where setting up IDEs and bundlers and CI is a big involved endeavor, but Go+static HTML is close to effortless. No need for CI pipelines to build and publish source code or docs packages, and the test framework and build tooling require minimal effort to set up in a CI capacity. Similarly, Dockerfiles are trivial and minimalist, and everything builds, tests, and deploys lightning fast. It’s not as glitzy as some really high end web apps, but the quality is usually higher on the medium and low ends and it’s almost always faster.
Agreed, but I contend that this is a small share of the sites that use a frontend JS framework (which is to say that these frameworks are often used unnecessarily) and even those which genuinely need some serious JS could likely scale it back considerably to significant benefit. I say this as someone who usually argues in favor of the new and shiny.
This is perhaps the oddest point the article makes.
They argue that JavaScript is still available for its “originally intended” purpose of light scripting, but that using less JS on the front end somehow frees you to use whatever you want on the back end.
But there is nothing inherent to SPAs that would force anyone to use JS on the back end.
And if “diversity is our strength” then I see no reason that wouldn’t be equally true when building JS-heavy SPAs.
You're maintaining two development environments without also using JS on the backend, and require developers that are skilled with both environments and languages. This isn't really an issue with htmx, or with using JS at both ends.
> We are fond of talking about the HOWL stack: Hypermedia On Whatever you'd Like. The idea is that, by returning to a (more powerful) Hypermedia Architecture, you can use whatever backend language you'd like: python, lisp, haskell, go, java, c#, whatever. Even javascript, if you like. There's no accounting for taste, after all. Since you are using hypermedia & HTML for your server interactions, you don't feel that pressure to adopt javascript on the backend that a huge javascript front end produces. You can still use javascript, of course, (perhaps in the form of alpine) but you use it in the manner it was originally intended: as a light, front end scripting language for enhancing your application. Or, if you are brave, perhaps you can try hyperscript for these needs.
> This is a world we would prefer live in: many programming language options, each with their own strengths, technical cultures and thriving communities, all able to participate in the web development world through the magic of more powerful hypermedia, rather than a monolith of SPAs-talking-to-Node-in-JSON. Diversity, after all, is our strength.