Hacker News Reader

Comment by ksbrooksjr | Hacker News Reader

Htmx is great for developers who need client side interactivity, but would rather not write any js. If you don't mind writing a bit of js however, you can't go wrong with Preact. Same api as React, but at a fraction of react-dom's bundle size. It looks like the minified source is even smaller than htmx (which is already very minimal) [1][2]. They've also packaged Preact in such a way that you don't need to add a build step to use it [3].

[1] https://unpkg.com/browse/htmx.org@1.8.2/dist/

[2] https://unpkg.com/browse/preact@10.11.2/dist/

[3] https://preactjs.com/guide/v10/getting-started#no-build-tool...

View on HN

The programming model is totally different when working with HTMX. The server returns HTML instead of a JSON API which is the usual solution when building apps with React/Preact and similar.

Yea htmx definitely has a different programming model than an SPA style framework like React/Preact. I actually like the JSON api programming model where the backend is as simple as possible, and the frontend js/ts code is completely responsible for handling the UI, but I guess it's a matter of personal preference.

The linked article is referring to a team switching from React to htmx though, so for them I'd imagine it would've been a much easier transition if they'd just added a Webpack alias[1] that replaced React with preact/compat, rather than switching to a completely different UI paradigm.

[1] https://preactjs.com/guide/v10/getting-started#aliasing-in-w...

The difference in programming model IS THE advantage of HTMX. Changing from react to preact is a perf optimization.

If you are doing the SPA thing correctly you must duplicate business logic (data validation). Also when your API just sends "dumb data" (JSON) to the client, you are forced to make changes to the backend and frontend in lockstep.

SPAs were a workaround to slow CPU servers serving millions of requests in the mind-2000s. Client computers were faster, so it made sense to push UX logic there.

We've flipped things around. Servers are fast as hell for rendering HTMl. We can leverage that and re-focus the client on UI code that only it can do.

They were also in response native mobile applications and desire to have a single api tier for all applications.

That and the panacea of being able to run same javascript on server and client.

According to the article we're commenting on, the programming model is not the sole reason for switching from React to Htmx. Look at the executive summary's bullet points. Four of them are related to performance (build time, time to interactive, data set size, and memory usage). Performance might not be the reason you personally use Htmx, but it's certainly put forward as an advantage in the article which we're commenting on (which is from the htmx team by the way).

I've often seen this meme repeated in debates that js frameworks require you to duplicate logic between the server and client, but most of the logic isn't being duplicated between the client and server, it's being moved from the server to the client. It's relocation, not duplication. Instead of your rails/django controllers deciding what html to render, that decision happens on the client. In this model your server is mostly just an authorization layer, and an interface between the user and the database. Hasura, Firebase, Firestore, Mongodb Realm, and several other products have been successfully built around this premise. You might not like the thick-client thin-server model, which is completely fine, but it's a somewhat subjective preference. The only objective criteria you might use to decide which approach to use is performance.

The article we're commenting on dedicates an entire section to talking about the dev team makeup and how it completely changed and unified the team approach to being fullstack. That's how thoroughly htmx changed the programming model.

You haven't disagreed with anything I said. My original comment says "Htmx is great for developers who need client side interactivity, but would rather not write any js". I'm sure a team of Python developers is enjoying not writing Javascript. My point is that you don't have to switch to a completely different paradigm to reap the performance benefits that the article lists.

I didn’t read the comment as disagreeing either. Sometimes people are commenting not to disagree ;)

I read it as a straw man argument, but that might not have been the author's intention at all. It's hard to judge tone through text alone.

Wouldn’t that also work the other way around?

Move to a JS backend and now every dev on the team can write client and server side code?

People certainly unify their stack on JS that way. For Contexte their team was one React/JS dev, two Django/python, and one full stack. So they had two and a half people writing python and one and a half writing Javascript before, then three python developers after.

Switching to JS would require a full backend rewrite. The backend devs may not do well with the switch, so they may have let go two developers and needed to hire a new JS dev. The presenter may have been let go with that approach, clearly not ideal for the person driving the project.

You'd also need to address the perf issues. htmx clearly sped things up. Is the alternative JS SSR?

"We are fond of talking about the HOWL stack: Hypermedia On Whatever you'd Like. The idea is that, by returning to a (more powerful) Hypermedia Architecture, you can use whatever backend language you'd like: python, lisp, haskell, go, java, c#, whatever. Even javascript, if you like.

Since you are using hypermedia & HTML for your server interactions, you don't feel that pressure to adopt javascript on the backend that a huge javascript front end produces. You can still use javascript, of course, (perhaps in the form of alpine.js) but you use it in the manner it was originally intended: as a light, front end scripting language for enhancing your application. Or, if you are brave, perhaps you can try hyperscript for these needs.

This is a world we would prefer to live in: many programming language options, each with their own strengths, technical cultures and thriving communities, all able to participate in the web development world through the magic of more powerful hypermedia, rather than a monolith of SPAs-talking-to-Node-in-JSON.

Diversity, after all, is our strength."

https://htmx.org/essays/a-response-to-rich-harris/

Validating data on the client and not doing it again on the server will lead to security vulnerabilities. At the very least you will end up duplicating that validation code.

If I were using htmx I would still want to validate data on the client and the server. If you don't validate data on the client, then you're effectively allowing clients to DDOS your server with invalid data.

Client side validation does not protect against that. You can't prevent people from making requests to your server without your client, i.e. `curl https://example.com/api --data 'dkfjrgoegvjergv'`.

Well yeah obviously you can bypass the client code and directly connect to a server. That's not my point.

Client side validation doesn't prevent a malicious user from sending invalid requests, but it can prevent legitimate users from sending invalid data to your server accidentally. In fact, if I see validation failures showing up in my server logs for something I know should have been filtered out via client side validation, I can mark that ip address as being potentially malicious and rate-limit their future requests.

And as a user I would rather find out about validation issues immediately instead of waiting for a network round trip to the server. If I'm typing in a password for example and it doesn't meet the website's length/complexity requirements, I'd rather know as I'm typing instead of waiting for an HTTP request to complete. That extra HTTP request is wasting the user's bandwidth and the server's resources.

How do you implement, e.g. a sortable table if the server sends HTML rather than JSON? Have we gone full circle and gone back to jQuery?

Here's the sortable example: https://htmx.org/examples/sortable/

IMHO something slightly more complex than this example (more client side stat) will require using something like React/Vue/Svelte. But there's no need to rewrite the whole FE. Just create a component that performs the rich client side interaction and use HTMX for the rest of your app. Win-Win.

> The server returns HTML

So back to ASP.NET WebForms update panels?

I was just picking technology for my new landing page and was looking into Preact first.

I wanted basic SSR and things like that. Preact has a library called preact-cli for this. The last commit is from Aug 17.

I ended up with SvelteKit. It just felt much more alive. I don't love learning a new technology just for a landing page, but that was kinda fun.

Svelte is another great option with a much smaller footprint than React. If you don't feel like setting up SSR by hand, you can also just use Next.js which works fine with Preact [1].

[1] https://github.com/vercel/next.js/tree/canary/examples/using...

Was the worry Aug 17 less than two months ago a sign the project was abandoned? Daily changes would worry me more.

Especially given the team has been actively working on a major version for several months and released an impressive improvement to their state model in the last month. They’re active and thoughtful about what they ship.

> The last commit is from Aug 17. I ended up with SvelteKit. It just felt much more alive.

I don’t understand - are you saying you think a project whose most recent commit was Aug 17, 2022 is not alive?

Preact is not a good comparison. If it "has the same API as React", then it's not solving any of the problems that the post talks about.

Bundle size is 1 problem of JS-heavy SPAs but the post goes into many other drawbacks not addressed by something like Preact.

Preact would solve most (if not all) of the performance problems listed in the executive summary of the post (build time, time to interactive, memory usage, and maximum data set size). It doesn't seem like a terrible comparison to mention a framework with the exact same api as the one the team in the post was using for 2 years before adopting htmx.

It's a pretty short post, but a lot of it boils down to the fact that the team is using a single language throughout the whole stack (Python), which allows everyone on the team to be a full stack developer. Like I said, if you're against writing js then htmx is probably a better solution for your team.

If you want a non-JavaScript client, ditch the browser all together and build a native client.

I think you have it backwards.

If you want to build a client using HTML, then targeting the browser is exactly the right choice.

Javascript-heavy SPAs are much closer to traditional native apps - and lose some of the benefits of running on the web/ in the browser as a result.

There's a lot more reason to consider native app if you are building an SPA than if you are building an MPA/SSR app.

I'm suggesting not using HTML for the client. Anything running in a browser is heavy and slow compared to well written native code.

I think there's an argument for HTML-focused clients - the whole web (including this site) benefits from hypermedia.

I'm less convinced about Javascript SPAs. Perhaps the biggest advantage is that you don’t have to "install" these apps. The browser just downloads the source and runs it automatically in a (somewhat) sand-boxed environment. Also, they work on "most" systems (though mobile vs. desktop is still a thing).

Reply on news.ycombinator.com