htmx(htmx.org)
htmx.org
htmx
https://htmx.org/
290 comments
Heh, the "Memes" section of their Essays page is brilliant: https://htmx.org/essays/#memes
I actually found their haiku quite insightful:
javascript fatigue:
longing for a hypertext
already in handAnd lots more if you follow him on Twitter.
https://twitter.com/htmx_org
https://twitter.com/htmx_org
A lot are also missing the point entirely for comedy's sake. Which is admittedly fine for a meme...
While I love making projects with htmx, doing the equivalent for the complicated frontends we've got at my dayjob would not be enjoyable to maintain either. You'd end up with with fragment routes all over the place and will have serious issues finding where which is used, as the routes are all just strings with variable substitutions. Its also annoying to write non-e2e tests for the resulting backend IME, which is totally fine for a lot of applications, but forces you to restructure your code awkwardly to be able to write unit-tests in the backend
While I love making projects with htmx, doing the equivalent for the complicated frontends we've got at my dayjob would not be enjoyable to maintain either. You'd end up with with fragment routes all over the place and will have serious issues finding where which is used, as the routes are all just strings with variable substitutions. Its also annoying to write non-e2e tests for the resulting backend IME, which is totally fine for a lot of applications, but forces you to restructure your code awkwardly to be able to write unit-tests in the backend
There's a class of applications where JS-heavy SPAs make perfect sense. HTMX should not be viewed as a general anti-JS movement. It is indeed unmaintainable to deliver the same functionality in HTML as a JS SPA would allow.
The catch is that very few JS SPAs actually deliver that functionality either - the functionality I'm talking about is desktop-app-grade functionality (think a trading terminal for example) that very few JS SPAs actually deliver. Most JS SPAs are just shitty reimplementations of basic browser functionality, and that is reasonably trivial to convert to server-side rendered HTML with HTML or ad-hoc (inline?) JS sprinkled in where necessary.
Keep in mind that server-side-routing doesn't prevent the use of React or similar frameworks either. If you have an application where 90% of the pages would be fine as server-side-rendered HTML but 10% require heavy interactivity, you can have your server return a page that embeds React or your JS framework of choice. (the reverse is also possible - if you have a JS-heavy website but have a few "boring" pages like for example an account details form, you can have your backend serve that as an HTML form and just have your JS iframe it)
The catch is that very few JS SPAs actually deliver that functionality either - the functionality I'm talking about is desktop-app-grade functionality (think a trading terminal for example) that very few JS SPAs actually deliver. Most JS SPAs are just shitty reimplementations of basic browser functionality, and that is reasonably trivial to convert to server-side rendered HTML with HTML or ad-hoc (inline?) JS sprinkled in where necessary.
Keep in mind that server-side-routing doesn't prevent the use of React or similar frameworks either. If you have an application where 90% of the pages would be fine as server-side-rendered HTML but 10% require heavy interactivity, you can have your server return a page that embeds React or your JS framework of choice. (the reverse is also possible - if you have a JS-heavy website but have a few "boring" pages like for example an account details form, you can have your backend serve that as an HTML form and just have your JS iframe it)
> You'd end up with with fragment routes all over the place
Or, you could define every route to render a full page by default and render a fragment only if you detect an htmx request. So you end up with the same number of routes as for a normal MPA.
Or, you could define every route to render a full page by default and render a fragment only if you detect an htmx request. So you end up with the same number of routes as for a normal MPA.
Those are great.
What's the logo of the cornucopia looking thing next to the django and rails logos?
What's the logo of the cornucopia looking thing next to the django and rails logos?
Flask, a python micro framework.
This is gold !
so good
Hmmmm... no.
This:
This:
<button hx-post="/clicked" hx-swap="outerHTML">
Click Me
</button>
<button 'outerHTML')">
Click Me
</button>
- When does something happen here?
When the button is clicked.
- What does happen?
htmx.post() is called.You are missing the fact that html has very restricted list of events that can be defined in an attribute. Htmx allows to listen on any event, plus some extra features on top, such as event throttling, polling, synchronization between elements. Stylistically I can see the appeal of your proposal and even agree on some ways, but it's not functionally equivalent
https://htmx.org/attributes/hx-trigger/ https://htmx.org/attributes/hx-sync/
https://htmx.org/attributes/hx-trigger/ https://htmx.org/attributes/hx-sync/
What would be a simple example of an event that you want to define inline but can't in plain html?
Can you give minimal example on jsfiddle so we can compare different approaches?
Can you give minimal example on jsfiddle so we can compare different approaches?
Here you go: https://plnkr.co/edit/DQJrBWWQFgHtpltf?open=index.html&previ...
Another big aspect of allowing to handle any event is integration with other JS libraries. See this basic example of interacting with Sortable JS [1]
Also, htmx has a response header called `HX-Trigger`[2] which lets server trigger custom events on the client and you can handle those events as well[3]. This is quite useful if you have interdependent data and you want to refresh regions on the page in response to user actions somewhere else (for which htmx allows multiple different patterns for different scenarios)[4]
[1]: https://htmx.org/examples/sortable/
[2]: https://htmx.org/headers/hx-trigger/
[3]: https://htmx.org/attributes/hx-trigger/#triggering-via-the-h...
[4]: https://htmx.org/examples/update-other-content/
Another big aspect of allowing to handle any event is integration with other JS libraries. See this basic example of interacting with Sortable JS [1]
Also, htmx has a response header called `HX-Trigger`[2] which lets server trigger custom events on the client and you can handle those events as well[3]. This is quite useful if you have interdependent data and you want to refresh regions on the page in response to user actions somewhere else (for which htmx allows multiple different patterns for different scenarios)[4]
[1]: https://htmx.org/examples/sortable/
[2]: https://htmx.org/headers/hx-trigger/
[3]: https://htmx.org/attributes/hx-trigger/#triggering-via-the-h...
[4]: https://htmx.org/examples/update-other-content/
Hmm... that does no look like a minimal example to me.
Is this the relevant line?
Is this the relevant line?
<div hx-get="/random" hx-trigger="every 2s"></div>
These are multiple minimal examples, they are completely self contained, independent of each other and separated by h1 tags.
I separated those examples to different files: https://plnkr.co/edit/0TWYrtbMGP9UAzE4
Also, you may notice there is <template/> tag. It's just for the demo [1], it serves as a mock endpoint
[1]: https://htmx.org/docs/#creating-demos
I separated those examples to different files: https://plnkr.co/edit/0TWYrtbMGP9UAzE4
Also, you may notice there is <template/> tag. It's just for the demo [1], it serves as a mock endpoint
[1]: https://htmx.org/docs/#creating-demos
Simpler version of example 1:
https://jsfiddle.net/w6nrek81/
No need to bring up multiple examples. We just need one to show that htmx makes something simpler. This isn't one though.
https://jsfiddle.net/w6nrek81/
No need to bring up multiple examples. We just need one to show that htmx makes something simpler. This isn't one though.
I'm sorry, but that's just not fair comparison. You requested a minimal example and then pick the simplest one and tell me that you can implement this minimal example with minimal code. Of course you can fill a div with a random number with Vanilla JS, it can even be just a one liner, but it's not the point.
Your solution, for example, will break if the target div already has content in it. It also won't work if we want to insert the content after or before the element, you need to somehow keep track of the element being triggered, so it will grow more complex.
And still, it won't work with custom events
> No need to bring up multiple examples. We just need one to show that htmx makes something simpler.
This approach is not productive. A single example could be easily dismissed on the ground that it's not enough to justify design decisions that htmx has. I wrote multiple examples and provided additional links specifically to show various use cases that htmx covers and to avoid playing ping-pong of tiny examples.
> This isn't one though.
You just picked one example, which also happened to be the simplest, and seemingly ignored everything else. I apologize, I don't know how to continue from here.
Your solution, for example, will break if the target div already has content in it. It also won't work if we want to insert the content after or before the element, you need to somehow keep track of the element being triggered, so it will grow more complex.
And still, it won't work with custom events
> No need to bring up multiple examples. We just need one to show that htmx makes something simpler.
This approach is not productive. A single example could be easily dismissed on the ground that it's not enough to justify design decisions that htmx has. I wrote multiple examples and provided additional links specifically to show various use cases that htmx covers and to avoid playing ping-pong of tiny examples.
> This isn't one though.
You just picked one example, which also happened to be the simplest, and seemingly ignored everything else. I apologize, I don't know how to continue from here.
Thanks for this. The basis of many new apps, I suspect ;-)
Think of the tags as a constraint. It's quite easy to check that certain constraints are met with tags. It's much harder to check on this <onevent>="htmx.<action>(<url>, <swap>)" convention. Soon you'll have unconstrained code creeping in (e.g. ? htmx.post('/clicked', 'outerHTML') : void(0)").
> no magic would be needed, a lot of indirection and complexity would be avoided
Is this an informed criticism based on your experience having worked with htmx, or is it just an off the cuff opinion?
Personally, I don't think the goal should be "no magic", or "no indirection", or "no salt", or no "sugar". I feel that aiming for just the right amount of those things, to have the goody without crossing over to disgust, is a sound goal.
Is this an informed criticism based on your experience having worked with htmx, or is it just an off the cuff opinion?
Personally, I don't think the goal should be "no magic", or "no indirection", or "no salt", or no "sugar". I feel that aiming for just the right amount of those things, to have the goody without crossing over to disgust, is a sound goal.
Do you consider the href attribute of anchors "magic"?
I like your change. Much clearer.
Makes me more interested than the current syntax.
Makes me more interested than the current syntax.
Your opinion is totally valid. However, is it really difficult or tricky to recognize that 'click' the default event of a 'button' tag? Isn't 'onclick=' kind of redundant?
we don't specify "click" on anchors or "submit" on forms, do we?
I use htmx heavily on https://golfcourse.wiki
It’s nice and easy to work with, and lets me keep almost everything in python (flask).
It’s a bit more bandwidth, but it’s a hobby/bootstrapped project right now, and since it’s an api, if I ever make any money, it’ll be easy to rewrite and heavy lifting.
I like it because I’ll write 3x the code in the same amount of time if it’s python. I just don’t like js much even though I know it’s fine.
It’s nice and easy to work with, and lets me keep almost everything in python (flask).
It’s a bit more bandwidth, but it’s a hobby/bootstrapped project right now, and since it’s an api, if I ever make any money, it’ll be easy to rewrite and heavy lifting.
I like it because I’ll write 3x the code in the same amount of time if it’s python. I just don’t like js much even though I know it’s fine.
"Load HTML from a URL and replace part of the page with it" is a powerful technique for progressive enhancement, even if you don't want to use a framework like this. A button can send users without JavaScript to the URL directly, while users with JavaScript can have that part of the page replaced inline.
HTMX is just HTML.
HTMX substitutes a DOM element with the HTML response you get from an on-click HTTP request instead of redirecting to a new page.
Claims of HTMX being yet another complexity or yet another JavaScript framework fail to acknowledge this.
HTMX substitutes a DOM element with the HTML response you get from an on-click HTTP request instead of redirecting to a new page.
Claims of HTMX being yet another complexity or yet another JavaScript framework fail to acknowledge this.
no, htmx is (technically speaking) just another JS framework.
Just look how VueJS got started, it began with sprinkled in html and was marketed as the framework for backend devs, as you were just writing html to render lists/objects etc.
And htmx does more then what you're alluding to here, as should be obvious from reading their docs about server-side events, notifications, lazy loading, JS extension api etc
Just look how VueJS got started, it began with sprinkled in html and was marketed as the framework for backend devs, as you were just writing html to render lists/objects etc.
And htmx does more then what you're alluding to here, as should be obvious from reading their docs about server-side events, notifications, lazy loading, JS extension api etc
This is VERY cool. I’m very excited to see a project like this. Is it me or there has been a lack of wow-factor projects lately like when jquery was introduced. Or templating engines like handlebars. Or when angular and react took over. Browsing the htmx site felt like learning about those aforementioned projects for the first time.
I love htmx and have used it to build internal tools quite successfully. It allows me to work in my preferred language on the backend, write some basic ass html and spinkle in a few attributes and get some frontend reactivity that I otherwise wouldn’t have because I hate Javascript.
My problem with this approach is the same one raised by Dijkstra against the goto statement. These update actions are too unrestricted and don't offer any way to analyze the program's progress systematically, based on the program source code.
The same can be said of a React frontend that talks to a JSON API. There is some structure, organization, and convention to the API endpoints, one-way data flow, and so on. Otherwise it’s chaos.
On our most recent project we do the same with Django and HTMX. Organized endpoints by component. Composable, reusable server-side components with django-components [1]. And we’ve been orders of magnitude more productive, shipping more in 1-2 months than we did the previous 12-18 months working with React.
[1] https://github.com/EmilStenstrom/django-components
On our most recent project we do the same with Django and HTMX. Organized endpoints by component. Composable, reusable server-side components with django-components [1]. And we’ve been orders of magnitude more productive, shipping more in 1-2 months than we did the previous 12-18 months working with React.
[1] https://github.com/EmilStenstrom/django-components
How same could be said? React makes calls to json api typically - both sides are very inspectable. Given that you have to resort to session for state, things can get messy on the data layer (a poison pill for stateless rest json api)
Could you elaborate? Genuinely curious.
let's say that you have an upvote button
<button hx-post="/upvote"
hx-trigger="click"
hx-target="#notification-bar"
hx-swap="outerHTML"
>
Upvote
</button>
That's because this example is an anti-pattern, the swap should be local [1], the button changes itself (to an orange arrow, to disable itself, etc) and the notification tag (#notification-bar) should be responsible of its own behavior.
An idea could be that the notification bar is polling a notification endpoint every Xsec or on a specific event [2], or if you want to be fancy with WebSockets [3]
[1] They actually talk about this: https://htmx.org/essays/locality-of-behaviour/
[2] for example afterRequest or afterSwap : https://htmx.org/events/#htmx:afterRequest
[3] https://htmx.org/extensions/web-sockets/
An idea could be that the notification bar is polling a notification endpoint every Xsec or on a specific event [2], or if you want to be fancy with WebSockets [3]
[1] They actually talk about this: https://htmx.org/essays/locality-of-behaviour/
[2] for example afterRequest or afterSwap : https://htmx.org/events/#htmx:afterRequest
[3] https://htmx.org/extensions/web-sockets/
This doesn't help. Now the implementation depends on another component correctly reading some global state, an undeclared dependency. If I'm reading the upvote button I have no idea that it uses a notification-bar. If I'm reading the notification-bar I have no idea what it's for or who uses it.
HTML ids are globally unique so the answer is wherever `id="notification-bar"` lives.
Isn't this comparable to any other situation where you reference something outside a project, even in C with libraries?
(I've never used HTMX or even looked beyond this page for it, so maybe what I'm about to say is logically wrong.)
If I said that for an HTMX project you must define all components you use within the project, wouldn't this hx-target example be very easy to identify quickly in the project? You simply grep '#notification-bar' and see where it lives in the project...
I think the goto comparison is somewhat related, because it's about reasoning about control flow (or rather, how it makes it unreasonable) - but isn't this example pretty easy to reason about when you consider you're one search away from finding the notification-bar in the project? You're still creating a tree of components and interactions, and in order for that to happen, you must be able to reference them with confidence in some way.
I still prefer the React way (tree structured components) regardless, but HTMX does seem interesting from a DevX point of view. I think it'll be forgotten about in about 5 years.
(I've never used HTMX or even looked beyond this page for it, so maybe what I'm about to say is logically wrong.)
If I said that for an HTMX project you must define all components you use within the project, wouldn't this hx-target example be very easy to identify quickly in the project? You simply grep '#notification-bar' and see where it lives in the project...
I think the goto comparison is somewhat related, because it's about reasoning about control flow (or rather, how it makes it unreasonable) - but isn't this example pretty easy to reason about when you consider you're one search away from finding the notification-bar in the project? You're still creating a tree of components and interactions, and in order for that to happen, you must be able to reference them with confidence in some way.
I still prefer the React way (tree structured components) regardless, but HTMX does seem interesting from a DevX point of view. I think it'll be forgotten about in about 5 years.
if you decided to write C by building a lot of tiny global functions with no local state that called other globals functions, then it would greatly resemble programming with GOTO.
> a lot of tiny global functions with no local state that called other globals functions
Isn't that Haskell?
Isn't that Haskell?
What’s the difference to writing vanilla JS to do the same thing?
no differerence at all. jQuery functions like
$('.foo').on('click', () => $.ajax(... $('.bar').html(result) ))
So your complaint is not about HTMX, but about using any kind of JS without using a framework like React.
You don't need a framework like React but you should try to implement modules that are explicit about their dependencies and use local state as much as possible.
For example the upvote could be implemented like this:
For example the upvote could be implemented like this:
function renderUpvote(container, showNotification) {
$("<button>").appendTo(container).on("click", () => $.ajax( ...
result => showNotification( result ))
}
That’s great for building JS apps, not so much for progressive enhancement of HTML.
I’d really like some explanation about what I’m misunderstanding, downvoting without explaining anything doesn’t help anyone.
I continue to be impressed at the effort people will put into avoiding writing any JavaScript. Is it really easier to learn yet another DSL embedded in attribute tags rather than taking a day to setup your JS dev environment and then writing idiomatic code for running inside a web browser? Surely your htmx project will eventually cross a complexity threshold where you've added enough scaffolding that you may as well have setup a JS bundler in the first place, and yet the debugging, testing and deploying challenges will continue to push you into less-trodden territory.
I believe there might be a sweet spot for small projects unlikely to grow in complexity, maintained by a Python dev who is allergic to JS. But I don't see why you would want to invite yet another abstraction into the web stack, when it's built on top of the very language you're trying to avoid, and which you'll inevitably encounter in all its automagically obfuscated glory as soon as you run into a moderately complex problem.
I believe there might be a sweet spot for small projects unlikely to grow in complexity, maintained by a Python dev who is allergic to JS. But I don't see why you would want to invite yet another abstraction into the web stack, when it's built on top of the very language you're trying to avoid, and which you'll inevitably encounter in all its automagically obfuscated glory as soon as you run into a moderately complex problem.
I might be going against the grain here, but the JS ecosystem is just a series of goalposts that are constantly moving and it has burned so many people over the years that folks just don’t want to deal with it.
I’m fine learning JS, but with the ecosystem it isn’t just learning JS. It’s learning the new hotness for packaging / versioning, it’s the frameworks that are constantly in flux, it’s the inconsistent abstractions that seem to be mercurial and constantly changing.
If we were to sit down and write some frontend code to say, make a simple kanban board every 9 months using “current” JS best practices or popular frameworks over the last 6 years…
How many different tools might you run across?
How easy would it be to take that 6 year old code and bring it up to modern standards?
The reason you see people allergic to the JS ecosystem is because it is incredibly opinionated while simultaneously being a free for all.
I’m fine learning JS, but with the ecosystem it isn’t just learning JS. It’s learning the new hotness for packaging / versioning, it’s the frameworks that are constantly in flux, it’s the inconsistent abstractions that seem to be mercurial and constantly changing.
If we were to sit down and write some frontend code to say, make a simple kanban board every 9 months using “current” JS best practices or popular frameworks over the last 6 years…
How many different tools might you run across?
How easy would it be to take that 6 year old code and bring it up to modern standards?
The reason you see people allergic to the JS ecosystem is because it is incredibly opinionated while simultaneously being a free for all.
What I hate is that you don't even write JavaScript anymore.
You write fantasy future JavaScript. Sure, it will be available in ECMAScript 23, scheduled to drop in real browsers in 2092. But for now, here's a convoluted mess of polyfills, Babel, and WebPack, that we HOPE papers over the real behaviour of browsers, and suddenly your test-and-debug cycle has introduced a flow-shattering 15-second build cycle each time you change a file.
You write fantasy future JavaScript. Sure, it will be available in ECMAScript 23, scheduled to drop in real browsers in 2092. But for now, here's a convoluted mess of polyfills, Babel, and WebPack, that we HOPE papers over the real behaviour of browsers, and suddenly your test-and-debug cycle has introduced a flow-shattering 15-second build cycle each time you change a file.
There's actually no need for that anymore. JavaScript as is supported right now in the latest Chrome, Firefox and Safari is already pretty good. You can get quite far without any backend tooling these days.
The only thing which I believe is still needed is a bundler when your project grows to a certain size. Fetching a complex graph of thousands of files will likely never be fast.
The only thing which I believe is still needed is a bundler when your project grows to a certain size. Fetching a complex graph of thousands of files will likely never be fast.
> The only thing which I believe is still needed is a bundler
And a type system... And maybe a styling system... Oh and let's have some nice Rx data flows!
But, jokes aside, even if you go that Route you still end up with a complex npm project that involves dozens of libraries.
I've been at that point every year since starting doing npm spas in 2014ish (mostly as side projects, my work is typically more serverside). At some point I just decided that the upkeep wasn't worth it any more as you create the same stack every year but with wildly different libs. For me the solution was to switch to an elm+sass+webpack boilerplate that hasn't changed since 2018 or there abouts.
And a type system... And maybe a styling system... Oh and let's have some nice Rx data flows!
But, jokes aside, even if you go that Route you still end up with a complex npm project that involves dozens of libraries.
I've been at that point every year since starting doing npm spas in 2014ish (mostly as side projects, my work is typically more serverside). At some point I just decided that the upkeep wasn't worth it any more as you create the same stack every year but with wildly different libs. For me the solution was to switch to an elm+sass+webpack boilerplate that hasn't changed since 2018 or there abouts.
Even bundlers can be pretty stupid and simple. I still just use r.js for even large apps. Webpack isn't hard to set up, either. But my frontend code has almost no dependencies... I refuse to deal with React, Angular, etc etc. I have a very nice, simple component-building / screen scaffolding system that's about 1000 LOC. You extend the component and load up some HTML and just work with it directly in JS when you want to update data, resize it, etc. There's no need for all these frameworks that try to plant logic back into HTML. I love having the HTML templates pure and the logic unbound from them.
Do you still use gulp or is it webpack nowadays?
Gulp is extremely out of date these days.
Using webpack resulted in some of the most painful experiences of supporting serious production software in my career.
The progress and maturity of JS tooling/DX as a result of stuff like esbuild and Vite, or Typescript more generally, can not he understated.
For people not doing frontend it can seem like a neverending series of new stuff but there is a very rational and tangible level of progress being made. Especially for serious JS devs not jumping on hype trains.
I don't miss the days of gulp and webpack at all and I don't blame anyone for hating on JS if they experienced using them professionally.
Using webpack resulted in some of the most painful experiences of supporting serious production software in my career.
The progress and maturity of JS tooling/DX as a result of stuff like esbuild and Vite, or Typescript more generally, can not he understated.
For people not doing frontend it can seem like a neverending series of new stuff but there is a very rational and tangible level of progress being made. Especially for serious JS devs not jumping on hype trains.
I don't miss the days of gulp and webpack at all and I don't blame anyone for hating on JS if they experienced using them professionally.
> Using webpack resulted in some of the most painful experiences of supporting serious production software in my career.
I never invested too much time in understanding webpack but it does feel like fighting it a lot of the time when I want to change something in my personal projects.
Care to share some anecdotes of those painful experiences?
I never invested too much time in understanding webpack but it does feel like fighting it a lot of the time when I want to change something in my personal projects.
Care to share some anecdotes of those painful experiences?
Gulp / Babel and then transition to webpack was my introduction to JS.
Now Vite seems to be all the rage? But is it a bundler?
Wepack seems to be very hard to configure. Looks like nginx config vs caddy config.
Now Vite seems to be all the rage? But is it a bundler?
Wepack seems to be very hard to configure. Looks like nginx config vs caddy config.
Tools such as babel, webpack, esbuild, postcss, etc. are now considered a bit low-level, and usually do not need to be set up manually these days.
Rather, one would opt for something like vite, the spiritual successor to react-scripts, that bundles all of these tools together with some good defaults/plugins, a means to configure them, and usually also some kind of dev server with hot module reloading, for a complete developer experience using your preferred toolchain.
Check out 'parcel' for something pretty modern, universal, and low effort, IMHO.
Rather, one would opt for something like vite, the spiritual successor to react-scripts, that bundles all of these tools together with some good defaults/plugins, a means to configure them, and usually also some kind of dev server with hot module reloading, for a complete developer experience using your preferred toolchain.
Check out 'parcel' for something pretty modern, universal, and low effort, IMHO.
It's JavaScript. Everyone is moving on to Turbopack. Or Vite. Or ESBuild. Or Bun.
I definitely like the batteries included and speed of bun.
Please don't tempt me.
You're outdated. Everyone is using Parcel now.
Funny, how even the sibling comment states something different. Maybe there are a lot of bundler bubbles in the JS world?
sorry, I said that 9 hours ago... now we're using Bun actually :D
With evergreen browsers, you can write modern JavaScript and it'll run in the browser just fine. And it's not like TC39 is pumping out lots of wild changes. The largest recent change is what, top level await? That's not exactly a wildly different language feature.
A lot of this JavaScript criticism was appropriate circa 2017, but these days JavaScript's gotten a lot more stable.
A lot of this JavaScript criticism was appropriate circa 2017, but these days JavaScript's gotten a lot more stable.
Sure. With evergreen browsers. For anyone using old devices with outdated hardware--tough luck! They can, I guess, go buzz off and leave you in peace to write Modern JS. After all, that's the most important thing.
At this point you'd need a 10 year old never-updated browser to run into this issue. Which, sure, maybe you need to cater to people who use browsers 10 years out of date. I don't think it's a huge market frankly and 10 year old browsers have larger issues like security.
I mean, JavaScript doesn't just run in browsers. Some older forms of JavaScript run in all kinds of software--embedded in Windows (JScript), embedded JavaScript engines in other runtimes (Java, Qt Quick), older Node.js software that people are stuck on for whatever reason. I'm sure many people don't care about making all of those devices obsolete but maybe with a slight amount of effort we can try to slow down the inevitable filling of landmines with perfectly workable devices?
Okay, those cases seem like situations where you'd need to be explicitly targeting those devices. Like if you're shipping new code to users that is being run on an old runtime, then sure, you should make sure that code is legacy JS. I don't see how that is unreasonable?
This is my problem with a lot of HN comments about JS: they read like they were written in 2014 (see also the “a new framework every week!” jokes)
ES2015 was the one big language update, and although it took a while to all roll out and for older browsers to die off, at this point we’re now living in “the future” and almost all language changes are incremental.
Like, you can write ES modules with async/await and run it in all modern browsers without any compilation. If you add an HTML import-map element you can even import node_modules by name.
Now, most people still prefer to use a bundler so that their users can load a single script instead of dozens of tiny ones, but that’s optional, and the gap between “the code you write” and “code that runs in the browser” hasn’t been this small in years.
ES2015 was the one big language update, and although it took a while to all roll out and for older browsers to die off, at this point we’re now living in “the future” and almost all language changes are incremental.
Like, you can write ES modules with async/await and run it in all modern browsers without any compilation. If you add an HTML import-map element you can even import node_modules by name.
Now, most people still prefer to use a bundler so that their users can load a single script instead of dozens of tiny ones, but that’s optional, and the gap between “the code you write” and “code that runs in the browser” hasn’t been this small in years.
Part of it could be different audiences.
Not everyone is on a greenfield project with full authority to grab the freshest and latest. Some of us are effectively living in 2014-- they can't say "no, you can't use IE11" to paying customers, or committed to a platform at the wrong phase of maturity, and remain stuck around a state-of-the-art-in-2014 build process.
Not everyone is on a greenfield project with full authority to grab the freshest and latest. Some of us are effectively living in 2014-- they can't say "no, you can't use IE11" to paying customers, or committed to a platform at the wrong phase of maturity, and remain stuck around a state-of-the-art-in-2014 build process.
The "new hotness" only matters if you're going to try and get a job as a FE dev in a large team. The "old hotness" still works, and likely has the more obscure bugs worked out of it.
And you can always just write the thing in JS without any hotness at all. The JS ecosystem's obsession with frameworks is a diversion. You really only need a framework if your site is super complex. And even then, if you're careful about how you write your JS, you may not need a framework (you'll end up creating your own, probably).
I'm with you that the JS ecosystem is a seething mess, but I don't think that's actually a problem unless you want a job as a FE dev. You can just ignore it ;)
And you can always just write the thing in JS without any hotness at all. The JS ecosystem's obsession with frameworks is a diversion. You really only need a framework if your site is super complex. And even then, if you're careful about how you write your JS, you may not need a framework (you'll end up creating your own, probably).
I'm with you that the JS ecosystem is a seething mess, but I don't think that's actually a problem unless you want a job as a FE dev. You can just ignore it ;)
This.
90% of the toolchain is not required at all. Just quality of life improvements.
Good ES6 (and TS) idiomatic code feels actually closer to reading Scala than reading a legacy Jquery app.
And the V8 engine has so much investment in optimizations today that is actually closer to Java and in some cases lighter than Go.
IMHO people don't hate JS in reality. They hate the strawman made of the worst parts of Junior code ever encountered and inconsistencies that really don't happen in practice unless you actively look for them.
90% of the toolchain is not required at all. Just quality of life improvements.
Good ES6 (and TS) idiomatic code feels actually closer to reading Scala than reading a legacy Jquery app.
And the V8 engine has so much investment in optimizations today that is actually closer to Java and in some cases lighter than Go.
IMHO people don't hate JS in reality. They hate the strawman made of the worst parts of Junior code ever encountered and inconsistencies that really don't happen in practice unless you actively look for them.
Same could be said for php…
I usually oppose the use of any new "hotness" in a project until that "hotness" is ~10 years old.
This is a great post. I'm not a web dev myself, but I have a couple on my team. I criminally underrated the challenge of maintaining a complex web app. It is madness: endless incompatible, forced upgrades.
Real Question: Why does this ecosystem have this issue, but others have it less? For example: Why doesn't Python or Java have the same madness?
Please don't read the question as criticizing web dev / JavaScript / etc. My curiosity is genuine.
To be fair, it does feel like C++ is more maddening than Python or Java, but part of can be explained by (1) native code generation (build is way harder than languages that run in a VM) and (2) the insane complexity of the language which _traditionally_ made IDEs much weaker than other languages. MSFT Visual Studio and JetBrains CLion have come a long way. (I can already feel the HN pitchforks poking at me for these C++ comments!)
Real Question: Why does this ecosystem have this issue, but others have it less? For example: Why doesn't Python or Java have the same madness?
Please don't read the question as criticizing web dev / JavaScript / etc. My curiosity is genuine.
To be fair, it does feel like C++ is more maddening than Python or Java, but part of can be explained by (1) native code generation (build is way harder than languages that run in a VM) and (2) the insane complexity of the language which _traditionally_ made IDEs much weaker than other languages. MSFT Visual Studio and JetBrains CLion have come a long way. (I can already feel the HN pitchforks poking at me for these C++ comments!)
Because the originals parts where broken. I am speaking of 90s JavaScript, the DOM/Browser API and the not so much "batteries included". They could neither get fixed without a standard by committee approach of the browser vendors.
So we started to compensate: end state: Typescript to fix JS, React/Angular/Svelte to fix DOM API and a npm package hell to have batteries included. And all of that bundles, compressed, etc to have a good download time.
So we started to compensate: end state: Typescript to fix JS, React/Angular/Svelte to fix DOM API and a npm package hell to have batteries included. And all of that bundles, compressed, etc to have a good download time.
Yes. When JavaScript is your only option, the only solution to JavaScript is... more JavaScript :(
Seems like the old joke about XML:
"XML is like violence: if it doesn't solve your problem, you're not using enough of it."
"XML is like violence: if it doesn't solve your problem, you're not using enough of it."
I’m pretty sure you can continue to use jquery and everything still works fine :D
I’m over here continuing to use react for 9+ years but every post on here acts like it’s changing every day.
Classes? Components as functions? Classes again? Hooks?
Classes still work fine if you want to keep using them.
This doesn't appear to be what the docs recommend anymore, which is exactly what my (obviously flippant) post was meant to highlight.
As a Vue user things have changed a lot.
I think this comment is a bit out of date, especially if you’ve been watching JS from a distance for the past couple decades. This would’ve been true circa 2014. In 2023 it’s obsolete.
There’s one framework that won, that’s all you have to learn, as far as the industry goes (as opposed to hobbyists) it’s been decided. React won. React is the framework you learn.
“Popular frameworks for the past 6 years” - React has been dominant over that entire time period, from beginning to end. React is what you would’ve reached for 6 years ago (it was already mature then, in 2017) and it’s what you’d turn to now. This is what I mean. You could update your React code to use hooks instead of classes - or you could not, it will continue to work if you don’t.
The “JS changes all the time” take is frankly out of date in 2023. “Which framework do I learn…” you learn React, the framework that won. It’s pretty much that simple.
There’s one framework that won, that’s all you have to learn, as far as the industry goes (as opposed to hobbyists) it’s been decided. React won. React is the framework you learn.
“Popular frameworks for the past 6 years” - React has been dominant over that entire time period, from beginning to end. React is what you would’ve reached for 6 years ago (it was already mature then, in 2017) and it’s what you’d turn to now. This is what I mean. You could update your React code to use hooks instead of classes - or you could not, it will continue to work if you don’t.
The “JS changes all the time” take is frankly out of date in 2023. “Which framework do I learn…” you learn React, the framework that won. It’s pretty much that simple.
That’s a bubble. You are in a bubble. React is dominant, sure, like the US is dominant, but it’s not The World.
The important part is that it's a bubble you can choose to live in. Companies everywhere use React and almost no one need ever choose to learn something else. As long as you know it you will be employable for another 20 years, just like with Java.
But people in that bubble keep shaming people who aren’t… and react keeps changing, so it’s not like you learn it once, it requires careful study and understanding of all the different permutations that are used in different environments.
You generally can’t go from company A to company B who both use react and have the same calling convention, code structure or tool chains even though they are both using react.
You generally can’t go from company A to company B who both use react and have the same calling convention, code structure or tool chains even though they are both using react.
Ouch, 20 years? I sincerely hope so for their sake, but I wouldn’t bet 10 dollars on it.
20 years is very optimistic; React is already losing users: https://2022.stateofjs.com/en-US/libraries/front-end-framewo...
Retention shows a clear trend for all frameworks and even in general conversation Solid.js has been taking up more and more of peoples' attention with signals.
The compound advertisement of hearing about Svelte and why it's always going to be faster than React because of not having a VDOM along with Solid.js will make a dent in React and it will become the next Angular. 20 years is not going to happen.
Retention shows a clear trend for all frameworks and even in general conversation Solid.js has been taking up more and more of peoples' attention with signals.
The compound advertisement of hearing about Svelte and why it's always going to be faster than React because of not having a VDOM along with Solid.js will make a dent in React and it will become the next Angular. 20 years is not going to happen.
I don't use React.
Only VanillaJS.
And my clients are happy it seems.
So React clearly isn't the only choice, unless you're a new graduate with no clue about anything, then sure start with React.
Only VanillaJS.
And my clients are happy it seems.
So React clearly isn't the only choice, unless you're a new graduate with no clue about anything, then sure start with React.
Hard disagree… react is probably one of the best examples of this. React 15/16/17/18 over this period of time is a nightmare to maintain for people who don’t keep up with react if they want to casually jump in or out of.
If you built an app in react 16 and wanted to upgrade to 18, using the documentation it almost resembles 2 different frameworks. Sure, maybe the code executes, but all the js devs would be like “why did you write it like that”?
If you built an app in react 16 and wanted to upgrade to 18, using the documentation it almost resembles 2 different frameworks. Sure, maybe the code executes, but all the js devs would be like “why did you write it like that”?
htmx is another tool just like that, another goalpost in the frontend webdev world. It's just happens that the most recent hype is "don't write JS", but fundamnetally it's no different. Just another framework/library that has gotten some traction. In a few years we'll be back full cycle and it will be in vogue to write JS again, probably because htmx and associated projects have grown to complex.
A key difference is the promise to be working even without JavaScript.
It's no different from anything else. The promise if every framework is to abstract away some low-level details. Whether that means writing "higher-level JS" like jQuery did many years ago already, and hundreds of other frameworks do today, or inventing some new DSL like htmx does that translated to JS internally. No difference.
"Htmx is a dependency-free, browser-oriented javascript library."
https://htmx.org/docs/#installing
https://htmx.org/docs/#installing
The framework itself is written in Javascript
The end user is NOT writing Javascript.
The end user is NOT writing Javascript.
> I might be going against the grain here, but the JS ecosystem is just a series of goalposts that are constantly moving
Welcome to real life.
Beware the ecosystem that does not change (COBOL).
Welcome to real life.
Beware the ecosystem that does not change (COBOL).
Never seen a tool where the people who don't use it seem to make up some of the craziest, most obscure, weirdest justifications for avoidance. It's totally fine if you're not personally down with HTMX!
However, stating that we're avoiding "idiomatic code" is incorrect. Are you claiming React and JSX and useEffect are idiomatic? Really? Surrounding HTML fragments with return() and attributes with braces is idiomatic? These are literally the antithesis of HTML.
Perhaps the real reason we're happy is that we're experiencing a huge productivity increase, lower cognitive load, fewer difficult bugs, terrific performance, and a great dev experience.
However, stating that we're avoiding "idiomatic code" is incorrect. Are you claiming React and JSX and useEffect are idiomatic? Really? Surrounding HTML fragments with return() and attributes with braces is idiomatic? These are literally the antithesis of HTML.
Perhaps the real reason we're happy is that we're experiencing a huge productivity increase, lower cognitive load, fewer difficult bugs, terrific performance, and a great dev experience.
Here's some code that I don't find especially idiomatic:
https://htmx.org/docs/#validation-example
<form hx-post="/test">
<input _="on htmx:validation:validate
if my.value != 'foo'
call me.setCustomValidity('Please enter the value foo')
else
call me.setCustomValidity('')"
name="example"
>
</form>
https://htmx.org/docs/#validation-example
the code here is hyperscript, not htmx:
https://hyperscript.org
i use hyperscript because I created it and like it, but the example could just as easily use JavaScript, the point is to show that htmx respects custom validations
https://hyperscript.org
i use hyperscript because I created it and like it, but the example could just as easily use JavaScript, the point is to show that htmx respects custom validations
The docs don't seem to suggest using it for non-trivial things without hyperscript. https://htmx.org/docs/
They do suggest being able to use it without learning a lot of hyperscript, but I see the same with Svelte, where you can get by on copying and pasting a great deal. https://learn.svelte.dev/
They do suggest being able to use it without learning a lot of hyperscript, but I see the same with Svelte, where you can get by on copying and pasting a great deal. https://learn.svelte.dev/
most of the examples don't have any hyperscript in them
htmx generalizes HTML as a hypermedia, making any element a hypermedia control that can issue any type of HTTP request in response to any event and target any element in the DOM for replacement
that's the concept, improve HTML, and it gives you quite a bit more than plain HTML, but it is intentionally constrained to not go beyond that
for things beyond what that gives you, I am not afraid to recommend scripting: Fielding explicitly included scripting as an optional constraint his description of the REST-ful architecture of the web
A good example of how we like to see scripting used w/ a hypermedia system is the Sortable.js demo, which shows htmx integrating w/ Sortable.js via events, the cleanest way to integrate hypermedia controls w/ client side scripting:
https://htmx.org/examples/sortable/
we have a chapter on client-side scripting in hypermedia systems here:
https://hypermedia.systems/book/client-side-scripting/
htmx generalizes HTML as a hypermedia, making any element a hypermedia control that can issue any type of HTTP request in response to any event and target any element in the DOM for replacement
that's the concept, improve HTML, and it gives you quite a bit more than plain HTML, but it is intentionally constrained to not go beyond that
for things beyond what that gives you, I am not afraid to recommend scripting: Fielding explicitly included scripting as an optional constraint his description of the REST-ful architecture of the web
A good example of how we like to see scripting used w/ a hypermedia system is the Sortable.js demo, which shows htmx integrating w/ Sortable.js via events, the cleanest way to integrate hypermedia controls w/ client side scripting:
https://htmx.org/examples/sortable/
we have a chapter on client-side scripting in hypermedia systems here:
https://hypermedia.systems/book/client-side-scripting/
> for things beyond what that gives you, I am not afraid to recommend scripting
I'm not suggesting that you don't. I'm suggesting that it's quite similar to SvelteKit, Remix, and now Next.js, and other form-friendly frameworks in what you'd need to know in order to do a non-trivial full stack JavaScript project that supports progressive enhancement.
I'm not suggesting that you don't. I'm suggesting that it's quite similar to SvelteKit, Remix, and now Next.js, and other form-friendly frameworks in what you'd need to know in order to do a non-trivial full stack JavaScript project that supports progressive enhancement.
The difference is that with HTMX you're not stuck in "full stack JavaScript" land. Any language that can generate HTML becomes a viable full stack option without the headaches of modern JS tools being forced into the mix.
Non native speaker here.
The unfamiliar programming language (which I've never used) seems to be binding some code to some type of validation event. "my" and "me" seem to refer to the input tag. "my.value" probably refers to the value of the input. If it's not foo it calls a setCustomValidity method with the input tag as the caller. Could be some built in method that you can call on any input tag or anything validatable.
Ok I just checked the link and setCustomValidity is part of the HTML5 Validation API (haven't worked on web dev in years).
I can assure you that the first person pronoun is among the first things we learn when studying English and assuming the code snippet does what I assume it does I'd say it's pretty intuitive to learn. Especially if we are comparing it to JS where "this" is not what you'd expect from using it in other languages, but the late-bound called of the function... except in all the cases where it isn't.
In any case, trying to guess how a programming language works is a very bad idea so it doesn't matter how obvious the language manages to be, you still should read the documentation.
The unfamiliar programming language (which I've never used) seems to be binding some code to some type of validation event. "my" and "me" seem to refer to the input tag. "my.value" probably refers to the value of the input. If it's not foo it calls a setCustomValidity method with the input tag as the caller. Could be some built in method that you can call on any input tag or anything validatable.
Ok I just checked the link and setCustomValidity is part of the HTML5 Validation API (haven't worked on web dev in years).
I can assure you that the first person pronoun is among the first things we learn when studying English and assuming the code snippet does what I assume it does I'd say it's pretty intuitive to learn. Especially if we are comparing it to JS where "this" is not what you'd expect from using it in other languages, but the late-bound called of the function... except in all the cases where it isn't.
In any case, trying to guess how a programming language works is a very bad idea so it doesn't matter how obvious the language manages to be, you still should read the documentation.
I would likely agree, however this example makes heavy use of hyperscript, which is an associated project by the same author, but is distinct from HTMX.
How do you do validation with custom error messages without it? It seems pretty table stakes for forms to me.
Where are the docs that make it easy to avoid hyperscript, if it's usable without hyperscript? This has hyperscript sprinkled in: https://htmx.org/docs/
Where are the docs that make it easy to avoid hyperscript, if it's usable without hyperscript? This has hyperscript sprinkled in: https://htmx.org/docs/
HTML already has a native validation API for form elements. https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_va... HTMX wraps that with some custom events and enables you to use the same API for non-form elements.
In the example above, if you need custom validation logic, you could handle the HTMX:validation:validate event with any normal JS event handler.
Of course, it's up to you to decide how much effort to put into client-side validation that can be easily bypassed.
In the example above, if you need custom validation logic, you could handle the HTMX:validation:validate event with any normal JS event handler.
Of course, it's up to you to decide how much effort to put into client-side validation that can be easily bypassed.
Mostly, you validate on the server and send html with error messages back.
If you really need client-side, yes, of course you have to script it. If hyperscript is not to your taste, you use a bit of js.
If you really need client-side, yes, of course you have to script it. If hyperscript is not to your taste, you use a bit of js.
That was implicit in my question. We aren't talking about writing purely server side web apps here, and it's reasonable to expect something like client side validation, given that this is meant to be an easy way to do full stack web apps. I think it is but not really easier than other major ones.
> We aren't talking about writing purely server side web apps here
Ok, but note that a big part part of the appeal of htmx is that yes, you work mostly server-side. If your use case absolutely needs client side code, htmx might not be the right fit. (But in many cases you don't need as much client-side Code as you might think at first.)
Ok, but note that a big part part of the appeal of htmx is that yes, you work mostly server-side. If your use case absolutely needs client side code, htmx might not be the right fit. (But in many cases you don't need as much client-side Code as you might think at first.)
Programming languages contain English words like if, self, else, then, function, def, this, exception…
Me/my is rarer: Reminds me of VB
Me/my is rarer: Reminds me of VB
it's a separate project, hyperscript:
https://hyperscript.org
it's based on HyperTalk, the scripting language of HyperCard:
https://hypercard.org/
with some Web-specific syntax thrown in to make things cleaner:
https://hyperscript.org
it's based on HyperTalk, the scripting language of HyperCard:
https://hypercard.org/
with some Web-specific syntax thrown in to make things cleaner:
add .visible to <section.fade-in/>Good luck having editor support, linting, formatting, intellisense or anything at all here. This is a f*ng nightmare.
Why do I continue to see people imply that React is the only way of writing frontend web applications with JavaScript? There are plenty of alternatives to React that I would say are far more "idiomatic". I highly recommend taking a look at Vue 3 or Svelte to get a better idea of what frontend JavaScript can be.
React isn't the only way, of course, but it's likely the most popular. Why do you consider Vue or Svelte to be valid alternatives but not HTMX, despite plenty of people endorsing it and openly proclaiming how successful it's been in their projects?
I personally do consider HTMX to be a valid alternative to React, but I also think that a lot of usage / promotion of it comes from people who are misinformed and think that the entirety of the JavaScript ecosystem is React. I consistently see a lot of people use HTMX over React alternatives purely because of a "distaste for JavaScript" or an understanding that everything is or has to be as complex as React unless you're using HTMX.
If people are "misinformed", that's a marketing fail by those other frameworks, despite many years of headstart. How are people even finding HTMX (with a single developer and until very recently, no corporate support) in a marketplace which includes Angular, backed by Google?
Or maybe people are kinda informed, and simply drawn to HTMX because it's easier to learn than Vue, Svelte, Mithril, Cycle, whatever (or they just don't want to try a zillion frameworks) and it works really well and developers seem to love it and recommend it a lot?
Or maybe people are kinda informed, and simply drawn to HTMX because it's easier to learn than Vue, Svelte, Mithril, Cycle, whatever (or they just don't want to try a zillion frameworks) and it works really well and developers seem to love it and recommend it a lot?
> or they just don't want to try a zillion frameworks
But isn't HTMX one of said zillion frameworks? What makes it any different?
But isn't HTMX one of said zillion frameworks? What makes it any different?
It's easy? It works? It feels like HTML? No build steps? No JSON? The primary documentation fits in a single page? Most common patterns (i.e. polling, and then stopping if necessary) are built-in? Because fundamentally, it's just standard HTML forms? The entire dev experience is focused on a single application (backend) as opposed to writing a backend and a seemingly separate frontend project, in a different language (unless you use JS on the backend)? Simply replacing HTML fragments is conceptually simpler than maintaining a shadow DOM? It embraces web standards/APIs (see client validation discussion above)?
Here's polling in Svelte: https://stackoverflow.com/questions/61391174/how-to-do-polli...
and in HTMX:
Maybe Svelte has an easier way, but Google isn't directing me straight to it, which is all part of the "easy to learn" aspect.
Here's polling in Svelte: https://stackoverflow.com/questions/61391174/how-to-do-polli...
and in HTMX:
hx-trigger="every 2s"
Maybe Svelte has an easier way, but Google isn't directing me straight to it, which is all part of the "easy to learn" aspect.
> Never seen a tool where the people who don't use it seem to make up some of the craziest, most obscure, weirdest justifications for avoidance
Sure you have: literally any frontend framework post, from React and Vue to roll-up, webpack, and everything in between. Tons of non-FE engineers or engineers that work on small and trivial apps will flood in to say why the lib in question, and usually the entire FE ecosystem, are crazy, rapidly changing, undecipherable, etc.
Sure you have: literally any frontend framework post, from React and Vue to roll-up, webpack, and everything in between. Tons of non-FE engineers or engineers that work on small and trivial apps will flood in to say why the lib in question, and usually the entire FE ecosystem, are crazy, rapidly changing, undecipherable, etc.
Is it really easier? Yes.
The project I’m currently building is an enterprise b2b SaaS and I’ve gotten it fully functional without writing a single line of JavaScript. By functional I mean it looks and behaves like there is JavaScript, because there is with HTMX, but it’s abstracted away to the point of taking none of my time, which is what matters.
There’s no way I could learn the JavaScript ecosystem in a day. Maybe I could get something functional in a day but the technical debt would be too costly. I’m not sure any human could learn it in a day with acceptable technical debt trade offs.
For my situation of an enterprise app that’s mostly declaring resources in the backend via API, it’s been much faster to write in my preferred backend language only. I build the API, make a command line tool in the same language that calls the API, then add a basic HTML form for the demo and it’s great.
The project I’m currently building is an enterprise b2b SaaS and I’ve gotten it fully functional without writing a single line of JavaScript. By functional I mean it looks and behaves like there is JavaScript, because there is with HTMX, but it’s abstracted away to the point of taking none of my time, which is what matters.
There’s no way I could learn the JavaScript ecosystem in a day. Maybe I could get something functional in a day but the technical debt would be too costly. I’m not sure any human could learn it in a day with acceptable technical debt trade offs.
For my situation of an enterprise app that’s mostly declaring resources in the backend via API, it’s been much faster to write in my preferred backend language only. I build the API, make a command line tool in the same language that calls the API, then add a basic HTML form for the demo and it’s great.
Software developers, especially DOM fearing front developers love using the word easy. It isn’t so much an infatuation but more like a fatal attraction obsession where obstruction means war on a very emotional level. Ironically, people are loathe to confront these feelings openly and thus cannot define the word easy with any kind of clear practical application.
So, I did the world a favor and wrote just such a definition: https://github.com/prettydiff/wisdom/blob/master/Easiness.md...
So, I did the world a favor and wrote just such a definition: https://github.com/prettydiff/wisdom/blob/master/Easiness.md...
I think what you're saying demonstrably doesn't apply to the majority of developers. You could follow something like this: https://learn.svelte.dev/tutorial/welcome-to-svelte
However you would just be able to do what you can do with SvelteKit (Parts 3 and 4). Not too different from what you can do with HTMX.
You would need to deploy SvelteKit but could have SvelteKit call your backend API for all of the heavy lifting and its deployment requirements would be minimal.
Yes, a bigger chunk of the JavaScript ecosystem takes longer to learn, but you can also do more with it. If you make an apples to apples comparison I think they're effectively in the same ballpark, and JavaScript is better just by having more resources.
However you would just be able to do what you can do with SvelteKit (Parts 3 and 4). Not too different from what you can do with HTMX.
You would need to deploy SvelteKit but could have SvelteKit call your backend API for all of the heavy lifting and its deployment requirements would be minimal.
Yes, a bigger chunk of the JavaScript ecosystem takes longer to learn, but you can also do more with it. If you make an apples to apples comparison I think they're effectively in the same ballpark, and JavaScript is better just by having more resources.
> You could follow something like this: https://learn.svelte.dev/tutorial/welcome-to-svelte
I think if you are, like me, someone who for various reasons never followed the JavaScript ecosystem for various reasons over the last few years (in my case because I was working on exclusively backend APIs in C#), coming back into trying to do any frontend website is just ten thousand people saying "it's not that hard, just follow something like this: x", where 'x' is any one of forfty hundred humungous different frameworks.
If you don't want to have to learn a whole new ecosystem but just want to bang out something that can take advantage of a bunch of modern-ish nice front end paradigms like being able to selectively update individual components without having to do a full page reload then htmx feels like it would hit the spot for a lot of different use cases.
(I say this having only read the site several times, usually when it pops up here in some context, and I always think "oh damn yeh that thing exists, I have to give it a go at some point!" but never actually have yet)
I think if you are, like me, someone who for various reasons never followed the JavaScript ecosystem for various reasons over the last few years (in my case because I was working on exclusively backend APIs in C#), coming back into trying to do any frontend website is just ten thousand people saying "it's not that hard, just follow something like this: x", where 'x' is any one of forfty hundred humungous different frameworks.
If you don't want to have to learn a whole new ecosystem but just want to bang out something that can take advantage of a bunch of modern-ish nice front end paradigms like being able to selectively update individual components without having to do a full page reload then htmx feels like it would hit the spot for a lot of different use cases.
(I say this having only read the site several times, usually when it pops up here in some context, and I always think "oh damn yeh that thing exists, I have to give it a go at some point!" but never actually have yet)
htmx is yet another one of those forty hundred humongous different frameworks.
It also uses a DSL that has no application outside of its specific corner.
It also forces you to return HTML fragments via AJAX.
By the way I did use intercooler.js (prev. iteration of htmx) intensively and while I liked it at first, it really added up to being an HTML/JS soup when other developers started extending.
It also uses a DSL that has no application outside of its specific corner.
It also forces you to return HTML fragments via AJAX.
By the way I did use intercooler.js (prev. iteration of htmx) intensively and while I liked it at first, it really added up to being an HTML/JS soup when other developers started extending.
> humongous
14kb
> It also forces you to return HTML fragments via AJAX.
not true, you can return anything. support client-side templating for JSON etc
14kb
> It also forces you to return HTML fragments via AJAX.
not true, you can return anything. support client-side templating for JSON etc
I doubt it – I haven't seen any indication of HTMX being a silver bullet.
Here's your list of examples: https://htmx.org/examples/
Here's validation: https://htmx.org/docs/#validation-example
It looks kinda like ruby.
Here's your list of examples: https://htmx.org/examples/
Here's validation: https://htmx.org/docs/#validation-example
It looks kinda like ruby.
I'd argue that neither is any particular JS framework a silver bullet. If HTMX works for their use cases without needing to write any JS then more power to them!
It is explicitly NOT a silver bullet
https://htmx.org/essays/when-to-use-hypermedia/#hypermedia-n...
https://htmx.org/essays/when-to-use-hypermedia/#hypermedia-n...
I'd like to point out that if you require offline functionality in one project that it likely isn't a good fit for your other project that doesn't require offline functionality. We all have finite time and it's great to learn something once and be able to use it multiple times.
Offline functionality naturally requires client-side code to handle storage, caching, synchronization etc, so client oriented frameworks are preferable in those scenarios. However, this comes at the cost of additional complexity, and I argue that this complexity may be unnecessary and htmx may help you achieve your goals easier
You said it yourself:
> We all have finite time and it's great to learn something once and be able to use it multiple times.
We all have finite time and it's great to use tools that help us work efficiently, following the strengths of those tools, instead of having to maintain unnecessarily complex solutions
You said it yourself:
> We all have finite time and it's great to learn something once and be able to use it multiple times.
We all have finite time and it's great to use tools that help us work efficiently, following the strengths of those tools, instead of having to maintain unnecessarily complex solutions
Is any of this available or would you be willing to share or discuss? I’ve done some HTMX/_hyperscript for prototypes and hobby projects and loved it; contributed a few of the cookbook examples. Overall it is a pleasant ecosystem. I’m curious how this worked out in your use-case because I’m considering it myself. What are the hurdles? Any lessons learned? Recommendations?
For a certain kind of application HTMX is a convenient way to work. It lets you write a webapp the way you did in 1999 except you can update pages partially. Here is a screenshot of an my HTMX-powered RSS reader
https://mastodon.social/@UP8/110432673973724419
This is a research project, but it's a research project by an applications programmer so it has to be solid. Yet I have to be able to change anything when I want to do it and if I used the "standard model" I'd have to change both the back end and the front end when adding a new task but this way I can add a new form once and add it to the rotation, pop it up in a modal, split it out on another page, etc. If this was a big production system with lots of people tagging things I could roll out new tasks by rolling out new forms and not force reloading of a front end.
I use it together with other client-side Javascript, for instance with D3.js for highly customized charts and visualizations.
A major time saver is that it skips the Javascript build. When I make I change I reboot a Python server and it comes up in 1.6s.
https://mastodon.social/@UP8/110432673973724419
This is a research project, but it's a research project by an applications programmer so it has to be solid. Yet I have to be able to change anything when I want to do it and if I used the "standard model" I'd have to change both the back end and the front end when adding a new task but this way I can add a new form once and add it to the rotation, pop it up in a modal, split it out on another page, etc. If this was a big production system with lots of people tagging things I could roll out new tasks by rolling out new forms and not force reloading of a front end.
I use it together with other client-side Javascript, for instance with D3.js for highly customized charts and visualizations.
A major time saver is that it skips the Javascript build. When I make I change I reboot a Python server and it comes up in 1.6s.
Hey! I'm also building an HTMX-powered RSS reader, although it's more a side project than a research project. Good luck, it's been lots of fun for me so far!
I've also found the productivity of a "strong" decoupling from frontend and backend to be super satisfying.
I've also found the productivity of a "strong" decoupling from frontend and backend to be super satisfying.
One architectural advantage is this.
Suppose you want to add a ‘plug-in’ such as a new social media share button: often this is going to involve front and back end changes. In my RSS reader this could be a python package with declared entry points so the application could read it, enabling a few more http endpoints and also adding templates to extension points.
In a ‘standard model’ application you need to have an npm package and a Python package and corresponding extension mechanisms on both sides. You can probably make a system that wraps an npm package inside a Python package or maybe the other way around but it will be a struggle.
(The architecture of my current system was inspired by a system I worked in that not only used Scala, Typescript and Python but also Docker such that builds took 20 minutes! They could afford to do that on a venture capitalist’s dime but I can’t.)
Suppose you want to add a ‘plug-in’ such as a new social media share button: often this is going to involve front and back end changes. In my RSS reader this could be a python package with declared entry points so the application could read it, enabling a few more http endpoints and also adding templates to extension points.
In a ‘standard model’ application you need to have an npm package and a Python package and corresponding extension mechanisms on both sides. You can probably make a system that wraps an npm package inside a Python package or maybe the other way around but it will be a struggle.
(The architecture of my current system was inspired by a system I worked in that not only used Scala, Typescript and Python but also Docker such that builds took 20 minutes! They could afford to do that on a venture capitalist’s dime but I can’t.)
You don't have to build JavaScript; it runs natively in the browser. In fact, the only time when you would have to consider a dedicated build step is if you were using something like TypeScript, or if you wish to use external modules.
In the case of external modules, check out ES6's import syntax. You can import from a URL just like it's an NPM module. I believe a few CDNs are designed to facilitate this use-case too.
That's how I use D3.js. But for the React programs I work on at work we are already committed to a build process, there are bits of Typescript, SCSS, and for production at least tree-shaking and minimization seem a most for something with that many moving parts.
SCSS? Never used it myself -- normally CSS in JS. I definitely understand that it's hard to move away from big build processes though.
I've used htmx to write some relatively simple internal tools, and it's been really useful for that. I know a little javascript, but my web skills are really outdated - I acquired them back when you rendered HTML on the server and maybe added a little interactivity with jquery. With that background, using htmx to swap out elements (rendered server-side with Jinja templates in flask) has been a lot more productive for me than trying to overcome my unfamiliarity with modern JS. The modular structure of Jinja templates actually works really well the htmx paradigm IMO.
This is exactly what I use it for. It keeps me working mostly in python, flask, and jinja, which I know a lot better than js. For just doing some background requests and element swapping, it’s absolutely more efficient for me.
I view it more as server-side first modern app development. If you have a Django app for example htmx is a fast and easy way to make it feel fluid and dynamic like a modern SPA, but still using all your server generated Django logic, templating, etc.
I seriously doubt many people decide they prefer coding up logic in attributes. It's just what HTML gives you as an extension point.
I seriously doubt many people decide they prefer coding up logic in attributes. It's just what HTML gives you as an extension point.
htmx removes abstractions from your web project, by extending the existing abstraction of hypermedia to the point that it can implement many common UI patterns without any other concepts:
https://htmx.org/examples
i have a free book available on the hypermedia approach and how it contrasts with the SPA/thick client approach (both its strengths and weaknesses) here:
https://hypermedia.systems
https://htmx.org/examples
i have a free book available on the hypermedia approach and how it contrasts with the SPA/thick client approach (both its strengths and weaknesses) here:
https://hypermedia.systems
I think you could expand your definition of small projects somewhat.
I used to work at a marketing agency many years ago, there's a huge number of professional, revenue generating websites out there that just host a form. And that form probably just needs to send an email.
Using a form, then a network request to some service, then showing some HTML will solve 100% of the problem for the local hair salon taking reservations, some mom and pop store's contact form, or a local newspaper's letter to the editor form.
HTMX supports that flow with a couple of HTML attributes. Barely anymore "code" than authoring and styling the actual form.
To be fair, a callback and fetch() call aren't much harder but provides just enough complexity to make shooting yourself in the foot easy when you bill hourly on a $200 budget.
I used to work at a marketing agency many years ago, there's a huge number of professional, revenue generating websites out there that just host a form. And that form probably just needs to send an email.
Using a form, then a network request to some service, then showing some HTML will solve 100% of the problem for the local hair salon taking reservations, some mom and pop store's contact form, or a local newspaper's letter to the editor form.
HTMX supports that flow with a couple of HTML attributes. Barely anymore "code" than authoring and styling the actual form.
To be fair, a callback and fetch() call aren't much harder but provides just enough complexity to make shooting yourself in the foot easy when you bill hourly on a $200 budget.
> there's a huge number of professional, revenue generating websites out there that just host a form. And that form probably just needs to send an email.
You don’t need JavaScript or htmx for this. It’s been in the html standard since 1.0. Forms work from plain vanilla html.
> Using a form, then a network request to some service, then showing some HTML will solve 100% of the problem for the local hair salon taking reservations, some mom and pop store's contact form, or a local newspaper's letter to the editor form.
All of these things can be done without htmx or JavaScript. It’s just forms.
(You “need” htmx or JavaScript if you need to dispatch a request without actually submitting the form and triggering a new page load, for example to autocomplete an email or get search suggestions. None of your examples need that.)
You don’t need JavaScript or htmx for this. It’s been in the html standard since 1.0. Forms work from plain vanilla html.
> Using a form, then a network request to some service, then showing some HTML will solve 100% of the problem for the local hair salon taking reservations, some mom and pop store's contact form, or a local newspaper's letter to the editor form.
All of these things can be done without htmx or JavaScript. It’s just forms.
(You “need” htmx or JavaScript if you need to dispatch a request without actually submitting the form and triggering a new page load, for example to autocomplete an email or get search suggestions. None of your examples need that.)
This response is an excellent example of how, when stating a case or making an argument on HN, you should provide as little concrete information as possible and avoid a specific example if possible.
The point they were making was that for many small single-purpose sites the interactivity needs are low but for various technical or social reasons may be higher than exposed with pure html/css, and htmx meets those needs adequately without adding much additional complexity.
But they used forms as an example, and now you're deep in the nitpicky weeds about the semantics and capabilities of html forms, having missed the point and left it in a ditch miles ago.
The point they were making was that for many small single-purpose sites the interactivity needs are low but for various technical or social reasons may be higher than exposed with pure html/css, and htmx meets those needs adequately without adding much additional complexity.
But they used forms as an example, and now you're deep in the nitpicky weeds about the semantics and capabilities of html forms, having missed the point and left it in a ditch miles ago.
Not really, I was directly refuting their bigger point, which was that htmx is not in an uncanny valley between basic HTML and real Javascript because there are all kinds of simple use cases where htmx is ideal. They then listed off use cases that in fact do not require htmx :-)
If you're going to make a point like that via examples, they should be (in aggregate) useful examples that make your point!
Even setting aside that examples made up basically that poster's entire point, the reason people provide examples even for more developed argumernts is because concrete evidence is important to persuasiveness (not because they are being charitable). When someone tries multiple examples and none prove their point, it's perfectly valid to point that out.
If you're going to make a point like that via examples, they should be (in aggregate) useful examples that make your point!
Even setting aside that examples made up basically that poster's entire point, the reason people provide examples even for more developed argumernts is because concrete evidence is important to persuasiveness (not because they are being charitable). When someone tries multiple examples and none prove their point, it's perfectly valid to point that out.
It's not that I avoid JavaScript, it's that I want my work to be accessible to someone without JS as a requirement, for whatever reason they may be in that state and configuration, whether by choice or not.
I write plenty of JS (12% of my biggest project, according to GitHub), but it's added onto HTML in such a way that the HTML still works for:
* a security-minded person who has it turned off in their browser,
* a user of a browser without JS support, such as Links, Lynx, w3m, Dillo,
* someone with an older device using NoScript for performance reasons,
* someone with a slow network connection who can't load the included library,
* a server operator who chooses to disable JS rendering/injection and serve plan HTML, such as the website for a Bitcoin conference,
* another scenario I haven't even thought of or imagined yet.
My conscience as a developer and enabler of information access just does not allow me to write off all these people as undeserving of accessing my websites. You may feel differently, and I think that is OK, too...
I write plenty of JS (12% of my biggest project, according to GitHub), but it's added onto HTML in such a way that the HTML still works for:
* a security-minded person who has it turned off in their browser,
* a user of a browser without JS support, such as Links, Lynx, w3m, Dillo,
* someone with an older device using NoScript for performance reasons,
* someone with a slow network connection who can't load the included library,
* a server operator who chooses to disable JS rendering/injection and serve plan HTML, such as the website for a Bitcoin conference,
* another scenario I haven't even thought of or imagined yet.
My conscience as a developer and enabler of information access just does not allow me to write off all these people as undeserving of accessing my websites. You may feel differently, and I think that is OK, too...
Every site I build works with JavaScript disabled. I use Next.js with server side rendering so that the initial page load is an accessible HTML document that is progressively enhanced for those with JS enabled during hydration by adding interactivity and smooth client side page transitions without full page reloads.
None of this is possible with HTMX if the user has JavaScript disabled. The first step to using HTMX is to import a JavaScript file from a CDN, and none of the features for partial page replacement will work without it. Whereas with Next.js, with JavaScript disabled, a Link will revert to a full page load where the next page is rendered on the server. It will be progressively enhanced to what appears to be a partial page load by using the same JavaScript that would render the full page on the server to instead render it on the client starting from the current state of the DOM.
None of this is possible with HTMX if the user has JavaScript disabled. The first step to using HTMX is to import a JavaScript file from a CDN, and none of the features for partial page replacement will work without it. Whereas with Next.js, with JavaScript disabled, a Link will revert to a full page load where the next page is rendered on the server. It will be progressively enhanced to what appears to be a partial page load by using the same JavaScript that would render the full page on the server to instead render it on the client starting from the current state of the DOM.
> None of this is possible with HTMX if the user has JavaScript disabled. The first step to using HTMX is to import a JavaScript file from a CDN, and none of the features for partial page replacement will work without it.
Umm, progressive enhancement is a general concept that can be applied to any stack, not just Next.js. With htmx we can just use good old anchor and form tags to fall back to full-page loads if JavaScript is disabled. In fact it makes it more obvious because usually those are the tags we're using even with htmx and JavaScript enabled.
Umm, progressive enhancement is a general concept that can be applied to any stack, not just Next.js. With htmx we can just use good old anchor and form tags to fall back to full-page loads if JavaScript is disabled. In fact it makes it more obvious because usually those are the tags we're using even with htmx and JavaScript enabled.
How do you do that if your backend is setup to respond to requests with partial content? You now need to make sure your backend can render both the full page and also individual components of it. That's not functionality that's provided by HTMX itself.
It's fairly easy. Htmx sends an `HX-Request: true` header with all requests. You can check for the presence of this header and have an if/else in your handler to render a partial or a full page. Or if you want to enable caching you can configure the `Accept` header with a customized content type like `text/html;hx=1`. That way you can set a response header `Vary: Accept` to ensure that caching is correct.
I get what you're saying but I the context of the discussion, Htmx requires JavaScript, doesn't it?
The community is convinced that their form of HTML attribute salad is hypermedia and others, that look better IMO, are not. That explains some of the excitement over it.
They have a tiny bit of a point, in that the forms are able to work without client-side JavaScript* thanks to progressive enhancement, and only Svelte and maybe Remix and a handful of others do that. Svelte does a better job of explaining it and making it customizable IMHO though. https://learn.svelte.dev/tutorial/progressive-enhancement
Though Svelte has this, I think perhaps most Svelte devs prefer JSON to form data, because it's directly nestable. That in general is good for full-stack development. You don't see very much TOML in the framework written by the author of TOML, but you do see a little. :) https://redwoodjs.com/ form-data is very TOML like in its data model.
* Except nowadays most of them depend on it to be usable.
They have a tiny bit of a point, in that the forms are able to work without client-side JavaScript* thanks to progressive enhancement, and only Svelte and maybe Remix and a handful of others do that. Svelte does a better job of explaining it and making it customizable IMHO though. https://learn.svelte.dev/tutorial/progressive-enhancement
Though Svelte has this, I think perhaps most Svelte devs prefer JSON to form data, because it's directly nestable. That in general is good for full-stack development. You don't see very much TOML in the framework written by the author of TOML, but you do see a little. :) https://redwoodjs.com/ form-data is very TOML like in its data model.
* Except nowadays most of them depend on it to be usable.
> thanks to progressive enhancement, and only Svelte and maybe Remix and a handful of others do that.
Notably, since a few weeks ago, Next.js (by far the biggest of the pack) has support for progressive enhancement with Form Actions.
https://nextjs.org/docs/app/building-your-application/data-f...
Notably, since a few weeks ago, Next.js (by far the biggest of the pack) has support for progressive enhancement with Form Actions.
https://nextjs.org/docs/app/building-your-application/data-f...
I hadn't realized that, but knew that's where it's headed, because I remember when they were accused of ripping features from Remix. https://news.ycombinator.com/item?id=31485733 Never a dull moment in the JavaScript community. ;) I'm helping with a Next 13 project so I'll see it firsthand soon though.
I think there is something to HATEOAS. It gets around the state sync issue of a distributed system in a clever way. As someone who has mostly built React based SPAs it’s like the network is just part of the unidirectional flow of a reactive app. It doesn’t work for all cases but I think it might work for 80% of them. It also feels right to be so close to just html in the browser.
htmx isn't about avoiding JS, it's about removing arbitrary limitations from HTML that have elsewhere been circumvented with JS. Users write less JS as a side effect of having an actually useful, modern "HTML", and with any luck the core features of htmx will eventually make it into standard HTML
That makes no sense, HTML is by design not supposed to be dynamic, that's the point of JS. There's a nice, clean, separation of concerns with HTML, CSS, and JS.
As an aside, htmx uses JS under the covers to make HTML dynamic.
As an aside, htmx uses JS under the covers to make HTML dynamic.
HTML is designed to be dynamic via hypermedia controls, that is, elements embedded in documents that communicate some sort of hypermedia interaction to a user agent. The two common hypermedia controls are anchors and forms.
htmx simply generalizes this concept, allowing any element to be a hypermedia control, issuing any sort of HTTP request, in response to any sort of event and replacing any element in the DOM.
I have written an essay on an alternative software design principle to the traditional separation of concerns that we see in web development here:
https://htmx.org/essays/locality-of-behaviour/
htmx simply generalizes this concept, allowing any element to be a hypermedia control, issuing any sort of HTTP request, in response to any sort of event and replacing any element in the DOM.
I have written an essay on an alternative software design principle to the traditional separation of concerns that we see in web development here:
https://htmx.org/essays/locality-of-behaviour/
> HTML is by design not supposed to be dynamic, that's the point of JS.
You are putting far too much faith in the design of web standards.
Anyways, here's a counterexample to your claim:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
You are putting far too much faith in the design of web standards.
Anyways, here's a counterexample to your claim:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
<audio> and <video> are older examples.
And of course <button type="submit">, <button type="reset">, annnnnd cough <a>.
There was <blink> and for some reason still <marquee> if you wanna consider animations dynamic.
And of course <button type="submit">, <button type="reset">, annnnnd cough <a>.
There was <blink> and for some reason still <marquee> if you wanna consider animations dynamic.
Thanks, yeah, there are lots of examples of standard HTML features that wouldn't make any sense in a true static document DSL like LaTeX, or a paper document.
HTML is interactive and dynamic.
HTML is interactive and dynamic.
I was just augmenting your answer as I liked it! It was also sort of a response to my sibling responder as they didn't seem to get what you were saying.
EDIT: Oh wait, maybe they did now that I re-read it... maybe? I think it's time for bed.
EDIT: Oh wait, maybe they did now that I re-read it... maybe? I think it's time for bed.
A dialogue doesn't need javascript. You can render in html and can use server side logic to decide to display it
Where in the spec for html did it specify that it's isn't meant to be dynamic?
HTMX effectively used js for a polyfill of potential html standards, very similar to using babel or postcss to prototype a proposed spec.
HTMX effectively used js for a polyfill of potential html standards, very similar to using babel or postcss to prototype a proposed spec.
A lot of htmx is just a smoother version of what people used to do with forms and iframes.
I don’t do any webdev stuff, so I don’t k or about setting up a stack and all that stuff. But, it would be nice from a user point of view if this became popular enough that I could go back to browsing with JavaScript turned off.
Just look at Wordpress for the demand for shoehorning things into something because it seems easier on the surface and accessible without learning harder programming stuff, or at least investing in the initial overhead.
There will always be demand. It's likely very practical for certain usecases but that won't stop people from abusing it in full SaaS web apps before some CTO joins and has to abandon it all when requirements evolve. Although I've seen some highly capable apps built on top of jquery plugins like Select2, which were extended well beyond their initial intent. Things that work is all that matters at the end of the day when it comes to making $$$.
There will always be demand. It's likely very practical for certain usecases but that won't stop people from abusing it in full SaaS web apps before some CTO joins and has to abandon it all when requirements evolve. Although I've seen some highly capable apps built on top of jquery plugins like Select2, which were extended well beyond their initial intent. Things that work is all that matters at the end of the day when it comes to making $$$.
Wordpress is a platform or framework, HTMX is neither. If you don't like what HTMX offers for your next feature... just don't use HTMX attributes on those elements. So comparing it to WordPress, or React, etc. is not accurate.
If you think this analogy is about frameworks vs libraries you missed the point.
It's the exact sort of technology option that is simple and accessible on the surface which is why someone inexperienced would adopt it in the early days. Then requirements naturally evolve and it gets shoehorned into ever more complex situations it was never intended for.
I'm speaking from experience and anyone who has worked in web app dev / JS for any length of time can see this coming from a mile away. The mountain of jQuery libraries alone should be enough but in the history of the internet WordPress is the classic cliché example of a simple technology that frequently gets abused beyond its original design. If your project is small and niche then obviously this critique isn't relevant. Nor is it dismissing the utility of htmx.
It's the exact sort of technology option that is simple and accessible on the surface which is why someone inexperienced would adopt it in the early days. Then requirements naturally evolve and it gets shoehorned into ever more complex situations it was never intended for.
I'm speaking from experience and anyone who has worked in web app dev / JS for any length of time can see this coming from a mile away. The mountain of jQuery libraries alone should be enough but in the history of the internet WordPress is the classic cliché example of a simple technology that frequently gets abused beyond its original design. If your project is small and niche then obviously this critique isn't relevant. Nor is it dismissing the utility of htmx.
Then you need to explain it better.
There is nothing wrong with offering simple solutions.
The problem with WordPress is that you can't just stop using it and painlessly swap to a more powerful framework/platform. You can really dig yourself into a hole.
This doesn't apply to HTMX.
There is nothing wrong with offering simple solutions.
The problem with WordPress is that you can't just stop using it and painlessly swap to a more powerful framework/platform. You can really dig yourself into a hole.
This doesn't apply to HTMX.
You must not work on frontend because I've seen plenty of "simple" libraries exactly like htmx adopted and turned into monsters that power entire SaaS products the same way WordPress is turned into pseudo custom Web apps by non-programmers countess times.
Being the guy who has to decipher it is not a fun job and gives you perspective on early technology choices.
I've read enough discourse on HN re htmx to recognize people seeing it as an adequate solution for serious business usecases because they don't grasp the natural evolution in demands for complexity and interactivity in browser UIs.
People love downplaying why more serious JS frameworks are adopted in the first place then find themselves in situations that need it but try to pretend they can just force it on primitive "simple" libraries, as we saw with jquery ad nauseam. Or more likely they leave their mess for the next developer to do the job properly from scratch.
Being the guy who has to decipher it is not a fun job and gives you perspective on early technology choices.
I've read enough discourse on HN re htmx to recognize people seeing it as an adequate solution for serious business usecases because they don't grasp the natural evolution in demands for complexity and interactivity in browser UIs.
People love downplaying why more serious JS frameworks are adopted in the first place then find themselves in situations that need it but try to pretend they can just force it on primitive "simple" libraries, as we saw with jquery ad nauseam. Or more likely they leave their mess for the next developer to do the job properly from scratch.
Every framework or library can be abused, but as a fellow software janitor I feel much better if the mess consists of just HTML templates and endpoints, rather than insane JS/TS/TSX build chains with invalid NPM dependency graphs (or a WordPress monstrosity).
One of the benefits of HTMX is that it doesn't add many abstractions, it primarily builds off existing ones. A HTMX dev must understand the basics of HTTP and the DOM, and not much else, to be functional.
One of the benefits of HTMX is that it doesn't add many abstractions, it primarily builds off existing ones. A HTMX dev must understand the basics of HTTP and the DOM, and not much else, to be functional.
All your endpoints are delivering partial HTML instead of JSON and you can switch to, say, React for your next feature?
I mean, you technically can, but for that amount of work and/or friction you can pretty much go between any 2 frameworks.
I mean, you technically can, but for that amount of work and/or friction you can pretty much go between any 2 frameworks.
There is nothing preventing you from having new endpoints serve frontend JSON, or from refactoring select endpoints away from HTMX.
If you are refactoring everything because a small subset of features didn't fit the HTMX glove, that's an engineering management failure.
If you are refactoring everything because a small subset of features didn't fit the HTMX glove, that's an engineering management failure.
You can say the same for the conversion between any 2 frontend frameworks, or even wordpress (you can just add another php file and do whatever next to your existing stuff), what's the special thing about htmx here?
You accept 5% complexity to completely drop all the rest. “Bundlers”? Please.
I know that from a webdev bubble it seems the world is made of JS - I should rather say “and its various frameworks” - but that is not the case. There are lots of places where keeping the surface area small is very much appreciated and the concept of using “bundlers” for your moderately complex crud interface will get you laughed out the room. I guess that is where htmx can shine, not in webdev consultancies.
I know that from a webdev bubble it seems the world is made of JS - I should rather say “and its various frameworks” - but that is not the case. There are lots of places where keeping the surface area small is very much appreciated and the concept of using “bundlers” for your moderately complex crud interface will get you laughed out the room. I guess that is where htmx can shine, not in webdev consultancies.
[deleted]
I think one big up with this html-centered approach is you don't have to worry about SSR
i will have you know that i wrote an awful lot of javascript to avoid writing javascript!
> I continue to be impressed at the effort people will put into avoiding writing any JavaScript
I continue to be impressed with the amount of handwaving the already-initiated do to downplay the horrors that are starting JS development in 2023.
I continue to be impressed with the amount of handwaving the already-initiated do to downplay the horrors that are starting JS development in 2023.
It’s very clear at this point that we need real browser APIs instead of implementations (real interfaces that can be implemented and run in any language using web assembly).
Many people may disable js when browsing. So there's that.
HTMX requires JavaScript to work. If your goal is to render a usable page on the server and return it to the client, you can do that with plenty of full stack JS frameworks like Next.js, and as a bonus, it uses the same code to render it as it does on the frontend.
Htmx is for backend devs who think frontend must be simple stuff for simple devs. Then when they realize it’s not, they come up with some crazy new framework to prove to themselves that they know better and can still act superior.
I'm not saying I agree with your point, but I will say that the worst engineers I've worked with in my career are backend engineers who look down on frontend engineers/engineering.
It makes sense to me that good web developers would be multifunctual enough to implement a solution based on the complexity of the required design. React is conversely way too complicated for a lot of the stuff that's easy to do in HTMX, so you should be able to do both in my opinion.
I'd still pick Unpoly over it. Seems far more high level, feature rich and easier to use although less popular. And if I wanted a popular approach I'd pick Hotwire which can be used with any backend framework anyways.
https://unpoly.com/
https://hotwired.dev/
https://unpoly.com/
https://hotwired.dev/
I am also interested in why you like Unpoly more. Genuinely curious because I use and like HTMX and don’t really understand what you get with Unpoly that you don’t with HTMX.
I could ask the same question I guess, what do you get from HTMX that I can't get from Unpoly?.
I think you can achieve the same thing with both, but Unpoly is higher level, that means I have to write less attributes/code to achieve the same stuff I guess.
"Compilers" are also a nice way to attach custom code. All the helpers for form validations, the extremely easy way it provides to do modals, and layers in general. The navigation feedback (a'la turbolinks) when navigating across pages, the caching, the error handling. The up-keep for keeping a video player or anything else across pages transitions, and absolutely everything of this can be accessed from a JavaScript API in case you need to perform any of this from your own code and most of these APIs also trigger events.
Probably you can do all of this with HTMX too, but it is more work.
I think you can achieve the same thing with both, but Unpoly is higher level, that means I have to write less attributes/code to achieve the same stuff I guess.
"Compilers" are also a nice way to attach custom code. All the helpers for form validations, the extremely easy way it provides to do modals, and layers in general. The navigation feedback (a'la turbolinks) when navigating across pages, the caching, the error handling. The up-keep for keeping a video player or anything else across pages transitions, and absolutely everything of this can be accessed from a JavaScript API in case you need to perform any of this from your own code and most of these APIs also trigger events.
Probably you can do all of this with HTMX too, but it is more work.
from the tutorial:
"You can update multiple fragments from a single request by separating selectors with a comma."
"The server still renders full HTML pages, but we only use the targeted fragments and discard the rest"
Wow... Of course full pages should have a lean markup, otherwise a lot of data transfered could be useless, but that's a pretty neat feature
"You can update multiple fragments from a single request by separating selectors with a comma."
"The server still renders full HTML pages, but we only use the targeted fragments and discard the rest"
Wow... Of course full pages should have a lean markup, otherwise a lot of data transfered could be useless, but that's a pretty neat feature
You can always detect server side if it’s an Unpoly request, and which fragments it is asking for as that information goes in the request headers.
Or point the request to another view that just returns those fragments.
But I don’t think many apps need this level of optimizations.
Or point the request to another view that just returns those fragments.
But I don’t think many apps need this level of optimizations.
I am now converting an app from htmx to unpoly. Indeed, much less attributes to write and now my app has proper browser history and full page rendering linked to this history, all with minimal effort. This is brilliant, how come I never heard of unpoly ? Thanks for pointing to it.
It has a marketing problem for sure, given how everyone loves HTMX and nobody even heard of Unpoly.
Not that I'm a fan of doing marketing of tech, but... that's the explanation I find for it.
Not that I'm a fan of doing marketing of tech, but... that's the explanation I find for it.
Can you expand a bit on why you prefer unpoly over htmx ? I like htmx but I'm genuinely interested in alternatives around the same concept.
Just answered this on a sibling comment.
I really want to use htmx on the next project but I am not sure how to make it handle poor network connections yet. The app I'm building will be used in areas with poor mobile connections - I want to submit a form, add it to a list and say it's pending saving, while the user can add more. Have to use hyperscript probably?
Can trivially do it in vanillajs so I'm sure it's possible?
Can trivially do it in vanillajs so I'm sure it's possible?
Hmmmm... can you define a "poor connection"? The web used to work the "htmx"/hypermedia through all the dial-up years where things were REALLY slow. I see no reason it would not work now.
"Hmmm I know better than you". Peak HN lol. This is for middle of the desert time tracking.
Woudn't a native app be better for that anyway? Why depend on a browser for this?
How many people will give a runaround before answering the question?
It's meant to run on a laptop. In an existing site that people will already be using. It's free software. If you wanna build a native client, too, be my guest. I might at some point.
It's meant to run on a laptop. In an existing site that people will already be using. It's free software. If you wanna build a native client, too, be my guest. I might at some point.
I thought the answer would be implicit in my question, but it's not very difficult to find an explicit answer, it's the second essay on the essays page: https://htmx.org/essays/when-to-use-hypermedia/#if-you-requi...
Having said that, for a time-tracking application, personally I wouldn't be OK with the risk of a browser screw-up (e.g. site data deleted, malware hoses the browser) losing tracking data. But you do you.
Having said that, for a time-tracking application, personally I wouldn't be OK with the risk of a browser screw-up (e.g. site data deleted, malware hoses the browser) losing tracking data. But you do you.
I mean, they use Google sheets or another web app already, so....
Yeah, I mean Google Sheets is created by Google, who can afford to throw craptons of money and warm bodies at the specific problem of making sure their browser is an inescapable part of the life of every modern computer user, so they can sell ads.
You and I don't have the same constraints and resources as Google.
You and I don't have the same constraints and resources as Google.
literally no connection at times. A queued request cannot be lost.
I'll probably just build a native app with godot or something...
Browser dev tools have a throttle mode, might help.
Ah yes…the daily htmx post
Yep, I’m delighted when I see it and then I give it my automatic upvote.
i really have no idea why this is happening and am kinda nervous...
Seriously, why does this keep popping up? I get it, it's cool. But I feel like in a month we're going to see "How I gamed the HN front page to put my website on the top every day for a month".
“Aren’t you sick of new web frameworks? Here’s a new web framework!! It’s different and special because we said so.”
Does this cause problems for web crawlers indexing sites, since these are not typical js event listeners etc? Even though they must use them in the background, there is an abstraction the crawler must be able to navigate. I had an entire site de-indexed for getting too fancy once, so I worry about this type of thing perpetually now.
I'd think HTMX would work with even the most basic of crawlers, since it doesn't require JS at all to be usable. But I don't know how well a JS aware crawler would do with it.
I guess you could block htmx.js in robots.txt to force them to the non-JS experience?
I guess you could block htmx.js in robots.txt to force them to the non-JS experience?
It won't matter as long as you are using regular `a` tags for links. You anyway don't want robots to submit forms and perform any actions that are meant for users.
For those with flexibility or a new project, also consider Phoenix LiveView. It’s been a joy to work with so far.
Or possibly Hotwire! (Turbo frames really) [0] Also found it to be wonderful to work with.
[0] https://hotwired.dev
[0] https://hotwired.dev
There are a variety of these types of frameworks for most peoples' favourite web-programming language (LiveView, Hotwire, LiveWire, Blazor...).
HTMX + Java is almost as good as react!
I think people mistake what htmx is - they think it is a way to not write react/js in a node environment.
Where HTMX really shines is being able to bring the experience of writing React-like code without a nodejs environment in Java for e.g. (or Golang, Rust, etc)
I think people mistake what htmx is - they think it is a way to not write react/js in a node environment.
Where HTMX really shines is being able to bring the experience of writing React-like code without a nodejs environment in Java for e.g. (or Golang, Rust, etc)
> Where HTMX really shines is being able to bring the experience of writing React-like code without a nodejs environment.
FWIW, if that's all you're after, and you've mastered the Rust borrow checker, Yew (a React-like experience), or Leptos (a SolidJS-like experience) might be interesting to look at.
FWIW, if that's all you're after, and you've mastered the Rust borrow checker, Yew (a React-like experience), or Leptos (a SolidJS-like experience) might be interesting to look at.
not its not the same thing. I work in Java (not rust), but the analogy will hold.
Yew is writing Rust to create html. Same as Java Thymeleaf. Here's the problem - Java developers are bad at UI. And good UI designers/developers think in HTML. I am not pro or anti this situation...im just talking about the reality.
The tooling is also around html. Figma-to-HTML is the most effective way to have your design cycle work.
This is where HTMX shines. HTMX is just HTML++. It is is not Rust or Java. Which means your design cycles will continue to work.
Yew is writing Rust to create html. Same as Java Thymeleaf. Here's the problem - Java developers are bad at UI. And good UI designers/developers think in HTML. I am not pro or anti this situation...im just talking about the reality.
The tooling is also around html. Figma-to-HTML is the most effective way to have your design cycle work.
This is where HTMX shines. HTMX is just HTML++. It is is not Rust or Java. Which means your design cycles will continue to work.
I never meant to claim "it's the same thing".
I was just suggesting, if, by "react-like" code, you meant "a UI library that uses a vDOM to transform functionally written code into DOM nodes", Yew fits the bill.
Also, typically, one writes JSX when writing react, not HTML. It's similar with Yew[0].
If you're already aware of Yew, I'm not trying to change your mind. I was just trying to make you aware if you weren't already.
[0] It says so right on the homepage: https://yew.rs/
I was just suggesting, if, by "react-like" code, you meant "a UI library that uses a vDOM to transform functionally written code into DOM nodes", Yew fits the bill.
Also, typically, one writes JSX when writing react, not HTML. It's similar with Yew[0].
If you're already aware of Yew, I'm not trying to change your mind. I was just trying to make you aware if you weren't already.
[0] It says so right on the homepage: https://yew.rs/
How does htmx compare with alpinejs (https://alpinejs.dev/)?
HTMX and Alpine pair well together.
Generally, Alpine would handle pure client-side functionality, like toggling classes, expanding a drop-down multi-select, etc.
HTMX for server interactions, fetching, posting updates, etc.
One can accomplish a lot with little to no JS, with the app primarily driven by the backend. Which is quite a benefit if you know and like PHP/Python/Go/Elixir/C++ better than JS. Or just don’t like working in JS.
Generally, Alpine would handle pure client-side functionality, like toggling classes, expanding a drop-down multi-select, etc.
HTMX for server interactions, fetching, posting updates, etc.
One can accomplish a lot with little to no JS, with the app primarily driven by the backend. Which is quite a benefit if you know and like PHP/Python/Go/Elixir/C++ better than JS. Or just don’t like working in JS.
Alpine is more of a Vue replacement and HTMX is more of a fetch replacement. You can use both, although it’s a little redundant.
On the one hand I see the appeal of staying inside, say, Django the whole time and getting 3x done.
On the other hand I am so pampered by front end component based templating especially with Tailwind.
It would be cool if I could just import my Svelte components from Django.
On the other hand I am so pampered by front end component based templating especially with Tailwind.
It would be cool if I could just import my Svelte components from Django.
Have you looked at something like Slippers[1]? It allows you to have a set of components that you use in Django templates. I'm using Bulma, not Tailwind, for my project and I like how it creates an abstracts over e.g. CSS classes.
[1]: https://mitchel.me/slippers/docs/introduction/
[1]: https://mitchel.me/slippers/docs/introduction/
how many times has this been posted here?
Not enough
I count about ~6 generic submissions to htmx root domain or direct /docs with upvotes. More generally it's higher if you include blog posts or self-HN posts. The original submission had 728 upvotes: https://news.ycombinator.com/item?id=23330881
react.dev and reactjs.org has had 2 root url submissions: (728 upvotes) https://news.ycombinator.com/item?id=35186812 and older https://news.ycombinator.com/item?id=15366446
vuejs.org only had about ~1 meaningful root domain submission: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
I suspect HTMX is more of an idea that people like to talk about on HN more generally, like Clojure and Erlang. Being the underdog matters on social media. Maybe it feels more authentic or relevant to discourse because it's still niche.
react.dev and reactjs.org has had 2 root url submissions: (728 upvotes) https://news.ycombinator.com/item?id=35186812 and older https://news.ycombinator.com/item?id=15366446
vuejs.org only had about ~1 meaningful root domain submission: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
I suspect HTMX is more of an idea that people like to talk about on HN more generally, like Clojure and Erlang. Being the underdog matters on social media. Maybe it feels more authentic or relevant to discourse because it's still niche.
> I suspect HTMX is more of an idea that people like to talk about on HN more generally, like Clojure and Erlang. Being the underdog matters on social media. Maybe it feels more authentic or relevant to discourse because it's still niche.
Pretty glib take.
The more exposure this stuff gets the better. I'd really like to have more job options out there that don't involve maintaining an internal web API so that two applications you own can talk to each other.
Pretty glib take.
The more exposure this stuff gets the better. I'd really like to have more job options out there that don't involve maintaining an internal web API so that two applications you own can talk to each other.
I might have been using HN too long but you start to notice some pet technologies everyone here loves to safely upvote on HN but IRL stays niche for a reason. Especially in the serious business world of software development, not side projects or stuff we like talking about on social media. And I say that as a big fan of both Erlang and Clojure.
It can, though. Lots of enterprise apps are just page after page of forms, as was the one enterprise app I worked on. There's no reason those things need frontend frameworks talking through APIs to separate backends. It's good for jobs, of course.
Can HTMX be used with static site generators, such as Hugo, to create interactive documentation websites?
I think that unpoly(https://unpoly.com/) would be easier for that use case. htmx generally expects succesive http requests to only return the fragment of html that will be swapped into the target, not the entire page. So you generally want something server side that can check the request and either return the full page (either for a first hit or disabled javascript) or return just a fragment (an htmx request).
Unpoly has similar goals to htmx, but by default works with full page responses, swapping only the identified content in the page.
Unpoly has similar goals to htmx, but by default works with full page responses, swapping only the identified content in the page.
You're correct that it's the general expectation, but it is possible to select certain elements from the response using `hx-select` [1], so it is possible, just not particularly efficient...
[1] https://htmx.org/attributes/hx-select/
[1] https://htmx.org/attributes/hx-select/
Unpoly is great. I used it a few years ago for reimplementing the UI of an application built with a traditional MVC framework and I was impressed with the results. Nobody could tell it was not React/vue/etc from the outside and the frontend code was quite simple and minimal.
Technically feasible? Absolutely. You can already create interactive documentation just with client side JS in your Hugo generated site. And HTMX is just a client-side JS system for building that sort of JS-required interactivity in HTML alone without directly touching JavaScript. That said, I don't think the tooling to make this simple to get started with in Hugo is there yet. Though you could certainly build it.
Why does documentation need any JavaScript at all beyond opening the hamburger menu?
No need for javascript for the hamburger menu, it is doable with CSS checkbox, see for example the hamburger menu on https://lanyon.getpoole.com/ .
Or another example, the teddit reddit-frontend has collapseable threads with the summary/details tags, also works without javascript.
Or another example, the teddit reddit-frontend has collapseable threads with the summary/details tags, also works without javascript.
The CSS checkbox method is considered bad for accessibility. They’re adding a popover attribute to use for no JS menus instead.
You don't need JavaScript for a hamburger menu, I am doing it with pure HTML. Hint: the <details> tag.
Hint: that’s bad for accessibility.
Hint: there's nothing inherently inaccessible about the <details> tag, it all depends on how you use it.
Why does it even need a hamburger menu?
Because you need to hide nav on mobile, since accessibility requirements from google and other web crawlers will require it to fill the much of the page, or your site won't be indexed.
This is the first time I've been excited to learn about a new web technology in a while. I'm going to have to play around with this to see how I want to use it. I wonder what other little things like this could be used to simplify webdev?
The crucial flaw with htmx is that it’s an enhancement of html itself; if a fancy and interesting new UI pattern is invented somewhere, the htmx devs or contributors will have to add support for it into htmx itself!
And imagine if htmx became absorbed into the real html standard. It would take much longer for the standards body (and then browser makers) to respond and implement.
So the crucial flaw is that it will always be reacting instead of innovating. And more generally, this is likely why the “thick client” approach is more popular on the web these days. Nobody wanted to wait around for standards bodies and browser makers.
And imagine if htmx became absorbed into the real html standard. It would take much longer for the standards body (and then browser makers) to respond and implement.
So the crucial flaw is that it will always be reacting instead of innovating. And more generally, this is likely why the “thick client” approach is more popular on the web these days. Nobody wanted to wait around for standards bodies and browser makers.
I'm not a fan of adding functionality to hypertext attributes. I want an expected set of attributes to a component, not a new set of attributes that extend existing components. A lot of functionality can get obfuscated.
Strictly speaking you could already do this with x- attributes and plain JS, right?
Long arguments here about whether HTMX or React or something else can qualify as idiomatic HTML.
But the truth is, HTML itself does so very little that it’s barely useful as a starting point for building applications.
Arguing about idiomatic HTML in this context is like arguing about how to write a scientific paper in idiomatic toddler language. One faction thinks you should stick to monosyllabic words. Another believes drawings of colorful balloons are key. Both are held back by the fundamental assumption.
But the truth is, HTML itself does so very little that it’s barely useful as a starting point for building applications.
Arguing about idiomatic HTML in this context is like arguing about how to write a scientific paper in idiomatic toddler language. One faction thinks you should stick to monosyllabic words. Another believes drawings of colorful balloons are key. Both are held back by the fundamental assumption.
The filler text on some of the examples (e.g. https://htmx.org/examples/tabs-hyperscript/) seems to be generated by Hipster Ipsum https://hipsum.co/. Cute.
I kinda like the aesthetic. It feels a bit like what HTML might have looked like if XHR had been baked in.
I kinda like the aesthetic. It feels a bit like what HTML might have looked like if XHR had been baked in.
I personally don't see the utility in this too much, but then I'm old fashioned and go out of my way to use as little JS as possible, doing everything via CSS as much as I can.
Even though JS is ubiquitous and small, well written JS is harmless, I still try to avoid it like the plague. Maybe just to somewhat fight back against all the excessive JS that plagues every site.
Even though JS is ubiquitous and small, well written JS is harmless, I still try to avoid it like the plague. Maybe just to somewhat fight back against all the excessive JS that plagues every site.
I'm old fashioned and go out of my way to use as little JS as possible
The point of HTMX is to avoid writing custom JavaScript.
The point of HTMX is to avoid writing custom JavaScript.
But it does that by including a bunch of JavaScript and obscuring it. So not exactly including as little JS as possible.
A lot of this what htmx does is a one-liner in Jquery.
I know: the unpopular old thing :)
Learning to use any new tool comes at a time cost, and if I learn this and then a newer, more convenient tool emerges that can replace it, I get stuck in the question.
Are people driving the tools?
Or are the tools binding people?
Are people driving the tools?
Or are the tools binding people?
Perhaps too cynical from my dislike of frontend but I sometimes suspect the churn is spicing up monotonous work for some people.
Yes, I also don't like doing front-end development work, not because front-end development work itself is offensive, but doing front-end development work is a very meticulous thing, which requires me to invest a lot of time, which will reduce my energy investment in other work content.
Anything new here?
Some discussion 5 months ago:
https://news.ycombinator.com/item?id=33987578
Some discussion 5 months ago:
https://news.ycombinator.com/item?id=33987578
This vaguely reminds me of Adobe's ColdFusion except in the browser for better or worse.
can htmx be used offline? i.e. am I screwed if I load an htmx page, close a laptop and get on a plane?
If the page has loaded, it's loaded. There's no moving parts once you have rendered HTML from the wire.
stop trying to make htmx happen, it's not going to happen
Seems like a horrible idea that totally breaks separation of concerns, so I’m sure it will be a huge success you’ll see everywhere very soon.
There are multiple ways of separating concerns. Htmx is faithful to the original HTML separation of structure / presentation / behavior. Elm cuts this way too but with a completely different approach. React does components.
Pick your poison because in any case there will be crossing of those concerns.
Personally I've never seen react code that doesn't go sour beyond a toy demo.
Pick your poison because in any case there will be crossing of those concerns.
Personally I've never seen react code that doesn't go sour beyond a toy demo.
More of an Angular fan though I haven't used post 1.x much.
htmx has been a revelation and has really opened my eyes to the nuances of hypermedia development modalities that I was ignorant of. For me, it has become very clear that htmx and hypermedia development is far more simple, productive, beneficial, and FUN for 90% of web dev use cases. I feel huge disappointment how unnecessarily web development evolved into bad client server rpc json protocol for basically everything web.
Kudos to the htxm creator and his vision of what should have been. My experience absolutely corroborates his thinking on these things.