I don’t think direct DOM manipulation was ever a problem, if done thoughtfully.
If keeping track of state is so hard that requires a library to render it, perhaps you have too much state for a single view. It’s ultimately a UI/UX design problem, as it will be hard on your users as well.
I find the way they mix markup with code distasteful, and lots more.
> By removing these arbitrary constraints htmx completes HTML as a hypertext
I agree, this is interesting. I even agree, htmx is probably a polyfill waiting for the browser standards to catch up.
That said, trying to make a markup language smart is a losing battle in the long-term. It makes simple things like `if` and `while` difficult. Markup also really struggles with time / interactivity.
e.g. What should be displayed when a form is invalid? https://htmx.org/docs/#validation-example is just not ergonomic even for a simple case, let alone complex validations that interact with other fields, are async, etc.
I get a allure of wanting "only a markup language", however, it just isn't enough to be competitive for 95% of web development these days. In a different response you say "if you're building the next Gmail, fine use React, but you don't need React for picking between 3 colors to order a shirt". This is true, but it is fundamentally lacking the realization that no company wants to end their feature set at 3 colors for a shirt. They "want" to build a foundation quickly, but then enhance it to be able to custom create the shirt for exactly your body sizes and allow interactive movement of the "logo" or "graphic" anywhere on the shirt. They want the validation to ensure the shirt can be printed, and they want to ensure their logistics network is dynamically updating the order history for live tracking of the package.
To get there, the best thing to do is to use React (or similar) even when it is "just 3 colors".
This is the premature optimization our industry suffers from.
If/when you get a few million users, then you worry about scaling your backend with microservices, crazy DBs, serverless, whatever. Until then (vast majority of business), LAMP is fine.
If/when you need 20 checkboxes/drop-downs (again, there are very few situations where this is reasonable to the user, the mental load is non-trivial, consider splitting the view and adding a “next step” or something) than you consider a framework devised to render the whole of Facebook, a site with way more views and features than the most sites would ever dream of.
It's less keeping track of state is hard and more keeping state in a medium that isn't suitable for it (the DOM). The argument of too much state in a single view is nil by what applications are built nowadays (and also expected). Obviously it was already possible without the rise of declarative rendering frameworks but it made it more accessible to the majority of developers and thus raising the bar.
If you do however find the way markup and code is mixed feels distateful, I'd suggest to not look at any templating engine in the last 20 years because that's what most of them already did.
If you’re building a Gmail competitor, by all means, go with React, build your own solution, whatever. If you need to choose the color of a shirt with 3 sizes, perhaps it’s an overkill.
If keeping track of state is so hard that requires a library to render it, perhaps you have too much state for a single view. It’s ultimately a UI/UX design problem, as it will be hard on your users as well.
I find the way they mix markup with code distasteful, and lots more.