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

41–50 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#41

Post by dvogel »

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.

When I initially read the htmx documentation I was confused because it kept talking about a hypermedia client. The context clues suggested they were referring to htmx but my brain kept saying "isn't the browser the hypermedia client?" Eventually it sank in that htmx is an extension of the hypermedia client. When I first tried to use htmx I experienced a lot of discomfort regarding areas where htmx feels non-standard, such as redirects in the hx- readers on a 200 response. Once I understood that htmx is explicitly trying to move the boundary of the hypermedia client a lot of that discomfort melted away.

Re: Is htmx Just Another JavaScript Framework?

#42

Post by unsupp0rted »

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…

People use it for the sake of not using JavaScript.

To a React client-side developer everything should be done in React on the client-side, with maybe a sprinkle of backend for unavoidable things, like where API keys live.

They’ll foot-gun as much backend stuff into the front end as possible.

To a certain kind of backend developer, everything should be done typesafe in non-JavaScript on the backend, with a sprinkle of client-side JavaScript for unavoidable things like showing/hiding elements. Of course even for this, 10 lines of CSS is preferable to 1 line of JS.

They’ll foot-gun as much client-side stuff into the back end as possible.

Re: Is htmx Just Another JavaScript Framework?

#43

Post by quonn »

danielvaughn wrote: post #25
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.

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…

That‘s why there is a lock file. The package manager and node version can likewise be locked.

Re: Is htmx Just Another JavaScript Framework?

#44

Post by quonn »

intrasight wrote: post #19
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.

The problem is that it's no longer an "interpreted" language.

How is that a problem?

Re: Is htmx Just Another JavaScript Framework?

#45

Post by intrasight »

hobofan wrote: post #34
intrasight wrote: post #14

I prefer to refer to htmx as a "future polyfill". Eventually, htmx semantics will become part of the web standard, and older browsers (or those that choose not to implement the feature) will need this polyfill.

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

s/will/may

It may be aspirational on my part, but I do hope that HTML can evolve. JQuery isn't a good analogy as it's not extending HTML.

Re: Is htmx Just Another JavaScript Framework?

#47

Post by hobofan »

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 component from it's parent component.

Re: Is htmx Just Another JavaScript Framework?

#48

Post by giraffe_lady »

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…

If we're judging by things I've seen at profitable companies the past, present and future is php.

Re: Is htmx Just Another JavaScript Framework?

#49

Post by lurking15 »

dvogel wrote: post #41
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.

When I initially read the htmx documentation I was confused because it kept talking about a hypermedia client. The context clues suggested they were referring to htmx but my brain kept saying "isn't the browser the hypermedia client?" Eventually it sank in that htmx is an extension of the hypermedia client. When I first tried to use htmx I experienced a lot of discomfort regarding areas where htmx feels non-standard,…

Yes htmx is an augmentation of the browser, specifically through enhancing HTML by way of JS. The idea is that JS frameworks became popular due to the lack of additional hypermedia controls which are the basis for how agents (users) interact with websites through hypermedia clients (browsers).

Re: Is htmx Just Another JavaScript Framework?

#50

Post by palmfacehn »

danielvaughn wrote: post #25
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.

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.

Post reply on HN