4 ms·

> 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

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

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.