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

61–70 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#61

Post by jabradoodle »

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.

For one thing I may have very simple requirements that I don't want to buy into maybe a day long setup for, nor hand write js when html could support it.

Re: Is htmx Just Another JavaScript Framework?

#62

Post by testermelon »

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

htmx is not a framework, or even library. it's only one implementation of an idea. an idea that needs to be implemented by the browser instead of something external like a js file.

Re: Is htmx Just Another JavaScript Framework?

#63

Post by diggan »

dad_chowder wrote: post #11

> But you can write React in this library-like manner too and nobody argues that React isn’t a framework. I think people do still make this argument

I'd absolutely make the argument that React isn't a framework, because by my definition it is a library, not a framework. https://news.ycombinator.com/item?id=38953266

Re: Is htmx Just Another JavaScript Framework?

#64

Post by mythz »

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.

Reasons why I no longer prefer SPA's:

  - Build tools are complex
  - Large FX's have 100's of npm dependencies
  - Every SPA I've created has suffered from bitrot overtime, including:
  - Often breaking changes on upgrade, incompatibility between package versions
  - Dependencies/tools/fxs often abandoned, rewritten, replaced, etc
  - Constantly wasting time working around issues
  - Doesn't scale, the larger the App, the slower initial load and slower the FCP
  - Heavy client state and need to manage client routing
I now prefer using #NoBuild [1] ESM builds of progressive JS FX's for adding behavior to static rendered content where each page only loads the JS it needs, which ends up being much simpler [2] and resolves these issues I used to have with SPAs. Blazor with static rendering and Enhanced Navigation is even nicer which gives SPA-like navigation responsiveness without SPA-like complexity [3].

[1] https://world.hey.com/dhh/you-can-t-get-faster-than-no-build...

[2] https://servicestack.net/posts/javascript

[3] https://servicestack.net/posts/net8-best-blazor

Re: Is htmx Just Another JavaScript Framework?

#65

Post by songbird23 »

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.

this is super helpful take. i get it now

Re: Is htmx Just Another JavaScript Framework?

#66

Post by msolberg »

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 big frameworks that I don't have the time to fully understand.

I know this doesn't add to the conversation very well but I just want to throw it out there that htmx is a good replacement for a larger framework that you don't fully understand.

Also shoutout aplineJs for making small JS changes easy.

Re: Is htmx Just Another JavaScript Framework?

#67

Post by donatj »

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…

This is exactly what we’re dealing with right now trying to upgrade TypeScript. We’re stuck on an early version of 4.X because of some dependency triangle I haven’t had time to work out.

Re: Is htmx Just Another JavaScript Framework?

#68

Post by yoyohello13 »

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.

Re: Is htmx Just Another JavaScript Framework?

#69

Post by jabradoodle »

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.

Re: Is htmx Just Another JavaScript Framework?

#70

Post by ahmedfromtunis »

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

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

Does the lock file render the need to update dependencies obsolete?

Of course not. It just avoids that the build system *automatically* updates X to 1.2.3 and *accidentally* breaks your code. But when it's time to bump the version up a notch, that very fragile equilibrium may suddenly crumble.

Lock files are not a substitute for sane dependency management.

Post reply on HN