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

Is htmx Just Another JavaScript Framework?

htmx.org

Post reply on HN
Print view View original

201–210 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#201

Post by satvikpendem »

zo1 wrote: post #199
satvikpendem wrote: post #138

Earlier quoted context omitted.

It's common everywhere that at least one dependency will have some breaking change, even in "same ecosystems."

No, this is highly unique to JS/TS. I've worked in plenty other languages and it's bo where near as bad. Yes they all have some form of this, but it's an order of magnitude smaller. One big contributor is JS's proclivity to have lots of smaller libraries. This increases the chances of one of the included libraries having a breaking change. Pile ontop of that this insane notion of constant version pinning and "semanti…

Not really. Python's is worse for example.

Re: Is htmx Just Another JavaScript Framework?

#202

Post by dpc_01234 »

karmarepellent wrote: post #131

As every discussion about HTMX usually evolves to people arguing why it is not widely adopted by big corporations and the like, let me be the first to share a thought on that topic. Could it just be an organizational problem? When you start using HTMX in your company your neat distinction between frontend and backend devs collapses and everyone suddenly must be a full-stack developer. When you can avoid that addition…

I think there's something to it. More important HTMX is just new and different enough that it needs time to be picked up by the industry, BUT indeed it does largely eliminate what is commonly considered strictly front-end work, and thus forces teams to change their composition and division of responsibilities.

At least where I worked there was often a frontend vs backend divide where some devs would write backend logic, and some others would worry only about consuming backend APIs to get the UI to do certain thing. The APIs is the contract and interface between the two sides and a natural place to divide responsibilities.

Now, with HTMX, the divide is gone. The backend generates and swaps the parts of the UI, effectively driving the UI/UX directly. This cuts tons of JS out of the picture and couples (not necessarily in a bad way) backend and frontend.

If you look at a popular YT video: https://www.youtube.com/watch?v=3GObi93tjZI , the result of HTMX rewrite was "JS guy left".

So in larger teams switching from something like React to HTMX largely turns everything upside down, not just on technical level but on how people work and collaborate.

It would be far easier for new teams and projects to go HTMX route, where they can start and keep hiring people who are fine in a new model.

Re: Is htmx Just Another JavaScript Framework?

#203

Post by philipwhiuk »

toastercat wrote: post #186

My biggest beef with htmx has more to do with the fact that it gets hyped as a React/Vue/Svelte alternative, when it's more accurate to describe htmx+ as an alternative. Also the constant use of pretentious memes on the official blog. But otherwise, I'm looking forward to trying it out for my next pet project.

> htmx+

You can use React with any backend.

Re: Is htmx Just Another JavaScript Framework?

#205

Post by bobthepanda »

nine_k wrote: post #194
Cthulhu_ wrote: post #77

Earlier quoted context omitted.

I was ultimately disappointed in HTML5 even though it was supposed to bring HTML into this era, with things like audio/video tags and new input methods for phone numbers and the like for mobile users. But ultimately it fell flat, was incomplete, and it feels like it's been stagnant again since HTML5 came out.

But how about Web Components? Finally, it seems, there's something reusable, and something reasonably framework-neutral.

is it that nice?

the beauty of HTML markup is that it's declarative. at least from the tutorials I've seen, WebComponents drag you firmly back into imperative land with document.addChild everywhere.

Re: Is htmx Just Another JavaScript Framework?

#206

Post by recursivedoubts »

dfabulich wrote: post #155
recursivedoubts wrote: post #128

I am the author of htmx. I think htmx is a library using the following definition: - a library you call - a framework calls your code in htmx you add attributes to HTML to "call" htmx, so, from the perspective, you can call it a library. On the other hand, those "calls" are called back into via event handlers in JavaScript, so an argument can be made that, even at this level, htmx is a framework. I liked alex's analy…

The React team argued that it was "merely a view library" for years, and as far as I can tell, this was a wrong-headed approach based entirely on vibes. Libraries are cute and charming; frameworks are humongous and domineering. If you think of React and HTMX as cute and charming, and especially if you think of them as much cuter and more charming than their other "frameworky" competitors, then you'll prefer to think…

yep, i understand that view, but i'm going to keep calling it a library because i think it's a library, but I get it

Re: Is htmx Just Another JavaScript Framework?

#207

Post by chatmasta »

zo1 wrote: post #199
satvikpendem wrote: post #138

Earlier quoted context omitted.

It's common everywhere that at least one dependency will have some breaking change, even in "same ecosystems."

No, this is highly unique to JS/TS. I've worked in plenty other languages and it's bo where near as bad. Yes they all have some form of this, but it's an order of magnitude smaller. One big contributor is JS's proclivity to have lots of smaller libraries. This increases the chances of one of the included libraries having a breaking change. Pile ontop of that this insane notion of constant version pinning and "semanti…

I agree that many packages in the JS ecosystem don't respect semantic versioning, which is why I pin my dependencies to an exact version. For updates, I rely on automated bots submitting PRs that update a single package at a time and run my test suites. But even if they did respect semver, I'd still use exact versions, because I want full control over when I update my dependencies, and I don't want lockfile updates leaking into unrelated PRs just because a developer ran `yarn install`. Yes, you can use `yarn install --immutable` (and you should in CI/prod), but this will fail if the lockfile changes, which it would if the semver resolved to an updated version. I just want to `yarn install` without changing the lockfile.

If you pin to an exact version, and use a lockfile, then you won't ever pull in any updates on `yarn install`, and installing your package in three years will result in downloading the exact same code as it does today. Just make sure you use nvm to pin Node, and corepack to pin your package manager, and you have a fully reproducible build chain as long as the dependencies are not unpublished from npm (which they can't be, after 72 hours of publishing).

The only time it makes sense to use a semver range is in the `peerDependencies` of a published library. Even the `dependencies` of a library should use an exact range. Why? Because firstly, if I'm following best practices, I should be bundling my library before publishing it as a package. And secondly, if that bundle depends on another package, that's okay because npm dependency model allows having multiple copies/versions of the same package. But if it's something like Emotion depending on React, where I only want one copy of the library at runtime, then I should use a peer dependency, and here it does make sense to refer to it with a semver range.

Re: Is htmx Just Another JavaScript Framework?

#208

Post by theultdev »

There's just little benefit in HTMX unless you have a live financial dashboard or something like that.

I find the opposite approach of local-first (database in the client).

It fits more solutions and solves many more things (free offline, syncing, undo support) and getting rid of caching, retries, and latency.

Of course the industry wants you to want more on the server though.

Same view applies to RSC (react server components).

Embrace CRDTs.

Re: Is htmx Just Another JavaScript Framework?

#209

Post by recursivedoubts »

ysavir wrote: post #185
recursivedoubts wrote: post #128

I am the author of htmx. I think htmx is a library using the following definition: - a library you call - a framework calls your code in htmx you add attributes to HTML to "call" htmx, so, from the perspective, you can call it a library. On the other hand, those "calls" are called back into via event handlers in JavaScript, so an argument can be made that, even at this level, htmx is a framework. I liked alex's analy…

Would you say templaters like Vue and Angular, with the HTML additions of `v-for`, `@click`, etc., are a library in a similar way to HTMX? If so, is the differentiation then just setting apart HTMX, Vue, etc from JSX and other JS-in-HTML approaches?

I'd look mainly at the amount of code you have to provide to them and the infrastructure (e.g. JSX) they require.

Not saying there isn't a blurry line here.

Re: Is htmx Just Another JavaScript Framework?

#210

Post by recursivedoubts »

lemoncade wrote: post #176
recursivedoubts wrote: post #128

I am the author of htmx. I think htmx is a library using the following definition: - a library you call - a framework calls your code in htmx you add attributes to HTML to "call" htmx, so, from the perspective, you can call it a library. On the other hand, those "calls" are called back into via event handlers in JavaScript, so an argument can be made that, even at this level, htmx is a framework. I liked alex's analy…

lol u are everywhere

i'm in ur walls
Post reply on HN