10 ms·

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 attribut

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.

pphysch 3y ago
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
- candiddevmike 3y ago
  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.
  - pphysch 3y ago
    > 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/dialog https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
    - ipaddr 3y ago
      A dialogue doesn't need javascript. You can render in html and can use server side logic to decide to display it
    - sodapopcan 3y ago
      <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.
      - pphysch 3y ago
        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.
        sodapopcan 3y ago
        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.
  - recursivedoubts 3y ago
    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/ https://htmx.org/essays/locality-of-behaviour/
  - flagrant_taco 3y ago
    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.
  - roywiggins 3y ago
    A lot of htmx is just a smoother version of what people used to do with forms and iframes.
benatkin 3y ago
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 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/ https://redwoodjs.com/ form-data is very TOML like in its data model. * Except nowadays most of them depend on it to be usable.
- n2d4 3y ago
  > 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-fetching/server-actions#progressive-enhancement https://nextjs.org/docs/app/building-your-application/data-f...
  - benatkin 3y ago
    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 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.
jgoodhcg 3y ago
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.
qbasic_forever 3y ago
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.
0xEFF 3y ago
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.
- benatkin 3y ago
  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 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.
  - trog 3y ago
    > You could follow something like this: https://learn.svelte.dev/tutorial/welcome-to-svelte 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)
deleted 3y ago
[deleted]
PaulHoule 3y ago
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 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.
- tentacleuno 3y ago
  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.
  - PaulHoule 3y ago
    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.
    - tentacleuno 3y ago
      SCSS? Never used it myself -- normally CSS in JS. I definitely understand that it's hard to move away from big build processes though.
graypegg 3y ago
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.
- eduction 3y 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. 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.)
  - giraffe_lady 3y ago
    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.
rafark 3y ago
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).
listenallyall 3y ago
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.
- benatkin 3y ago
  Here's some code that I don't find especially idiomatic: <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> It has a multiline HTML attribute value and an unfamiliar programming language with the english word me that is sure to be confusing to some who don't speak it as a first language. https://htmx.org/docs/#validation-example https://htmx.org/docs/#validation-example
  - listenallyall 3y ago
    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.
    - benatkin 3y ago
      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/ https://htmx.org/docs/
      - 3y ago
recursivedoubts 3y ago
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 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://hypermedia.systems
genmud 3y ago
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.
- marcus_holmes 3y ago
  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 ;)
  - Andrew_nenakhov 3y ago
    I usually oppose the use of any new "hotness" in a project until that "hotness" is ~10 years old.
  - leidenfrost 3y ago
    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.
dmix 3y ago
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 $$$.
- pphysch 3y ago
  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.
  - dmix 3y ago
    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.
    - pphysch 3y ago
      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.
dimatura 3y ago
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.
- dicriseg 3y ago
  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.
slmjkdbtl 3y ago
I think one big up with this html-centered approach is you don't have to worry about SSR
forgotmypw17 3y ago
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...
- unmole 3y ago
  I get what you're saying but I the context of the discussion, Htmx requires JavaScript, doesn't it?
- chatmasta 3y ago
  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.
  - yawaramin 3y ago
    > 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.
recursivedoubts 3y ago
i will have you know that i wrote an awful lot of javascript to avoid writing javascript!
nbow 3y ago
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.
darig 3y ago
[dead]
robertoandred 3y ago
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.
- seattle_spring 3y ago
  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.
SanderNL 3y ago
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.
chaxor 3y ago
Many people may disable js when browsing. So there's that.
- chatmasta 3y ago
  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.
bee_rider 3y ago
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.
alex_lav 3y ago
> 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.

pphysch 3y ago

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

candiddevmike 3y ago
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.
- pphysch 3y ago
  > 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/dialog https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
  - ipaddr 3y ago
    A dialogue doesn't need javascript. You can render in html and can use server side logic to decide to display it
  - sodapopcan 3y ago
    <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.
    - pphysch 3y ago
      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.
      - sodapopcan 3y ago
        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.
- recursivedoubts 3y ago
  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/ https://htmx.org/essays/locality-of-behaviour/
- flagrant_taco 3y ago
  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.
- roywiggins 3y ago
  A lot of htmx is just a smoother version of what people used to do with forms and iframes.

benatkin 3y ago

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 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/ https://redwoodjs.com/ form-data is very TOML like in its data model. * Except nowadays most of them depend on it to be usable.

n2d4 3y ago
> 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-fetching/server-actions#progressive-enhancement https://nextjs.org/docs/app/building-your-application/data-f...
- benatkin 3y ago
  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 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.

jgoodhcg 3y ago

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.

qbasic_forever 3y ago

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.

0xEFF 3y ago

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.

benatkin 3y ago
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 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.
- trog 3y ago
  > You could follow something like this: https://learn.svelte.dev/tutorial/welcome-to-svelte 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)

deleted 3y ago

[deleted]

PaulHoule 3y ago

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 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.

tentacleuno 3y ago
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.
- PaulHoule 3y ago
  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.
  - tentacleuno 3y ago
    SCSS? Never used it myself -- normally CSS in JS. I definitely understand that it's hard to move away from big build processes though.

graypegg 3y ago

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.

eduction 3y 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. 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.)
- giraffe_lady 3y ago
  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.

rafark 3y ago

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).

listenallyall 3y ago

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.

benatkin 3y ago
Here's some code that I don't find especially idiomatic: <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> It has a multiline HTML attribute value and an unfamiliar programming language with the english word me that is sure to be confusing to some who don't speak it as a first language. https://htmx.org/docs/#validation-example https://htmx.org/docs/#validation-example
- listenallyall 3y ago
  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.
  - benatkin 3y ago
    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/ https://htmx.org/docs/
    - 3y ago

recursivedoubts 3y ago

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 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://hypermedia.systems

genmud 3y ago

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.

marcus_holmes 3y ago
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 ;)
- Andrew_nenakhov 3y ago
  I usually oppose the use of any new "hotness" in a project until that "hotness" is ~10 years old.
- leidenfrost 3y ago
  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.

dmix 3y ago

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 $$$.

pphysch 3y ago
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.
- dmix 3y ago
  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.
  - pphysch 3y ago
    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.

dimatura 3y ago

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.

dicriseg 3y ago
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.

slmjkdbtl 3y ago

I think one big up with this html-centered approach is you don't have to worry about SSR

forgotmypw17 3y ago

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...

unmole 3y ago
I get what you're saying but I the context of the discussion, Htmx requires JavaScript, doesn't it?
chatmasta 3y ago
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.
- yawaramin 3y ago
  > 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.

recursivedoubts 3y ago

i will have you know that i wrote an awful lot of javascript to avoid writing javascript!

nbow 3y ago

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.

darig 3y ago

[dead]

robertoandred 3y ago

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.

seattle_spring 3y ago
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.

SanderNL 3y ago

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.

chaxor 3y ago

Many people may disable js when browsing. So there's that.

chatmasta 3y ago
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.

bee_rider 3y ago

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.

alex_lav 3y ago

> 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.