[nlstitch]

I was seriously thinking about using HTMX myself, but I'm kinda scared it's developer pool seems too small to hire devs from.

I'm used to proprietary frameworks, in my case I worked with intershop which uses isml. (this is comparible to something like thymeleaf). In recent years we tried to move away from this approach and go to the angular front end Stack because it's easier to hire a dedicated frontend developer than it is to hire a specialized fullstacker. Stuff can get complex when you're using something like htmx and developers don't want to fight spaghetti monsters. You don't want you backend guys to be the bottleneck, e.g. when FE just creates HTML and the backend has to tie it all together.

My question is; has HTMX thought about the pitfalls like this, and how do you counter it?

[Hendrikto]

> I'm kinda scared it's developer pool seems too small to hire devs from

It is very straightforward to pick up. Unless you hire code camp devs who only ever learned React, no actual CS topics, anybody should be productive within at most a week.

[randomgiy3142]

While true this is divorce from organization’s hiring practices. I have to fill out a form to request someone and htmx won’t be on it. You will get someone who only know react and will stomp their feet as to why can’t we use react. A lot of bootcamp programmers are cert jockeys who don’t care or know about development, not that they can’t learn.

[8organicbits]

For the sake of your organization, get them to add a fill in the blank on that form. Picking a tech stack based on the options on an HR form is a sure way to end up using ancient tech. HR is failing you.

[yellow_lead]

I would go so far as to say if you can understand React, you can understand HTMX.

[danslo]

If you can understand HTML, you can understand HTMX.

[infecto]

How to counter it. HTMX takes no more than half a day to pick up, probably quicker than that.

Keep in mind HTMX does not solve all scenarios, there are times when a SPA using a JS framework is required.

[nymanjon]

That's not entirely correct. It takes a day to pick up and a week to master :-). Well, it does take a little longer to learn all the nuances. Also, I've used this pattern in my personal apps (and for one app at work) and sometimes I felt that I needed to use a front end lib for a page, but after thinking about it I learned that I still didn't need a front end lib as hypermedia covered my needs.

I do agree there are times that a traditional front end lib might be needed but it is much rarer than we think.

[pmarreck]

I know nothing about HTMX. Where do I look first?

[recursivedoubts]

If you want a longer introduction you can read out book (free online): https://hypermedia.systems

[pmarreck]

ah, thanks! This looks to satisfy a similar use-case to LiveView which I already have access to in my current stack but it's always good to know about other options

[npilk]

https://htmx.org/

The examples at https://htmx.org/examples/ may also be helpful

[pmarreck]

aha! I already have access to LiveView so this seems redundant but this is good to know about

[ricardobeat]

> Stuff can get complex when you're using something like htmx

Interesting to hear that after a mention of Angular. Different ideas of complexity I guess - frameworks like it give you structure but complexity is still there, and probably orders of magnitude higher.

Ultimately you want FE devs that know the web stack well - JS, CSS, HTML, browser APIs. They will be able to pick the best tools & frameworks for the job. Something like HTMx is trivial to pick up.

[recursivedoubts]

Well, nothing succeeds like success, and htmx came in at #2 on the 2023 js rising stars:

https://risingstars.js.org/2023/en#section-framework

Just behind react and ahead of vue, svelte & angular. So the future looks promising in that regard (although I do expect it to drop back after the initial excitement dies down).

htmx is pretty simple, most web developers can pick it up in a day or so. It does require a mental shift for both developers as well as PM/architects in how development is done, because it pushes the organization more towards a full-stack paradigm, with developers owning whole features rather than "front end" and "back end". We have a book, free online, you can read, that will help with this:

https://hypermedia.systems

In addition to the docs (https://htmx.org/docs, which should take about an hour to read) we also have a bunch of essays on both philosophical & practical issues around htmx & hypermedia in general:

https://htmx.org/essays

htmx tries to be "scaleable" in that there are very few base ideas to the library and you can use only a few of them to implement useful behavior (e.g. lazy loading, to pull a section of a page out of the critical first-paint path, is two attributes: https://htmx.org/examples/lazy-load) but then it provides enough hooks and deeper features (e.g. events, event filters, etc.) that as you get deeper into it you can accomplish what you want.

finally, with respect to spaghetti code, this is a perennial danger in all software development. My admittedly limited experience with SPA libraries has not convinced me that they prevent spaghetti. w/htmx you want to focus your efforts on the back end and take advantage of whatever tools your server-side environment offers to properly factor your application. Because htmx allows you to pick any server side technology (SPAs put pressure on you to adopt JavaScript/TypeScript on the back-end, since you already have a large application written in them for the front-end) you have many more options & paradigms available for organizing the bulk of your application logic.

addendum: I should mention that i try to outline when htmx is a good choice for an application here:

https://htmx.org/essays/when-to-use-hypermedia/

htmx is a tool, a good tool in many cases, but just a tool, and i want to be clear that it isn't a silver bullet for web development

[nymanjon]

It's more about their back end skills as you would be hiring a back end dev who can do a little front end. No need to worry about having HTMX on their resume, just something like <Whatever back end language you like> and JavaScript. And most developers that are web developers qualify for that.

[sethammons]

I've not used it in a team environment. I'm used to working with an FE developer or team. The last time I did js, jquery was the new hotness. For me on a personal project, I tried react and svelte. Both we monsters for building a site that needed some js elements and interaction. I was able to get htmx working quickly and I've only had a couple of snags.

One neat benefit is that I am now able to unit test (well, unit integration) my views with a headless browser because my UI is served by my backend and not a separate service that has to run with all the yarn and npm bs.

TL;DR: I'm a backend person who struggled to pick up react over a weekend but picked up htmx in an hour. Your FE devs will have no problems with htmx.

They will have to become familiar with your system's templates syntax and how to work in the backend to organize their partials and components and may even have to decide how that should all be structured.