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

151–160 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#151

Post by gofreddygo »

quonn wrote: post #130
gofreddygo wrote: post #73

Earlier quoted context omitted.

> what's the problem with a bundler/transpiler Problem is why do we even need one? All I'm trying to do is for my client code to update a part of the page and not the entire page. Why do I need to even introduce concepts of bundling and transpiling for this pig-headed simple task ? Further, react has a steep learning curve that a backend person need not be subjected to. And it evolves, so that search-copy-paste phase…

They don‘t start if they use complex frameworks, many dependencies, don‘t use lock files, don‘t lock their package manager and don‘t lock nodeJS and don‘t use Docker. If they use plain TypeScript and plain React, have a lock file, lock their package manager version and lock their nodeJS version and optionally ship a sane Docker setup they will certainly run. It is true that it would be nice to have a single tool that…

Lockfiles aren't a magic bullet. They point to an a specific old version of all internal dependencies. That still requires the maintainer of each of my dependencies to have published a patch to an OLD version when vulns show up.

And the alternative of typscript + react + nodejs + npm + docker for a damn web based UI is just terrible ! Sorry, no bueno.

I don't want to be at the mercy of all the maintainers of my dependencies. So clearly, I need to cut down on my dependencies. htmx is a great middle ground. Clearly, you can now at least see the appeal of htmx + a backend service for a robust though not fully optimized web based app.

And I can't see the JS ecosystem's last 10 years as outright "progress", but rather a series of experiments, that work for some and don't for others.

Re: Is htmx Just Another JavaScript Framework?

#152

Post by recursivedoubts »

jslakro wrote: post #110
internet101010 wrote: post #81

Earlier quoted context omitted.

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?

Scripting is part of web development, htmx endorses hypermedia-friendly scripting:

https://htmx.org/essays/hypermedia-friendly-scripting/

https://hypermedia.systems/client-side-scripting/

Re: Is htmx Just Another JavaScript Framework?

#153

Post by recursivedoubts »

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…

:) that's great to hear man

Re: Is htmx Just Another JavaScript Framework?

#155

Post by dfabulich »

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 of your code as a library instead of a framework.

Instead, I urge you to describe HTMX as a "lightweight HTML framework."

Re: Is htmx Just Another JavaScript Framework?

#156

Post by recursivedoubts »

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…

htmx 2.0 will be 99% compatible w/ htmx 1.0, and we'll provide a backwards compatibility extension:

https://github.com/bigskysoftware/htmx/blob/v2.0v2.0/www/con...

we will also continue to support htmx 1.0 for the forseeable future for people who need IE support or don't want to upgrade

Re: Is htmx Just Another JavaScript Framework?

#157

Post by recursivedoubts »

intrasight wrote: post #107
jbverschoor wrote: post #89

Earlier quoted context omitted.

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.

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

Re: Is htmx Just Another JavaScript Framework?

#158

Post by quonn »

gofreddygo wrote: post #151
quonn wrote: post #130

Earlier quoted context omitted.

They don‘t start if they use complex frameworks, many dependencies, don‘t use lock files, don‘t lock their package manager and don‘t lock nodeJS and don‘t use Docker. If they use plain TypeScript and plain React, have a lock file, lock their package manager version and lock their nodeJS version and optionally ship a sane Docker setup they will certainly run. It is true that it would be nice to have a single tool that…

Lockfiles aren't a magic bullet. They point to an a specific old version of all internal dependencies. That still requires the maintainer of each of my dependencies to have published a patch to an OLD version when vulns show up. And the alternative of typscript + react + nodejs + npm + docker for a damn web based UI is just terrible ! Sorry, no bueno. I don't want to be at the mercy of all the maintainers of my depen…

Many of these libraries cannot have meaningful vulnerabilities. What‘s a possible vulnerability in lodash that can be exploited without already being able to inject code?

Furthermore, any vulnerability in a dependency could also exist in code written by myself or a team member. And then never get fixed or even found.

Re: Is htmx Just Another JavaScript Framework?

#159

Post by sureglymop »

smallerfish wrote: post #28

htmx + kotlinx.html + kotlinjs is an excellent combo that gives you an MPA that looks and feels like a modern webapp, with minimal stack complexity, and fully typesafe/compiled UI code. I'm also layering in tailwind & flowbite. With the hotswapagent project, you get hotswap that works for when you're building out UIs. One day I'll blog about this stack in more detail and post here.

This sounds interesting. Would you be so kind as to explain how to set this up or link to an example?

I do have experience with plain kotlin but googling yielded not many results on how to integrate all these components you mentioned into a basic MPA. So - blog post encouraged :)

Re: Is htmx Just Another JavaScript Framework?

#160

Post by infamia »

iterateoften wrote: post #71
hellcow wrote: post #26

Earlier quoted context omitted.

> You set it up once. It takes a few hours, maybe a day. Until you need to update a dependency on a large codebase, which takes weeks because dependency A doesn't work with dependency B version X, and updating dependency B means that it no longer works with dependency C version Y, and so on. And nobody uses dependency C anymore -- it's unmaintained, so you need to rewrite everything to use dependency D. Then you need…

Seems a bit of an over reaction. Never experienced anything like you say since working with typescript after working on multiple billion+ $ SaaS apps. It’s basically the same as any other language.

Did you not deal with the debacle of js changing imports how imports work? That was absolutely miserable and js libraries have a very short half life indeed. JavaScript's culture of small, relatively short lived libraries makes maintaining a JS app particularly miserable for many (see the comments affirming this misery). It is not anything close to the same.
Post reply on HN