12 ms·

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 t

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.
    - recursivedoubts 3y ago
      > Those are not "hypermedia controls". As I said elsewhere: stop appropriating concepts for your benefit. What would you call links & forms? The W3C seems to agree w/my language: https://www.w3.org/2019/wot/hypermedia https://www.w3.org/2019/wot/hypermedia "This document introduces an ontology for links and forms, the main hypermedia controls in use on the Web." > 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. I don't know about that. What about forms? And script tags. And all the other stuff? > You're not better. This is not what founders envisioned. I don't claim to be better, i don't know what that means in this context. I'm trying to generalize what I understand to be hypermedia controls (links & forms) in HTML, in a way that conforms to Roy Fielding's definitions of the uniform interface. I don't understand the hostility here. htmx isn't perfect or some sort of amazing piece of software, it's a flawed implementation by a flawed human of a perhaps flawed idea of generalizing hypermedia controls. But it's not obviously terrible either: people are having success using it, as a quick cruise around the other comments in this thread would indicate.
      - troupo 3y ago
        > The W3C seems to agree w/my language: Ah. Interesting. I stand corrected. Skimming through the document it looks like a very late retrofit and attempt at standardization for some parts of the w3c tech stack like RDF, web of things etc. > What about forms? And script tags. And all the other stuff? None of them existed in the "basic idea of HTML". "All the other stuff" accumulated over the years. Until early 2002 the whole idea was still to lay out the page in one rendering pass (and this was only changed IIRC sometime in 2001-2002 with optimisations for tables). > I'm trying to generalize what I understand to be hypermedia controls (links & forms) in HTML, in a way that conforms to Roy Fielding's definitions of the uniform interface. No, you're appropriating the definition, contorting it to pretend that it only means HTML as extended by HTMX, e.g. this [0]: --- start quote --- The Hypermedia Driven Application (HDA) architecture... - An HDA uses declarative, HTML-embedded syntax rather than imperative scripting to achieve better front-end interactivity - An HDA interacts with the server in terms of hypermedia (i.e. HTML) rather than a non-hypermedia format (e.g. JSON) --- end quote --- Nope. JSON (or literally anything else) can also be hypermedia as long as there's a client which can understand it and present it to the user, and can follow links etc. > I don't understand the hostility here. I'm just getting tired of people hijacking specific terms to suit their own narrow definitions (however many hoops they have to jump through to get there), and present these narrow contorted definitions as the only true way. [0] https://htmx.org/essays/hypermedia-driven-applications/ https://htmx.org/essays/hypermedia-driven-applications/
- lioeters 3y ago
  > Phoenix Liveview or Laravel LiveWire, or even Hotwire I want a banana and you suggest these jungles. Thanks but no thanks, I'd rather try HTMX which is a library not a framework.
randomgiy3142 3y ago
You’re missing a huge point: there’s a ton of devs that went into react bootcamp or whatever. Building a 50 person team on a technology that isn’t widely used or heavily supported by Google/Adobe/Microsoft is a huge hurdle. Even Typescript isn’t really used correctly, people basically use ts-lint on a lot of projects I see. For large companies they will also turn projects into BAU (business as usual) where the pressure is to push down costs and move it overseas. Finding a large overseas team on htmx at React prices will be difficult. Typescript is popular because people don’t use it a lot, and it doesn’t break things. If you’re introducing something new the bar is incredibly high to be obvious as to why to switch.
dpc_01234 3y ago
I think there's something to it. More important HTMX is just new and different enough that it needs time to be picked up by the industry, BUT indeed it does largely eliminate what is commonly considered strictly front-end work, and thus forces teams to change their composition and division of responsibilities. At least where I worked there was often a frontend vs backend divide where some devs would write backend logic, and some others would worry only about consuming backend APIs to get the UI to do certain thing. The APIs is the contract and interface between the two sides and a natural place to divide responsibilities. Now, with HTMX, the divide is gone. The backend generates and swaps the parts of the UI, effectively driving the UI/UX directly. This cuts tons of JS out of the picture and couples (not necessarily in a bad way) backend and frontend. If you look at a popular YT video: https://www.youtube.com/watch?v=3GObi93tjZI https://www.youtube.com/watch?v=3GObi93tjZI , the result of HTMX rewrite was "JS guy left". So in larger teams switching from something like React to HTMX largely turns everything upside down, not just on technical level but on how people work and collaborate. It would be far easier for new teams and projects to go HTMX route, where they can start and keep hiring people who are fine in a new model.

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.
  - recursivedoubts 3y ago
    > Those are not "hypermedia controls". As I said elsewhere: stop appropriating concepts for your benefit. What would you call links & forms? The W3C seems to agree w/my language: https://www.w3.org/2019/wot/hypermedia https://www.w3.org/2019/wot/hypermedia "This document introduces an ontology for links and forms, the main hypermedia controls in use on the Web." > 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. I don't know about that. What about forms? And script tags. And all the other stuff? > You're not better. This is not what founders envisioned. I don't claim to be better, i don't know what that means in this context. I'm trying to generalize what I understand to be hypermedia controls (links & forms) in HTML, in a way that conforms to Roy Fielding's definitions of the uniform interface. I don't understand the hostility here. htmx isn't perfect or some sort of amazing piece of software, it's a flawed implementation by a flawed human of a perhaps flawed idea of generalizing hypermedia controls. But it's not obviously terrible either: people are having success using it, as a quick cruise around the other comments in this thread would indicate.
    - troupo 3y ago
      > The W3C seems to agree w/my language: Ah. Interesting. I stand corrected. Skimming through the document it looks like a very late retrofit and attempt at standardization for some parts of the w3c tech stack like RDF, web of things etc. > What about forms? And script tags. And all the other stuff? None of them existed in the "basic idea of HTML". "All the other stuff" accumulated over the years. Until early 2002 the whole idea was still to lay out the page in one rendering pass (and this was only changed IIRC sometime in 2001-2002 with optimisations for tables). > I'm trying to generalize what I understand to be hypermedia controls (links & forms) in HTML, in a way that conforms to Roy Fielding's definitions of the uniform interface. No, you're appropriating the definition, contorting it to pretend that it only means HTML as extended by HTMX, e.g. this [0]: --- start quote --- The Hypermedia Driven Application (HDA) architecture... - An HDA uses declarative, HTML-embedded syntax rather than imperative scripting to achieve better front-end interactivity - An HDA interacts with the server in terms of hypermedia (i.e. HTML) rather than a non-hypermedia format (e.g. JSON) --- end quote --- Nope. JSON (or literally anything else) can also be hypermedia as long as there's a client which can understand it and present it to the user, and can follow links etc. > I don't understand the hostility here. I'm just getting tired of people hijacking specific terms to suit their own narrow definitions (however many hoops they have to jump through to get there), and present these narrow contorted definitions as the only true way. [0] https://htmx.org/essays/hypermedia-driven-applications/ https://htmx.org/essays/hypermedia-driven-applications/
lioeters 3y ago
> Phoenix Liveview or Laravel LiveWire, or even Hotwire I want a banana and you suggest these jungles. Thanks but no thanks, I'd rather try HTMX which is a library not a framework.

randomgiy3142 3y ago

You’re missing a huge point: there’s a ton of devs that went into react bootcamp or whatever. Building a 50 person team on a technology that isn’t widely used or heavily supported by Google/Adobe/Microsoft is a huge hurdle. Even Typescript isn’t really used correctly, people basically use ts-lint on a lot of projects I see. For large companies they will also turn projects into BAU (business as usual) where the pressure is to push down costs and move it overseas. Finding a large overseas team on htmx at React prices will be difficult. Typescript is popular because people don’t use it a lot, and it doesn’t break things. If you’re introducing something new the bar is incredibly high to be obvious as to why to switch.

dpc_01234 3y ago

I think there's something to it. More important HTMX is just new and different enough that it needs time to be picked up by the industry, BUT indeed it does largely eliminate what is commonly considered strictly front-end work, and thus forces teams to change their composition and division of responsibilities. At least where I worked there was often a frontend vs backend divide where some devs would write backend logic, and some others would worry only about consuming backend APIs to get the UI to do certain thing. The APIs is the contract and interface between the two sides and a natural place to divide responsibilities. Now, with HTMX, the divide is gone. The backend generates and swaps the parts of the UI, effectively driving the UI/UX directly. This cuts tons of JS out of the picture and couples (not necessarily in a bad way) backend and frontend. If you look at a popular YT video: https://www.youtube.com/watch?v=3GObi93tjZI https://www.youtube.com/watch?v=3GObi93tjZI , the result of HTMX rewrite was "JS guy left". So in larger teams switching from something like React to HTMX largely turns everything upside down, not just on technical level but on how people work and collaborate. It would be far easier for new teams and projects to go HTMX route, where they can start and keep hiring people who are fine in a new model.