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

221–230 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#221

Post by davexunit »

alexpetros wrote: post #182
davexunit wrote: post #170

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…

This is correct, but... logic belongs in attribute strings! Even in basic HTML, it can change what kind of HTTP request your makes, or what kind of value your sends, or where your link goes. Without question, there's a low er expressivity ceiling to attribute-based specifications, but there is a lot that you can do within that ceiling, and you benefit in other ways by keeping your application at that "level," so to s…

I think this is a bit of reductionist interpretation of what I'm saying. Yes, it's technically correct that the attributes on a form change the type request made. That's not really what I'm talking about, though. In the same way that I wouldn't want to manually type a lot of CSS into a style attribute, I wouldn't want to write a small program in an hx-trigger attribute. Something like hx-trigger="input changed delay:500ms, search" is getting rather complicated, imo, and it's a new DSL with new semantics to understand. And then the recommended escape hatch is... yet another new language? I dunno I just feel like there's something missing here.

Re: Is htmx Just Another JavaScript Framework?

#222

Post by vlod »

eugenekolo wrote: post #18

Haven't heard of htmx before, but I might use it on a future project if I remember. As somebody who is not a frontend engineer, but still likes to make a website every now and then. I haven't found a full framework (vue, react, etc.) that I've been able to go full into and still use jquery and writing plain css/html. Htmx looks like a slight feature upgrade to jquery that I enjoy.

I just watched this video: "HTMX For React Developers in 10 Minutes" [0] that you might like as an intro.

[0] https://www.youtube.com/watch?v=r0XBULqzsT0

Re: Is htmx Just Another JavaScript Framework?

#223

Post by paulddraper »

karmarepellent wrote: post #86
crftr wrote: post #21

HTMX aims to render itself obsolete by serving as a proof of concept to advance the HTML specification. In various interviews and blog posts, Carson has mentioned that jQuery was essential only until browsers implemented features like `querySelectorAll`. The discussion about Library vs. Framework misses the core objective of the HTMX project.

Are you sure HTMX aims to be eventually incorporated in some form or another into the HTML spec? I think I read most of the blog articles on the website but I cannot remember such a statement. Another question in the same vein: In your view, why is it so important for the project to advance the HTML spec? By the way I am actually curious about this, I am an avid user of HTMX, but have never contemplated this. Edit: O…

It's not so much that HTMX itself would be included, as much as its philosophy of improved HTML.

Re: Is htmx Just Another JavaScript Framework?

#224

Post by cosmojg »

chatmasta wrote: post #117
exabrial wrote: post #94

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…

It sounds like your devs are not following best practices with regards to lockfiles and version pinning.

Lockfiles and version pinning are bandaid solutions to be applied in the absence of resources for supporting new versions of libraries, especially given that, unless you maintain your own internal package repositories, you're then dependent on those ancient versions remaining available through your usual channels for the unforeseeable future. On my team, we stick to pulling the latest versions of dependencies, but we run our CI/CD pipeline on every commit and hold onto the logs from the last few successful builds. When it's clear that a dependency upgrade has caused a failure, we check to see if we can afford the work we'd need to do to accommodate the new version, and only if it's nontrivial do we resort to pinning the dependency (but it's usually trivial). Even then, the intention is that this is a temporary workaround until we have the time and people required to make the change.

Using lockfiles and version pinning by default opens you up to all sorts of issues. Breaking changes accumulate, and you'll fall further and further behind, increasing the development effort required to get up to date. If you ever want to use some hot, new library that just dropped with a must-have feature for your project, you're highly likely to run into a conflict that will force you to make all those changes you've been procrastinating. Of course, you'll also find yourself stuck with whatever security vulnerabilities exist in your pinned version of the dependency, to be discovered and exploited at some future date. This is a complete nonstarter in my field of work.

Re: Is htmx Just Another JavaScript Framework?

#225

Post by hobofan »

diggan wrote: post #135
hobofan wrote: post #115

Earlier quoted context omitted.

But when you initially setup a React project, do you write the code that bootstraps the application? Or do you just run (`pnpm create vite` +) `pnpm run dev` and the application figures out what to load, and starts the application for you? We can do this all day...

When you initially setup a React project, you run `npm install --save react react-dom` or similar, create a HTML file that loads a JS file that you also need to write, that includes a call to `ReactDOM.render` somewhere. That's it, no more, no less. Contrast that with rails where you run `rails new $app`, then `rails server` and everything is made for you. Not sure why you're mentioning vite here, we're explicitly ta…

`pnpm create vite` is one of the modern alternatives of `create-react-app`, which isn't maintained anymore.

It fills the exact same role as `rails new $app` does of scaffolding a project, which apparently is a hallmark of a framework. So where does "wrappers or tooling around them" start and end? Why shouldn't we count `create-react-app` (which was maintained by the React team), but count `rails new`?

All this just goes to show that the "you have to call the entrypoint" distinction you are trying to declare is just as fuzzy as most other library vs. framework definitions.

There is next to no difference in hand-writing an essentially fixed entrypoint of React.render vs. getting that file autogenerated vs. calling a "binary" (that is also just an interpreted script that contains the same entrypoint).

Re: Is htmx Just Another JavaScript Framework?

#226

Post by sebastianconcpt »

I've recently adopted htmx from a Smalltalk backend and feels lovely.

When coding to do that it felt like a library and not a framework and provides a lot of flexibility in design options.

And I agree that the backend should do as much HTML as possible but some times you still need to do things with js. Bu again the backend can send the html plus the bits of js specific for that UI screen or component and that's super flexible and efficient if you keep it properly factored and with nice separation of concerns.

Here is a talk where I've made the case for a particular stack and demoed it last November in the Smalltalks 2023 conference https://www.youtube.com/watch?v=4_gmvN0pimI

Re: Is htmx Just Another JavaScript Framework?

#227

Post by paulddraper »

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.

Web Components are how you can create user-land HTML elements.

But there is a widespread desire for better native HTML elements.

E.g., a date range input.

Re: Is htmx Just Another JavaScript Framework?

#228

Post by davexunit »

nine_k wrote: post #197
davexunit wrote: post #170

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.

Give a programmer a non-Turing complete language and they will use a Turing complete language to compile down to it. When a program is only configurable in YAML, someone will use jinja2 to generate it so they can have loops. SASS exists because CSS isn't expressive enough. Etc. etc. etc. I just really don't subscribe to purposely limiting expressive power via non-Turing completeness. I've never wanted to do this in my own software and it's only ever been a roadblock for me to route around as a user. Spent a lot of time in DevOps where this sort of thing is rampant.

Re: Is htmx Just Another JavaScript Framework?

#229

Post by drbawb »

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…

I agree with your definition, and I also believe it's an important distinction and a _better definition_ than the article author's. However I'm not sure I agree with your self-assessment of htmx being a library.

HTML is not the host programming language: that'd be JavaScript. Arguably, in this case, it's also whatever is on the other side of the HTTP requests htmx is making; which is almost certainly _not_ HTML.

htmx is maintaining its own event-loop (to react to DOM changes, read attributes, auto-wire itself, etc.), it's _calling into_ the user's code, either via the _declaratively configured_ HTTP endpoints when reacting to DOM events, or via callbacks provided by your event subscribers. These reactions were not explicitly programmed by a library-user in JavaScript, the host language. They were configured in markup and your framework altered its internal state and event-processing accordingly based on that configuration.

It is very much magic, and very much behaves like a framework. (I say this with the utmost respect, I don't think "framework" is a dirty word or anything. htmx is great conceptually, you've done a fantastic job implementing it, and it's a blast to use. I don't think it being a "framework", per this definition, detracts from what it is. I think it can also compete with other frameworks _just fine_ without needing to twist semantics.)

htmx's model is no different to me, conceptually, than Phoenix, Rails, et al. "magically" knowing which controller & action to invoke because I declared a route somewhere in a DSL, which they in-turn invoke to respond to an event. (I definitely don't consider either of those to be libraries.) What sets htmx apart is that it's a small, focused, _easily understood_ framework.

I do understand the need to differentiate htmx from the contemporary burdensomely-complex JS frameworks, but I don't think framework v. library is the right way to frame it.

Re: Is htmx Just Another JavaScript Framework?

#230

Post by twic »

jbverschoor wrote: post #89
hobofan wrote: post #34

Earlier quoted context omitted.

> Eventually, htmx semantics will become part of the web standard Why do you think that will be the case? I'm not aware of any effort being made to evolve htmx into a web standard (either by introduction into existing specifications or direct adoption by browser), so this is about as baseless of a claim as someone saying "I see JQuery as a future polyfill" in ~2006.

Because it's a damn good name. As a matter of fact, when I read about HTMLX, I assumed it was a browser supported feature that I had missed

The X is a bit meaningless though. Xtended? It could have leaned into the hypermedia angle and been Hyper-HTML, or H2ML.
Post reply on HN