8 ms·

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

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/ https://unpkg.com/browse/htmx.org@1.8.2/dist/ [2] https://unpkg.com/browse/preact@10.11.2/dist/ https://unpkg.com/browse/preact@10.11.2/dist/ [3] https://preactjs.com/guide/v10/getting-started#no-build-tools-route https://preactjs.com/guide/v10/getting-started#no-build-tool...

flexterra 4y ago
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.
- ksbrooksjr 4y ago
  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-webpack https://preactjs.com/guide/v10/getting-started#aliasing-in-w...
  - flexterra 4y ago
    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.
    - strife25 4y ago
      +1 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.
      - ec109685 4y ago
        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.
    - ksbrooksjr 4y ago
      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.
      - yawaramin 4y ago
        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.
- zarzavat 4y ago
  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?
  - flexterra 4y ago
    Here's the sortable example: https://htmx.org/examples/sortable/ 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.
- password4321 4y ago
  > The server returns HTML So back to ASP.NET WebForms update panels?
Void_ 4y ago
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.
- ksbrooksjr 4y ago
  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-preact https://github.com/vercel/next.js/tree/canary/examples/using...
- ipaddr 4y ago
  Was the worry Aug 17 less than two months ago a sign the project was abandoned? Daily changes would worry me more.
  - eyelidlessness 4y ago
    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.
- rrdharan 4y ago
  > 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?
criddell 4y ago
If you want a non-JavaScript client, ditch the browser all together and build a native client.
- lliamander 4y ago
  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.
  - criddell 4y ago
    I'm suggesting not using HTML for the client. Anything running in a browser is heavy and slow compared to well written native code.
    - lliamander 4y ago
      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).
nateberkopec 4y ago
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.
- ksbrooksjr 4y ago
  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.

flexterra 4y ago

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.

ksbrooksjr 4y ago
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-webpack https://preactjs.com/guide/v10/getting-started#aliasing-in-w...
- flexterra 4y ago
  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.
  - strife25 4y ago
    +1 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.
    - ec109685 4y ago
      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.
  - ksbrooksjr 4y ago
    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.
    - yawaramin 4y ago
      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.
zarzavat 4y ago
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?
- flexterra 4y ago
  Here's the sortable example: https://htmx.org/examples/sortable/ 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.
password4321 4y ago
> The server returns HTML So back to ASP.NET WebForms update panels?

Void_ 4y ago

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.

ksbrooksjr 4y ago
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-preact https://github.com/vercel/next.js/tree/canary/examples/using...
ipaddr 4y ago
Was the worry Aug 17 less than two months ago a sign the project was abandoned? Daily changes would worry me more.
- eyelidlessness 4y ago
  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.
rrdharan 4y ago
> 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?

criddell 4y ago

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

lliamander 4y ago
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.
- criddell 4y ago
  I'm suggesting not using HTML for the client. Anything running in a browser is heavy and slow compared to well written native code.
  - lliamander 4y ago
    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).

nateberkopec 4y ago

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.

ksbrooksjr 4y ago
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.