mamcx
Using html (and tailwindcss) have been the major productivity gain in web front-end development for us.

The speed on the UI is noticeable for our users (a lot of underpowered androids!) and the interactivity is equal than our prior vue version.

React/Vue is like Nosql: Good for certain niche scenarios but overkill for most use cases. Plain html/css is pretty performant and so easy to do than duplicate the state (+validations, structures, routes,...) between client/server.

So, if you are on the fence: Just try it. Is very likely it will be FAR simpler than you imagine!

AtomicOrbital
I decided to become a server developer as opposed to front end to avoid the js ecosystem meltdown... however I see server side tools like kubernetes have also become so ladened with exposing complexity we too find little time for actual creative development

watching a time lapse of a single biological cell develop for it's first few hours reminds me of the software tooling landscape... throbbing, twisting, shaking, bifurcating

mouzogu
Its funny to me how all these people who learned js/react (bootcampers/"fullstackers"?) before html are now discovering html. as a web dinosaur like me (15 years) i've watched this whole cycle play out.

not that js/react are not useful, but rarely should be your starting point. much better to use them progressively when the trade off are worthwhile.

likortera
Something it took me some time to understand, and I feel very dumb for that, is that with these modern "SPA" tools such as Next, you can still do quite easily dumbed down non interactive websites that do traditional form posts. It works perfectly fine.

The other way around, using the dumber tools and trying to do highly interactive apps, is a lot harder.

That might be part of the reasoning most things are nowadays built with these spa like frameworks.

Not that I agree. Just trying to understand.

recursivedoubts
great article showing how htmx and hyperscript can play together

i know they aren't going to be everyone's cup of tea, but htmx is a pretty pure take on "what if HTML had kept going as a hypermedium", generalizing the various limitations currently placed on HTML. htmx stays within the original, REST-ful model of the web, exchanging hypermedia with the server in a way that is extremely compatible w/ Roy Fielding's description of the web architecture.

hyperscript is an event & DOM oriented scripting language, based on HyperTalk, the old scripting language for HyperCard. definitely not everyone's cup of tea, but it fills a need for a general, event oriented language that is easily embedded directly in HTML. This complements htmx really well in many cases. hyperscript is definitely much more speculative, but it has some pretty interesting features, such as async-transparency: https://hyperscript.org/docs/#async

anyway, it's a different take on web dev, but I'm glad to see some folks running with it and I'm happy to answer questions

dangrossman
I miss hand-writing webpages in Notepad and then FTP'ing them to the public_html directory on the server to make them live. The amount of infrastructure, libraries, build tools, pseudo-languages, etc layered on top of each other some developers/orgs use to make a simple form today is crazy to me. It also feels super fragile: deploy a website today, come back to it in 5 years to make some changes, and half the tools and libraries you need will be gone.
shroompasta
Angular -> React -> Vue -> Svelte -> Solid -> Marko -> Hotwire

Please stop.

The reason why React is so powerful is because of the maturity of React Native.

If you're a startup deciding your FE framework and you have mobile to consider, then chances are that React is best fit.

Unless you have capital to blow on a separate native team, lest it even be more separated to kotlin / swift, then sure you can possibly afford all these niche FE frameworks.

Lets not even talk about hiring pools.

React is good enough, and it's a shame that many of you think the answer is a new framework with better philosophy.

Trust me, I love reactivity > virtual dom, but React is good enough.

It doesn't need to be the best, it just needs to do its job.

The only thing I'll ever consider switching to is when WASM comes out with a framework - till then I'm betting on React.

tipiirai
What is the lesson of this article? Instead of using React or Vue, you should use htmx and hyperscript to have less stuff under node_modules?
bryanrasmussen
The first comment on that page is that this approach produces inaccessible UIs, not sure if that would be the absolute case or not, as it didn't look like the article was taking accessibility into consideration.

All that said I don't think this gives any real benefit over JS, sure, fix node_modules bloat, but I guess I'm a little bit skeptical if there wouldn't end up being hyperscript bloat if it became the biggest programming language in the world powering what for many is their defacto platform and thus everything needed to be solved in it.

synergy20
it's a good fit(alpine also fits well here) for 'legacy' server-side-rendering framework like django. rails and php already have their own similar approaches.

SPA still has its own place though: a backend provides the data, and a frontend renders it. the separation of two concerns still has lots of benefits not just for traditional website, but also for browser-based GUI(e.g. Electron apps).

bluewalt
I think people in comment should not try to compare HTMX to SPA directly, but have a broader view of the whole pros/cons of the tech stack.

For example, let's say you need to write an admin dashboard with many pages, no fancy stuff. Odds are you'll be very productive with a good old Django/Rails, having no API to write and a single simpler project to maintain.

Once that monolithic framework choice is made, before HTMX, as soon as you needed interactivity, you had to mess with jQuery and the code was quickly awful. The only solution was to plug a SPA framework and develop an API (this is not trivial!). HTMX (and other tools like Alpine.js) solve that problem well.

So, the question is not "is HTMX better than SPA frameworks", but rather: "Knowing that I can now build decent front-end with Django/Rails, does a more complex stack with Next worth it?"

HTMX-like tools make SPA frameworks a little less indispensable in some use cases. That's it.

rexpop
"A backend web and desktop application developer" whose "preferred frameworks are Django for Python and WPF for C#" has, unsurprisingly, a naive impression of what's needed out of a UI framework.
beebeepka
What the htmx anti js crowd refuses to accept is the existence of applications that do not fit their world view.

Serving html is trivial but do we really need every back-end juggling this stuff just to make these guys happy? What do they do when they have to support a number of clients. Oops...

projektfu
The article uses as its first example one of my most-hated fashions as a user of a website--the modal dialog entry form in html. Makes it hard for me to stay interested. Honestly, this is one thing I like about the multi-page app flow over single-page apps.
gimme_treefiddy
One of the things that I found lacking, was doing like general computing-esque business intelligence tasks in htmx. For example, how would you set src on image tag upon a click. Ended up having to use jquery.
moltar
That syntax just smells like a leaky abstraction and is jarring. Also probably lacks typing and poor intellisense support. Not sure why I’d pick that over conventional offerings.
dgut
I prefer Stimulus vs htmx + hyperscript for two reasons:

1. You can easily reimplement all htmx and hyperscript functionality and fine-tune to your liking

2. You are not limited by htmx and hyperscript

asciiresort
> In recent years, a few mavericks and renegades have started to turn away from the world of JS frameworks and the inevitable bloated node_modules folders

Some projects claim they are "zero dependencies" but a few sentences into the readme and you see an `npm install` and now you notice there is `package.json` after all . They meant zero runtime dependencies, which is still praiseworthy, but not zero `devDependencies`.

For my greenfield web app, I attempted to have zero dev dependencies on Node. I wrote some vanilla HTML, JS, CSS, and now needed to reduce network transfer. Requirements:

- minify

- inlining CSS file into HTML

- compress with Brotli

- print out final byte size

- nice to have: run a dev server that serves static Brotli

We know the story with WebPack. I looked to Parcel instead because it's the "zero-config" tool. It was promising because it inlined my `@import css` into my HTML, and logged out the filesize. The watch and reload feature wasn't working as promised, but that was nice to have anyways. For Brotli compression, which is mainstream at this point, I quickly needed to add a `.parcelrc` config. Their code sample didn't work because it turns out that in the real world you need to make your .parcelrc extend/inherit "@parcel/config-default". Parcel stopped logging at the compressed file sizes and not the final Brotli file sizes. Finally, Parcel's dev server is useless to me because you can't set encoding headers for "Brotli" files so the browser just attempts to download it. I didn't have a .gitignore file, and adding this one Node dependency on Parcel added 3,000 new files. To be fair, that's miniscule for a Node project.

I asked myself if I can achieve the same results with CLI tools that are not Node. I first looked to the Golang ecosystem. I stumbled upon https://github.com/tdewolff/minify. It just does minification. It's comparable in output size to other Node minifiers, but faster and just works. The lexer code is very readable, even for me who is not a compiler or systems expert. It's one command to install the CLI, and one command to Minify. You can do `npm install global -g` to get CLIs, but Node supply chains tend to be much deeper.

This bespoke one-liner does the CSS inlining for me:

  RUN sed -i "s/@import \"style.css\"/$(cat style.css)/g" index.html`
For Brotli compression, I went with the official first party CLI ( also Go based ) instead of using a third-party wrapper like you'd have to do with JavaScript.

One thing I was missing in NPM scripts as a self-documenting way of describing what commands to build, run, test. I've seen cases where people are beholden to a `package.json`, sometimes when their project doesn't even involve JavaScript. When you have a hammer, everything looks like a nail. It turns out Makefiles are a better way of doing this, especially if you don't already have a active relationship with Node

  .PHONY: help

  help: ## This help.
   @awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST)

  # DOCKER TASKS
  build: ## Build the container
    podman build -t ${APP_NAME} .

  run: ## Run container on port configured in `config.env`
   podman run -it --rm -d --env-file=./config.env - 
 p=$(HOST_PORT):80 --name="$(APP_NAME)" 

It's even better than self-documentation, because the documentation is self-documenting:

  $ make help 
  help                           This help.
  build                          Build the container
  run                            Run container on port 
  configured in `config.env`
bzmrgonz
I am keeping my fingers crossed and saying a few our fathers for www.redwoodjs.com JAMSTACK for the WIN.
sr.ht