6 ms·

http://htmx.org http://htmx.org + whatever backend you like best

ASalazarMX 5y ago
Wait, this looks and feels like a very pragmatic way of making modern websites. How has this not become more popular? What are its cons?
- mamcx 5y ago
  > What are its cons? Is very pragmatic. That means your whole investment in the arcane ways of JS are dust. Not hipster at all. --- More seriously, Is of little issues here. You setup and it works, so is not something that lead to "generate content" like other setups. I found only a significant issue (to me) (https://github.com/bigskysoftware/htmx/issues/596 https://github.com/bigskysoftware/htmx/issues/596) but then I do something that have never done in long time with a JS library: I poke into the source and fix it myself. Far easier than expected! (ie: The code is plain!)
- boyter 5y ago
  You return HTML from your "api" endpoint's is the biggest opposition I have found. Can mean additional work when you do want to switch to JSON, as the endpoints end up not being very reusable. I quite like HTMX myself, although I consider it a tool you use to enhance websites and not something you use to build full blown web apps.
  - deniz-a 5y ago
    You don't return HTML from API endpoints, you return it from your UI endpoints. You could reuse those for JSON with content negotiation, or have a frontend server+backend server setup where the backend server is also a public API, or some other solution.
    - boyter 5y ago
      Semantics over the name aside, you end up returning small chunks of HTML from newly defined routes that are only useful for your HTMX frontend, hence my usage of API as the interface really only makes sense to the machine and not the user without the rest of the page content. Yes you could inspect the headers and such to determine what type to return, but the core problem remains, that the HTML in those is not reusable whereas as JSON would be. How much overhead this is for you depends on your design of course, but it does mean some work might potentially be wasted if you go down the full SPA application later and even if not changing layouts and such might be a pain.
      - recursivedoubts 5y ago
        essay related: https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/
        animesh 5y ago
        Thanks for HTMX and your essays. Today I was reading HTMX documentation on what to do when we design API-first for a particular project but don't want any of the frontend magic aka SPA. I found immediately that I need to use both json_enc and client-side-templates extensions. Hope I am on the right path.
        recursivedoubts 5y ago
        hi animesh, that would only be the case if you are trying to retrofit htmx on top of an existing JSON API if it is greenfield development, it is much better to simply return SSR HTML and avoid that complexity you can join the discord for more immediate help: https://htmx.org/discord https://htmx.org/discord
        animesh 5y ago
        That makes sense. I didn't think about it that way, but traditional MVC views would do just as well I guess for greenfield work.
mamcx 5y ago
And pair with https://tailwindcss.com https://tailwindcss.com and you are golden. Seriously, is super productive this way!
- tfehring 5y ago
  This is really interesting. Assuming I'm willing to trust the author's claim that semantic class names are the reason CSS is hard to maintain, what's the advantage of `<img class="w-32 h-32">` over `<img style="width: 32px; height: 32px;">`?
  - mhoad 5y ago
    I like to think of Tailwind as CSS without the C. Everything is now all at the same global namespace and all of the issues that people run into with specificity go away in the process. It’s not my personal choice on how to solve that problem I think shadowDOM via web components are a much nicer option personally but Tailwind has a lot of very enthusiastic fans who seem to enjoy it.
  - gls2ro 5y ago
    Media Queries
  - slater 5y ago
    Less typing, less bandwidth (ab)used.
    - tfehring 5y ago
      I'd think the former would typically (depending on how many times the class is re-used) use more bandwidth, if anything, since it still requires the framework to define the `w-32 h-32` class attributes elsewhere using the more verbose identifiers. Plus the overhead for an additional request if that class definition happens in an external style sheet.
  - code_biologist 5y ago
    I'm willing to trust the author's claim that semantic class names are the reason CSS is hard to maintain Here's a great talk on why he asserts that: https://www.youtube.com/watch?v=J_7_mnFSLDg https://www.youtube.com/watch?v=J_7_mnFSLDg Not sure I 100% agree, but I appreciate the fresh look at oil patters.
midrus 5y ago
I'm a big fan of Unpoly. Pretty similar to Htmx. Unpoly just fits my brain better. https://unpoly.com/ https://unpoly.com/

Wait, this looks and feels like a very pragmatic way of making modern websites. How has this not become more popular? What are its cons?

mamcx 5y ago
> What are its cons? Is very pragmatic. That means your whole investment in the arcane ways of JS are dust. Not hipster at all. --- More seriously, Is of little issues here. You setup and it works, so is not something that lead to "generate content" like other setups. I found only a significant issue (to me) (https://github.com/bigskysoftware/htmx/issues/596 https://github.com/bigskysoftware/htmx/issues/596) but then I do something that have never done in long time with a JS library: I poke into the source and fix it myself. Far easier than expected! (ie: The code is plain!)
boyter 5y ago
You return HTML from your "api" endpoint's is the biggest opposition I have found. Can mean additional work when you do want to switch to JSON, as the endpoints end up not being very reusable. I quite like HTMX myself, although I consider it a tool you use to enhance websites and not something you use to build full blown web apps.
- deniz-a 5y ago
  You don't return HTML from API endpoints, you return it from your UI endpoints. You could reuse those for JSON with content negotiation, or have a frontend server+backend server setup where the backend server is also a public API, or some other solution.
  - boyter 5y ago
    Semantics over the name aside, you end up returning small chunks of HTML from newly defined routes that are only useful for your HTMX frontend, hence my usage of API as the interface really only makes sense to the machine and not the user without the rest of the page content. Yes you could inspect the headers and such to determine what type to return, but the core problem remains, that the HTML in those is not reusable whereas as JSON would be. How much overhead this is for you depends on your design of course, but it does mean some work might potentially be wasted if you go down the full SPA application later and even if not changing layouts and such might be a pain.
    - recursivedoubts 5y ago
      essay related: https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/
      - animesh 5y ago
        Thanks for HTMX and your essays. Today I was reading HTMX documentation on what to do when we design API-first for a particular project but don't want any of the frontend magic aka SPA. I found immediately that I need to use both json_enc and client-side-templates extensions. Hope I am on the right path.
        recursivedoubts 5y ago
        hi animesh, that would only be the case if you are trying to retrofit htmx on top of an existing JSON API if it is greenfield development, it is much better to simply return SSR HTML and avoid that complexity you can join the discord for more immediate help: https://htmx.org/discord https://htmx.org/discord
        animesh 5y ago
        That makes sense. I didn't think about it that way, but traditional MVC views would do just as well I guess for greenfield work.

mamcx 5y ago

And pair with https://tailwindcss.com https://tailwindcss.com and you are golden. Seriously, is super productive this way!

tfehring 5y ago
This is really interesting. Assuming I'm willing to trust the author's claim that semantic class names are the reason CSS is hard to maintain, what's the advantage of `<img class="w-32 h-32">` over `<img style="width: 32px; height: 32px;">`?
- mhoad 5y ago
  I like to think of Tailwind as CSS without the C. Everything is now all at the same global namespace and all of the issues that people run into with specificity go away in the process. It’s not my personal choice on how to solve that problem I think shadowDOM via web components are a much nicer option personally but Tailwind has a lot of very enthusiastic fans who seem to enjoy it.
- gls2ro 5y ago
  Media Queries
- slater 5y ago
  Less typing, less bandwidth (ab)used.
  - tfehring 5y ago
    I'd think the former would typically (depending on how many times the class is re-used) use more bandwidth, if anything, since it still requires the framework to define the `w-32 h-32` class attributes elsewhere using the more verbose identifiers. Plus the overhead for an additional request if that class definition happens in an external style sheet.
- code_biologist 5y ago
  I'm willing to trust the author's claim that semantic class names are the reason CSS is hard to maintain Here's a great talk on why he asserts that: https://www.youtube.com/watch?v=J_7_mnFSLDg https://www.youtube.com/watch?v=J_7_mnFSLDg Not sure I 100% agree, but I appreciate the fresh look at oil patters.

midrus 5y ago

I'm a big fan of Unpoly. Pretty similar to Htmx. Unpoly just fits my brain better. https://unpoly.com/ https://unpoly.com/