how many times has this been posted here?
Not enough
htmx
101–110 of 291 posts
Re: htmx
#102I continue to be impressed at the effort people will put into avoiding writing any JavaScript. Is it really easier to learn yet another DSL embedded in attribute tags rather than taking a day to setup your JS dev environment and then writing idiomatic code for running inside a web browser? Surely your htmx project will eventually cross a complexity threshold where you've added enough scaffolding that you may as well…
[dead]
Re: htmx
#103I continue to be impressed at the effort people will put into avoiding writing any JavaScript. Is it really easier to learn yet another DSL embedded in attribute tags rather than taking a day to setup your JS dev environment and then writing idiomatic code for running inside a web browser? Surely your htmx project will eventually cross a complexity threshold where you've added enough scaffolding that you may as well…
Just look at Wordpress for the demand for shoehorning things into something because it seems easier on the surface and accessible without learning harder programming stuff, or at least investing in the initial overhead. There will always be demand. It's likely very practical for certain usecases but that won't stop people from abusing it in full SaaS web apps before some CTO joins and has to abandon it all when requi…
Wordpress is a platform or framework, HTMX is neither. If you don't like what HTMX offers for your next feature... just don't use HTMX attributes on those elements. So comparing it to WordPress, or React, etc. is not accurate.
Re: htmx
#104Earlier quoted context omitted.
How do you do validation with custom error messages without it? It seems pretty table stakes for forms to me. Where are the docs that make it easy to avoid hyperscript, if it's usable without hyperscript? This has hyperscript sprinkled in: https://htmx.org/docs/
Mostly, you validate on the server and send html with error messages back. If you really need client-side, yes, of course you have to script it. If hyperscript is not to your taste, you use a bit of js.
That was implicit in my question. We aren't talking about writing purely server side web apps here, and it's reasonable to expect something like client side validation, given that this is meant to be an easy way to do full stack web apps. I think it is but not really easier than other major ones.
Re: htmx
#105I continue to be impressed at the effort people will put into avoiding writing any JavaScript. Is it really easier to learn yet another DSL embedded in attribute tags rather than taking a day to setup your JS dev environment and then writing idiomatic code for running inside a web browser? Surely your htmx project will eventually cross a complexity threshold where you've added enough scaffolding that you may as well…
Never seen a tool where the people who don't use it seem to make up some of the craziest, most obscure, weirdest justifications for avoidance. It's totally fine if you're not personally down with HTMX! However, stating that we're avoiding "idiomatic code" is incorrect. Are you claiming React and JSX and useEffect are idiomatic? Really? Surrounding HTML fragments with return() and attributes with braces is idiomatic?…
Why do I continue to see people imply that React is the only way of writing frontend web applications with JavaScript? There are plenty of alternatives to React that I would say are far more "idiomatic". I highly recommend taking a look at Vue 3 or Svelte to get a better idea of what frontend JavaScript can be.
Re: htmx
#106Earlier quoted context omitted.
Just look at Wordpress for the demand for shoehorning things into something because it seems easier on the surface and accessible without learning harder programming stuff, or at least investing in the initial overhead. There will always be demand. It's likely very practical for certain usecases but that won't stop people from abusing it in full SaaS web apps before some CTO joins and has to abandon it all when requi…
Wordpress is a platform or framework, HTMX is neither. If you don't like what HTMX offers for your next feature... just don't use HTMX attributes on those elements. So comparing it to WordPress, or React, etc. is not accurate.
If you think this analogy is about frameworks vs libraries you missed the point.
It's the exact sort of technology option that is simple and accessible on the surface which is why someone inexperienced would adopt it in the early days. Then requirements naturally evolve and it gets shoehorned into ever more complex situations it was never intended for.
I'm speaking from experience and anyone who has worked in web app dev / JS for any length of time can see this coming from a mile away. The mountain of jQuery libraries alone should be enough but in the history of the internet WordPress is the classic cliché example of a simple technology that frequently gets abused beyond its original design. If your project is small and niche then obviously this critique isn't relevant. Nor is it dismissing the utility of htmx.
Re: htmx
#107HTMX + Java is almost as good as react!
I think people mistake what htmx is - they think it is a way to not write react/js in a node environment.
Where HTMX really shines is being able to bring the experience of writing React-like code without a nodejs environment in Java for e.g. (or Golang, Rust, etc)
Re: htmx
#108Earlier quoted context omitted.
It's not that I avoid JavaScript, it's that I want my work to be accessible to someone without JS as a requirement, for whatever reason they may be in that state and configuration, whether by choice or not. I write plenty of JS (12% of my biggest project, according to GitHub), but it's added onto HTML in such a way that the HTML still works for: * a security-minded person who has it turned off in their browser, * a u…
Every site I build works with JavaScript disabled. I use Next.js with server side rendering so that the initial page load is an accessible HTML document that is progressively enhanced for those with JS enabled during hydration by adding interactivity and smooth client side page transitions without full page reloads. None of this is possible with HTMX if the user has JavaScript disabled. The first step to using HTMX i…
> None of this is possible with HTMX if the user has JavaScript disabled. The first step to using HTMX is to import a JavaScript file from a CDN, and none of the features for partial page replacement will work without it.
Umm, progressive enhancement is a general concept that can be applied to any stack, not just Next.js. With htmx we can just use good old anchor and form tags to fall back to full-page loads if JavaScript is disabled. In fact it makes it more obvious because usually those are the tags we're using even with htmx and JavaScript enabled.
Re: htmx
#109Earlier quoted context omitted.
Wordpress is a platform or framework, HTMX is neither. If you don't like what HTMX offers for your next feature... just don't use HTMX attributes on those elements. So comparing it to WordPress, or React, etc. is not accurate.
If you think this analogy is about frameworks vs libraries you missed the point. It's the exact sort of technology option that is simple and accessible on the surface which is why someone inexperienced would adopt it in the early days. Then requirements naturally evolve and it gets shoehorned into ever more complex situations it was never intended for. I'm speaking from experience and anyone who has worked in web app…
Then you need to explain it better.
There is nothing wrong with offering simple solutions.
The problem with WordPress is that you can't just stop using it and painlessly swap to a more powerful framework/platform. You can really dig yourself into a hole.
This doesn't apply to HTMX.
Re: htmx
#110Earlier quoted context omitted.
I might be going against the grain here, but the JS ecosystem is just a series of goalposts that are constantly moving and it has burned so many people over the years that folks just don’t want to deal with it. I’m fine learning JS, but with the ecosystem it isn’t just learning JS. It’s learning the new hotness for packaging / versioning, it’s the frameworks that are constantly in flux, it’s the inconsistent abstract…
htmx is another tool just like that, another goalpost in the frontend webdev world. It's just happens that the most recent hype is "don't write JS", but fundamnetally it's no different. Just another framework/library that has gotten some traction. In a few years we'll be back full cycle and it will be in vogue to write JS again, probably because htmx and associated projects have grown to complex.
A key difference is the promise to be working even without JavaScript.