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

101–110 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#101

Post by karmarepellent »

iterateoften wrote: post #88
karmarepellent wrote: post #80

Earlier quoted context omitted.

But it is not a given that the scope of the problem eventually exceeds what HTMX is capable of. It is perfectly fine to set HTMX aside and choose another framework if you feel that it better suits the problem at hand. Meanwhile there is still a ton of projects for which HTMX is more than enough (and always will be). So what you are mentioning is not an issue of HTMX, but one of "chosing the right tool for the problem…

That’s fair. I guess my comment was inadvertently responding to another about why you don’t see it at large companies. One team at my company wanted to use HTMX and write the product with it and then the PM kept asking for features to bring it to parity with the rest of the application with regards to client side behavior and things devolved. They used hyperscript and eventually the frontend was just rewritten to be…

Well I would not dare going through the hassle of moving from React to something like HTMX if the former is already well-established in the company, except when everyone is on board. So I totally get that.

Re: Is htmx Just Another JavaScript Framework?

#102

Post by dragonelite »

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…

Yeah that was the same impression i had of HTMX it makes sense to integrate HTMX functionality into HTML 6 or whatever.

Re: Is htmx Just Another JavaScript Framework?

#103

Post by deliriumchn »

quonn wrote: post #12

So what's the problem with a bundler/transpiler etc? You set it up once. It takes a few hours, maybe a day. Then your platform _is_ TypeScript + React. This abstraction basically never leaks. I never need to look at the transpiled files to find an error. Nobody argues that a C compiler is worse than assembly or that drivers or an operating system are bad.

> It takes a few hours, maybe a day.

Even then, most of the times it doesn't take even an hour because majority of people will grab default config or use something that allows no-config (parcel, vite, etc)... Some are fine with default CRA for a long time until they really need something custom, for example.

Re: Is htmx Just Another JavaScript Framework?

#104

Post by mring33621 »

endisneigh wrote: post #79
yoyohello13 wrote: post #68

Earlier quoted context omitted.

> Why use htmx instead of Django templates? HTMX is meant to be used WITH backend framework templates. The point of HTMX is it allows you to use your backend templating system to return pieces of HTML instead of JSON. We are using it at our org for our intranet applications and it's been great so far.

I understand that, but why? You can write the entire thing in Django alone and use Hotwire and not use any JavaScript to begin with.

I would say that Hotwire is somewhat a competitor to htmx.

Re: Is htmx Just Another JavaScript Framework?

#105

Post by radlad »

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…

Maybe not an explicit aim, but it sounds like Carson Gross holds a positive view of browsers implementing these features directly: https://news.ycombinator.com/item?id=35831981

Re: Is htmx Just Another JavaScript Framework?

#106

Post by karmarepellent »

afavour wrote: 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.

> It's a way of making a web site where you write less JS.

It bothers me that this point always comes up when a discussion about HTMX arises. For me writing less JS is just a very pleasant side-effect of using HTMX. But the main benefit is just having (nearly) everything in one place (the backend). It is just so much easier to reason about the code.

Re: Is htmx Just Another JavaScript Framework?

#107

Post by intrasight »

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

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.

Re: Is htmx Just Another JavaScript Framework?

#108

Post by jokethrowaway »

taeric wrote: post #96
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…

This feels extreme? Any chance you could share numbers or more details on these prototypes? I agree that the ecosystem seems crazy fast on moving. I wouldn't have thought it was that bad. React, in particular, I thought had been fairly stable? (Yes, there are new ways of doing things, but most of the old still work there, to their credit.)

I don't think it's been the case for the last few months in particular, but Next has been historically terrible for this case. It sucks because it's also the best way of developing a React app without worrying much about tons of boilerplate crap.

I have different next projects started at different times and whenever I need to change a single line of text, I have a 50% chance something won't work and I'll have to debug some error coming from the intersection of different versions of node being used in the JAM host. I got hit by OpenSSL issues for a static website. Then a potential solution is to upgrade the framework (next or react) but then you start running into a bunch of other issues and you find yourself 8 hours deep for a copy change.

Performance is also a pain to get right as the abstractions keep piling up and especially the rendering cycle of React is a massive pain. The move from class to functional (for the majority a net positive as the functional version is way more readable and clear) made accessing some hooks harder, so know you need to remember some special rules or functions to call in order to get the behaviour you want.

For all new projects I just use solid.js which is a bit nicer compared to React while keeping most of React syntax. The abstraction layer is much smaller compared to React (no vdom, no custom rendering cycle, your function gets executed once, not once per re-render). You just have to remember you are dealing with Proxy instances and you're good to go.

Somehow I didn't have problems with updates but there is way less activity compared to React. I have some projects from 3 years ago just using solid.js, and a bunch of projects with solid-start. I didn't bother updating them, they keep on running, can't complain.

Re: Is htmx Just Another JavaScript Framework?

#109

Post by ajayvk »

msolberg wrote: post #66

As a devops engineer who has recently been tasked with building UIs for our team and our developers, HTMX is a godsend. I create apps that often get steadily worked on for weeks and then only maintenance once and a while after that. I used to write django apps, but recently switched to a go backend with go html templates and htmx. This allows me to push everything in one docker image and avoid the black box nature of…

Hypermedia based web applications are a great fit for developing internal and operational tools. I have been building https://github.com/claceio/clace for making development and deployment easier for such web apps.

Re: Is htmx Just Another JavaScript Framework?

#110

Post by jslakro »

internet101010 wrote: post #81
msolberg wrote: post #66

As a devops engineer who has recently been tasked with building UIs for our team and our developers, HTMX is a godsend. I create apps that often get steadily worked on for weeks and then only maintenance once and a while after that. I used to write django apps, but recently switched to a go backend with go html templates and htmx. This allows me to push everything in one docker image and avoid the black box nature of…

Alpine + htmx + tailwind is pretty much what I use for every quick little front-end thing now. I do still use Django but plan to transition to Rust as a way to get more comfortable with Rust.

What do you use alpine for? htmx is not enough?
Post reply on HN