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

231–240 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#231

Post by runarberg »

tangue wrote: post #168
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.

Yep in 2024 we still haven’t found a generic datepicker and hundreds of people on the internet are coding their own version. HTML5 snafu

What is wrong with ?

Re: Is htmx Just Another JavaScript Framework?

#232

Post by theultdev »

recursivedoubts wrote: post #218
theultdev wrote: post #213

Earlier quoted context omitted.

centralizing would be using HTMX and authoritative servers. local-first is more decentralized as your clients can sync directly with each other (or through a dumb proxy for NAT punching) I see no need for servers to be anything but dumb proxies for clients. Not the opposite of making clients dumb terminals.

welp, when you are coordinating things it's often a tremendous simplification to have a centralized source of truth and then present representations of that truth in the form of hypermedia to hypermedia clients, using hypermedia as the engine of application state of course, it's not right for everything and there are alternative approaches that work better or worse, depending on context, but i'd say it's hard to not…

a centralized source of truth is a pretty successful approach to distributed systems?

seems more like a successful escape hatch. yes it's simpler, but it's antithetical to the goal.

Re: Is htmx Just Another JavaScript Framework?

#233

Post by chatmasta »

cosmojg wrote: post #224
chatmasta wrote: post #117

Earlier quoted context omitted.

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…

> Using lockfiles and version pinning by default opens you up to all sorts of other issues

Agreed this is a tradeoff. That's why you need a rigorous auto-update process. Your approach works too, it's just a question of when you want to detect failures caused by an upgrade

Regarding security, you're still vulnerable until you update. In your approach, you couple those updates with ongoing development. But what if nobody's pushed code for a month? You'd probably want automated upgrades, right? So in that case why not pin your dependencies too?

> you're then dependent on those ancient versions remaining available through your usual channels for the unforeseeable future

It's a safe-ish bet that versions will remain available on npm since it's not possible to unpublish a package from there after 72 hours of publishing it.

But you don't need to rely on the registry if you cache your dependencies, and you can take more advanced measures to hold onto that cache. In our codebase we build Docker images from every commit, and for the JS images we store the Yarn cache in a shared Docker layer. This was a bit finicky to get working, but isn't strictly necessary anyway since the final build includes the node_modules too. So we have reproducible builds at the application level, but we also hold onto all versions of Docker images (tagged by commit, and only rebuilt when their source changes), so we have reproducible deployments and - crucially - the ability to rollback to an earlier version without relying on any external dependencies.

This was not an easy system to build, but it's more of a general devops problem than one that's limited to any specific packaging system. Our monorepo includes JS, Python, C, Lua, and a bunch of other languages and packages. I will say that the code for making Python properly reproducible was a lot more complicated (we use Pants and some hackery for generating a locked requirements.txt).

Re: Is htmx Just Another JavaScript Framework?

#234

Post by jsunderland323 »

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 has always been my take too, it reeks of a DSL. It's sort of like a no-code/low-code solution for people overwhelmed by the complexity of the FE ecosystem and/or those who don't want to learn anymore web technology but are proficient backend engineers. This is a completely understandable feeling and I have this feeling almost every day. I think DSLs that abstract markup work great for personal projects (just as a CMS works great for personal websites and marketing blogs), but for anything that starts picking up utility you will inevitably have to do something that breaks out of the DSL's abstraction.

Here's my fear of using DSLs like htmx. At first the escape hatch is your friend but eventually the project stops being an htmx project and becomes a "hyperscript" (or equivalent) project. For anything that reaches maturity, you're then left with the painful task of figuring out how to port hyperscript and htmx to react/vue/svelte (the very thing you were trying to avoid in the first place). This is way harder and more painful than using one of these frameworks as a foundation for your project.

What I don't get is why people that harbor this resentment to FE tech, don't just limit their feature usage. Think server components are dumb -- don't use them! Think react hooks are stupid -- write class components! In the event you actually have to do something that requires you to do something outside of your comfort-zone, you just have to push a little bit of your react/vue/svelte knowledge instead of appending more escape hatches to an increasingly bastardized DSL abstraction.

Re: Is htmx Just Another JavaScript Framework?

#235

Post by [deleted] »

endisneigh wrote: post #24

htmx is one of those things, like SQLite on the server, that you will incessantly see on HN, but rarely see used at large profitable companies. Say you use python and Django. Why use htmx instead of Django templates? Same with ruby and rails, elixir and phoenix, etc. the trend is clearly towards live view/hotwire OR things like server side react. Htmx is in a weird position that makes no sense unless you want to use…

[deleted]

Re: Is htmx Just Another JavaScript Framework?

#236

Post by mlhpdx »

As a humble, new user of HTMX I don’t care what noun you choose for it (stereotyping by another word still smells the same). The facts as I have experienced them are a) it’s simple to do simple things; and b) it keeps difficult things possible. My highest praise. So, I’m using it. I’m a bit of a nut, and my backend is pure AWS Step Functions. Declarative web app, all the way down.

Yes, because of HTMX the backend is different than it would be with “plain” HTML or the JS framework du jour. But, the backend is very simple and clean, so I agree it has a nice influence whatever y’all decide to call it.

Re: Is htmx Just Another JavaScript Framework?

#237

Post by bilalq »

mlhpdx wrote: post #236

As a humble, new user of HTMX I don’t care what noun you choose for it (stereotyping by another word still smells the same). The facts as I have experienced them are a) it’s simple to do simple things; and b) it keeps difficult things possible. My highest praise. So, I’m using it. I’m a bit of a nut, and my backend is pure AWS Step Functions. Declarative web app, all the way down. Yes, because of HTMX the backend is…

What do you write your step functions in? Are you using ASL or something that compiles to it?

Re: Is htmx Just Another JavaScript Framework?

#238

Post by tarcon »

croes wrote: post #8

>But you can write React in this library-like manner too and nobody argues that React isn’t a framework. >React - The library for web and native user interfaces https://react.dev/ https://www.reddit.com/r/reactjs/comments/126uzfo/why_is_rea... https://medium.com/@Angie.O/why-react-is-a-library-and-not-a... https://www.oreilly.com/library/view/what-react-is/978149199...

If you use hooks, react expects code in certain places and in a certain order. At that point, react becomes framework-y.

Re: Is htmx Just Another JavaScript Framework?

#239

Post by briantakita »

alexpetros wrote: post #178
tangentstorm wrote: post #93

> Even though you aren’t writing the 3P code yourself, by including it in your project you are committed to understanding it—and refreshing that understanding if you want to upgrade it. This is a nice thought, but I suspect hardly anyone who uses a framework or library really understands it, or makes the commitment to try. Obviously, a subset of really talented users eventually learn to understand the framework, but…

The main point I'm trying to make here is that even if you're in the "leap of faith" category, you still on some level have to understand the framework constructs (i.e. its API) in order to make use of it. If that API changes with a new version, and you want to upgrade, you're going to have to learn enough about that new API to make the upgrade. Obviously you benefit from understanding the internals too, but realisti…

> Obviously you benefit from understanding the internals too, but realistically, the more complicated the thing you're using, the less of the internals even a motivated user is going to bother with.

This is a problem that grows with a large library...An api change has a higher cost than with a smaller library. Smaller libraries also tend to be easier to fully understand. Large libraries tend to be more of a "leap of faith" than small libraries.

Re: Is htmx Just Another JavaScript Framework?

#240

Post by leptons »

dfabulich wrote: post #141
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.

I'd love to see something like HTMX get standardized, but I'm extremely pessimistic for HTMX's prospects for standardization in HTML. In talking to a few standards folks about it, they've all said, "oh, yeah, you want declarative AJAX; people have tried and failed to get that standardized for years." Even just trying to get to target a section of the page that isn't an has been argued about and hashed out for years.…

HTMX breaks the "separation of concerns" paradigm. It's not going to help anyone doing anything complex, and it's going to be a crutch for anyone getting started. It breaks down quickly when the problem is anything more complex than clicking a button to load some content, and then what - rewrite everything in a more capable framework?
Post reply on HN