Oh wow! This is a huge honour, thank you so much! I definitely started writing a "lol HTMX is shit" post, but it just wasn't honest. HTMX is incredibly powerful - I am a fan of what you all have done with it. This attempt on my part to try and write something server-side rendered wouldn't have happened without the kick up the butt HTMX gives me (and all of us).
No problem at all. There are aspects of htmx that are good and bad depending on context and experience, and I like having different perspectives on it available for people to read, so thank you for taking the time to put together an in depth essay on it.
I was quite excited for Datastart until I saw that they keep a good chunk of the functionality behind a proprietary license [1]. It's not even about the price (it is a bit steep though, but I guess if you use it in a commercial project it will pay for itself), it's the proprietary part.
A "good chunk of functionality" is a mischaracterisation. I don't use anything from pro and I use datastar at work. I do believe in making open source maintainable though so bought the license.
The pro stuff is mostly a collection of foot guns you shouldn't use and are a support burden for the core team. In some niche corporate context they are useful. You can also implement your own plugins with the same functionality if you want it's just going to cost you time in instead of money.
I find devs complaining about paying for things never gets old. A one off life time license? How scandalous! Sustainable open source? Disgusting. Oh a proprietary AI model that is built on others work without their concent and steals my data? Only 100$ a month? Take my money!
It's not about the money, it's about the fact that I would depend on vendor-locked functionality. I cannot maintain my own fork of it if for whatever reason I had to. I don't want to fork datastar if I don't have to, but I want to be able to do so if I have to.
Alpine does have a "pro" version as well, but it's just copy&paste code examples. I am not complaining about Alpine, and I even got my employer to pay the maintainer more than what the datastart guys are charging for their pro version. So again, this is not about money.
You get the entire source with pro. Nothing is stopping you maintaining your own private fork for use in your commercial product. If datastar the non profit disappear tomorrow you would still have the source. So where is the problem?
Datastar uses SSE. In practice you almost always want SSE rather than websockets or your own UDP protocol. Websockets are an operational nightmare once you get off the happy path.
Yeah, in my (limited) experience, htmx works best to grease the wheels of an oldschool multi-page app.
I tried building something with SPAish drag-and-drop interactivity using htmx, and my ultimate conclusion was that functionality like that should either be totally encapsulated as one big htmx swap unit or be written as js "islands" outside htmx.
For my projects that require a distinct unit of functionality, I typically reach for a JS library that I can include as a payload (no npm, no deps, just a JS file). SortableJS is a good example, so is MarkdownJS if I want the browser to handle MD rendering.
This only goes so far, though. At some point, an app developer might want to integrate these distinct units of functionality, and I'm not sure how I would go about that. I haven't gotten to that point.
I think I'd try a lightweight framework like preact or vue that I can use without a build step. Keep components as separate & stateless as possible; let them live as little islands of javascript, notifying other parts of the frontend of updates through custom DOM events and talking to the server directly with fetches.
I would love to see cross browser support for forms encoded as application/json instead of url encoded. Additionally making name attributes in forms a query path selector to be able to nest JSON data structures would go a very long way.
Regarding web components and htmx: I kind of disagree with the server sided rendering approach there because I believe in local first web apps that use JSON or other data formats to communicate, but I'm pretty stubborn like that.
Don't have much to prove it yet, but I'm working on gooey, my bindings and components library for WebASM. Hopefully I'll get there in the next months, though Go has a couple of limitations due to how the type system works.
> I would love to see cross browser support for forms encoded as application/json instead of url encoded. Additionally making name attributes in forms a query path selector to be able to nest JSON data structures would go a very long way.
This would be simply amazing. Would so drastically reduce the JavaScript truly needed for basic CRUD stuff. Could even eliminate it if you don’t need variable-length arrays. Just the simplicity of POSTing forms…
The first principles thinking of projects like htmx and Datastar is sorely needed in web development. The field has been led astray far too long by blindly following trends that were poorly designed to begin with.
You're so right - React is overwhelmingly popular despite its horrid design of running things on the client. No one should ever do that. Make the server do all the work!
innerHTML was the default of htmx for historical reasons, Alex pointed out that anything that can be achieved with innerHTML (or the other swap styles) can also be achieved with outerHTML (albeit with more violence to the DOM) so we felt that was the simplest option for a more general proposal.
I've been doing IT for decades. Many times I've come across something that seems stupid yet also has a non-trivial number of supporters. When this happens (and it will many times), don't just continue to think it's stupid. Question if you are stuck on some paradigm or mindset that makes the thing seem stupid to you. That might call for a good head shake, a walk in the park, or a weekend-long bender to open your mind to new ideas. You don't have to jump on their bandwagon, but at least you'll increase your understanding and strengthen your position.
Maybe it’s for a use case I don’t understand… but I don’t see why anyone would use this for a modern, complex, richly interactive web-app. I also don’t really see any examples of a high quality major production site using htmx.
Just reacting to the executive summary: where are the tradeoffs? The port decreased memory usage on the client significantly, by how much did the server's burden increase? How have their hosting costs changed now that less work is being offloaded to the clients?
idk they didn’t say, but the server side delta of JSON generation vs HTML generation is small in the overall scheme of things and HTML-style apps tend to be less chatty because they push you towards the one-request-per-view ideal
Right? Someone show this kid how we used to make web apps back in the day, using hardware 1/100th as powerful. Turns out you don't need to send megabytes of JS to the client to have it render a table
https://htmx.org/essays/#on-the-other-hand
Regarding the default swap behavior of "innerHTML":
https://htmx.org/quirks/#the-default-swap-strategy-is-innerh...
Our proposal to merge htmx functionality into the HTML spec uses outerHTML:
https://alexanderpetros.com/triptych/
Also consider datastar, it was written from an SSE-first perspective by a go engineer:
https://data-star.dev/