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

51–60 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#51

Post by wmfiv »

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.

One challenge a bundler and transpiler introduce is they enable an unconstrained set of solutions.

If a particular application has 10 patterns that support all the applications UI interactions, then a simple, constrained solution like htmx that supports those 10 patterns is preferable (to me) than an unconstrained solution like Typescript + React where each developer will likely use their creativity and experience to design slightly or wildly bespoke solutions for each feature.

Re: Is htmx Just Another JavaScript Framework?

#52

Post by resoluteteeth »

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…

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

This is true. However:

> Say you use python and Django. Why use htmx instead of Django templates?

This doesn't make sense and makes me think you might be confused about what htmx is. The purpose of htmx is precisely so you can just use things like django and render pages on the server but still make a website feel more like a modern website by replacing elements without having everything require a whole page reload and without having to write your own javascript code.

That said, I personally think there are reasons why approaches like what htmx does fell out of favor.

Re: Is htmx Just Another JavaScript Framework?

#53

Post by game_the0ry »

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 :)

Re: Is htmx Just Another JavaScript Framework?

#55

Post by metaltyphoon »

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…

Because just like ASP Razor templates, you still need to write JS for anything basic and with htmx you can get to 80/20.

Re: Is htmx Just Another JavaScript Framework?

#56

Post by leetrout »

hobofan wrote: post #47
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...

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…

My favorite quip (not mine): somethings wrong when express is a "framework" and react is a "library".

Re: Is htmx Just Another JavaScript Framework?

#57

Post by sodapopcan »

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…

Things need time to take hold while people unlearn what they thought was "law". Python had its time of being "the new hipster language" (in whatever disparaging vernacular we used back then, I'm too old to remember)

Re: Is htmx Just Another JavaScript Framework?

#58

Post by yoyohello13 »

palmfacehn wrote: post #50
danielvaughn wrote: post #25

Earlier quoted context omitted.

I don't know how build systems work at lower levels, but things move so fast in the web development world that it renders your codebase inoperable if you don't maintain it. I've had a codebase that sat for as little as 6 months without me touching it. When I tried to run it again, I ran into so many compatibility issues that I had to tediously copy out all of my code into a new project and then fix the remaining issu…

Inevitably someone will respond claiming that if you don't like the current ball of duct tape, it is because, "you haven't wrapped this weeks hottest flavor of duct tape as yet another layer on top" There's something seriously wrong with modern front end tooling when the norm is downloading hundreds of dependencies to display semi-interactive text in a browser.

> downloading hundreds of dependencies to display semi-interactive text in a browser.

I think you mean thousands.

Re: Is htmx Just Another JavaScript Framework?

#59

Post by jacobyoder »

quonn wrote: post #38
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…

Dependency management is an unrelated issue and it exists for any platform. Unless you copy paste code or unless you just avoid dependencies. Which is easy to do in TypeScript as well. Nobody says you need to install hundreds of packages.

> Nobody says you need to install hundreds of packages.

If I need one, I have to get that package's dependencies. People don't choose to say "Damn, I'd really love to have 1800 dependencies!" But if you have 4-5, you automatically get dozens or hundreds out of your control.

Yes, could you build everything yourself by hand? Sure. That's a hard sell to many depts/projects. "This will take 3 weeks to build" vs "This will take 4 minutes to npm install". That 4 minutes is introducing a lot of potential risk and headache and time later, but it's providing immediate relief.

FWIW, "dependency management" is a problem in every platform, but I have nowhere near the same number of issues in the composer/php world (nor previously in the maven/java world) as I do in the npm/js world.

Re: Is htmx Just Another JavaScript Framework?

#60

Post by diggan »

hobofan wrote: post #47
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...

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. But then there are tons of frameworks that uses React, nextjs is probably one of the more common ones.

Post reply on HN