18 ms·

Is htmx Just Another JavaScript Framework?

284 points by cubefox 3y ago

cranberryturkey 3y ago
no
- cubefox 3y ago
  The article says it is a JavaScript framework.
  - beanjuiceII 3y ago
    thats because it is
- dartos 3y ago
  Kekw
cranberryturkey 3y ago
https://primatejs.com https://primatejs.com has supported htmx from day one.
jakelazaroff 3y ago
I like this fuzzy definition better than "your code calls a library; a framework calls your code." The sweet spot for HTMX I've found involves liberally using the hx-boost attribute enhance links and forms that already work without JavaScript. You definitely sacrifice some of the expressivity of HTMX, but you also get a website that is much less coupled to the (library|framework).
- philipwhiuk 3y ago
  That reduces a framework to 'anything that accepts a callback function.
croes 3y ago
>But you can write React in this library-like manner too and nobody argues that React isn’t a framework. >React - The library for web and native user interfaces https://react.dev/ https://react.dev/ https://www.reddit.com/r/reactjs/comments/126uzfo/why_is_react_considered_a_library_and_not_a/ https://www.reddit.com/r/reactjs/comments/126uzfo/why_is_rea... https://medium.com/@Angie.O/why-react-is-a-library-and-not-a-framework-533d95692fe1 https://medium.com/@Angie.O/why-react-is-a-library-and-not-a... https://www.oreilly.com/library/view/what-react-is/9781491996744/ch01.html https://www.oreilly.com/library/view/what-react-is/978149199...
- hobofan 3y ago
  Yeah, that sentence surprised me too. While I generally would also consider React more a library than a framework, I think there are arguments to be made that it's a framework. If we go by the common "your code calls a library; a framework calls your code" distinction, then you definitely have to structure your components in a very specific manner so that the React internals can "call your code" to e.g. render one component from it's parent component.
  - leetrout 3y ago
    My favorite quip (not mine): somethings wrong when express is a "framework" and react is a "library".
  - diggan 3y ago
    One vital distinction is that even if you define 100 components, nothing will happen unless you call .render from react-dom. Nothing is automatically setup for you. Compare that to Laravel or anything else that is obviously a framework. You write code and put it in a file in the right place, and it gets picked up automatically, most of the time. This makes me still consider React a library, rather than a framework. But then there are tons of frameworks that uses React, nextjs is probably one of the more common ones.
    - bcrosby95 3y ago
      Note that by this definition Spring Boot isn't a framework - you call SpringApplication.run to start it.
afavour 3y ago
Sounds like a similar argument outlined here in a framework-agnostic way: https://blog.jim-nielsen.com/2023/html-web-components/ https://blog.jim-nielsen.com/2023/html-web-components/ I don't really understand why people would bother arguing whether htmx is a library or a framework. It's a way of making a web site where you write less JS.
- karmarepellent 3y ago
  > It's a way of making a web site where you write less JS. It bothers me that this point always comes up when a discussion about HTMX arises. For me writing less JS is just a very pleasant side-effect of using HTMX. But the main benefit is just having (nearly) everything in one place (the backend). It is just so much easier to reason about the code.
- asdajksah2123 3y ago
  The article explains why that's important in the way the author defined the difference between framework and library. In a nutshell, as defined by the author, a library is a cog which is included by your application and can easily be replaced if it's not being maintained anymore, whereas a framework is the system within which you create your application and switching to a new framework would require essentially rewriting the system (and throwing away what you learnt about how you developed your current app and having to learn the way to develop with the new framework). Whether you agree with the author's definitions or not is irrelevant to the piece. What is relevant, however, is that one can be far less judicious when including a library, because you can simply replace it in the future, whereas you need to be far more careful when switching to a new framework because it's not as easy to replace.
germandiago 3y ago
It is not the same at all. Of course it needs javascript on the back to work. But the concept is totally different. It uses a hypermedia declarative model, an extended POST/GET etc. model. It keeps things very simple compared to a framework like React where you need a package manager, a transpiler and a json backend for data (not returning hypermedia). So I would not consider it another Javascript frontend framework at all. I would consider it more like original html with extensions that support Ajax respecting the original web model.
- synergy20 3y ago
  that's true, it also need more support from the backend, for react a restful background is all you need, for htmx or html+ajax the backend has to do routing, state management,etc, it's really the traditional MVC approach, but easier for the frontend(no json, just html)
  - AzalinRex 3y ago
    if you put your state in the front end, you will end up tracking state on the front end and the server
- chrisco255 3y ago
  AJAX means Asynchronous Javascript and XML. It's quite literally JS. AJAX was not part of the original web model. It came out around the year 2000.
  - jbverschoor 3y ago
    Before that, we could use JSRS (JavaScript Remote Scripting)
  - germandiago 3y ago
    The only part that htmx adds is avoiding reloading the hypermedia and allow swaps via AJAX as you say. But the programming model stays hypermedia-based. For example, your server returns markup, not Json to a React frontend or similar. This simplifies things a lot though it also has some disadvantages. Advantages: if your backend changes the return to extend functionality, the hypermedia will be returned with no required changes on the frontend. On the other hand, if you want to do a data-based json API htmx is not what you want, because it conflates returning functionality (embedded in the hypermedia) with presentation, instead of returning only data.
dad_chowder 3y ago
> But you can write React in this library-like manner too and nobody argues that React isn’t a framework. I think people do still make this argument
- preommr 3y ago
  There's people in this thread that are (implictly) making that argument
- diggan 3y ago
  I'd absolutely make the argument that React isn't a framework, because by my definition it is a library, not a framework. https://news.ycombinator.com/item?id=38953266 https://news.ycombinator.com/item?id=38953266
quonn 3y ago
So what's the problem with a bundler/transpiler etc? You set it up once. It takes a few hours, maybe a day. Then your platform _is_ TypeScript + React. This abstraction basically never leaks. I never need to look at the transpiled files to find an error. Nobody argues that a C compiler is worse than assembly or that drivers or an operating system are bad.
- jollyllama 3y ago
  Once you're in the NPM ecosystem, there is a maintenance overhead. See: https://htmx.org/essays/no-build-step/ https://htmx.org/essays/no-build-step/ https://dubroy.com/blog/cold-blooded-software/ https://dubroy.com/blog/cold-blooded-software/
- intrasight 3y ago
  The problem is that it's no longer an "interpreted" language.
  - quonn 3y ago
    How is that a problem?
    - intrasight 3y ago
      People like to interact with interpreted languages
      - quonn 3y ago
        But in the browser the browser interacts with it anyway. It‘s not like the app would run in a repl and now doesn‘t. There is no meaningful difference in this case, even less so if hot reloading is used.
- danielvaughn 3y ago
  I don't know how build systems work at lower levels, but things move so fast in the web development world that it renders your codebase inoperable if you don't maintain it. I've had a codebase that sat for as little as 6 months without me touching it. When I tried to run it again, I ran into so many compatibility issues that I had to tediously copy out all of my code into a new project and then fix the remaining issues with my code itself. Web dev build systems are dependencies on top of dependencies on top of dependencies, and they're all introducing breaking changes every other week it seems.
duxup 3y ago
I like this article, it's interesting. I will say that in the web dev world I'm a whole lot less worried about definitions than I am trying to figure out what library or framework works for given use cases, what its benefits are ... and where it stops being helpful. That's not information that is nearly as easy to write though and sadly seems to just take trial and error by each individual.
intrasight 3y ago
I prefer to refer to htmx as a "future polyfill". Eventually, htmx semantics will become part of the web standard, and older browsers (or those that choose not to implement the feature) will need this polyfill.
- hobofan 3y ago
  > Eventually, htmx semantics will become part of the web standard Why do you think that will be the case? I'm not aware of any effort being made to evolve htmx into a web standard (either by introduction into existing specifications or direct adoption by browser), so this is about as baseless of a claim as someone saying "I see JQuery as a future polyfill" in ~2006.
  - intrasight 3y ago
    s/will/may It may be aspirational on my part, but I do hope that HTML can evolve. JQuery isn't a good analogy as it's not extending HTML.
  - jbverschoor 3y ago
    Because it's a damn good name. As a matter of fact, when I read about HTMLX, I assumed it was a browser supported feature that I had missed
    - intrasight 3y ago
      Hadn't considered it before, but thinking about it now, I can see that a brilliant name choice probably played a big role in the traction that it's had.
      - recursivedoubts 3y ago
        ironically I originally rejected it in favor of "kutty": https://htmx.org/posts/2020-5-17-kutty-er-htmx-0-0-3-is-released/ https://htmx.org/posts/2020-5-17-kutty-er-htmx-0-0-3-is-rele... better to be lucky than good, I guess
mista2nith 3y ago
Yes
- caporaltito 3y ago
  Thank you.
eugenekolo 3y ago
Haven't heard of htmx before, but I might use it on a future project if I remember. As somebody who is not a frontend engineer, but still likes to make a website every now and then. I haven't found a full framework (vue, react, etc.) that I've been able to go full into and still use jquery and writing plain css/html. Htmx looks like a slight feature upgrade to jquery that I enjoy.
- dartos 3y ago
  That’s basically where it lives, though it expects your backend to return html chunks iirc
  - naasking 3y ago
    You don't need to return partial html, you can use hx-boost and return full pages and it will only update the body.
- vlod 3y ago
  I just watched this video: "HTMX For React Developers in 10 Minutes" [0] that you might like as an intro. [0] https://www.youtube.com/watch?v=r0XBULqzsT0 https://www.youtube.com/watch?v=r0XBULqzsT0
pier25 3y ago
It's obviously a library. Same as React or jQuery. Obviously like any lib it has an API but HTMX doesn't force a project structure to you.
crftr 3y ago
HTMX aims to render itself obsolete by serving as a proof of concept to advance the HTML specification. In various interviews and blog posts, Carson has mentioned that jQuery was essential only until browsers implemented features like `querySelectorAll`. The discussion about Library vs. Framework misses the core objective of the HTMX project.
- dartos 3y ago
  I hope it works! HTML is in dire need of some tlc
  - Cthulhu_ 3y ago
    I was ultimately disappointed in HTML5 even though it was supposed to bring HTML into this era, with things like audio/video tags and new input methods for phone numbers and the like for mobile users. But ultimately it fell flat, was incomplete, and it feels like it's been stagnant again since HTML5 came out.
    - tangue 3y ago
      Yep in 2024 we still haven’t found a generic datepicker and hundreds of people on the internet are coding their own version. HTML5 snafu
      - runarberg 3y ago
        What is wrong with <input type="date">?
        Koffiepoeder 3y ago
        Timezone support, no date ranges (eg from-to), date formats are a mess (mdn: "At the moment, the best way to deal with dates in forms in a cross-browser way is to have the user enter the day, month, and year in separate controls, or to use a JavaScript library such as jQuery date picker."), often rules are needed (eg only weekdays), non gregorian calendars, ... A good date input would cover at least like 80-90% of use cases in my opinion. From experience it's currently more something like ~40% or so.
endisneigh 3y ago
htmx is one of those things, like SQLite on the server, that you will incessantly see on HN, but rarely see used at large profitable companies. Say you use python and Django. Why use htmx instead of Django templates? Same with ruby and rails, elixir and phoenix, etc. the trend is clearly towards live view/hotwire OR things like server side react. Htmx is in a weird position that makes no sense unless you want to use it for the sake of using it.
- unsupp0rted 3y ago
  People use it for the sake of not using JavaScript. To a React client-side developer everything should be done in React on the client-side, with maybe a sprinkle of backend for unavoidable things, like where API keys live. They’ll foot-gun as much backend stuff into the front end as possible. To a certain kind of backend developer, everything should be done typesafe in non-JavaScript on the backend, with a sprinkle of client-side JavaScript for unavoidable things like showing/hiding elements. Of course even for this, 10 lines of CSS is preferable to 1 line of JS. They’ll foot-gun as much client-side stuff into the back end as possible.
  - karmarepellent 3y ago
    Maybe some people are using it to avoid JS at all costs. I am using it to have everything (validation, authentication) in one place, the backend. It also saves me currently four serialization and deserialization steps, which drastically improved performance. meanwhile there will also be a few 10s or 100s lines of JS to enable some specific behaviour that I do not want to (or would be awkward to) implement in HTMX. I am not saying that it is a silver bullet and people may use it for a variety of reasons, even avoid JS. I try to be less biased and make the best of both worlds. Until now, it has been pure joy.
  - philipwhiuk 3y ago
    Happy full-stack React + Back-end guy here :)
- dizhn 3y ago
  This is not necessarily refuting what you said but perhaps a different point of view. I wrote a simple backend servive with go and wanted to have some on off switches and status icons for it. I don't know js and am not interested in learning it. Htmx gave me enough interactivity to put together that one status thing with buttons in a few hours. To me that's valuable.
smallerfish 3y ago
htmx + kotlinx.html + kotlinjs is an excellent combo that gives you an MPA that looks and feels like a modern webapp, with minimal stack complexity, and fully typesafe/compiled UI code. I'm also layering in tailwind & flowbite. With the hotswapagent project, you get hotswap that works for when you're building out UIs. One day I'll blog about this stack in more detail and post here.
- sureglymop 3y ago
  This sounds interesting. Would you be so kind as to explain how to set this up or link to an example? I do have experience with plain kotlin but googling yielded not many results on how to integrate all these components you mentioned into a basic MPA. So - blog post encouraged :)
  - smallerfish 3y ago
    I definitely will post about it, but it's probably a blog length walkthrough :). I have an email notification form on my blog if you want to be notified when I get it done: https://smaller.fish/ https://smaller.fish/ (I promise no spam.)
Bluescreenbuddy 3y ago
"it's all javascript!?" "always has been" ᕦ(̿ ̿ -̿ ̿ )つ/̵͇̿̿/’̿’̿ ̿ ̿̿ ̿̿ ̿̿
lanecwagner 3y ago
Recently I had Carson on my podcast: https://youtu.be/9H5VK9vJ-aw?si=cv4ScxFTnJMRbsSH https://youtu.be/9H5VK9vJ-aw?si=cv4ScxFTnJMRbsSH He talked about this idea quite a bit, I love the idea of giving backend developers more control over the UI without resorting to huge JS frameworks
kopirgan 3y ago
Liked this phrase.. Explains the big picture beautifully "a system by which elements enter and exit the DOM via network request."
masfoobar 3y ago
I would refer it as a library. Like any library, it has a bunch of functions available to use. The difference, however, is that you don't use them directly. You are just writing html with htmx tags, etc.. and letting htmx, the library, do the rest. This is it for the most part - but I understand some complications could break that rule. I doubt it would be that often if at all.
nonethewiser 3y ago
Returning your data in html which is coupled to your frontend html and css sucks.
- nickmonad 3y ago
  Why? If the primary client is a browser, you're giving it exactly what it needs to render.
mattkevan 3y ago
I’ve had a lot of fun building an app with HTMX and Django. Makes things so much easier as I don’t need to use anything other than the standard templating system and still get an SPA-like front-end experience.
game_the0ry 3y ago
I never used or looked into htmx, but... I feel like htmx fell into the same hype-cycle as every JS framework - initial interest was enthusiastic, but will likely fade as folks use it in the real world and any holes in the things it tries to solve are exposed. On to the next, I guess... Or go back to Ruby on Rails :)
- testermelon 3y ago
  htmx is not a framework, or even library. it's only one implementation of an idea. an idea that needs to be implemented by the browser instead of something external like a js file.
- jabradoodle 3y ago
  There are simple things it would be nice to do without either 1. A server + framework, 2. A full on SPA, 3. Hand writing tedious js. There is a nice sweet spot for htmx here; whether it can build the required network effect is another story, and not always reflective of the quality of the idea.
  - game_the0ry 3y ago
    Don't get me wrong - I love the idea of an open source project pushing mainstream ideas of how tech should be done, but those projects should be scrutinized and will always need to prove themselves in real world implementations. When that happens, the tech needs to evolve, be well-documented, and well-maintained. I think htmx is doing an admirable job so far.
- marcosdumay 3y ago
  > Or go back to Ruby on Rails When you do that, you'll see the point of htmx.
- recursivedoubts 3y ago
  gotta start somewhere
- pastor_bob 3y ago
msolberg 3y ago
As a devops engineer who has recently been tasked with building UIs for our team and our developers, HTMX is a godsend. I create apps that often get steadily worked on for weeks and then only maintenance once and a while after that. I used to write django apps, but recently switched to a go backend with go html templates and htmx. This allows me to push everything in one docker image and avoid the black box nature of big frameworks that I don't have the time to fully understand. I know this doesn't add to the conversation very well but I just want to throw it out there that htmx is a good replacement for a larger framework that you don't fully understand. Also shoutout aplineJs for making small JS changes easy.
- internet101010 3y ago
  Alpine + htmx + tailwind is pretty much what I use for every quick little front-end thing now. I do still use Django but plan to transition to Rust as a way to get more comfortable with Rust.
  - jslakro 3y ago
    What do you use alpine for? htmx is not enough?
    - recursivedoubts 3y ago
      Scripting is part of web development, htmx endorses hypermedia-friendly scripting: https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/ https://hypermedia.systems/client-side-scripting/ https://hypermedia.systems/client-side-scripting/
    - arcanemachiner 3y ago
      Alpine is for client-powered reactivity and HTMX is for server-powered reactivity. Think about pressing a button that opens a modal with content already delivered by the server (like a settings modal). You don't need to make a HTTP request for that, so you could use Alpine. Let's say instead that you click a user icon and you want to render a modal that contains user info which hasn't been fetched from the server (because why waste resources loading all this data the user might not see or need?). When clicking that icon, you could use HTMX to fetch the user data from the server then display the resulting content in a modal. Two different actions with similar visual results (from the user's perspective), but one is all client-side and one requires extra info from the server. Alpine and HTMX are frequently confused this way, as they solve seemingly similar problems from different ends of the network.
iterateoften 3y ago
The problem I have with this style of library for frontend dev work is eventually the scope of the problem exceeds what the library is capable of doing. Then you have to embed JS which then gets pretty messy and spaghetti code and enough of this you are right back to where you started setting up a JS build system to make up for the deficiencies. Only now it is worse because you are working around one library and you start fragmenting your app because you started with the wrong thing.
- karmarepellent 3y ago
  But it is not a given that the scope of the problem eventually exceeds what HTMX is capable of. It is perfectly fine to set HTMX aside and choose another framework if you feel that it better suits the problem at hand. Meanwhile there is still a ton of projects for which HTMX is more than enough (and always will be). So what you are mentioning is not an issue of HTMX, but one of "chosing the right tool for the problem".
  - iterateoften 3y ago
    That’s fair. I guess my comment was inadvertently responding to another about why you don’t see it at large companies. One team at my company wanted to use HTMX and write the product with it and then the PM kept asking for features to bring it to parity with the rest of the application with regards to client side behavior and things devolved. They used hyperscript and eventually the frontend was just rewritten to be react.
    - karmarepellent 3y ago
      Well I would not dare going through the hassle of moving from React to something like HTMX if the former is already well-established in the company, except when everyone is on board. So I totally get that.
deleted 3y ago
[deleted]
toinbis 3y ago
It's surelly not "just another htmx framework" for at least one more reason - it has 100+ CEOs, way more than any other! Check them all out https://htmx.ceo https://htmx.ceo . I'm one of them. Really proud!
exabrial 3y ago
HTMX is signaling they're around for the long haul, we'll see if they break backwards compatibility or rewrite their API 15 times in the next year. I had one of my dev's do several node/js framework POCs in _September_ last 2023 (current year is Jan 2024 at the time of this writing). Nearly all of the POCs won't even run or build any more because the developers have rewritten something and broke all backwards compatibility. The Javascript/Node ecosystem is terrible for businesses and you're incinerating cash if your company running in the Node/Javascript rat race. I'm hoping HTMX injects some sanity into frontend development.
- taeric 3y ago
  This feels extreme? Any chance you could share numbers or more details on these prototypes? I agree that the ecosystem seems crazy fast on moving. I wouldn't have thought it was that bad. React, in particular, I thought had been fairly stable? (Yes, there are new ways of doing things, but most of the old still work there, to their credit.)
  - jokethrowaway 3y ago
    I don't think it's been the case for the last few months in particular, but Next has been historically terrible for this case. It sucks because it's also the best way of developing a React app without worrying much about tons of boilerplate crap. I have different next projects started at different times and whenever I need to change a single line of text, I have a 50% chance something won't work and I'll have to debug some error coming from the intersection of different versions of node being used in the JAM host. I got hit by OpenSSL issues for a static website. Then a potential solution is to upgrade the framework (next or react) but then you start running into a bunch of other issues and you find yourself 8 hours deep for a copy change. Performance is also a pain to get right as the abstractions keep piling up and especially the rendering cycle of React is a massive pain. The move from class to functional (for the majority a net positive as the functional version is way more readable and clear) made accessing some hooks harder, so know you need to remember some special rules or functions to call in order to get the behaviour you want. For all new projects I just use solid.js which is a bit nicer compared to React while keeping most of React syntax. The abstraction layer is much smaller compared to React (no vdom, no custom rendering cycle, your function gets executed once, not once per re-render). You just have to remember you are dealing with Proxy instances and you're good to go. Somehow I didn't have problems with updates but there is way less activity compared to React. I have some projects from 3 years ago just using solid.js, and a bunch of projects with solid-start. I didn't bother updating them, they keep on running, can't complain.
tangentstorm 3y ago
> Even though you aren’t writing the 3P code yourself, by including it in your project you are committed to understanding it—and refreshing that understanding if you want to upgrade it. This is a nice thought, but I suspect hardly anyone who uses a framework or library really understands it, or makes the commitment to try. Obviously, a subset of really talented users eventually learn to understand the framework, but most are at its mercy. Even then, you can't study every possible framework before choosing one to master - there are too many, and the cost of understanding the foreign code is simply too high. So I suspect that in general, people try frameworks by taking a leap of faith, and then, sometimes, make the effort to actually understand it later - if and when it becomes necessary.
- alexpetros 3y ago
  The main point I'm trying to make here is that even if you're in the "leap of faith" category, you still on some level have to understand the framework constructs (i.e. its API) in order to make use of it. If that API changes with a new version, and you want to upgrade, you're going to have to learn enough about that new API to make the upgrade. Obviously you benefit from understanding the internals too, but realistically, the more complicated the thing you're using, the less of the internals even a motivated user is going to bother with.
  - briantakita 3y ago
    > Obviously you benefit from understanding the internals too, but realistically, the more complicated the thing you're using, the less of the internals even a motivated user is going to bother with. This is a problem that grows with a large library...An api change has a higher cost than with a smaller library. Smaller libraries also tend to be easier to fully understand. Large libraries tend to be more of a "leap of faith" than small libraries.
hintoftime 3y ago
Reading the first part of the book [0] featuring the concepts behind hypermedia systems has helped me to really understand the goals of HTMX. I would highly recommend it even if you don't experiment with HTMX yourself. I bought it as an ebook to support the author but it is also free to read. [0] https://hypermedia.systems/ https://hypermedia.systems/
deleted 3y ago
[deleted]
recursivedoubts 3y ago
I am the author of htmx. I think htmx is a library using the following definition: - a library you call - a framework calls your code in htmx you add attributes to HTML to "call" htmx, so, from the perspective, you can call it a library. On the other hand, those "calls" are called back into via event handlers in JavaScript, so an argument can be made that, even at this level, htmx is a framework. I liked alex's analysis and I think his definitions and thinking contribute to the discussion, so I posted it to the htmx website. Even though I still consider htmx a library. :)
- ncphillips 3y ago
  I’m the CEO of HTMX. This is correct.
- dfabulich 3y ago
  The React team argued that it was "merely a view library" for years, and as far as I can tell, this was a wrong-headed approach based entirely on vibes. Libraries are cute and charming; frameworks are humongous and domineering. If you think of React and HTMX as cute and charming, and especially if you think of them as much cuter and more charming than their other "frameworky" competitors, then you'll prefer to think of your code as a library instead of a framework. Instead, I urge you to describe HTMX as a "lightweight HTML framework."
  - alexpetros 3y ago
    Broadly speaking, that's basically what this article says!
  - recursivedoubts 3y ago
    yep, i understand that view, but i'm going to keep calling it a library because i think it's a library, but I get it
  - mhink 3y ago
    For what it's worth, the landscape of Web development was much, much different in 2014 or so. Ruby on Rails was still a huge player, and most major OSS projects meant to enable Web development took a lot of cues from it. Projects like Angular, Ember.JS, and Backbone (and for that matter, Rails' own Turbolinks system) very much expected you to build your entire application in them from the get-go. The gist of React saying "this is a view library" at that point was largely about what you should expect React not to do for you. For example, two-way data binding, where the framework managed a fetch lifecycle as well as plugging the result into a view. "React is a view library" was letting devs know that they shouldn't expect React to do this- they should expect to make calls themselves and re-render the view accordingly. I actually think it's still fair to say that React *itself* is still "just a view library", but that's sorta like saying Linux is "just a kernel". Sure, it's technically true, but at this point when we're talking about React we're talking about the whole ecosystem surrounding it as well. That wasn't the case 10 years ago (damn, has it really been that long?)
karmarepellent 3y ago
As every discussion about HTMX usually evolves to people arguing why it is not widely adopted by big corporations and the like, let me be the first to share a thought on that topic. Could it just be an organizational problem? When you start using HTMX in your company your neat distinction between frontend and backend devs collapses and everyone suddenly must be a full-stack developer. When you can avoid that additional cost by simply continuing to use React (or others), why wouldn't you? Edit: As a side note, I have never used any large JS framework, only HTMX. Just trying to put myself in the shoes of happy React users and such.
- troupo 3y ago
  I'm a fullstack developer in the widest sense of the world: I worked exclusively on the backend side, and exclusively on the frontend side, and on both at the same time. I wouldn't touch HTMX with a ten-foot pole :) It's a somewhat haphazardly defined DSL around magical attributes, their values, and awkward workarounds with somewhat badly specified behaviours (what's `hx-select-oob` exactly?). There are other projects that do these things better, with less pretentiousness: Phoenix Liveview or Laravel LiveWire, or even Hotwire
  - recursivedoubts 3y ago
    all of those projects are much more magical, particularly the live* flavor of hypermedia driven applications htmx generalizes the standard hypermedia controls found in HTML: anchors & forms this makes it more work to implement some things, but sticks closer to the basic ideas of HTML and, as always, if nothing magically works, nothing magically breaks
    - troupo 3y ago
      > all of those projects are much more magical, Oh, they are not. They are more powerful, but they use rather simple concepts. Speaking as the user of Phoenix LiveView who even created his own templating library to work with it. > htmx generalizes the standard hypermedia controls found in HTML: anchors & forms Those are not "hypermedia controls". As I said elsewhere: stop appropriating concepts for your benefit. > the basic ideas of HTML The "basic idea of HTML" is "render a text page with a few images in one rendering pass with links to other such documents". That is it. You are perhaps referring to the hypertext vision of Sir Tim Berners-Lee, but that is as far removed from HTMX as HTMX is removed from any other concepts it keeps trying to appropriate. HTMX is a utility lib with a few diffing utilities that does what nearly every other library does, but chose the high ground of "we're doing it with HTML chunks, so we're better and this is what the founders envisioned". You're not better. This is not what founders envisioned.
pphysch 3y ago
How do HTMX users manage the complexity of endpoint dependency graphs? Once you go from simple route->page mapping to heavy HTMX usage, you now have routes that are implicitly dependent on other routes to work properly. "/users/42/" relies on hx-post="/users/42/send-email", and so on. Are there ways to model that dependency graph outside of your brain, say an IDE plugin.
- mxey 3y ago
  You might like https://htmx.org/extensions/path-deps/ https://htmx.org/extensions/path-deps/
arrakeen 3y ago
in a world where XHTML 2 was widely adopted, would HTMX have been necessary? it seems like it was the (failed) attempt at evolving the hypermedia aspects of HTML
ndyg 3y ago
> As they should! Building with htmx works a lot better if you play to its strengths. You can send JSON-formatted form bodies, if you really insist. But you shouldn’t! This excellent essay overlooked a '*': * unless you are using bash + jq for your backend, in which case, JSON-formatted form bodies are quite reasonable.
- alexpetros 3y ago
  Author here. Happy to admit that bash + jq backends are an excellent reason to use JSON formatted bodies. Godspeed you crazy animal.
davexunit 3y ago
I like the basic idea of htmx: respond to user input by making server requests that return new html for a subset of the page. However, I think there's a pretty significant language design problem and htmx's solution is language proliferation. There is a very low "expressivity ceiling" for what can be encoded into html attributes. The hx-trigger attribute defines a new, very limited domain specific programming language for expressing side-effects with few means of combination or abstraction. For anything slightly complicated, hyperscript seems to be the favored solution which is yet another new language. All of this caused by trying to shove logic into attribute strings.
- alexpetros 3y ago
  This is correct, but... logic belongs in attribute strings! Even in basic HTML, it can change what kind of HTTP request your <form> makes, or what kind of value your <input> sends, or where your <a> link goes. Without question, there's a lower expressivity ceiling to attribute-based specifications, but there is a lot that you can do within that ceiling, and you benefit in other ways by keeping your application at that "level," so to speak. [0] [0] https://unplannedobsolescence.com/blog/custom-html-has-levels/ https://unplannedobsolescence.com/blog/custom-html-has-level...
  - davexunit 3y ago
    I think this is a bit of reductionist interpretation of what I'm saying. Yes, it's technically correct that the attributes on a form change the type request made. That's not really what I'm talking about, though. In the same way that I wouldn't want to manually type a lot of CSS into a style attribute, I wouldn't want to write a small program in an hx-trigger attribute. Something like hx-trigger="input changed delay:500ms, search" is getting rather complicated, imo, and it's a new DSL with new semantics to understand. And then the recommended escape hatch is... yet another new language? I dunno I just feel like there's something missing here.
    - alexpetros 3y ago
      I somewhat agree with you but I think it's important to clarify whether you're talking about htmx or the hx-trigger syntax specifically. In the parent comment you say: > However, I think there's a pretty significant language design problem and htmx's solution is language proliferation. There is a very low "expressivity ceiling" for what can be encoded into html attributes. And then here you say: > In the same way that I wouldn't want to manually type a lot of CSS into a style attribute, I wouldn't want to write a small program in an hx-trigger attribute. Something like hx-trigger="input changed delay:500ms, search" is getting rather complicated I wouldn't write a small program in the hx-trigger syntax either (although, we not only have users who do that, but have contributed to hx-trigger optimizations because they use it so heavily). Many htmx use cases don't need this at all, some need complexity up to this point, some need far more complexity. It's really up to you to decide at what point you bring in the bigger guns—whether that's hx-trigger, alpineJS, hyperscript, or a React Island. I agree that hx-trigger is a DSL, and represents the outer limits of htmx's expressivity. My objection is to the argument that htmx's attribute design is an expressivity problem, rather than a well-chosen level of abstraction for the types of problems htmx is best suited to solve (see the sibling comment about Rule of Least Power too).
deleted 3y ago
[deleted]
tiddybittyes 3y ago
Before the JS hipsters arrived on the scene attempting to implement Java on the web again. There was and still is nothing wrong with full page refreshes and javascript augmentation per page. HTMX is an aim to get back to that and Web Components are looking good as well.
toastercat 3y ago
My biggest beef with htmx has more to do with the fact that it gets hyped as a React/Vue/Svelte alternative, when it's more accurate to describe htmx+<backend of your choice> as an alternative. Also the constant use of pretentious memes on the official blog. But otherwise, I'm looking forward to trying it out for my next pet project.
- philipwhiuk 3y ago
  > htmx+<backend of your choice> You can use React with any backend.
  - toastercat 3y ago
    My point is that htmx is not for SPAs. You need something like Alpine.js. A React app can live entirely in an .html file.
zubairq 3y ago
I have heard so much about HTMX but never really “got” the essence of it. This finally brought me a bit closer, thanks!
vlugovsky 3y ago
It's definitely not "just another." I believe this term implies that the framework would follow current trends, such as Components, Templates, etc. HTMX is different and incorporates some old JSF-like ideas, which makes it feel fresh for some developers, especially those who don't really want to learn React, Angular, Vue, and others.
robertoandred 3y ago
> htmx is for writing HTML This is false. All of those proprietary custom attributes mean it's for writing htmx, not HTML. If anything, JSX is closer to HTML and htmx is.
philipwhiuk 3y ago
It infests the 'rest' of your code. It's a framework.
theultdev 3y ago
There's just little benefit in HTMX unless you have a live financial dashboard or something like that. I find the opposite approach of local-first (database in the client). It fits more solutions and solves many more things (free offline, syncing, undo support) and getting rid of caching, retries, and latency. Of course the industry wants you to want more on the server though. Same view applies to RSC (react server components). Embrace CRDTs.
- recursivedoubts 3y ago
  oh, i dunno, seems like the internet has been somewhat successful as a distributed system, but ymmv
  - theultdev 3y ago
    centralizing would be using HTMX and authoritative servers. local-first is more decentralized as your clients can sync directly with each other (or through a dumb proxy for NAT punching) I see no need for servers to be anything but dumb proxies for clients. Not the opposite of making clients dumb terminals.
    - recursivedoubts 3y ago
      welp, when you are coordinating things it's often a tremendous simplification to have a centralized source of truth and then present representations of that truth in the form of hypermedia to hypermedia clients, using hypermedia as the engine of application state of course, it's not right for everything and there are alternative approaches that work better or worse, depending on context, but i'd say it's hard to not call it a pretty successful approach to distributed systems
      - theultdev 3y ago
        a centralized source of truth is a pretty successful approach to distributed systems? seems more like a successful escape hatch. yes it's simpler, but it's antithetical to the goal.
proc0 3y ago
XML is a pain, and I'm including JSX in this. Writing open/close tags, and then using wakas (<, >) everywhere seems unnecessary and creates ugly files. I feel the DOM should also expose other languages to interface with and browsers should detect that. Imagine web apps written with python and YAML for templates (on the client side, without transpiling).
sebastianconcpt 3y ago
I've recently adopted htmx from a Smalltalk backend and feels lovely. When coding to do that it felt like a library and not a framework and provides a lot of flexibility in design options. And I agree that the backend should do as much HTML as possible but some times you still need to do things with js. Bu again the backend can send the html plus the bits of js specific for that UI screen or component and that's super flexible and efficient if you keep it properly factored and with nice separation of concerns. Here is a talk where I've made the case for a particular stack and demoed it last November in the Smalltalks 2023 conference https://www.youtube.com/watch?v=4_gmvN0pimI https://www.youtube.com/watch?v=4_gmvN0pimI
mlhpdx 3y ago
As a humble, new user of HTMX I don’t care what noun you choose for it (stereotyping by another word still smells the same). The facts as I have experienced them are a) it’s simple to do simple things; and b) it keeps difficult things possible. My highest praise. So, I’m using it. I’m a bit of a nut, and my backend is pure AWS Step Functions. Declarative web app, all the way down. Yes, because of HTMX the backend is different than it would be with “plain” HTML or the JS framework du jour. But, the backend is very simple and clean, so I agree it has a nice influence whatever y’all decide to call it.
- bilalq 3y ago
  What do you write your step functions in? Are you using ASL or something that compiles to it?
  - mlhpdx 3y ago
    Straight ASL.
lakomen 3y ago
Htmx = pointless hype. It solves no problems and makes everything more complicated. You have to learn not 1 but 2 new "languages" hypermedia queries and htmx special html attributes. And what do you receive in return? Nothing that can't be done with other JS frameworks or libraries. Yes, htmx is JS. That HN people fall for this trick is no surprise as it's frequented mostly by booksmart idiots.
ralmidani 3y ago
There is a spectre haunting SPA frameworks… It’s a shame htmx wasn’t invented 10 years ago, but it makes sense that it’s bursting onto the scene now as a reaction to end-stage SPA mania. If htmx-like functionality gets rolled into browsers with native optimizations (i.e. faster than the Virtual DOMs and custom JS runtimes of SPA frameworks, not to mention the no-build-step benefits we’re already seeing with htmx), then it hopefully won’t be just htmx that will get rendered obsolete; Angular, Ember, React, Svelte, Vue, etc. need to go even more urgently. Pardon my enthusiasm, I really am looking forward to an HTML Renaissance.
andrewstuart 3y ago
I'm a React developer, pretty happy with it. What is the core thing(s) I should be appreciating about HTMx?
wutwutwat 3y ago
Don't know anything about htmx, just popping in to see if anyone else remembers "dhtml", and "dhtml guru". A different time. A different internet. htmx triggered that random memory, and then a flood of others, like: the gold rush of people, sometimes kids, renting servers or colocating space, installing cpanel, and starting a shared hosting company dreamhost, remember dreamhost? vps hosting providers that offered emulated systems, before public cloud was a thing, before vmware or hypervisor OSs, before kvm, or virtualization in general webmin/virtualmin (which is still going strong it seems) turnkeylinux (which is also still going strong) linux from scratch macromedia betaarchive.com Chris Pirillo
guru4consulting 3y ago
My product has the typical SPA front-end and API backend. I understand that with HTMX, those API backends would have to return HTML fragments instead of JSON data (or another server endpoint that returns HTML fragments). I have few questions with this HTMX approach: - We don't hire full-stack developers. Our UI/UX designers and web developers fully focus on the front-end (responsive for mobile/tablet/desktop, A/B testing, quick iterations of UI/UX enhancements) without bothering about the backend. The backend API developers focus on API returning the right data and don't care about UI. I like this separation as it helps to really iterate the UI/UX faster. With HTMX, those backend devs will now have to worry about returning the correct HTML fragment based on the client device, position of the HTML div, etc. The presentation concerns spill over to backend developer and we are back to the days of server-side templates like JSP/ASP/RoR/PHP/Django. Anyone else sees issue with this approach? - React/similar web apps can handle quite complex UI with multiple flows and navigations. I assume HTMX is probably not suited for complex UIs. Is that right? has anyone built any complex UI with HTMX?
- recursivedoubts 3y ago
  If the FE/BE split is working well for you, then htmx isn't as compelling. It is more compelling when you have full-stack developers who can take ownership of entire features and shepherd them from start to finish, without needing to coordinate with another team to get the data/functionality they need. Here is an example of a fairly sophisticated application that was written in react, then moved to htmx with good results: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ As far as what you can achieve with htmx, I outline when hypermedia (the more general concept behind htmx) is a good choice or a bad choice here: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ You can get an idea of the basic level of interactivity you can achieve with htmx by looking at the examples: https://htmx.org/examples/ https://htmx.org/examples/ all of which compose well together. You can get more dynamic than that if you are willing to do client-side scripting (https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/) another essay that might be of interest, regarding your APIs: https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/ and, if you want a complete introduction and overview of the hypermedia approach, we have a book available online for free: https://hypermedia.systems https://hypermedia.systems
EGreg 3y ago
This is how we do it in our framework, which we started in 2011 and have been using continuously and improving until now: https://qbix.com/platform/guide/tools https://qbix.com/platform/guide/tools We define "tools" to add/remove behavior to/from existing elements. The tools are added by an HTML5-compliant microformat. For example: <div class="Q_tool Q_columns_tool"> <form class="Q_tool Q_form_tool"> </form> </div> Tools can contain other tools, and you can specify them when you attach event handlers, for example, so the handlers get removed when the tool gets removed, e.g. when its container tool is removed: event.set(handler, tool); // no need to remove it later As a more complex example, here we have a chatroom, which has extensions like calling people and mentioning people: <div class='Q_tool Streams_chat_tool Streams_mentions_chat tool Media_call_chat_tool any_normal_classes_too' data-streams-chat='{" publisherId": "abcjwuqk", "streamName": "..." }' data-media-call-chat='{ "livestream": { "private": true, "max": 3 } }' some-other-attributes="" > elements may be empty or have some existing content </div> And we also support Handlebars helpers: <ul> {{#each list}} <li>{{tool "Streams/chat" publisherId="abc" streamName="..."}}</li> {{/each}} </ul> Finally, we can also activate them dynamically via Javascript: Q.Tool.prepare(someElement, "Streams/chat", options); or div = Q.Tool.prepare('div', "Streams/chat", options); Then we just call Q.activate(container) which traverses the container and activates all tools inside it. At any point in the console you can type Q.Tool.active and it will show you all active tools. You can see it in action for example at https://intercoin.app https://intercoin.app PS: I used to originally call it the "Q" Framework but because of people on HN constantly complaining that it was conflicting with the "excellent Q library for promises", I finally relented and called it "Qbix Platform"... now the Q library for promises is obsolete but we still call it Qbix... so maybe it's better for SEO though? https://news.ycombinator.com/item?id=6053211 https://news.ycombinator.com/item?id=6053211
sublinear 3y ago
yes
thomas-guettler 3y ago
We are ugly, but we have the music

284 points by cubefox 3y ago

cranberryturkey 3y ago

cubefox 3y ago
The article says it is a JavaScript framework.
- beanjuiceII 3y ago
  thats because it is
dartos 3y ago
Kekw

cranberryturkey 3y ago

https://primatejs.com https://primatejs.com has supported htmx from day one.

jakelazaroff 3y ago

I like this fuzzy definition better than "your code calls a library; a framework calls your code." The sweet spot for HTMX I've found involves liberally using the hx-boost attribute enhance links and forms that already work without JavaScript. You definitely sacrifice some of the expressivity of HTMX, but you also get a website that is much less coupled to the (library|framework).

philipwhiuk 3y ago
That reduces a framework to 'anything that accepts a callback function.

croes 3y ago

>But you can write React in this library-like manner too and nobody argues that React isn’t a framework. >React - The library for web and native user interfaces https://react.dev/ https://react.dev/ https://www.reddit.com/r/reactjs/comments/126uzfo/why_is_react_considered_a_library_and_not_a/ https://www.reddit.com/r/reactjs/comments/126uzfo/why_is_rea... https://medium.com/@Angie.O/why-react-is-a-library-and-not-a-framework-533d95692fe1 https://medium.com/@Angie.O/why-react-is-a-library-and-not-a... https://www.oreilly.com/library/view/what-react-is/9781491996744/ch01.html https://www.oreilly.com/library/view/what-react-is/978149199...

hobofan 3y ago
Yeah, that sentence surprised me too. While I generally would also consider React more a library than a framework, I think there are arguments to be made that it's a framework. If we go by the common "your code calls a library; a framework calls your code" distinction, then you definitely have to structure your components in a very specific manner so that the React internals can "call your code" to e.g. render one component from it's parent component.
- leetrout 3y ago
  My favorite quip (not mine): somethings wrong when express is a "framework" and react is a "library".
- diggan 3y ago
  One vital distinction is that even if you define 100 components, nothing will happen unless you call .render from react-dom. Nothing is automatically setup for you. Compare that to Laravel or anything else that is obviously a framework. You write code and put it in a file in the right place, and it gets picked up automatically, most of the time. This makes me still consider React a library, rather than a framework. But then there are tons of frameworks that uses React, nextjs is probably one of the more common ones.
  - bcrosby95 3y ago
    Note that by this definition Spring Boot isn't a framework - you call SpringApplication.run to start it.

afavour 3y ago

Sounds like a similar argument outlined here in a framework-agnostic way: https://blog.jim-nielsen.com/2023/html-web-components/ https://blog.jim-nielsen.com/2023/html-web-components/ I don't really understand why people would bother arguing whether htmx is a library or a framework. It's a way of making a web site where you write less JS.

karmarepellent 3y ago
> It's a way of making a web site where you write less JS. It bothers me that this point always comes up when a discussion about HTMX arises. For me writing less JS is just a very pleasant side-effect of using HTMX. But the main benefit is just having (nearly) everything in one place (the backend). It is just so much easier to reason about the code.
asdajksah2123 3y ago
The article explains why that's important in the way the author defined the difference between framework and library. In a nutshell, as defined by the author, a library is a cog which is included by your application and can easily be replaced if it's not being maintained anymore, whereas a framework is the system within which you create your application and switching to a new framework would require essentially rewriting the system (and throwing away what you learnt about how you developed your current app and having to learn the way to develop with the new framework). Whether you agree with the author's definitions or not is irrelevant to the piece. What is relevant, however, is that one can be far less judicious when including a library, because you can simply replace it in the future, whereas you need to be far more careful when switching to a new framework because it's not as easy to replace.

germandiago 3y ago

It is not the same at all. Of course it needs javascript on the back to work. But the concept is totally different. It uses a hypermedia declarative model, an extended POST/GET etc. model. It keeps things very simple compared to a framework like React where you need a package manager, a transpiler and a json backend for data (not returning hypermedia). So I would not consider it another Javascript frontend framework at all. I would consider it more like original html with extensions that support Ajax respecting the original web model.

synergy20 3y ago
that's true, it also need more support from the backend, for react a restful background is all you need, for htmx or html+ajax the backend has to do routing, state management,etc, it's really the traditional MVC approach, but easier for the frontend(no json, just html)
- AzalinRex 3y ago
  if you put your state in the front end, you will end up tracking state on the front end and the server
chrisco255 3y ago
AJAX means Asynchronous Javascript and XML. It's quite literally JS. AJAX was not part of the original web model. It came out around the year 2000.
- jbverschoor 3y ago
  Before that, we could use JSRS (JavaScript Remote Scripting)
- germandiago 3y ago
  The only part that htmx adds is avoiding reloading the hypermedia and allow swaps via AJAX as you say. But the programming model stays hypermedia-based. For example, your server returns markup, not Json to a React frontend or similar. This simplifies things a lot though it also has some disadvantages. Advantages: if your backend changes the return to extend functionality, the hypermedia will be returned with no required changes on the frontend. On the other hand, if you want to do a data-based json API htmx is not what you want, because it conflates returning functionality (embedded in the hypermedia) with presentation, instead of returning only data.

dad_chowder 3y ago

> But you can write React in this library-like manner too and nobody argues that React isn’t a framework. I think people do still make this argument

preommr 3y ago
There's people in this thread that are (implictly) making that argument
diggan 3y ago
I'd absolutely make the argument that React isn't a framework, because by my definition it is a library, not a framework. https://news.ycombinator.com/item?id=38953266 https://news.ycombinator.com/item?id=38953266

quonn 3y ago

So what's the problem with a bundler/transpiler etc? You set it up once. It takes a few hours, maybe a day. Then your platform _is_ TypeScript + React. This abstraction basically never leaks. I never need to look at the transpiled files to find an error. Nobody argues that a C compiler is worse than assembly or that drivers or an operating system are bad.

jollyllama 3y ago
Once you're in the NPM ecosystem, there is a maintenance overhead. See: https://htmx.org/essays/no-build-step/ https://htmx.org/essays/no-build-step/ https://dubroy.com/blog/cold-blooded-software/ https://dubroy.com/blog/cold-blooded-software/
intrasight 3y ago
The problem is that it's no longer an "interpreted" language.
- quonn 3y ago
  How is that a problem?
  - intrasight 3y ago
    People like to interact with interpreted languages
    - quonn 3y ago
      But in the browser the browser interacts with it anyway. It‘s not like the app would run in a repl and now doesn‘t. There is no meaningful difference in this case, even less so if hot reloading is used.
danielvaughn 3y ago
I don't know how build systems work at lower levels, but things move so fast in the web development world that it renders your codebase inoperable if you don't maintain it. I've had a codebase that sat for as little as 6 months without me touching it. When I tried to run it again, I ran into so many compatibility issues that I had to tediously copy out all of my code into a new project and then fix the remaining issues with my code itself. Web dev build systems are dependencies on top of dependencies on top of dependencies, and they're all introducing breaking changes every other week it seems.

duxup 3y ago

I like this article, it's interesting. I will say that in the web dev world I'm a whole lot less worried about definitions than I am trying to figure out what library or framework works for given use cases, what its benefits are ... and where it stops being helpful. That's not information that is nearly as easy to write though and sadly seems to just take trial and error by each individual.

intrasight 3y ago

I prefer to refer to htmx as a "future polyfill". Eventually, htmx semantics will become part of the web standard, and older browsers (or those that choose not to implement the feature) will need this polyfill.

hobofan 3y ago
> Eventually, htmx semantics will become part of the web standard Why do you think that will be the case? I'm not aware of any effort being made to evolve htmx into a web standard (either by introduction into existing specifications or direct adoption by browser), so this is about as baseless of a claim as someone saying "I see JQuery as a future polyfill" in ~2006.
- intrasight 3y ago
  s/will/may It may be aspirational on my part, but I do hope that HTML can evolve. JQuery isn't a good analogy as it's not extending HTML.
- jbverschoor 3y ago
  Because it's a damn good name. As a matter of fact, when I read about HTMLX, I assumed it was a browser supported feature that I had missed
  - intrasight 3y ago
    Hadn't considered it before, but thinking about it now, I can see that a brilliant name choice probably played a big role in the traction that it's had.
    - recursivedoubts 3y ago
      ironically I originally rejected it in favor of "kutty": https://htmx.org/posts/2020-5-17-kutty-er-htmx-0-0-3-is-released/ https://htmx.org/posts/2020-5-17-kutty-er-htmx-0-0-3-is-rele... better to be lucky than good, I guess

mista2nith 3y ago

Yes

caporaltito 3y ago
Thank you.

eugenekolo 3y ago

Haven't heard of htmx before, but I might use it on a future project if I remember. As somebody who is not a frontend engineer, but still likes to make a website every now and then. I haven't found a full framework (vue, react, etc.) that I've been able to go full into and still use jquery and writing plain css/html. Htmx looks like a slight feature upgrade to jquery that I enjoy.

dartos 3y ago
That’s basically where it lives, though it expects your backend to return html chunks iirc
- naasking 3y ago
  You don't need to return partial html, you can use hx-boost and return full pages and it will only update the body.
vlod 3y ago
I just watched this video: "HTMX For React Developers in 10 Minutes" [0] that you might like as an intro. [0] https://www.youtube.com/watch?v=r0XBULqzsT0 https://www.youtube.com/watch?v=r0XBULqzsT0

pier25 3y ago

It's obviously a library. Same as React or jQuery. Obviously like any lib it has an API but HTMX doesn't force a project structure to you.

crftr 3y ago

HTMX aims to render itself obsolete by serving as a proof of concept to advance the HTML specification. In various interviews and blog posts, Carson has mentioned that jQuery was essential only until browsers implemented features like `querySelectorAll`. The discussion about Library vs. Framework misses the core objective of the HTMX project.

dartos 3y ago
I hope it works! HTML is in dire need of some tlc
- Cthulhu_ 3y ago
  I was ultimately disappointed in HTML5 even though it was supposed to bring HTML into this era, with things like audio/video tags and new input methods for phone numbers and the like for mobile users. But ultimately it fell flat, was incomplete, and it feels like it's been stagnant again since HTML5 came out.
  - tangue 3y ago
    Yep in 2024 we still haven’t found a generic datepicker and hundreds of people on the internet are coding their own version. HTML5 snafu
    - runarberg 3y ago
      What is wrong with <input type="date">?
      - Koffiepoeder 3y ago
        Timezone support, no date ranges (eg from-to), date formats are a mess (mdn: "At the moment, the best way to deal with dates in forms in a cross-browser way is to have the user enter the day, month, and year in separate controls, or to use a JavaScript library such as jQuery date picker."), often rules are needed (eg only weekdays), non gregorian calendars, ... A good date input would cover at least like 80-90% of use cases in my opinion. From experience it's currently more something like ~40% or so.

endisneigh 3y ago

htmx is one of those things, like SQLite on the server, that you will incessantly see on HN, but rarely see used at large profitable companies. Say you use python and Django. Why use htmx instead of Django templates? Same with ruby and rails, elixir and phoenix, etc. the trend is clearly towards live view/hotwire OR things like server side react. Htmx is in a weird position that makes no sense unless you want to use it for the sake of using it.

unsupp0rted 3y ago
People use it for the sake of not using JavaScript. To a React client-side developer everything should be done in React on the client-side, with maybe a sprinkle of backend for unavoidable things, like where API keys live. They’ll foot-gun as much backend stuff into the front end as possible. To a certain kind of backend developer, everything should be done typesafe in non-JavaScript on the backend, with a sprinkle of client-side JavaScript for unavoidable things like showing/hiding elements. Of course even for this, 10 lines of CSS is preferable to 1 line of JS. They’ll foot-gun as much client-side stuff into the back end as possible.
- karmarepellent 3y ago
  Maybe some people are using it to avoid JS at all costs. I am using it to have everything (validation, authentication) in one place, the backend. It also saves me currently four serialization and deserialization steps, which drastically improved performance. meanwhile there will also be a few 10s or 100s lines of JS to enable some specific behaviour that I do not want to (or would be awkward to) implement in HTMX. I am not saying that it is a silver bullet and people may use it for a variety of reasons, even avoid JS. I try to be less biased and make the best of both worlds. Until now, it has been pure joy.
- philipwhiuk 3y ago
  Happy full-stack React + Back-end guy here :)
dizhn 3y ago
This is not necessarily refuting what you said but perhaps a different point of view. I wrote a simple backend servive with go and wanted to have some on off switches and status icons for it. I don't know js and am not interested in learning it. Htmx gave me enough interactivity to put together that one status thing with buttons in a few hours. To me that's valuable.

smallerfish 3y ago

htmx + kotlinx.html + kotlinjs is an excellent combo that gives you an MPA that looks and feels like a modern webapp, with minimal stack complexity, and fully typesafe/compiled UI code. I'm also layering in tailwind & flowbite. With the hotswapagent project, you get hotswap that works for when you're building out UIs. One day I'll blog about this stack in more detail and post here.

sureglymop 3y ago
This sounds interesting. Would you be so kind as to explain how to set this up or link to an example? I do have experience with plain kotlin but googling yielded not many results on how to integrate all these components you mentioned into a basic MPA. So - blog post encouraged :)
- smallerfish 3y ago
  I definitely will post about it, but it's probably a blog length walkthrough :). I have an email notification form on my blog if you want to be notified when I get it done: https://smaller.fish/ https://smaller.fish/ (I promise no spam.)

Bluescreenbuddy 3y ago

"it's all javascript!?" "always has been" ᕦ(̿ ̿ -̿ ̿ )つ/̵͇̿̿/’̿’̿ ̿ ̿̿ ̿̿ ̿̿

lanecwagner 3y ago

Recently I had Carson on my podcast: https://youtu.be/9H5VK9vJ-aw?si=cv4ScxFTnJMRbsSH https://youtu.be/9H5VK9vJ-aw?si=cv4ScxFTnJMRbsSH He talked about this idea quite a bit, I love the idea of giving backend developers more control over the UI without resorting to huge JS frameworks

kopirgan 3y ago

Liked this phrase.. Explains the big picture beautifully "a system by which elements enter and exit the DOM via network request."

masfoobar 3y ago

I would refer it as a library. Like any library, it has a bunch of functions available to use. The difference, however, is that you don't use them directly. You are just writing html with htmx tags, etc.. and letting htmx, the library, do the rest. This is it for the most part - but I understand some complications could break that rule. I doubt it would be that often if at all.

nonethewiser 3y ago

Returning your data in html which is coupled to your frontend html and css sucks.

nickmonad 3y ago
Why? If the primary client is a browser, you're giving it exactly what it needs to render.

mattkevan 3y ago

I’ve had a lot of fun building an app with HTMX and Django. Makes things so much easier as I don’t need to use anything other than the standard templating system and still get an SPA-like front-end experience.

game_the0ry 3y ago

I never used or looked into htmx, but... I feel like htmx fell into the same hype-cycle as every JS framework - initial interest was enthusiastic, but will likely fade as folks use it in the real world and any holes in the things it tries to solve are exposed. On to the next, I guess... Or go back to Ruby on Rails :)

testermelon 3y ago
htmx is not a framework, or even library. it's only one implementation of an idea. an idea that needs to be implemented by the browser instead of something external like a js file.
jabradoodle 3y ago
There are simple things it would be nice to do without either 1. A server + framework, 2. A full on SPA, 3. Hand writing tedious js. There is a nice sweet spot for htmx here; whether it can build the required network effect is another story, and not always reflective of the quality of the idea.
- game_the0ry 3y ago
  Don't get me wrong - I love the idea of an open source project pushing mainstream ideas of how tech should be done, but those projects should be scrutinized and will always need to prove themselves in real world implementations. When that happens, the tech needs to evolve, be well-documented, and well-maintained. I think htmx is doing an admirable job so far.
marcosdumay 3y ago
> Or go back to Ruby on Rails When you do that, you'll see the point of htmx.
recursivedoubts 3y ago
gotta start somewhere
pastor_bob 3y ago

msolberg 3y ago

As a devops engineer who has recently been tasked with building UIs for our team and our developers, HTMX is a godsend. I create apps that often get steadily worked on for weeks and then only maintenance once and a while after that. I used to write django apps, but recently switched to a go backend with go html templates and htmx. This allows me to push everything in one docker image and avoid the black box nature of big frameworks that I don't have the time to fully understand. I know this doesn't add to the conversation very well but I just want to throw it out there that htmx is a good replacement for a larger framework that you don't fully understand. Also shoutout aplineJs for making small JS changes easy.

internet101010 3y ago
Alpine + htmx + tailwind is pretty much what I use for every quick little front-end thing now. I do still use Django but plan to transition to Rust as a way to get more comfortable with Rust.
- jslakro 3y ago
  What do you use alpine for? htmx is not enough?
  - recursivedoubts 3y ago
    Scripting is part of web development, htmx endorses hypermedia-friendly scripting: https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/ https://hypermedia.systems/client-side-scripting/ https://hypermedia.systems/client-side-scripting/
  - arcanemachiner 3y ago
    Alpine is for client-powered reactivity and HTMX is for server-powered reactivity. Think about pressing a button that opens a modal with content already delivered by the server (like a settings modal). You don't need to make a HTTP request for that, so you could use Alpine. Let's say instead that you click a user icon and you want to render a modal that contains user info which hasn't been fetched from the server (because why waste resources loading all this data the user might not see or need?). When clicking that icon, you could use HTMX to fetch the user data from the server then display the resulting content in a modal. Two different actions with similar visual results (from the user's perspective), but one is all client-side and one requires extra info from the server. Alpine and HTMX are frequently confused this way, as they solve seemingly similar problems from different ends of the network.

iterateoften 3y ago

The problem I have with this style of library for frontend dev work is eventually the scope of the problem exceeds what the library is capable of doing. Then you have to embed JS which then gets pretty messy and spaghetti code and enough of this you are right back to where you started setting up a JS build system to make up for the deficiencies. Only now it is worse because you are working around one library and you start fragmenting your app because you started with the wrong thing.

karmarepellent 3y ago
But it is not a given that the scope of the problem eventually exceeds what HTMX is capable of. It is perfectly fine to set HTMX aside and choose another framework if you feel that it better suits the problem at hand. Meanwhile there is still a ton of projects for which HTMX is more than enough (and always will be). So what you are mentioning is not an issue of HTMX, but one of "chosing the right tool for the problem".
- iterateoften 3y ago
  That’s fair. I guess my comment was inadvertently responding to another about why you don’t see it at large companies. One team at my company wanted to use HTMX and write the product with it and then the PM kept asking for features to bring it to parity with the rest of the application with regards to client side behavior and things devolved. They used hyperscript and eventually the frontend was just rewritten to be react.
  - karmarepellent 3y ago
    Well I would not dare going through the hassle of moving from React to something like HTMX if the former is already well-established in the company, except when everyone is on board. So I totally get that.

deleted 3y ago

[deleted]

toinbis 3y ago

It's surelly not "just another htmx framework" for at least one more reason - it has 100+ CEOs, way more than any other! Check them all out https://htmx.ceo https://htmx.ceo . I'm one of them. Really proud!

exabrial 3y ago

HTMX is signaling they're around for the long haul, we'll see if they break backwards compatibility or rewrite their API 15 times in the next year. I had one of my dev's do several node/js framework POCs in _September_ last 2023 (current year is Jan 2024 at the time of this writing). Nearly all of the POCs won't even run or build any more because the developers have rewritten something and broke all backwards compatibility. The Javascript/Node ecosystem is terrible for businesses and you're incinerating cash if your company running in the Node/Javascript rat race. I'm hoping HTMX injects some sanity into frontend development.

taeric 3y ago
This feels extreme? Any chance you could share numbers or more details on these prototypes? I agree that the ecosystem seems crazy fast on moving. I wouldn't have thought it was that bad. React, in particular, I thought had been fairly stable? (Yes, there are new ways of doing things, but most of the old still work there, to their credit.)
- jokethrowaway 3y ago
  I don't think it's been the case for the last few months in particular, but Next has been historically terrible for this case. It sucks because it's also the best way of developing a React app without worrying much about tons of boilerplate crap. I have different next projects started at different times and whenever I need to change a single line of text, I have a 50% chance something won't work and I'll have to debug some error coming from the intersection of different versions of node being used in the JAM host. I got hit by OpenSSL issues for a static website. Then a potential solution is to upgrade the framework (next or react) but then you start running into a bunch of other issues and you find yourself 8 hours deep for a copy change. Performance is also a pain to get right as the abstractions keep piling up and especially the rendering cycle of React is a massive pain. The move from class to functional (for the majority a net positive as the functional version is way more readable and clear) made accessing some hooks harder, so know you need to remember some special rules or functions to call in order to get the behaviour you want. For all new projects I just use solid.js which is a bit nicer compared to React while keeping most of React syntax. The abstraction layer is much smaller compared to React (no vdom, no custom rendering cycle, your function gets executed once, not once per re-render). You just have to remember you are dealing with Proxy instances and you're good to go. Somehow I didn't have problems with updates but there is way less activity compared to React. I have some projects from 3 years ago just using solid.js, and a bunch of projects with solid-start. I didn't bother updating them, they keep on running, can't complain.

tangentstorm 3y ago

> Even though you aren’t writing the 3P code yourself, by including it in your project you are committed to understanding it—and refreshing that understanding if you want to upgrade it. This is a nice thought, but I suspect hardly anyone who uses a framework or library really understands it, or makes the commitment to try. Obviously, a subset of really talented users eventually learn to understand the framework, but most are at its mercy. Even then, you can't study every possible framework before choosing one to master - there are too many, and the cost of understanding the foreign code is simply too high. So I suspect that in general, people try frameworks by taking a leap of faith, and then, sometimes, make the effort to actually understand it later - if and when it becomes necessary.

alexpetros 3y ago
The main point I'm trying to make here is that even if you're in the "leap of faith" category, you still on some level have to understand the framework constructs (i.e. its API) in order to make use of it. If that API changes with a new version, and you want to upgrade, you're going to have to learn enough about that new API to make the upgrade. Obviously you benefit from understanding the internals too, but realistically, the more complicated the thing you're using, the less of the internals even a motivated user is going to bother with.
- briantakita 3y ago
  > Obviously you benefit from understanding the internals too, but realistically, the more complicated the thing you're using, the less of the internals even a motivated user is going to bother with. This is a problem that grows with a large library...An api change has a higher cost than with a smaller library. Smaller libraries also tend to be easier to fully understand. Large libraries tend to be more of a "leap of faith" than small libraries.

hintoftime 3y ago

Reading the first part of the book [0] featuring the concepts behind hypermedia systems has helped me to really understand the goals of HTMX. I would highly recommend it even if you don't experiment with HTMX yourself. I bought it as an ebook to support the author but it is also free to read. [0] https://hypermedia.systems/ https://hypermedia.systems/

deleted 3y ago

[deleted]

recursivedoubts 3y ago

I am the author of htmx. I think htmx is a library using the following definition: - a library you call - a framework calls your code in htmx you add attributes to HTML to "call" htmx, so, from the perspective, you can call it a library. On the other hand, those "calls" are called back into via event handlers in JavaScript, so an argument can be made that, even at this level, htmx is a framework. I liked alex's analysis and I think his definitions and thinking contribute to the discussion, so I posted it to the htmx website. Even though I still consider htmx a library. :)

ncphillips 3y ago
I’m the CEO of HTMX. This is correct.
dfabulich 3y ago
The React team argued that it was "merely a view library" for years, and as far as I can tell, this was a wrong-headed approach based entirely on vibes. Libraries are cute and charming; frameworks are humongous and domineering. If you think of React and HTMX as cute and charming, and especially if you think of them as much cuter and more charming than their other "frameworky" competitors, then you'll prefer to think of your code as a library instead of a framework. Instead, I urge you to describe HTMX as a "lightweight HTML framework."
- alexpetros 3y ago
  Broadly speaking, that's basically what this article says!
- recursivedoubts 3y ago
  yep, i understand that view, but i'm going to keep calling it a library because i think it's a library, but I get it
- mhink 3y ago
  For what it's worth, the landscape of Web development was much, much different in 2014 or so. Ruby on Rails was still a huge player, and most major OSS projects meant to enable Web development took a lot of cues from it. Projects like Angular, Ember.JS, and Backbone (and for that matter, Rails' own Turbolinks system) very much expected you to build your entire application in them from the get-go. The gist of React saying "this is a view library" at that point was largely about what you should expect React not to do for you. For example, two-way data binding, where the framework managed a fetch lifecycle as well as plugging the result into a view. "React is a view library" was letting devs know that they shouldn't expect React to do this- they should expect to make calls themselves and re-render the view accordingly. I actually think it's still fair to say that React *itself* is still "just a view library", but that's sorta like saying Linux is "just a kernel". Sure, it's technically true, but at this point when we're talking about React we're talking about the whole ecosystem surrounding it as well. That wasn't the case 10 years ago (damn, has it really been that long?)

karmarepellent 3y ago

As every discussion about HTMX usually evolves to people arguing why it is not widely adopted by big corporations and the like, let me be the first to share a thought on that topic. Could it just be an organizational problem? When you start using HTMX in your company your neat distinction between frontend and backend devs collapses and everyone suddenly must be a full-stack developer. When you can avoid that additional cost by simply continuing to use React (or others), why wouldn't you? Edit: As a side note, I have never used any large JS framework, only HTMX. Just trying to put myself in the shoes of happy React users and such.

troupo 3y ago
I'm a fullstack developer in the widest sense of the world: I worked exclusively on the backend side, and exclusively on the frontend side, and on both at the same time. I wouldn't touch HTMX with a ten-foot pole :) It's a somewhat haphazardly defined DSL around magical attributes, their values, and awkward workarounds with somewhat badly specified behaviours (what's `hx-select-oob` exactly?). There are other projects that do these things better, with less pretentiousness: Phoenix Liveview or Laravel LiveWire, or even Hotwire
- recursivedoubts 3y ago
  all of those projects are much more magical, particularly the live* flavor of hypermedia driven applications htmx generalizes the standard hypermedia controls found in HTML: anchors & forms this makes it more work to implement some things, but sticks closer to the basic ideas of HTML and, as always, if nothing magically works, nothing magically breaks
  - troupo 3y ago
    > all of those projects are much more magical, Oh, they are not. They are more powerful, but they use rather simple concepts. Speaking as the user of Phoenix LiveView who even created his own templating library to work with it. > htmx generalizes the standard hypermedia controls found in HTML: anchors & forms Those are not "hypermedia controls". As I said elsewhere: stop appropriating concepts for your benefit. > the basic ideas of HTML The "basic idea of HTML" is "render a text page with a few images in one rendering pass with links to other such documents". That is it. You are perhaps referring to the hypertext vision of Sir Tim Berners-Lee, but that is as far removed from HTMX as HTMX is removed from any other concepts it keeps trying to appropriate. HTMX is a utility lib with a few diffing utilities that does what nearly every other library does, but chose the high ground of "we're doing it with HTML chunks, so we're better and this is what the founders envisioned". You're not better. This is not what founders envisioned.

pphysch 3y ago

How do HTMX users manage the complexity of endpoint dependency graphs? Once you go from simple route->page mapping to heavy HTMX usage, you now have routes that are implicitly dependent on other routes to work properly. "/users/42/" relies on hx-post="/users/42/send-email", and so on. Are there ways to model that dependency graph outside of your brain, say an IDE plugin.

mxey 3y ago
You might like https://htmx.org/extensions/path-deps/ https://htmx.org/extensions/path-deps/

arrakeen 3y ago

in a world where XHTML 2 was widely adopted, would HTMX have been necessary? it seems like it was the (failed) attempt at evolving the hypermedia aspects of HTML

ndyg 3y ago

> As they should! Building with htmx works a lot better if you play to its strengths. You can send JSON-formatted form bodies, if you really insist. But you shouldn’t! This excellent essay overlooked a '*': * unless you are using bash + jq for your backend, in which case, JSON-formatted form bodies are quite reasonable.

alexpetros 3y ago
Author here. Happy to admit that bash + jq backends are an excellent reason to use JSON formatted bodies. Godspeed you crazy animal.

davexunit 3y ago

I like the basic idea of htmx: respond to user input by making server requests that return new html for a subset of the page. However, I think there's a pretty significant language design problem and htmx's solution is language proliferation. There is a very low "expressivity ceiling" for what can be encoded into html attributes. The hx-trigger attribute defines a new, very limited domain specific programming language for expressing side-effects with few means of combination or abstraction. For anything slightly complicated, hyperscript seems to be the favored solution which is yet another new language. All of this caused by trying to shove logic into attribute strings.

alexpetros 3y ago
This is correct, but... logic belongs in attribute strings! Even in basic HTML, it can change what kind of HTTP request your <form> makes, or what kind of value your <input> sends, or where your <a> link goes. Without question, there's a lower expressivity ceiling to attribute-based specifications, but there is a lot that you can do within that ceiling, and you benefit in other ways by keeping your application at that "level," so to speak. [0] [0] https://unplannedobsolescence.com/blog/custom-html-has-levels/ https://unplannedobsolescence.com/blog/custom-html-has-level...
- davexunit 3y ago
  I think this is a bit of reductionist interpretation of what I'm saying. Yes, it's technically correct that the attributes on a form change the type request made. That's not really what I'm talking about, though. In the same way that I wouldn't want to manually type a lot of CSS into a style attribute, I wouldn't want to write a small program in an hx-trigger attribute. Something like hx-trigger="input changed delay:500ms, search" is getting rather complicated, imo, and it's a new DSL with new semantics to understand. And then the recommended escape hatch is... yet another new language? I dunno I just feel like there's something missing here.
  - alexpetros 3y ago
    I somewhat agree with you but I think it's important to clarify whether you're talking about htmx or the hx-trigger syntax specifically. In the parent comment you say: > However, I think there's a pretty significant language design problem and htmx's solution is language proliferation. There is a very low "expressivity ceiling" for what can be encoded into html attributes. And then here you say: > In the same way that I wouldn't want to manually type a lot of CSS into a style attribute, I wouldn't want to write a small program in an hx-trigger attribute. Something like hx-trigger="input changed delay:500ms, search" is getting rather complicated I wouldn't write a small program in the hx-trigger syntax either (although, we not only have users who do that, but have contributed to hx-trigger optimizations because they use it so heavily). Many htmx use cases don't need this at all, some need complexity up to this point, some need far more complexity. It's really up to you to decide at what point you bring in the bigger guns—whether that's hx-trigger, alpineJS, hyperscript, or a React Island. I agree that hx-trigger is a DSL, and represents the outer limits of htmx's expressivity. My objection is to the argument that htmx's attribute design is an expressivity problem, rather than a well-chosen level of abstraction for the types of problems htmx is best suited to solve (see the sibling comment about Rule of Least Power too).

deleted 3y ago

[deleted]

tiddybittyes 3y ago

Before the JS hipsters arrived on the scene attempting to implement Java on the web again. There was and still is nothing wrong with full page refreshes and javascript augmentation per page. HTMX is an aim to get back to that and Web Components are looking good as well.

toastercat 3y ago

My biggest beef with htmx has more to do with the fact that it gets hyped as a React/Vue/Svelte alternative, when it's more accurate to describe htmx+<backend of your choice> as an alternative. Also the constant use of pretentious memes on the official blog. But otherwise, I'm looking forward to trying it out for my next pet project.

philipwhiuk 3y ago
> htmx+<backend of your choice> You can use React with any backend.
- toastercat 3y ago
  My point is that htmx is not for SPAs. You need something like Alpine.js. A React app can live entirely in an .html file.

zubairq 3y ago

I have heard so much about HTMX but never really “got” the essence of it. This finally brought me a bit closer, thanks!

vlugovsky 3y ago

It's definitely not "just another." I believe this term implies that the framework would follow current trends, such as Components, Templates, etc. HTMX is different and incorporates some old JSF-like ideas, which makes it feel fresh for some developers, especially those who don't really want to learn React, Angular, Vue, and others.

robertoandred 3y ago

> htmx is for writing HTML This is false. All of those proprietary custom attributes mean it's for writing htmx, not HTML. If anything, JSX is closer to HTML and htmx is.

philipwhiuk 3y ago

It infests the 'rest' of your code. It's a framework.

theultdev 3y ago

There's just little benefit in HTMX unless you have a live financial dashboard or something like that. I find the opposite approach of local-first (database in the client). It fits more solutions and solves many more things (free offline, syncing, undo support) and getting rid of caching, retries, and latency. Of course the industry wants you to want more on the server though. Same view applies to RSC (react server components). Embrace CRDTs.

recursivedoubts 3y ago
oh, i dunno, seems like the internet has been somewhat successful as a distributed system, but ymmv
- theultdev 3y ago
  centralizing would be using HTMX and authoritative servers. local-first is more decentralized as your clients can sync directly with each other (or through a dumb proxy for NAT punching) I see no need for servers to be anything but dumb proxies for clients. Not the opposite of making clients dumb terminals.
  - recursivedoubts 3y ago
    welp, when you are coordinating things it's often a tremendous simplification to have a centralized source of truth and then present representations of that truth in the form of hypermedia to hypermedia clients, using hypermedia as the engine of application state of course, it's not right for everything and there are alternative approaches that work better or worse, depending on context, but i'd say it's hard to not call it a pretty successful approach to distributed systems
    - theultdev 3y ago
      a centralized source of truth is a pretty successful approach to distributed systems? seems more like a successful escape hatch. yes it's simpler, but it's antithetical to the goal.

proc0 3y ago

XML is a pain, and I'm including JSX in this. Writing open/close tags, and then using wakas (<, >) everywhere seems unnecessary and creates ugly files. I feel the DOM should also expose other languages to interface with and browsers should detect that. Imagine web apps written with python and YAML for templates (on the client side, without transpiling).

sebastianconcpt 3y ago

I've recently adopted htmx from a Smalltalk backend and feels lovely. When coding to do that it felt like a library and not a framework and provides a lot of flexibility in design options. And I agree that the backend should do as much HTML as possible but some times you still need to do things with js. Bu again the backend can send the html plus the bits of js specific for that UI screen or component and that's super flexible and efficient if you keep it properly factored and with nice separation of concerns. Here is a talk where I've made the case for a particular stack and demoed it last November in the Smalltalks 2023 conference https://www.youtube.com/watch?v=4_gmvN0pimI https://www.youtube.com/watch?v=4_gmvN0pimI

mlhpdx 3y ago

As a humble, new user of HTMX I don’t care what noun you choose for it (stereotyping by another word still smells the same). The facts as I have experienced them are a) it’s simple to do simple things; and b) it keeps difficult things possible. My highest praise. So, I’m using it. I’m a bit of a nut, and my backend is pure AWS Step Functions. Declarative web app, all the way down. Yes, because of HTMX the backend is different than it would be with “plain” HTML or the JS framework du jour. But, the backend is very simple and clean, so I agree it has a nice influence whatever y’all decide to call it.

bilalq 3y ago
What do you write your step functions in? Are you using ASL or something that compiles to it?
- mlhpdx 3y ago
  Straight ASL.

lakomen 3y ago

Htmx = pointless hype. It solves no problems and makes everything more complicated. You have to learn not 1 but 2 new "languages" hypermedia queries and htmx special html attributes. And what do you receive in return? Nothing that can't be done with other JS frameworks or libraries. Yes, htmx is JS. That HN people fall for this trick is no surprise as it's frequented mostly by booksmart idiots.

ralmidani 3y ago

There is a spectre haunting SPA frameworks… It’s a shame htmx wasn’t invented 10 years ago, but it makes sense that it’s bursting onto the scene now as a reaction to end-stage SPA mania. If htmx-like functionality gets rolled into browsers with native optimizations (i.e. faster than the Virtual DOMs and custom JS runtimes of SPA frameworks, not to mention the no-build-step benefits we’re already seeing with htmx), then it hopefully won’t be just htmx that will get rendered obsolete; Angular, Ember, React, Svelte, Vue, etc. need to go even more urgently. Pardon my enthusiasm, I really am looking forward to an HTML Renaissance.

andrewstuart 3y ago

I'm a React developer, pretty happy with it. What is the core thing(s) I should be appreciating about HTMx?

wutwutwat 3y ago

Don't know anything about htmx, just popping in to see if anyone else remembers "dhtml", and "dhtml guru". A different time. A different internet. htmx triggered that random memory, and then a flood of others, like: the gold rush of people, sometimes kids, renting servers or colocating space, installing cpanel, and starting a shared hosting company dreamhost, remember dreamhost? vps hosting providers that offered emulated systems, before public cloud was a thing, before vmware or hypervisor OSs, before kvm, or virtualization in general webmin/virtualmin (which is still going strong it seems) turnkeylinux (which is also still going strong) linux from scratch macromedia betaarchive.com Chris Pirillo

guru4consulting 3y ago

My product has the typical SPA front-end and API backend. I understand that with HTMX, those API backends would have to return HTML fragments instead of JSON data (or another server endpoint that returns HTML fragments). I have few questions with this HTMX approach: - We don't hire full-stack developers. Our UI/UX designers and web developers fully focus on the front-end (responsive for mobile/tablet/desktop, A/B testing, quick iterations of UI/UX enhancements) without bothering about the backend. The backend API developers focus on API returning the right data and don't care about UI. I like this separation as it helps to really iterate the UI/UX faster. With HTMX, those backend devs will now have to worry about returning the correct HTML fragment based on the client device, position of the HTML div, etc. The presentation concerns spill over to backend developer and we are back to the days of server-side templates like JSP/ASP/RoR/PHP/Django. Anyone else sees issue with this approach? - React/similar web apps can handle quite complex UI with multiple flows and navigations. I assume HTMX is probably not suited for complex UIs. Is that right? has anyone built any complex UI with HTMX?

recursivedoubts 3y ago
If the FE/BE split is working well for you, then htmx isn't as compelling. It is more compelling when you have full-stack developers who can take ownership of entire features and shepherd them from start to finish, without needing to coordinate with another team to get the data/functionality they need. Here is an example of a fairly sophisticated application that was written in react, then moved to htmx with good results: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ As far as what you can achieve with htmx, I outline when hypermedia (the more general concept behind htmx) is a good choice or a bad choice here: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ You can get an idea of the basic level of interactivity you can achieve with htmx by looking at the examples: https://htmx.org/examples/ https://htmx.org/examples/ all of which compose well together. You can get more dynamic than that if you are willing to do client-side scripting (https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/) another essay that might be of interest, regarding your APIs: https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/ and, if you want a complete introduction and overview of the hypermedia approach, we have a book available online for free: https://hypermedia.systems https://hypermedia.systems

EGreg 3y ago

This is how we do it in our framework, which we started in 2011 and have been using continuously and improving until now: https://qbix.com/platform/guide/tools https://qbix.com/platform/guide/tools We define "tools" to add/remove behavior to/from existing elements. The tools are added by an HTML5-compliant microformat. For example: <div class="Q_tool Q_columns_tool"> <form class="Q_tool Q_form_tool"> </form> </div> Tools can contain other tools, and you can specify them when you attach event handlers, for example, so the handlers get removed when the tool gets removed, e.g. when its container tool is removed: event.set(handler, tool); // no need to remove it later As a more complex example, here we have a chatroom, which has extensions like calling people and mentioning people: <div class='Q_tool Streams_chat_tool Streams_mentions_chat tool Media_call_chat_tool any_normal_classes_too' data-streams-chat='{" publisherId": "abcjwuqk", "streamName": "..." }' data-media-call-chat='{ "livestream": { "private": true, "max": 3 } }' some-other-attributes="" > elements may be empty or have some existing content </div> And we also support Handlebars helpers: <ul> {{#each list}} <li>{{tool "Streams/chat" publisherId="abc" streamName="..."}}</li> {{/each}} </ul> Finally, we can also activate them dynamically via Javascript: Q.Tool.prepare(someElement, "Streams/chat", options); or div = Q.Tool.prepare('div', "Streams/chat", options); Then we just call Q.activate(container) which traverses the container and activates all tools inside it. At any point in the console you can type Q.Tool.active and it will show you all active tools. You can see it in action for example at https://intercoin.app https://intercoin.app PS: I used to originally call it the "Q" Framework but because of people on HN constantly complaining that it was conflicting with the "excellent Q library for promises", I finally relented and called it "Qbix Platform"... now the Q library for promises is obsolete but we still call it Qbix... so maybe it's better for SEO though? https://news.ycombinator.com/item?id=6053211 https://news.ycombinator.com/item?id=6053211

sublinear 3y ago

yes

thomas-guettler 3y ago

We are ugly, but we have the music