Interesting talk. I've been looking into this stack recently as a backend/ML developer who wants to start building web apps but doesn't want to dive deep into the NextJS/React ecosystem. So far it's going well, I'm definitely avoiding all of the previous stumbling blocks around setting up a JS/TS environment, not knowing NextJS best practices, etc. The learning curve there in the past was painful.
However, now that I'm getting to the point where I want to take my web app from "pretty cool toy" to something I can sell to users with all the bells and whistles, I'm having a bit more trouble. There just aren't as many examples out there for "bell and whistle" patterns than there are with React.
Eg: I want to implement typeahead. When I google "typeahead htmx alpine" I get some blog posts, some reddit posts, some random github gists. Cool, but looks like I'm going to have to think about the problem and toy around with it a bit to get it working. It's not quite "copy and paste this component". When I google "typeahead react" the 1st link is a pretty popular npm package that seems to support everything I want (and some stuff I didn't even know I wanted). Complete with user guides and docs and everything.
So now I'm asking myself whether I made the right decision trying to keep things "simple" with htmx/alpine? It's not even about whether my app is a SPA or not, or "how much interactivity I want" (which is a difficult question actually if you're not familiar with FE - what is interactivity, exactly?), it's more like "which framework is easier to blindly stumble through (with ChatGPT's help) to get what I want".
Actually I am in the same boat. Infact I swung twice. First I went from vanilla server side template rendering (in Go) -- all the way to going full in on NextJS and beginning to hate all the complexity and then now back. But this time with Go+Htmx (not even alpine - that is on the todolist). I have realized for the "fancy" use cases - just use client side JS as and when needed - did not need any fancy react stuff. ie instead of building a front-end only app and then adding server side capabilities, I started server side rendering first and then adding JS only when needed.
> It's not quite "copy and paste this component". When I google "typeahead react" the 1st link is a pretty popular npm package that seems to support everything I want (and some stuff I didn't even know I wanted).
> it's more like "which framework is easier to blindly stumble through (with ChatGPT's help) to get what I want".
I understand the sentiment but tech-wise it's a good thing that it's harder to do.
The other way would have you installing a (probably large) dependency, of which you'd use perhaps use 10% of its capabilities, expecting a response from the server that you might not have, and add more custom CSS that you'd have to wrangle together with your own styling.
Which might be fine if it's just you and you understand the tradeoffs, but if it was a team of 20 people each of them would do the same thing and the app would grow by accretion. Not just in size but in complexity. Which would necessitate more build tooling, more tests, maybe even changes to infrastructure...
Cobbling together things like that, while fast and fun, isn't necessarily great engineering. Sometimes we all have to do something quick and dirty, sure, but being forced to take a step back to think it through isn't a bad thing.
I don't know specifically if it addresses typehead (can't remember, read it a while back) but the HTMX creator's online book [0] has a LOT of "how do I do THIS thing?":
Htmx has been great. I reach for it in a lot on my projects. Although I have to admit that for my larger Django projects it gets a bit difficult to work with. Creating a url then a template then a view every time I need my page to change gets a bit repetitive and difficult to work with.
Alpine.js has never really clicked for me. Outside of anything simple I find myself struggling with the framework.
For my side project, I feel stack simplicity, error handling, "dont break back button" and eliminating many papercuts pulls me to HTMX, while Vue+TS offers type safety and model of "html is a function of state". I suspect more complex projects may make the stringly typed HTMX and Alpine less attractive.
I no longer default to creating a new or alternative view for returning html specifically for htmx. Sticking with existing views and using hx-select to select and swap content is totally fine most of the time.
However, now that I'm getting to the point where I want to take my web app from "pretty cool toy" to something I can sell to users with all the bells and whistles, I'm having a bit more trouble. There just aren't as many examples out there for "bell and whistle" patterns than there are with React.
Eg: I want to implement typeahead. When I google "typeahead htmx alpine" I get some blog posts, some reddit posts, some random github gists. Cool, but looks like I'm going to have to think about the problem and toy around with it a bit to get it working. It's not quite "copy and paste this component". When I google "typeahead react" the 1st link is a pretty popular npm package that seems to support everything I want (and some stuff I didn't even know I wanted). Complete with user guides and docs and everything.
So now I'm asking myself whether I made the right decision trying to keep things "simple" with htmx/alpine? It's not even about whether my app is a SPA or not, or "how much interactivity I want" (which is a difficult question actually if you're not familiar with FE - what is interactivity, exactly?), it's more like "which framework is easier to blindly stumble through (with ChatGPT's help) to get what I want".