Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

htmx

htmx.org

Post reply on HN
Print view View original

131–140 of 291 posts

Re: htmx

#131

Post by Andrew_nenakhov »

marcus_holmes wrote: post #98
genmud wrote: post #52

Earlier 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…

The "new hotness" only matters if you're going to try and get a job as a FE dev in a large team. The "old hotness" still works, and likely has the more obscure bugs worked out of it. And you can always just write the thing in JS without any hotness at all. The JS ecosystem's obsession with frameworks is a diversion. You really only need a framework if your site is super complex. And even then, if you're careful about…

I usually oppose the use of any new "hotness" in a project until that "hotness" is ~10 years old.

Re: htmx

#132

Post by dmix »

pphysch wrote: post #109
dmix wrote: post #106

Earlier quoted context omitted.

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.

You must not work on frontend because I've seen plenty of "simple" libraries exactly like htmx adopted and turned into monsters that power entire SaaS products the same way WordPress is turned into pseudo custom Web apps by non-programmers countess times.

Being the guy who has to decipher it is not a fun job and gives you perspective on early technology choices.

I've read enough discourse on HN re htmx to recognize people seeing it as an adequate solution for serious business usecases because they don't grasp the natural evolution in demands for complexity and interactivity in browser UIs.

People love downplaying why more serious JS frameworks are adopted in the first place then find themselves in situations that need it but try to pretend they can just force it on primitive "simple" libraries, as we saw with jquery ad nauseam. Or more likely they leave their mess for the next developer to do the job properly from scratch.

Re: htmx

#133

Post by daguava »

listenallyall wrote: post #44
chatmasta wrote: post #6

I 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?…

[dead]

Re: htmx

#134

Post by number6 »

The_Colonel wrote: post #129
hakfoo wrote: post #123

Earlier quoted context omitted.

What I hate is that you don't even write JavaScript anymore. You write fantasy future JavaScript. Sure, it will be available in ECMAScript 23, scheduled to drop in real browsers in 2092. But for now, here's a convoluted mess of polyfills, Babel, and WebPack, that we HOPE papers over the real behaviour of browsers, and suddenly your test-and-debug cycle has introduced a flow-shattering 15-second build cycle each time…

There's actually no need for that anymore. JavaScript as is supported right now in the latest Chrome, Firefox and Safari is already pretty good. You can get quite far without any backend tooling these days. The only thing which I believe is still needed is a bundler when your project grows to a certain size. Fetching a complex graph of thousands of files will likely never be fast.

Do you still use gulp or is it webpack nowadays?

Re: htmx

#135

Post by leidenfrost »

marcus_holmes wrote: post #98
genmud wrote: post #52

Earlier 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…

The "new hotness" only matters if you're going to try and get a job as a FE dev in a large team. The "old hotness" still works, and likely has the more obscure bugs worked out of it. And you can always just write the thing in JS without any hotness at all. The JS ecosystem's obsession with frameworks is a diversion. You really only need a framework if your site is super complex. And even then, if you're careful about…

This.

90% of the toolchain is not required at all. Just quality of life improvements.

Good ES6 (and TS) idiomatic code feels actually closer to reading Scala than reading a legacy Jquery app.

And the V8 engine has so much investment in optimizations today that is actually closer to Java and in some cases lighter than Go.

IMHO people don't hate JS in reality. They hate the strawman made of the worst parts of Junior code ever encountered and inconsistencies that really don't happen in practice unless you actively look for them.

Re: htmx

#136

Post by marko-lev »

HTMX is just HTML.

HTMX substitutes a DOM element with the HTML response you get from an on-click HTTP request instead of redirecting to a new page.

Claims of HTMX being yet another complexity or yet another JavaScript framework fail to acknowledge this.

Re: htmx

#137

Post by listenallyall »

creatable wrote: post #105
listenallyall wrote: post #44

Earlier quoted context omitted.

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.

React isn't the only way, of course, but it's likely the most popular. Why do you consider Vue or Svelte to be valid alternatives but not HTMX, despite plenty of people endorsing it and openly proclaiming how successful it's been in their projects?

Re: htmx

#138

Post by julianeon »

genmud wrote: post #52
chatmasta wrote: post #6

I 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…

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…

I think this comment is a bit out of date, especially if you’ve been watching JS from a distance for the past couple decades. This would’ve been true circa 2014. In 2023 it’s obsolete.

There’s one framework that won, that’s all you have to learn, as far as the industry goes (as opposed to hobbyists) it’s been decided. React won. React is the framework you learn.

“Popular frameworks for the past 6 years” - React has been dominant over that entire time period, from beginning to end. React is what you would’ve reached for 6 years ago (it was already mature then, in 2017) and it’s what you’d turn to now. This is what I mean. You could update your React code to use hooks instead of classes - or you could not, it will continue to work if you don’t.

The “JS changes all the time” take is frankly out of date in 2023. “Which framework do I learn…” you learn React, the framework that won. It’s pretty much that simple.

Re: htmx

#139

Post by throwaway2037 »

genmud wrote: post #52
chatmasta wrote: post #6

I 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…

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…

This is a great post. I'm not a web dev myself, but I have a couple on my team. I criminally underrated the challenge of maintaining a complex web app. It is madness: endless incompatible, forced upgrades.

Real Question: Why does this ecosystem have this issue, but others have it less? For example: Why doesn't Python or Java have the same madness?

Please don't read the question as criticizing web dev / JavaScript / etc. My curiosity is genuine.

To be fair, it does feel like C++ is more maddening than Python or Java, but part of can be explained by (1) native code generation (build is way harder than languages that run in a VM) and (2) the insane complexity of the language which _traditionally_ made IDEs much weaker than other languages. MSFT Visual Studio and JetBrains CLion have come a long way. (I can already feel the HN pitchforks poking at me for these C++ comments!)

Re: htmx

#140

Post by alex_lav »

zackify wrote: post #127
baby wrote: post #122

Earlier quoted context omitted.

I’m pretty sure you can continue to use jquery and everything still works fine :D

I’m over here continuing to use react for 9+ years but every post on here acts like it’s changing every day.

Classes? Components as functions? Classes again? Hooks?
Post reply on HN