5 ms·
Htmx vs. React: A Complete Comparison – Semaphore
- curtisblaine 3y agoApple vs Oranges: A complete comparison.
- bugbuddy 3y agoBoth are fruits though. Similarly these are also both front end library/framework.
- levkk 3y agoWe've been using Turbo for over a year now (similar idea to Htmx). Pretty happy not to be using React anymore. Most of the complexity is offloaded to the backend where we can handle it better with a typed language system and no middle layer (e.g. GraphQL) between our app and the database. TypeScript is not typed fwiw, e.g. `as any`.
- SahAssar 3y ago> TypeScript is not typed fwiw, e.g. `as any`. So because it has a feature to disable typing it is not typed? Would you say the same thing for any language that has similar "unsafe" flags, like rust or basically all the others?
- levkk 3y agoYou'd have to try very hard to override a type in Rust when that type comes directly from your database (see SQLx). Rust unsafe features don't allow you to override type safety, but you can directly manipulate raw pointers if you're so inclined. TypeScript really does let you bypass the type checking entirely and drop down to just JavaScript.
- SahAssar 3y agoYes, typescript allows you to do that. It is entirely voluntary and you can do untypesafe things in almost any typed language. I'm not sure how that makes typescript "not typed".
- hellcow 3y agoI think the parent is simply pointing out that “Typescript’s types are not sound.” That is, the types at runtime may not be what you assumed at compile-time. This happens very often at API boundaries because fetch returns `any`. Many languages do have sound type systems, and I would argue we should prefer those.
- jakelazaroff 3y agoThe fetch issue (and JSON.parse/localStorage.getItem/etc) can mostly be mitigated by using type guards to “parse” data at the point of ingress.
- SahAssar 3y agoThat is certainly one interpretation, but even then within most compile-time but not runtime-checked languages you can usually perform runtime checks. For example I've used Zod (https://zod.dev/ https://zod.dev/) quite a bit in typescript to do runtime typechecks at the boundaries.
- throwanem 3y agoI don't know much about Rust, but it has the same problem, doesn't it? As I understand it this is something the serde crate (at least) is often used to solve. This is reasonable, given that untyped data received at a system boundary is going to need some kind of type checking no matter what the language or type system; I'm not sure that can even be fairly called a 'problem'. But it also would leave the putative line of argument rather footless, in that blaming Typescript for something Rust also requires is incoherent. Perhaps the originator of the claim under discussion will clarify his meaning.
- infogulch 3y ago| Static | Dynamic -------+--------+--------- Strong | Rust | (lisp?) Weak | TS | JS TypeScript bolts on a Static type checker onto JS, and the types are erased before running in a real JS runtime. At runtime the types can change out from underneath you for many local and nonlocal reasons. This is simply impossible in Rust in general.
- throwanem 3y agoSure, that's true. Under the same rule, C also isn't typed because void pointer casts are possible.
- dkjaudyeqooe 3y agohttps://github.com/hotwired/turbo https://github.com/hotwired/turbo
- throwitaway1123 3y agoWhat about the empty interface type in Go?[0] Is that just as problematic for you? [0] https://go.dev/tour/methods/14 https://go.dev/tour/methods/14
- throwitaway1123 3y agoCorrection: the empty interface is actually analogous to TypeScript's unknown type rather than the any type.
- ZeWaka 3y agoAs much as React is too wordy and bloated these days, this comparison seems extremely unfair, bordering on biased.
- recursive 3y agoFor web apps, you can't use react without react-dom. That adds 131kb. (for react-dom.production.min.js@18.2.0) Very misleading to say react is 6kb in weight.
- pier25 3y agoReact weight 6.4 kB? In which universe? React-dom alone is 42kB gzip. https://bundlephobia.com/package/react-dom https://bundlephobia.com/package/react-dom
- andai 3y agoPreact is 3kb and works as a drop in replacement for React (most of the time). It's also way faster.
- Octoth0rpe 3y agoSimilar to how the size of react without accounting for react-dom is deceptive, one is also unlikely to use preact without @preact/hooks and/or @preact/signals which increases the size somewhat. Still much, MUCH smaller than react though.
- kreetx 3y agoIs there a reason to use the original react, or will most libraries also work with preact, which is both faster and smaller?
- hankchinaski 3y agoAs a backend engineer I Still haven’t managed to learn how react data management or JSX works. Every time I try to dive into it I get a strong migraine. I hope something easier comes popular before I would need to learn FE
- recursive 3y agoHave you looked at htmx? Or even full vanilla?
- hankchinaski 3y agohtmx better i generally just use vanilla or jquery, htmx it's still bearable
- crooked-v 3y agoJSX is just one-to-one syntactic sugar for a createElement call (https://react.dev/reference/react/createElement https://react.dev/reference/react/createElement). You don't even need to use it with React, any library that defines an identical function interface will do.
- hankchinaski 3y agoi just struggle with hooks, data management, how data flows in between components etc etc
- firecall 3y agoYou are not alone! I found it useful to actually work through the React tutorials. Keep things simple and learn the simple use cases first. The world of React is now a very busy place, so trying to jump in to a full stack can quickly become overwhelming! FWIW I'm not a fan of how many React and GrpahQL frontends are built. For me it's a lot of complexity for little gain and plenty of pain!
- ummonk 3y ago
- redder23 3y agoWordPress just implemented the interactivity API, inspired of Alpine.js, using parts of Preact. It's really great and extensible, 10 kB only. https://wptavern.com/interactivity-api-prepares-for-its-official-debut-in-wordpress-6-5 https://wptavern.com/interactivity-api-prepares-for-its-offi...
- joegibbs 3y agoI think the list of features says it all. They're not exactly comparable, are they? I don't think there's even anything preventing you from using both with e.g. React on the backend and Htmx on the frontend to load in the HTML that React generates.
- sesm 3y agoReact on the backend + HTMX on the frontend would be hilarious. Someone should write a tutorial on this pretending to be serious.
- yawaramin 3y agoActually someone is already doing this. React components on the backend, rendered to static markup, sent over the wire to the frontend, which uses htmx. Someone tweeted about this recently.
- throwanem 3y agoReact and HTMX aren't addressing the same problem domain. This comparison is about as meaningful as any could be under that constraint.
- rrr_oh_man 3y agoWhy is "dynamic web app without page reloads" not the same domain?
- deleted 3y ago[deleted]
- hermiod 3y agoThat's certainly part of the domain of react applications. But there are a lot of react applications that aren't (really) in the domain of HTMX, like "local first" applications or other applications that rely heavily on browser js APIs.
- arandomusername 3y agoAbsolutely, but there's a huge overlap in terms of what react and htmx can serve. Most websites that use react, can just as easily use htmx.
- MatthiasPortzel 3y agoIt's a little like comparing HTML and JavaScript, isn't it? React is a JavaScript library (in the sense that you write your own code that calls React functions). Whereas HTMX doesn't integrate with your application logic at all. It provides a mechanism for placing your application components on the screen.
- SahAssar 3y agoAny time someone shows only HTMX examples without error handling I feel like they have not tried it in an actual use case. To me it feels non-obvious how to handle these non-happy-path things without having to write client-side code which is what I understood HTMX promised to do away with. In the traditional browser model that HTMX espouses to emulate and improve on we have form resubmitting (with a warning that it will resubmit data), we have different errors for if the server returns an error or if your wifi disconnected, etc. Those errors are perhaps not well designed, but they are there and explain what is happening. With HTMX (at least when I tried it) it just got swallowed and one had to write client side code to handle it.
- zaphar 3y agoTo be fair most framework and library examples or showcases never show the error handling or edge case pieces so I don't think it's unusual. htmx doesn't promise to do away with client side code. Most uses of it I see still have client side code. They tend to go in one of two directions with it. 1. Web Components to encapsulate client side error handling and behavior. 2. The hx-on attribute for scripted event handling. It's not really an anti Javascript library. It's more of a different approach to server side state synchronization. I have to dynamic apps I use for personal usages. One is an offline first spa app so htmx won't work well for it. It's all client side code with json apis. The other has no offline use case and htmx is a great fit for it but I still have several hundred lines of vanilla javascript in there for client side behavior bits.
- acrispino 3y agoWhere is this promise on the htmx website?
- _heimdall 3y agoHow errors are handled is often pretty specific to each use case. Sometimes it does make sense to send back an HTML fragment with an inline error message, or a fragment that gets injected as a toast notification. Other times you may want to redirect to an error page with a full page refresh. Depending on the HTTP request method used, you may be able to return an HTTP error response too.
- a_wild_dandan 3y agoComparing a view library to a full front-end framework feels...weird. Even granting this stretch, it makes bizarre claims: > Goal: Add modern interactivity features directly in HTML vs Provide a component-based, full-featured UI JavaScript library Ah, no. Anyone who's used React.js should know otherwise. React is a declarative view library. It doesn't even handle routing or app state management, let alone the requirements for a "full-featured UI." > [React] Features: [...] one-way data binding, state management These statements are between "weirdly put" to "outright wrong." > Learning curve: [Htmx] Gentle v. [React] Steep React is dead simple. Your `HelloWorld = () => <button onClick={console.log}>Hello!</button>`. The learning front-end development can certainly be steep, but React is light-years away from kitchen sink frameworks that have you fiddling with yet another templating engine, controller classes, etc. > React: A full-featured JavaScript library for building user interfaces based on reusable components written in JSX This conflates React, ReactDOM, and JSX. > Because of its unique approach to web development, React has a steep learning curve. Before building your first React application, you need to understand the concepts of SPA (Single Page Application), Virtual DOM, JSX, state management, props, re-renders, and more. This may overwhelm some beginners. You don't need literally any of this aside from `props`. If you do use JSX, then its syntax will feel far more familiar than `hx-get` or whatever. > SPA applications built in React usually contain a lot of JavaScript. That results in higher network utilization and client-side rendering times. This conflates React with frameworks like Create React App. It ignores alternatives with SSR like Next.js. Also: don't encourage people to make more SPAs with React. Please.
- arandomusername 3y ago> It doesn't even handle routing or app state management Doesn't it? [1] > another templating engine, controller classes, etc. Template engines are easier than React, considering it's generally as easy as {{ and }} inside html. Controller classes? It's as simple as print('<html><button>Hello!</button></html>')! > If you do use JSX, then its syntax will feel far more familiar than `hx-get` or whatever. Definitely not. Few attributes is a lot easier than JSX. [1] - https://react.dev/learn/managing-state https://react.dev/learn/managing-state
- lxe 3y agoHTMX relying on a server request to make even minor UI changes (e.g. their first example https://htmx.org/examples/click-to-edit/ https://htmx.org/examples/click-to-edit/) is wild to me. You might remember when a thing called DHTML revolutionized how JavaScript could be used to build interactive UIs on the web... why go back to pre-2001 era? I get it, SPAs are overkill, but swinging the pendulum all the way back is very strange.
- Karrot_Kream 3y agoWhat's a good middle ground for you? I don't intend to be combative at all, I just mostly hack on backend professionally and for fun so when it comes to evaluating frontend technologies I'm useless. Is it preact? Svelte?
- lxe 3y agoYou can make a reasonable interactive app with htmx + javascript, but tings will be rather barebones -- you'll need to invent some patterns outside of what HTMX prescribes. With react you get somewhat prescriptive low-level patterns when it comes to "managing data flow", so I would probably use react to keep things consistent.
- jddj 3y agoI've been seeing more lately that the stack is being mentioned as htmx+alpinejs. Not sure how long it'll be until the htmx part gets rationalised out in those instances. Maybe it won't, and people will keep shipping both. Stranger things have happened
- deleted 3y ago[deleted]
- recursivedoubts 3y agohttps://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/ https://hypermedia.systems/client-side-scripting/ https://hypermedia.systems/client-side-scripting/ I can understand the objection to the first request but the second is necessary to update state on the server. You could avoid the first request via scripting but the complexity, in my opinion in most cases, would not be worth it.
- exabrial 3y agoI’m sorry to be a naysayer… but you can’t say React is a better performant or higher scale when the user experience down right stinks. There are a few exceptions, but it is overused to the point of detriment of the entire web so some developer can scratch an over engineering itch.
- tills13 3y agoI sense just a little bias in this based on the table at the beginning of the article alone.
- recursivedoubts 3y agohtmx is not 2k, sadly it is 15k: https://bundlephobia.com/package/htmx.org@1.9.10 https://bundlephobia.com/package/htmx.org@1.9.10 the authors are confusing it with another package: https://bundlephobia.com/package/htmx@0.0.2 https://bundlephobia.com/package/htmx@0.0.2
- KatrinaKitten 3y agoReact is also not 6.4kb, it's 316kb for base React + 4.5mb for React DOM + who knows how much for any other library you decide to use.
- avtar 3y agoParent was referring to bundle sizes: - https://bundlephobia.com/package/react@18.2.0 https://bundlephobia.com/package/react@18.2.0 - https://bundlephobia.com/package/react-dom@18.2.0 https://bundlephobia.com/package/react-dom@18.2.0
- KatrinaKitten 3y agoI presumed, but either way you still have to consider that React's "6.4kb" is without any of the actual building blocks a web app will need, just the absolute bare minimum of what React itself needs.