3 ms·

Forgive me if my comment comes across as snarky, but why would HTMX not be suitable for projects at work? And what characteristic makes a tool only suitable for

Forgive me if my comment comes across as snarky, but why would HTMX not be suitable for projects at work? And what characteristic makes a tool only suitable for side-projects? I absolutely use HTMX at work, but then I do not work at a large corporation with tons of users. Likewise someone working at a large company would never touch HTMX for new projects in anticipation of some kind of roadblock that they may stumble across. Edit: I do not think there is anything you should wait for to happen as if the community one day settles on HTMX and its concepts being "the right way to go". Just use it for your projects if you feel like it suits the problem and enjoy!

Dansvidania 3y ago
I am not in the position to judge myself, at least not yet, and I got bit last time when I tried Elm :D By the book (hypermedia systems I mean) it seems very promising even for mid-sized or large organisations, I can see potentials to develop micro-frontends using the patterns, but I am not a frontend focused engineer at work, and I don't really trust my intuition (see the Elm reference above). I am not waiting for anything, I am using htmx for my projects and I am indeed enjoying it, but the question in my OP still stands IMO.
- solardev 3y ago
  (My opinion only, please treat it as just one person's thought process, not some eternal truth) As a frontend dev, for me it's primarily just an ecosystem thing. There's nothing wrong with HTMX or any other solution, like Ruby on Rails or Hotwire or even other JS frameworks like Angular or Gatsby, but they are not really what I see in the majority of the web dev ecosystem. By ecosystem, I mean this: - Developers are easy to find & hire for, and can work on existing code without much training because there are (relatively) standardized practices - For any common problem, I can easily reuse (or at least learn from the source for) a package on NPM - For any uncommon problem, I can find multiple robust discussion about it on various forums, Stack, etc. And ChatGPT probably has a workable overview. - I can reasonably expect medium-term robust vendor support, not just from the framework developers but various hosts, third-party commercial offerings (routers, state management, UI libs, CMSes, etc.), i.e., it's going to stay a viable ecosystem for 3-5 years at least - I don't have to reinvent the wheel for every new project / client, and can spin up a working prototype in a few minutes using boilerplates and 1-click deploys I've been building websites since I was a kid some 30 years ago, first using Perl and cgi-bin and then PHP, and evolved my stack with it over time. I've never been as productive as I am in the modern React ecosystem, especially with Next or Vite + MUI (https://mui.com/ https://mui.com/). Primarily this is because it allows me to build on top of other people's work and spend time only on the business logic of my app, at a very high level of abstraction (business components) and with a very high likelihood of being able find drop-in solutions for most common needs. I'm not reinventing the wheel constantly, or dealing with low-level constructs like manually updating the DOM. Or worse, dealing with server issues or updating OS packages. What used to take days/weeks of setup now takes one click and two minutes, and I can have a useable prototype up in 2-3 hours. Because 95%+ of my codebase isn't mine anymore; I can just reuse what someone else built, and then reframe it for my own needs. And when someone else needs to continue the work, they can just pick up where I left off with minimal onboarding, because they probably already have React knowledge. I think React, for all its faults, has just reached a point of saturation where it's like the old "nobody ever got fired for buying IBM", i.e., it's a safe, proven bet for most use cases. It may or may not be the BEST bet for any project, but it's probably good enough that it would at least warrant consideration, especially if the other stacks have less community/ecosystem support. At the end of the day, my job isn't to deliver the leanest frontend as close to the HTML as possible, it's to meet business needs. Robust componentization and a rich ecosystem are better for doing that, quickly and easily, than simpler or less popular solutions, again because it allows me to build off so much other people's work. There's a steep learning curve upfront, but once you learn it, day-to-day work is relatively straightforward and productive.
  - dunk010 3y ago
    I think you’re somewhere off base here. Yes, you understand React very well, but many don’t. And HTMX gives you a lot of leverage without needing to (1) deal with learning React, (2) deal with all the extra baggage that comes with it (oodles of extra complexity and code)
    - solardev 3y ago
      I don't disagree with any of that...? My argument was that as a frontender, the added complexity is worth it because the ecosystem is so huge that it enables a lot of code re-use. I don't see the same "easy to build on top"-ness in other frameworks, whether it's HTMX or even other JS frameworks. For simpler projects, I absolutely don't think it's necessary to learn a JS framework or (or even just React). But for apps of medium complexity and up, it's been a super productive system to work in, full-time, with other React devs and open-source contributions. The reusable component model is SUPER important in my day-to-day work and outweighs a lot of other factors (like technical complexity). The complexity you have to learn once (or every year or two), whereas the code re-use/NPM drop-ins is like multiple times a day. Edit: Really it comes down to this: https://survey.stackoverflow.co/2023/#section-most-popular-technologies-web-frameworks-and-technologies https://survey.stackoverflow.co/2023/#section-most-popular-t... (under "Professional developers"). It's just a lot easier to use what everyone else is using. HTMX sadly doesn't even make the list, as far as I can tell :(
pavlov 3y ago
For corporate projects, the most important attribute isn’t whether the framework can do the job, but whether it has résumé forward compatibility: “Can we hire people later to develop and maintain this project?”
- vundercind 3y ago
  It’s also the case that you take basically no risk picking a shitty tool as long as it’s popular (in enterprise). 10 problems with that, you catch no heat. 1 problem with the just-outside-the-norm thing you pushed for? That’s your fault.
- ipaddr 3y ago
  If you hired an average developer they can pick up most frameworks in a short amount of time. What I never understood was new developers have no business context and everyone accepts that will take time. When it comes to languages if someone hasn't worked with specific framework/version all is lost and no one will hire you without x amount of specific experience. Picking up a new framework is easier than picking up your specific industry terms and practices but employers get stuck with these false ideas.
  - 63stack 3y ago
    My take is that we are in this situation because most hiring is done by managers and/or recruiters who have very little knowledge, or are completely clueless about programming. This leads to checkmark based recruiting where the client wants tech x, candidate has tech x on his CV,
moomoo11 3y ago
Honestly because at bigger corporations customers usually pay to solve specific problems. They literally don’t care if you use x y z technology. Can you solve their problem? The technology, even for a tech company, is usually never the primary concern for the end user unless your end user is technical. Why take a risk in this case when you’re running a business that’s already printing dollar bills? I would personally never use any niche technology to build UIs. I stick to what is easiest and cheapest to develop, deploy, and maintain. It’s 2024 and most people who pay have high speed internet. It’s not 2008 anymore. 20kb vs 8kb vs spending millions of dollars on refactor or learning. I mean it’s a business not a hackathon right? I am all for people trying out new things. But unless those things add significant ROI to the business they’re not worth using. If it happens to align then yeah the business should do it, or pull a Meta with react. Just my opinion.

Dansvidania 3y ago

I am not in the position to judge myself, at least not yet, and I got bit last time when I tried Elm :D By the book (hypermedia systems I mean) it seems very promising even for mid-sized or large organisations, I can see potentials to develop micro-frontends using the patterns, but I am not a frontend focused engineer at work, and I don't really trust my intuition (see the Elm reference above). I am not waiting for anything, I am using htmx for my projects and I am indeed enjoying it, but the question in my OP still stands IMO.

solardev 3y ago
(My opinion only, please treat it as just one person's thought process, not some eternal truth) As a frontend dev, for me it's primarily just an ecosystem thing. There's nothing wrong with HTMX or any other solution, like Ruby on Rails or Hotwire or even other JS frameworks like Angular or Gatsby, but they are not really what I see in the majority of the web dev ecosystem. By ecosystem, I mean this: - Developers are easy to find & hire for, and can work on existing code without much training because there are (relatively) standardized practices - For any common problem, I can easily reuse (or at least learn from the source for) a package on NPM - For any uncommon problem, I can find multiple robust discussion about it on various forums, Stack, etc. And ChatGPT probably has a workable overview. - I can reasonably expect medium-term robust vendor support, not just from the framework developers but various hosts, third-party commercial offerings (routers, state management, UI libs, CMSes, etc.), i.e., it's going to stay a viable ecosystem for 3-5 years at least - I don't have to reinvent the wheel for every new project / client, and can spin up a working prototype in a few minutes using boilerplates and 1-click deploys I've been building websites since I was a kid some 30 years ago, first using Perl and cgi-bin and then PHP, and evolved my stack with it over time. I've never been as productive as I am in the modern React ecosystem, especially with Next or Vite + MUI (https://mui.com/ https://mui.com/). Primarily this is because it allows me to build on top of other people's work and spend time only on the business logic of my app, at a very high level of abstraction (business components) and with a very high likelihood of being able find drop-in solutions for most common needs. I'm not reinventing the wheel constantly, or dealing with low-level constructs like manually updating the DOM. Or worse, dealing with server issues or updating OS packages. What used to take days/weeks of setup now takes one click and two minutes, and I can have a useable prototype up in 2-3 hours. Because 95%+ of my codebase isn't mine anymore; I can just reuse what someone else built, and then reframe it for my own needs. And when someone else needs to continue the work, they can just pick up where I left off with minimal onboarding, because they probably already have React knowledge. I think React, for all its faults, has just reached a point of saturation where it's like the old "nobody ever got fired for buying IBM", i.e., it's a safe, proven bet for most use cases. It may or may not be the BEST bet for any project, but it's probably good enough that it would at least warrant consideration, especially if the other stacks have less community/ecosystem support. At the end of the day, my job isn't to deliver the leanest frontend as close to the HTML as possible, it's to meet business needs. Robust componentization and a rich ecosystem are better for doing that, quickly and easily, than simpler or less popular solutions, again because it allows me to build off so much other people's work. There's a steep learning curve upfront, but once you learn it, day-to-day work is relatively straightforward and productive.
- dunk010 3y ago
  I think you’re somewhere off base here. Yes, you understand React very well, but many don’t. And HTMX gives you a lot of leverage without needing to (1) deal with learning React, (2) deal with all the extra baggage that comes with it (oodles of extra complexity and code)
  - solardev 3y ago
    I don't disagree with any of that...? My argument was that as a frontender, the added complexity is worth it because the ecosystem is so huge that it enables a lot of code re-use. I don't see the same "easy to build on top"-ness in other frameworks, whether it's HTMX or even other JS frameworks. For simpler projects, I absolutely don't think it's necessary to learn a JS framework or (or even just React). But for apps of medium complexity and up, it's been a super productive system to work in, full-time, with other React devs and open-source contributions. The reusable component model is SUPER important in my day-to-day work and outweighs a lot of other factors (like technical complexity). The complexity you have to learn once (or every year or two), whereas the code re-use/NPM drop-ins is like multiple times a day. Edit: Really it comes down to this: https://survey.stackoverflow.co/2023/#section-most-popular-technologies-web-frameworks-and-technologies https://survey.stackoverflow.co/2023/#section-most-popular-t... (under "Professional developers"). It's just a lot easier to use what everyone else is using. HTMX sadly doesn't even make the list, as far as I can tell :(

pavlov 3y ago

For corporate projects, the most important attribute isn’t whether the framework can do the job, but whether it has résumé forward compatibility: “Can we hire people later to develop and maintain this project?”

vundercind 3y ago
It’s also the case that you take basically no risk picking a shitty tool as long as it’s popular (in enterprise). 10 problems with that, you catch no heat. 1 problem with the just-outside-the-norm thing you pushed for? That’s your fault.
ipaddr 3y ago
If you hired an average developer they can pick up most frameworks in a short amount of time. What I never understood was new developers have no business context and everyone accepts that will take time. When it comes to languages if someone hasn't worked with specific framework/version all is lost and no one will hire you without x amount of specific experience. Picking up a new framework is easier than picking up your specific industry terms and practices but employers get stuck with these false ideas.
- 63stack 3y ago
  My take is that we are in this situation because most hiring is done by managers and/or recruiters who have very little knowledge, or are completely clueless about programming. This leads to checkmark based recruiting where the client wants tech x, candidate has tech x on his CV,

moomoo11 3y ago

Honestly because at bigger corporations customers usually pay to solve specific problems. They literally don’t care if you use x y z technology. Can you solve their problem? The technology, even for a tech company, is usually never the primary concern for the end user unless your end user is technical. Why take a risk in this case when you’re running a business that’s already printing dollar bills? I would personally never use any niche technology to build UIs. I stick to what is easiest and cheapest to develop, deploy, and maintain. It’s 2024 and most people who pay have high speed internet. It’s not 2008 anymore. 20kb vs 8kb vs spending millions of dollars on refactor or learning. I mean it’s a business not a hackathon right? I am all for people trying out new things. But unless those things add significant ROI to the business they’re not worth using. If it happens to align then yeah the business should do it, or pull a Meta with react. Just my opinion.