I've been having a lot ot success with #htmx and #AlpineJS but I know a lot of people have concerns that these technologies are not as "powerful" or "scalable" as other web frontend technologies.
Does anyone have any stories to tell about how htmx and/or alpine fell short for them? Did anyone go down an htmx based path and regret it?
@webology @rustickode @jamerive @_chrismay @martinvanaken
Thank you all for the responses!
So it sounds like the main issues are:
- component based development is sorely missed
- #AlpineJS is like dark magic if you aren't used to js development, or are not used to dealing with the kinds of problems it solves
- if you need to build a complicated frontend then things can get hairy. I think this is probably mostly to do with using #htmx to update lots of things at once
Is that about right?
@sheena I don't have any htmx horror stories yet, but I found Alpine to very quickly make me feel in over my head. I think it's a steeper learning curve for someone who only touches JS a few times a year (aka me.)
@webology @sheena I think that it's normal considering that tech that tend to simplify a complex scenario are harder to catch up but in the end, the reward is huge. The ridiculous requirements to web browser in now days is the result to implement that over abstraction resulting in a ton of framework and libraries pile one upon other and resulting in a poor performance. Htmx and alpineJS are trying to avoid the excessive abstraction that led us to the mess that web is today.
@sheena The only time I have questioned using solely htmx and alpine was when working on the UI for a complex rules engine.
The two worked beautifully for a while, but as the complexity of the rules engine became more apparent, I struggled to write understandable code, especially since I was the only one on the project at that time and needed a collaborator.
All that said, if I had to do it again, I'd not count them out. They are very powerful together.
@sheena my current main concerns are:
- I find React make it easy to keep complexity at a reasonable level with the component structure. Keeping a set of template and a bit of Alpine/htmx feels more complex to me
- One of the biggest productivity benefits of full stack framework nowaday is the availability of open source, quality components (Antd, Shad, Mantine, MUI, ...) - I generally don't want/need to reinvent the wheel on the UI side
@martinvanaken Open source components is one of the things I hadn't thought of until more recently.
My team got burned by several OS components that were either a pain to customize to what we needed or were so complex and hard to understand.
I know there are sites with alpine components, but I only look at them for inspiration.
I'd like to know more about your experience with components. How are you able to adopt OS components?
@_chrismay I'm working mostly with small teams (1-8) in B2B situations where UX is as important as anywhere but the UI can be "standard" as long as it works.
As a tech lead I generally push for "this is what we using, here is what's possible to configure but we don't recode/create our own".
I've now worked with Antd, Shadcn and MUI and find them all more than good enough for like 80-90% of use cases.
Components are more than good enough for this to be a significant productivity gain
@martinvanaken excellent. Thank you for sharing!
@sheena I think I have touched almost all the features of #htmx including sockets when building inbox for my side project https://hellokea.com . I have almost completed it after migrating from vue2. The backend is Django. I have used alpinejs before but don't want to use it for this project.
Overall, I would say it's the best experience I got. There were few glitches with DOM loading. Thanks to @adamchainz for django-htmx . It's the best.