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

71–80 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#71

Post by iterateoften »

hellcow wrote: post #26
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.

> 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.

Re: Is htmx Just Another JavaScript Framework?

#72

Post by modmodmod »

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.

best joke heard all day

Re: Is htmx Just Another JavaScript Framework?

#73

Post by gofreddygo »

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.

> 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 just never ends.

And then dependencies update. Another comment here details why that is a nightmare.

If you want to feel the pain, search for any react project from 2 years ago on github or even some showhn projects here. Literally none of them even start !

So you see htmx does address a group just like react does. Its a tool and it's great at what it does.

Re: Is htmx Just Another JavaScript Framework?

#74

Post by iterateoften »

The problem I have with this style of library for frontend dev work is eventually the scope of the problem exceeds what the library is capable of doing. Then you have to embed JS which then gets pretty messy and spaghetti code and enough of this you are right back to where you started setting up a JS build system to make up for the deficiencies. Only now it is worse because you are working around one library and you start fragmenting your app because you started with the wrong thing.

Re: Is htmx Just Another JavaScript Framework?

#75

Post by game_the0ry »

jabradoodle wrote: post #69
game_the0ry wrote: post #53

I never used or looked into htmx, but... I feel like htmx fell into the same hype-cycle as every JS framework - initial interest was enthusiastic, but will likely fade as folks use it in the real world and any holes in the things it tries to solve are exposed. On to the next, I guess... Or go back to Ruby on Rails :)

There are simple things it would be nice to do without either 1. A server + framework, 2. A full on SPA, 3. Hand writing tedious js. There is a nice sweet spot for htmx here; whether it can build the required network effect is another story, and not always reflective of the quality of the idea.

Don't get me wrong - I love the idea of an open source project pushing mainstream ideas of how tech should be done, but those projects should be scrutinized and will always need to prove themselves in real world implementations. When that happens, the tech needs to evolve, be well-documented, and well-maintained.

I think htmx is doing an admirable job so far.

Re: Is htmx Just Another JavaScript Framework?

#76

Post by bcrosby95 »

diggan wrote: post #60
hobofan wrote: post #47

Earlier quoted context omitted.

Yeah, that sentence surprised me too. While I generally would also consider React more a library than a framework, I think there are arguments to be made that it's a framework. If we go by the common "your code calls a library; a framework calls your code" distinction, then you definitely have to structure your components in a very specific manner so that the React internals can "call your code" to e.g. render one co…

One vital distinction is that even if you define 100 components, nothing will happen unless you call .render from react-dom. Nothing is automatically setup for you. Compare that to Laravel or anything else that is obviously a framework. You write code and put it in a file in the right place, and it gets picked up automatically, most of the time. This makes me still consider React a library, rather than a framework. B…

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

Re: Is htmx Just Another JavaScript Framework?

#77

Post by Cthulhu_ »

dartos wrote: post #29
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 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.

Re: Is htmx Just Another JavaScript Framework?

#79

Post by endisneigh »

yoyohello13 wrote: post #68
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…

> 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.

Re: Is htmx Just Another JavaScript Framework?

#80

Post by karmarepellent »

iterateoften wrote: post #74

The problem I have with this style of library for frontend dev work is eventually the scope of the problem exceeds what the library is capable of doing. Then you have to embed JS which then gets pretty messy and spaghetti code and enough of this you are right back to where you started setting up a JS build system to make up for the deficiencies. Only now it is worse because you are working around one library and you…

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".
Post reply on HN