8 ms·

Great news. I have had good success and a rewarding experience using htmx the past year. It has been so great in tandem with Clojure using hiccup for SSR. Onc

Great news. I have had good success and a rewarding experience using htmx the past year. It has been so great in tandem with Clojure using hiccup for SSR. Once htmx clicks for you, you are almost left stunned by how simple and flexible it is. You can't believe that this isn't how HTML evolved to as a hypermedia. It becomes very obvious that this is how web development should have evolved. I hope someday that what htmx is doing through javascript becomes baked right into HTML and the browser clients. If you are mistakenly believing it is just some derivative of Angular or you are not grasping the significance of its advancement of the architecture of hypermedia, please do yourself a favor and read the excellent essays on their site; you will then truly understand what REST is and what the importance of real HATEOAS means: https://htmx.org/essays/ https://htmx.org/essays/ They also have a free book here: https://hypermedia.systems/ https://hypermedia.systems/ We made a costly wrong turn 10 -15 years ago by attempting to rebuild thick clients on the web with a JSON API architecture instead of expanding and enriching the new and powerful idea of the early web: hypermedia.

afavour 3y ago
> It becomes very obvious that this is how web development should have evolved. I have to disagree with that. I’m happy htmx exists and that it works for many but in my professional life I've found few cases where it's the best choice. And that’s fine! It’s a wonderful thing that the web has been able to grow in so many diverse ways, there should be no one way it “should have evolved”. IMO this is the biggest mistake in web dev in the last decade or so: that there should be One Right Way. No matter if you’re making the next Gmail or if you’re making a static blog the cargo cult of an industry tells you it should all be done the same way when common sense would tell you that’s not the case at all.
- silver-arrow 3y ago
  That's fair. I agree - that type of blanket statement is not helpful in the technical realm. I should have kept it at just: HTML should have continued to be expanded into what htmx is doing.
  - Spivak 3y ago
    I would have love to see rather than JS evolving to include HTML and CSS, HTML should have evolved to include JS and CSS as more first-class. Being able to write components in a single HTML file would be wonderful.
    - grncdr 3y ago
      I've mentioned it here on HN before, but I've been using https://jhuddle.github.io/ponys/ https://jhuddle.github.io/ponys/ for this and I still think it's pretty great.
      - Spivak 3y ago
        Woah woah woah. This is a game changer.
- giraffe_lady 3y ago
  I'm kind of guessing / reading into their comment here but. Using htmx doesn't give me the feeling of "this is the only way I ever want to do this" but more "if html worked like this I wouldn't use js most of the time." The sense that an opportunity was missed and now we're paying for it in complexity.
  - gochi 3y ago
    The complexity is just shifted around from JS to HTMX (or hypothetically, html). Not a noticeable improvement.
    - giraffe_lady 3y ago
      For many basic & routine web page interactions, I have not found that to be true.
      - gochi 3y ago
        I can only see that experience being true if you've never used jquery (aka the same shorthands you're relying on within htmx and likely hyperscript).
        giraffe_lady 3y ago
        My frontend experience predates the rise of react etc. I have used jquery. The advantage of htmx over jquery is declaring the replace condition & behavior inline as part of the component. Conceptually this is easy to reckon with as a separation of concerns thing as well as a sandi metz-ish "when would this code need to be changed" thing. The html tag is responsible for its own update, and so its update is part of the html tag. Jquery does the same things but requires you to declare the behavior separately from the component, decide on & maintain abstractions and reuse patterns. And manage code organization so that for any updatable template code you can find the corresponding behavior declarations and understand their scope w/r/t other template code.
        3y ago
- dgb23 3y ago
  I fully agree with you. I'm a fan of htmx, can recommend it and have used it in some projects by now. But... For one, htmx is not a full solution to avoid JS. It's excellent for the parts that are AJAX/CRUD, which certainly covers a lot of ground. You still need something more if you're doing stuff that doesn't fit here like interactive visualizations and many other use cases. However, it integrates very well with other lightweight libraries. Secondly, htmx is great if you're developing full-stack (like GP). Meaning you touch every part of a site from the data model to coordinating messages to the frontend etc. If you want a much clearer separation between frontend and backend of a site, especially in terms of contributors/teams, then it might not be the right tool. IMO there are plenty of good reasons to do either. Third, and this is a bit of a combination of the first two points, if you directly fetch data from a third party, say a JSON API, then htmx doesn't help you at all. So really as you said, there is no one right way. For me it has been working very well though. People should look into it for sure though. There's an opportunity to combine htmx with orthogonal libraries that do the dynamic parts like lit etc.
  - charukiewicz 3y ago
    > If you want a much clearer separation between frontend and backend of a site, especially in terms of contributors/teams, then it might not be the right tool. The point to take away from htmx and hypermedia more broadly is that there isn't a clean separation between the front end and back end of a site. The concept of completely separate front and back end teams building SPAs/JSON APIs has been a very costly development that has brought substantial complexity that is wholly unnecessary for most applications. Your banking/project management/todo list/budgeting/insurance/education/whatever app almost certainly doesn't need to be an SPA and would be developed faster or for less money if it leaned into server side rendering (SSR) and used a library like htmx or Stimulus to enhance the user experience as needed.
0xParlay 3y ago
[flagged]
- aCoreyJ 3y ago
  You don't do your conspiracy theory any favors by making absurd blanket statements
- taffer 3y ago
  Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
andsoitis 3y ago
> I have had good success and a rewarding experience using htmx the past year. It has been so great in tandem with Clojure using hiccup for SSR. What kind of app are you working on?
ksec 3y ago
>You can't believe that this isn't how HTML evolved to as a hypermedia. That is why I wish HTMX to be merged into HTML5 spec. For something like 98%+ of the web it will be good enough. You then have a small JS library for the other 1.9%. The 0.1% left is just pure JS Web Apps.
- recursivedoubts 3y ago
  i very much hope that htmx serves as inspiration for future HTML releases, I agree that this ideally should be part of the HTML infrastructure
uxns 3y ago
Out of curiosity, I presume you were working on the frontend part using Clojurescript? Have you used some kind of wrappers around htmx or just a simple js interop was enough?
- silver-arrow 3y ago
  We moved away from ClojureScript entirely. We just run a plain ole java uberjar with the Clojure/ring/hiccup/Compojure spitting out the HTML with whatever htmx attributes and response headers we need. There are instances where we may need to sprinkle in some javascript for some extra dynamic things - which turns out to be very infrequent. Instead of sprinkling in the javascript, we have been using _hyperscript instead - love _hyperscript. Yeah, so moving to htmx has allowed us to jettison ClojureScript which just entailed too many parts. As a matter of fact, before going more htmx with our projects, we had moved away from ClojureScript to React directly.
PaulHoule 3y ago
I am happy with HTMX for my RSS reader. The issue with front end apps is, and always has been, the complexity of updating the UI after a user makes a change. For instance, inside an HTMX application, I just coded up a plain ordinary <script> (no framework, no build system) that displays a count of how many characters are in a text field and also disables or enables a submit button according to that size. It's 9 lines of code plus an attribute on the input. It might be less if I did it in https://hyperscript.org/ https://hyperscript.org/ Immediately it faces the problem that there are two paths: (1) the initial setting of the length display (the field is pre-populated with text, I ended up setting it in the SSR) and (2) what happens when the text content changes. If you use signals or hooks or useEvent or lifecycle methods or whatever you always see a certain amount of awkwardness that stems from the above. Note I could have done the above with "pure HTMX" in that I could have had the event handler trigger a server round trip that repaints the text field and the submit button, it wouldn't be as bad as it sounds in performance, but boy it seems like a waste. I've built applications that were a lot like Figma, Photoshop, or Eclipse, where the user could update some data and it could have very arbitrary effects on the UI because the user is able to add and remove many different UI elements and in a case like that you need some system that can manage dependencies at runtime. React has revolutionized how people build widget-based frameworks, there is never going to be anything like Tk, Cocoa, GTK, WPF, Spring, JavaFX ever again, or if it is it is going to be influenced by React. There's the awkward fact that React is overkill for the typical form processing and e-Publishing applications people write with it but it is not up to the task (without an additional state management frameworm) of applications like Figma. Personally I'd like to see a mostly declarative form processing framework with a sprinkle of scripting: before there was the iPhone there was WAP https://en.wikipedia.org/wiki/Wireless_Application_Protocol https://en.wikipedia.org/wiki/Wireless_Application_Protocol which had a way to send multipart forms to the client. Something like that designed to work with a software factory https://www.amazon.com/Software-Factories-Assembling-Applications-Frameworks/dp/0471202843 https://www.amazon.com/Software-Factories-Assembling-Applica... (one of the most visionary books of all time... the authors built an enterprise software development framework for Microsoft that was nowhere near as cool as their vision) or a "no-code" app builder could be great. I'm still trying to get my head around websockets. I've built some small demos that are awesome, like a program that controls the volume of my smart speakers and has the sliders move when I change the volume with the remote control. I really wish my RSS reader could update my "favorites" window as soon as I add a favorite in another window, but doing that efficiently requires answering questions all the way from the front end to the back end to the database. I'll probably find a half-baked way to do it but it's sad that I'm settling on a web application to have the limitations web applications had 15 years ago.
sesm 3y ago
What are technical differences between HTMX and early versions of Angular 1? It has the same idea of sprinkling some attributes over HTML to make it dynamic for easy cases. There were many frameworks that started like this (Angular 1, Vue, etc), and after getting some traction they grew into full-blown SPA frameworks, because there is a real need for more difficult cases. If I had to pick an “Angular-1-like” framework, I would pick the one that clearly documents it’s boundaries and provides a clear way to use a mature SPA framework when there is a need to cross those boundaries. If anyone is aware of such framework, please share.
- recursivedoubts 3y ago
  htmx uses hypermedia, rather than client-side managed state as much as possible, htmx tries to take HTML to its logical conclusion (from my perspective) as a hypermedia, rather than imposing other ideas on top of it
  - sesm 3y ago
    Does this ideology lead to significant technical differences from early versions of Angular 1 and early versions of Vue?
    - sesm 3y ago
      Ok, I see, the idea is to render parts of the page on server and swap those parts on the client with things like: https://htmx.org/attributes/hx-swap/ https://htmx.org/attributes/hx-swap/ So it's not really an "Angular-1-like", but more like Vaadin in JS.
  - criddell 3y ago
    You keep using the term hypermedia and I'm not certain what is meant by that term (I was thinking it referred to linked media). Hyper means over, right? So is hypermedia more about the environment media is in than it is about links?
    - 3y ago

afavour 3y ago

> It becomes very obvious that this is how web development should have evolved. I have to disagree with that. I’m happy htmx exists and that it works for many but in my professional life I've found few cases where it's the best choice. And that’s fine! It’s a wonderful thing that the web has been able to grow in so many diverse ways, there should be no one way it “should have evolved”. IMO this is the biggest mistake in web dev in the last decade or so: that there should be One Right Way. No matter if you’re making the next Gmail or if you’re making a static blog the cargo cult of an industry tells you it should all be done the same way when common sense would tell you that’s not the case at all.

silver-arrow 3y ago
That's fair. I agree - that type of blanket statement is not helpful in the technical realm. I should have kept it at just: HTML should have continued to be expanded into what htmx is doing.
- Spivak 3y ago
  I would have love to see rather than JS evolving to include HTML and CSS, HTML should have evolved to include JS and CSS as more first-class. Being able to write components in a single HTML file would be wonderful.
  - grncdr 3y ago
    I've mentioned it here on HN before, but I've been using https://jhuddle.github.io/ponys/ https://jhuddle.github.io/ponys/ for this and I still think it's pretty great.
    - Spivak 3y ago
      Woah woah woah. This is a game changer.
giraffe_lady 3y ago
I'm kind of guessing / reading into their comment here but. Using htmx doesn't give me the feeling of "this is the only way I ever want to do this" but more "if html worked like this I wouldn't use js most of the time." The sense that an opportunity was missed and now we're paying for it in complexity.
- gochi 3y ago
  The complexity is just shifted around from JS to HTMX (or hypothetically, html). Not a noticeable improvement.
  - giraffe_lady 3y ago
    For many basic & routine web page interactions, I have not found that to be true.
    - gochi 3y ago
      I can only see that experience being true if you've never used jquery (aka the same shorthands you're relying on within htmx and likely hyperscript).
      - giraffe_lady 3y ago
        My frontend experience predates the rise of react etc. I have used jquery. The advantage of htmx over jquery is declaring the replace condition & behavior inline as part of the component. Conceptually this is easy to reckon with as a separation of concerns thing as well as a sandi metz-ish "when would this code need to be changed" thing. The html tag is responsible for its own update, and so its update is part of the html tag. Jquery does the same things but requires you to declare the behavior separately from the component, decide on & maintain abstractions and reuse patterns. And manage code organization so that for any updatable template code you can find the corresponding behavior declarations and understand their scope w/r/t other template code.
        3y ago
dgb23 3y ago
I fully agree with you. I'm a fan of htmx, can recommend it and have used it in some projects by now. But... For one, htmx is not a full solution to avoid JS. It's excellent for the parts that are AJAX/CRUD, which certainly covers a lot of ground. You still need something more if you're doing stuff that doesn't fit here like interactive visualizations and many other use cases. However, it integrates very well with other lightweight libraries. Secondly, htmx is great if you're developing full-stack (like GP). Meaning you touch every part of a site from the data model to coordinating messages to the frontend etc. If you want a much clearer separation between frontend and backend of a site, especially in terms of contributors/teams, then it might not be the right tool. IMO there are plenty of good reasons to do either. Third, and this is a bit of a combination of the first two points, if you directly fetch data from a third party, say a JSON API, then htmx doesn't help you at all. So really as you said, there is no one right way. For me it has been working very well though. People should look into it for sure though. There's an opportunity to combine htmx with orthogonal libraries that do the dynamic parts like lit etc.
- charukiewicz 3y ago
  > If you want a much clearer separation between frontend and backend of a site, especially in terms of contributors/teams, then it might not be the right tool. The point to take away from htmx and hypermedia more broadly is that there isn't a clean separation between the front end and back end of a site. The concept of completely separate front and back end teams building SPAs/JSON APIs has been a very costly development that has brought substantial complexity that is wholly unnecessary for most applications. Your banking/project management/todo list/budgeting/insurance/education/whatever app almost certainly doesn't need to be an SPA and would be developed faster or for less money if it leaned into server side rendering (SSR) and used a library like htmx or Stimulus to enhance the user experience as needed.

0xParlay 3y ago

[flagged]

aCoreyJ 3y ago
You don't do your conspiracy theory any favors by making absurd blanket statements
taffer 3y ago
Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

andsoitis 3y ago

> I have had good success and a rewarding experience using htmx the past year. It has been so great in tandem with Clojure using hiccup for SSR. What kind of app are you working on?

ksec 3y ago

>You can't believe that this isn't how HTML evolved to as a hypermedia. That is why I wish HTMX to be merged into HTML5 spec. For something like 98%+ of the web it will be good enough. You then have a small JS library for the other 1.9%. The 0.1% left is just pure JS Web Apps.

recursivedoubts 3y ago
i very much hope that htmx serves as inspiration for future HTML releases, I agree that this ideally should be part of the HTML infrastructure

uxns 3y ago

Out of curiosity, I presume you were working on the frontend part using Clojurescript? Have you used some kind of wrappers around htmx or just a simple js interop was enough?

silver-arrow 3y ago
We moved away from ClojureScript entirely. We just run a plain ole java uberjar with the Clojure/ring/hiccup/Compojure spitting out the HTML with whatever htmx attributes and response headers we need. There are instances where we may need to sprinkle in some javascript for some extra dynamic things - which turns out to be very infrequent. Instead of sprinkling in the javascript, we have been using _hyperscript instead - love _hyperscript. Yeah, so moving to htmx has allowed us to jettison ClojureScript which just entailed too many parts. As a matter of fact, before going more htmx with our projects, we had moved away from ClojureScript to React directly.

PaulHoule 3y ago

I am happy with HTMX for my RSS reader. The issue with front end apps is, and always has been, the complexity of updating the UI after a user makes a change. For instance, inside an HTMX application, I just coded up a plain ordinary <script> (no framework, no build system) that displays a count of how many characters are in a text field and also disables or enables a submit button according to that size. It's 9 lines of code plus an attribute on the input. It might be less if I did it in https://hyperscript.org/ https://hyperscript.org/ Immediately it faces the problem that there are two paths: (1) the initial setting of the length display (the field is pre-populated with text, I ended up setting it in the SSR) and (2) what happens when the text content changes. If you use signals or hooks or useEvent or lifecycle methods or whatever you always see a certain amount of awkwardness that stems from the above. Note I could have done the above with "pure HTMX" in that I could have had the event handler trigger a server round trip that repaints the text field and the submit button, it wouldn't be as bad as it sounds in performance, but boy it seems like a waste. I've built applications that were a lot like Figma, Photoshop, or Eclipse, where the user could update some data and it could have very arbitrary effects on the UI because the user is able to add and remove many different UI elements and in a case like that you need some system that can manage dependencies at runtime. React has revolutionized how people build widget-based frameworks, there is never going to be anything like Tk, Cocoa, GTK, WPF, Spring, JavaFX ever again, or if it is it is going to be influenced by React. There's the awkward fact that React is overkill for the typical form processing and e-Publishing applications people write with it but it is not up to the task (without an additional state management frameworm) of applications like Figma. Personally I'd like to see a mostly declarative form processing framework with a sprinkle of scripting: before there was the iPhone there was WAP https://en.wikipedia.org/wiki/Wireless_Application_Protocol https://en.wikipedia.org/wiki/Wireless_Application_Protocol which had a way to send multipart forms to the client. Something like that designed to work with a software factory https://www.amazon.com/Software-Factories-Assembling-Applications-Frameworks/dp/0471202843 https://www.amazon.com/Software-Factories-Assembling-Applica... (one of the most visionary books of all time... the authors built an enterprise software development framework for Microsoft that was nowhere near as cool as their vision) or a "no-code" app builder could be great. I'm still trying to get my head around websockets. I've built some small demos that are awesome, like a program that controls the volume of my smart speakers and has the sliders move when I change the volume with the remote control. I really wish my RSS reader could update my "favorites" window as soon as I add a favorite in another window, but doing that efficiently requires answering questions all the way from the front end to the back end to the database. I'll probably find a half-baked way to do it but it's sad that I'm settling on a web application to have the limitations web applications had 15 years ago.

sesm 3y ago

What are technical differences between HTMX and early versions of Angular 1? It has the same idea of sprinkling some attributes over HTML to make it dynamic for easy cases. There were many frameworks that started like this (Angular 1, Vue, etc), and after getting some traction they grew into full-blown SPA frameworks, because there is a real need for more difficult cases. If I had to pick an “Angular-1-like” framework, I would pick the one that clearly documents it’s boundaries and provides a clear way to use a mature SPA framework when there is a need to cross those boundaries. If anyone is aware of such framework, please share.

recursivedoubts 3y ago
htmx uses hypermedia, rather than client-side managed state as much as possible, htmx tries to take HTML to its logical conclusion (from my perspective) as a hypermedia, rather than imposing other ideas on top of it
- sesm 3y ago
  Does this ideology lead to significant technical differences from early versions of Angular 1 and early versions of Vue?
  - sesm 3y ago
    Ok, I see, the idea is to render parts of the page on server and swap those parts on the client with things like: https://htmx.org/attributes/hx-swap/ https://htmx.org/attributes/hx-swap/ So it's not really an "Angular-1-like", but more like Vaadin in JS.
- criddell 3y ago
  You keep using the term hypermedia and I'm not certain what is meant by that term (I was thinking it referred to linked media). Hyper means over, right? So is hypermedia more about the environment media is in than it is about links?
  - 3y ago