I've been using htmx since the intercooler days, but I'm of the opinion that just using Next.js and treating React like simple HTML is much easier for starters.
Or Alpine, but not htmx. Learning all those attributes (30, not counting the HTML headers and the JS API and the CSS classes, and events like htmx:historyCacheMissError) is not as simple as some in HN make it out to be. Just look at the most basic example in the top here: https://htmx.org/docs/. Meanwhile Alpine is read much easier, and has half the amount of attributes (15): https://alpinejs.dev/. Also look at the interactive component example from React: https://reactjs.org/tutorial/tutorial.html#making-an-interac.... It looks easier if you don't hate JS.
Of course, I respect that some avoid JS with passion, but I don't buy that it's simpler. It's juss less javascript-y.
Unfortunately, "easier" does not always equal "simpler". Next.js/CRA is "easier" because it hides a lot of the complexity away from you. In my opinion, ignoring how it all works under the hood and just blindly accepting tools/clis because "it works" sets you up for confusion down the road. I've met several JS developers who don't know that JSX gets transformed to JavaScript function calls after a build step -- they just assume it's part of how browsers work at this point. And that is mindblowing to me.
Most of what OP needs can probably be achieved with a few HTML files and <script> tags. It will probably be a few more keystrokes than `npx create-next-app`, but the disconnect between the code he/she is writing and the final running application will be much smaller, and I think he/she will have a better understanding of what the heck is going on.
Fair point on htmx and Alpine; I have not given Alpine a shot yet, but it looks nice from the docs.
> I've met several JS developers who don't know that JSX gets transformed to JavaScript function calls after a build step -- they just assume it's part of how browsers work at this point. And that is mindblowing to me.
I believe you, and I've also met some like you described who came to our interviews indeed, but it's more like the failure of their mentors. I've also met back-end engineers, with a lot of experience, who couldn't write a simple HTTP service with C#, without using ASP.NET, nor open a simple DB connection without using EntityFramework APIs.
Understanding what's going on will be even harder if it's not your main field (back-end developer just trying to get front-end out of the way) and some magic there won't cause a lot of problems IMHO.
failure of their mentors? To an early point, but beyond that everyone who considers themselves a professional needs to sit down with a book or three and understand stuff. 'mentors' is a small excuse IMO.
This is a valid criticism of SSR and the complex mental model it requires to implement effectively, even with Next.js. You need a firm understanding of the HTTP request lifecycle and the serialization boundary. For a novice programmer starting with frontend dev, I would not recommend starting with Next for this reason (create-react-app would be better).
But for an experienced backend developer, the mental model of Next is no problem, and the flexibility of SSR will feel liberating. After a few weeks you might even put down the Flask!
If you want to use SSR on your pages, I'd recommend sampling some Next projects (just pick one of the examples and get it running locally). You might like what you find. And for closer integration with Python, I'm sure there are options for server-side rendering of JSX that you could use, although they'll all ultimately need to either wrap a JS runtime or emulate JSX compilation in Python. So you may as well just skip the middleman and go to straight to react, whether via a framework or otherwise.
If you don't want a heavy framework, or you just want basic CSR for some richer pages, you can accomplish a lot with just `react` and `esbuild`. Even SSR is just a matter of calling `ReactDOMServer.renderToPipeableStream()` and doesn't need a framework like Next. They're just nice because they take care of all the problems you'd end up solving in a robust deployment anyway.
As a non-js developer I found Alpine lacking. In the examples they use something like await axios get to get new content. I have no idea what any of those mean or why they have to there in that order with that syntax.
What does "hx-get" do? Does it replace the HTML from that url? Why is it on a div, does it happen on load or does it wait for an event? It's a study on its own:
Oh, apparently I can put hx-trigger="mouseup mousemove delay:500ms" there to make it explicit. I mean this thing has its own DSL, and IMHO, you are escaping from JS and jumping to another language, which you still have to learn and less people know of.
In alpine, it's explicit. You can say fetch, then replace something in your data, and use that thing in your x-html. You still need to learn some, but in my experience, much less to keep in mind than htmx.
OTOH, Next.js is even easier than Alpine to learn. You just create pages as js files and run the server. Yes, you need to run a BFF (back-end for front-end) but it's just that. The thing even updates in real-time. Only thing that can match this is Phoenix LiveView but I can't speak for it as I've just played with it and nothing more.
Yeah... I'm about as far to the other side of this as you can get.
It really looks like the x-html attribute you're complaining about is just using plain old javascript. It takes a statement that resolves to a string, and renders that.
The statement they provided happens to be pretty terrible for docs (I would have just used the built in fetch api, instead of the axios networking library - https://github.com/axios/axios), but it's plain old js regardless.
Your example is some custom fucking DSL that I have NO idea what it's doing. When does it run? how does it handle errors? What is the base url? What happens to the original text? How does it auth? What if I needed to post, or put, or delete? It's an entire fucking language I have to learn on top of the actual css/html/js knowledge required to understand this. In almost all cases, you're better off just learning "plain old javascript" since that skillset travels with you everywhere.
basically: DO NOT MAKE ME LEARN YOUR FUCKING DSL. It's wasted time and effort for me, and learning it provides absolutely zero benefits outside of your library. Further - it will fucking leak, and then you're right back at writing plain old js again, but now you have to understand the intimate details of the library implementing the dsl to tweak the right spots.
Even alpine turns me off a bit here (it's still a dsl, even if most of it reverts to plain old js) - but at least they're incredibly up front about the total time investment to learn the dsl (15 attrs, 6 props, 2 methods). HTMX is like 5 times the size (https://htmx.org/reference/), so I assume roughly 20 times the effort to learn the DSL.
I wrote an internal tools framework on top of htmx with a desire to make things easier for backend contributors, but ran into exactly this problem - even htmx isn't quite simple. What I would have likely done next is try to create jinja abstractions around htmx
Or Alpine, but not htmx. Learning all those attributes (30, not counting the HTML headers and the JS API and the CSS classes, and events like htmx:historyCacheMissError) is not as simple as some in HN make it out to be. Just look at the most basic example in the top here: https://htmx.org/docs/. Meanwhile Alpine is read much easier, and has half the amount of attributes (15): https://alpinejs.dev/. Also look at the interactive component example from React: https://reactjs.org/tutorial/tutorial.html#making-an-interac.... It looks easier if you don't hate JS.
Of course, I respect that some avoid JS with passion, but I don't buy that it's simpler. It's juss less javascript-y.