Live data from Hacker News

Is htmx Just Another JavaScript Framework?

htmx.org

191–200 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#191
post #9

Sounds like a similar argument outlined here in a framework-agnostic way: https://blog.jim-nielsen.com/2023/html-web-components/ I don't really understand why people would bother arguing whether htmx is a library or a framework. It's a way of making a web site where you write less JS.

The article explains why that's important in the way the author defined the difference between framework and library.

In a nutshell, as defined by the author, a library is a cog which is included by your application and can easily be replaced if it's not being maintained anymore, whereas a framework is the system within which you create your application and switching to a new framework would require essentially rewriting the system (and throwing away what you learnt about how you developed your current app and having to learn the way to develop with the new framework).

Whether you agree with the author's definitions or not is irrelevant to the piece. What is relevant, however, is that one can be far less judicious when including a library, because you can simply replace it in the future, whereas you need to be far more careful when switching to a new framework because it's not as easy to replace.

Re: Is htmx Just Another JavaScript Framework?

#192

Earlier quoted context omitted.

Hadn't considered it before, but thinking about it now, I can see that a brilliant name choice probably played a big role in the traction that it's had.

ironically I originally rejected it in favor of "kutty": https://htmx.org/posts/2020-5-17-kutty-er-htmx-0-0-3-is-rele... better to be lucky than good, I guess

I, for one, am glad that you didn't release a self-harm framework ;)

Re: Is htmx Just Another JavaScript Framework?

#193
It's definitely not "just another." I believe this term implies that the framework would follow current trends, such as Components, Templates, etc.

HTMX is different and incorporates some old JSF-like ideas, which makes it feel fresh for some developers, especially those who don't really want to learn React, Angular, Vue, and others.

Re: Is htmx Just Another JavaScript Framework?

#194
post #29

Earlier quoted context omitted.

I hope it works! HTML is in dire need of some tlc

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.

Re: Is htmx Just Another JavaScript Framework?

#196

HTMX is signaling they're around for the long haul, we'll see if they break backwards compatibility or rewrite their API 15 times in the next year. I had one of my dev's do several node/js framework POCs in _September_ last 2023 (current year is Jan 2024 at the time of this writing). Nearly all of the POCs won't even run or build any more because the developers have rewritten something and broke all backwards compati…

Any POCs your devs wrote would have been targeted at a specific version of their framework dependencies via their NPM package.json / package-lock.json. So why would any later changes made by framework authors, even backwards incompatible ones, made you unable to run or build them?

I assume they mean they updated their dependencies to the latest. That's somewhat valid.

The trap is this: you have a strong need to update a dependency for a bug fix (particularly security fixes), but the update isn't compatible. So you've got no good option: either live with unfixed bugs or pay the price to update your app to the latest version.

There is some wiggle room though. (1) libraries will often maintain a compatible branch for important fixes. (2) you can often find and apply just the fix/fixes you want to your own version of the library. Obviously, you start to lose the benefit of someone else maintaining the library for you, but when you aren't paying for it, you should always understand that is a nice but temporary state of affairs, so enjoy it while it lasts. (Actually, even when you are paying -- maybe even a lot -- you can still get left behind.)

Re: Is htmx Just Another JavaScript Framework?

#197

I like the basic idea of htmx: respond to user input by making server requests that return new html for a subset of the page. However, I think there's a pretty significant language design problem and htmx's solution is language proliferation. There is a very low "expressivity ceiling" for what can be encoded into html attributes. The hx-trigger attribute defines a new, very limited domain specific programming languag…

Often you want to limit the expressive power, in order to obtain other important guarantees. E.g. much of the time you don't want a Turing-complete language, because it must be able to express a never-terminating program.

HTMX is expressive enough for many smaller cases. If your case requires more richness, you can always pick React, Vue, Elm, etc, and be able to do basically anything on the client side.

Re: Is htmx Just Another JavaScript Framework?

#198
post #82

Earlier quoted context omitted.

Note that by this definition Spring Boot isn't a framework - you call SpringApplication.run to start it.

Forgive my ignorance, I'm not super deep into the Java ecosystem, but is Spring Boot the same as just "Spring"? Or what is the difference precisely?

Some people jokingly call Spring Boot a framework to manage Spring - another framework.

If having a entrypoint function/object is enough to call something a library then both Spring Boot and Spring are just libraries. But in reality they are not - so entrypoint rule is not correct.

Re: Is htmx Just Another JavaScript Framework?

#199
post #136

Earlier quoted context omitted.

> they want to be on the latest version all the time which obviously will have breaking changes Not very common in sane ecosystems.

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 "semantic versioning" and you have devs that willy nilly change public facing interfaces.

Post reply on HN