Hacker News Reader

Comment by xvinci | Hacker News Reader

I am still trying to get HTMX adopted in a ~ 800 employee software development company. And while we do not yet have a project using HTMX in production, I like to use it a lot in thought experiments with mentees: Could you do it with HTMX / Fragments? If yes, how would you design it? Do we REALLY need an SPA?

Kudos to the developers.

View on HN

I do think "use HTMX" is a tough sell for a 800 employee company, just because it doesn't really solve issues on it's own. (Imagining the pitch is "add HTMX to an existing project") Going all-in on hypermedia definitely means the service that serves your application needs to be more than just a JSON parrot. Templating HTML and sending the right chunks back is hard to do if those services aren't built around being hypermedia services.

I really like turbo-rails [0] (the ruby gem that Rails 7+ bundles in for turbo support, meaning helpers that make turbo frames/responses a native "thing" rails understands) because it's a complete solution. There's at least some obvious structure to build off of, and I'm not stuck trying to build up my own framework on the BE for my newly simpler FE.

django-htmx [1] also fits in this case too. I feel like any honest pitch of HTMX should involve some BE solution as well.

[0] https://github.com/hotwired/turbo-rails

[1] https://github.com/adamchainz/django-htmx

I dont intend it to be an all-in, but I do believe it could do the job in 50% or more cases just as well as any SPA framework. A lot we do is "just crudl" with some sprinkles on top.

A large chunk of our business comes from Spring Boot, so we are experimenting with JTE - looks decent so far (Thymeleaf feels just old nowadays).

My sell is pretty simple: You have regulations coming up in europe which will require you to keep applications up-to date and secure. Extending your SBOM by 1k NPM libraries is a huge cost. I want to get rid of that.

I tried to get HTMX adopted for a new project but the unanimous response was "what is this? why not React? everyone knows React. period" and most of my arguments for HTMX were ignored, because to most people, HTMX looked like some obscure, yet another JS framework created last week, with questionable future.

The reason is because all new technology is a staffing and training problem management needs to solve. Someone has to maintain your thing after its built and be ready when you leave the organization. If React can solve the issue in a similar timeframe and level of effort and it is easy to source React developers then obviously your proposal will be rejected because React is simply far easier to deal with from a training and staffing perspective for what you are trying to do. You need more merits to warrant the introduction of new languages and frameworks.

Very anti React person went for Svelte but the kind of modularity React offers, HTMX can't hope to match especially on larger projects.

Modern React is too simple. A component is just a pure function taking arguments and returning UI as JSX. The only other thing you need to know is few hooks.

maybe you can send me to the right tutorial. I'm a backend, distributed systems engineer. I have worked on eye-watering scale. React is anything but simple to me.

I tried create-react-app, the thing built and downloaded for several minutes, and then there was a nest of file relationships that I didn't grok. It seemed like any change required three files to be updated. Lots of ancillary things like bundlers, packers, tree shakers, lions, tigers, and bears, oh my. After an hour, I didn't get what I was doing. Somehow, altering this function over here made this other thing over there go "moo."

I used to do web development back in like 2001. I understand the web, http, css, html, and basic js. I'm not up on all the latest, but I have a very firm base.

I got htmx working and pretty much fully digested in the same amount of time I wasted on React and have produced a working prototype. I find htmx to be like how the web used to be. It makes sense.

FWIW, create-react-app is overloaded with every package you could ever potentially want to use for some weird reason. It's way overkill and I wouldn't recommend using it.

It's much better just to use Vite with React as a plugin. Then you only need to install three React packages to get your app going.

The best tutorial I've used was "Road to React" by Robin Weiruch. His example app you learn is how to build a Hacker News front page. Very clear and it goes step by step.

Most of the tutorials online are all over the place, or mix Class tutorials with Hooks tutorials, or starts adding in things like Redux (which aren't needed).

The person you're responding to is correct, at it's core React is very simple, especially if you just stick to hooks. Most of my code is just bog standard HTML (as JSX), CSS and JS with a few React hooks thrown in.

FWIW, I've been doing frontend dev since '94 and personally find React jives the most for me and how normal HTML/JS/CSS work. I can see why people would like HTMX, but I've never liked overloading HTML attributes as some strange event model. But it's good there are choices.

React has very good documentation and an excellent tutorial. Here is a link to it: https://react.dev/learn . I recommend doing the exercises. They really help you learn React.

Create React App should not be used because it is no longer maintained. Here is its GitHub repro: https://github.com/facebook/create-react-app/commits/main/ . It has had very few updates since July 2022. This is bad because it needs constant updates because it depends on a large number of packages and those packages are constantly releasing security updates.

That doesn't sound like a good selling point for react.

create-react-app is not react

While true, if cargo was exploitable we'd say it was rust.

To be fair, this would be more analogous to some random person creating a crate called 'create-rust-app' and then abandoning it. Hardly a signal that Rust is dead.

Never said it was saying react/rust were dead, I said it "doesnt look good". Those words were not in my mouth.

I understand your confusion and dismay over React because I'm myself a backend developer and the kind of complexity doesn't exist in backend tech stack.

But this all or none of it has anything to do with React rather with a broken language design which never imagined anyone would write JavaScript worth more than a few paragraphs in a single file.

That's where tons of bundlers come into play from parcel and webpack to vite.

But then there are some language extensions that must be transpiled before they can be bundled. Your JSX comes to mind.

Typescript can be considered in the same league.

Minus all that - Modern React has a very minimal surface area, very few concepts and that's about it.

> Modern React is too simple. A component is just a pure function

React is simple only in some mathematical theoretical sense, but not for understanding by human minds which fundamentally operate imperatively ("if I click on this, load data X from the server and show them to the user...").

You can get some hello world example relatively easily, but you hit the complexity wall quite quickly (need to know "some hooks" - some, like useEffect() are very complex, yet often needed for basic things). The worst of all is debugging with stacktraces making no sense with it all being from the React itself, not your code, not tracking some logical pathway.

(I'm saying that as someone who generally likes React and would choose it for a new project)

useEffect is simple. If I recall correctly, with no arguments it is like onMount and with the dependent variables listed in array, it would be executed every time any of the listed variables change.

> The only other thing you need to know is few hooks.

And where you can't use them. Hopefully there are zillions of YT videos from experts teaching you all react gotchas.

> The only other thing you need to know is few hooks.

...and then draw the rest of the owl.

try passing state around the component hierarchy and see how simple it is. HTMX makes it easy but centralising the state in one place ie the server. try coming back to your code base in a year or two and see how simple it seems then :D

Except when your state appears in many parts of the page, HTMX makes it hard to keep everything updated.

Fully ack. But this can actually be turned into something good imho: I try to challenge all layers (Analysis, UI / UX design) on simplicity: "Do we really need X parts of the page all be affected / updated by something? How could we design it differently with locality in mind? Can we simplify the state somehow?" -> I think that the resulting solutions are often simpler, cheaper, and work just as well.

agreed: htmx is good for "swap out this one element and its children". It is not good for "and these other related elements need to update"

> It is not good for "and these other related elements need to update"

That seems a bit backwards, no? Why can't those other elements manage their own updates? You can have the server respond with an `HX-Trigger` header to dispatch an event and any elements that care about that event can listen for it. Far simpler than trying to coordinate surgical DOM updates in a single HTTP request.

Events form the backbone of the browser environment and leaning into that model makes a lot of things much easier

To a certain extent, it works, but there's definitely a point of complexity that you can hit in the app at which it becomes painful. Those are the kinds of apps where htmx is just not a good fit.

Not any more complicated than passing parameters to a function.

If that is actually the case, there is an issue with your component design.

You pull the state up. Props down.

Of course you get pushbacks. Is there any *real* advantage, technical or otherwise, at an organization level, of adopting this new model of creating web pages, other than your personal preferences? You are moving away from an established system with tools that everyone is familiar with, to a system that much fewer people use, with no clear performance/maintenance/management benefit (at least not demonstrated). Maybe you don't like writing JS/TS, but plenty of other people do, and they don't need to cater to your preferences.

People need to spend time learning this tool. They need to be proficient with it. Your new stack might need to still work with existing code at some point. That means training, overhead, ramp up and potential risk in a less established area. Why would people do that?

You should be thankful you didn't get warnings from your boss for messing around instead of actually pushing features out.

To be fair, it's not an unfair response. Being able to hire for a technology, and having a large community around the tech stack you use has tangible value.

HTMX might not be something that will vanish in a week, but it's also nowhere close to a mainstream framework.

That's a fair response:

https://htmx.org/essays/when-to-use-hypermedia/#if-your-team...

the reality is that the only way to prove htmx is around for the long term is to stick around for the long term, and I hope this essay contributes towards that.

We'll see how this years JS rising stars shakes out.

Same story here, although the poison of choice is angular.

I built an HTMX fragment framework for Django. It allows you to render a fragment, and automatically serves the fragment separately for live-updates. I'll open source it tonight and post back.

In my opinion, HTMX + custom elements does everything React does but better, and is a billion times cleaner.

> I'll open source it tonight and post back.

Would be interested in seeing this

Sounds great!

Reply on news.ycombinator.com