Hacker News Reader

Comment by MrWiffles | Hacker News Reader

What's the actual advantage of HTMX over something like React or Vue? All 3 require some form of JavaScript library coupled with markup to build interfaces. While I'm all about killing JavaScript as much as possible (why should I let $MEGACORP execute code on my device all willy-nilly without any real restrictions?), I just don't see the tangible benefit to the end user here.

(And don't start with "it's faster/more efficient", that comparison isn't terribly valid because the inefficiencies seen with React/Vue are largely an artifact of bad code/practices, not the libraries themselves.)

View on HN

You can generate your HTML using a server-side template, and it is mostly just HTML.

> All 3 require some form of JavaScript library coupled with markup to build interfaces.

With HTMX you're typically including one static javascript file that you just download, you're not using any kind of javascript build system at all. Where it has very limited scope it's possible to imagine a browser that doesn't have javascript but that has HTMX built in.

Calling it a javascript library might be a bit much, I mean you're not typically installing this with node/npm, or minifying it, or importing it. You're just including it in a script tag at the bottom of your site. While they both do technically run on javascript I think they have more differences than things they have in common, and saying "Well they're both just javascript libraries" is a very sophomoric take. I mean you might as well just say that all javascript libraries are the same, and it doesn't matter what you use. So why choose react/vue over jquery?

> inefficiencies seen with React/Vue are largely an artifact of bad code/practices, not the libraries themselves.

Ehh, I'm sure you can make a fast bug-free website in server-side assembly if you're so inclined but it's probably not the right tool for the job. The question is what kind of design patterns do the libraries/tools encourage, not "can I do X with Y".

I want to note that Vue provides official instructions on how to use it without build tools [1], and lots of folks who have written posts on how to use React without tooling as well [2]. I agree that they're ultimately designed to be used with tooling, but it's not a blanket requirement.

- [1] https://vuejs.org/guide/quick-start.html#without-build-tools

- [2] https://blog.jim-nielsen.com/2020/react-without-build-tools/

The main advantage I see of traditional server side rendering (like in Rails/Django) is that you develop a single project, not two (SPA + API).

Instead of api models and client models, you just have models.

Instead of api routes and client routes, you just have routes.

Instead of unit testing api and client, you test one project.

Instead of having the client making N requests to load all the data it needs from the server (and being careful not to return more data than you need for performance reasons), you return an html with all the data it needs in a single request, and nothing more.

In the case of client stacks using SSR (like Next/Nuxt):

Instead of running the SPA on the server so the server returns the html rendered, you just make the server return the html rendered.

The benefit to the developer is higher productivity. The benefit to the end user should follow from that.

The tight coupling removes a lot of scalability possibilities though. I understand the higher productivity argument, but wouldn't it be time consuming on the long run to lock yourself in an environment where you would have to go back and build an API if you want to extend your web app to mobile for example?

It depends on the needs of the mobile version. Often, a well designed responsive version of the same web app is enough. Even if it's a mobile native app, you might still be able to reuse some/most of the screens with the same html in a webview.

Even if you really needed it to be an API, you can always make the server side return either html or json depending on some request header. There's also a chance that the mobile version will be different enough from the desktop that it warrants new, custom built endpoints anyway.

Web devs have zero right to run their javascript disasters on my computer. Htmx outsources 99% of the rendering and logic to the server, where it can use up their valuable time.

Why stop there? They should get their own end users as well.

If you hate it so much just turn off JavaScript and enjoy waiting for the page to reload every time you click on anything

Which is often faster than the response time of a client side app.

Great! Enjoy it!

Can you further explain your principles around the web? I'm curious to hear more. For instance, it sounds like you don't think web sites ought to be able to distribute JavaScript which executes on your computer in order to generate a user interface, but it seems you do think web devs have the right to utilize your internet bandwidth to download markup from a server in order to generate a user interface. Is that the case, and if so, why do you make that distinction?

Maybe GP wants to access the information and not the unnecessary local processing?

Edit: wording

Theoretically my local computer is faster to render something than my network connection can download the pre-rendered content.

However, 99% of javascript blobs of hatred end up slower than downloading the pre-rendered content.

One big advantage is simplicity: you eliminate the need for a lot of client side technology, such as routing, and push everything back to the server.

Also, by eliminating application javascript, it allows you to spend more time in your preferred language on the back end.

The downside is the same as regular HTML, although less pronounced: since you are driving application state through hypermedia (HATEOAS), the less coarse-grained your state or UI gets the more annoying things are going to be. There are some patterns that help but eventually, if you want to update 12 different places in your UI at once on every keystroke, the hypermedia approach just isn't going to cut it.

> Also, by eliminating application javascript, it allows you to spend more time in your preferred language on the back end.

But these days (using transpilers and/or WebAssembly) you can choose just about any language on the front-end ...

That's true and, in the case of pyscript in particular, may limit the appeal of something like htmx.

On the other hand, the simplicity of the hypermedia approach, and the flexibility of ReST are still there.

We'll see.

It's faster. React apps often load hundreds of KBs - if not MBs - of code before they start to work. HTMX loads 10KB (gzipped).

Then use Preact, Solid or its ilk. Then your bundle size is going to be a tiny fraction of the kinds of things users tend to like, such as images.

Doesn't really matter unless you're targeting low-bandwidth customers. The Amazon homepage is ~4MB, and an average user session is going to downloading many times that in additional images and markup while browsing. In that context, React or other JS files will be single-digit percentage of what was downloaded.

The idea is that the js is used to implement the functionality that the author believes should be built-in. In theory you could have a browser plugin/extension for handling htmx and it would work across every site using htmx. You app-specific "code" is all declarative, just extra properties in your html tags. With most frontend frameworks, even if the browser came with built in support for Vue, React or whatever, you'd still tons of imperative js for each single webapp to define how it uses the framework.

Imagine not having html at all. You'd have to create pages from scratch imperatively by doing things like let element = createElement("p"); element.setContent("my paragraph"); parent.addChild(element); It'd be really ugly, a PITA to change stuff and error-prone. htmx is the opposite of that. It tries to make web development declarative again, among other things.

Without any real restrictions? JavaScript is very restricted in what it can do. Most APIs that you'd expect to be gated behind a permission are gated behind a permission.

I think the article kind of explains it pretty well.

It kind of returns to the original intention of the web.

Reply on news.ycombinator.com