Any 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 w…
Htmx vs. React: A Complete Comparison – Semaphore
41–50 of 88 posts
Re: Htmx vs. React: A Complete Comparison – Semaphore
#42I 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.
Re: Htmx vs. React: A Complete Comparison – Semaphore
#43React and HTMX aren't addressing the same problem domain. This comparison is about as meaningful as any could be under that constraint.
Why is "dynamic web app without page reloads" not the same domain?
Re: Htmx vs. React: A Complete Comparison – Semaphore
#44Earlier quoted context omitted.
i just struggle with hooks, data management, how data flows in between components etc etc
Hooks making things complicated, before that it's actually simple, let's try to talk with class-based component. There's only two kinds of data inside a component (class-based), first is props. Props is, similar with html attribute, are given to the component by the caller / owner / parent. ` ` has type as the props key, and "password" as it's value. State is data that lives inside a component and cannot in any way a…
Other than being overly verbose, I think React is ok after building my website with Sveltekit. There just seems to be way more support for off the shelf react components and 99% of jobs ask for React.
Re: Htmx vs. React: A Complete Comparison – Semaphore
#45We'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`.
Re: Htmx vs. React: A Complete Comparison – Semaphore
#46You 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.
Re: Htmx vs. React: A Complete Comparison – Semaphore
#47Re: Htmx vs. React: A Complete Comparison – Semaphore
#48Re: Htmx vs. React: A Complete Comparison – Semaphore
#49For 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.
Presumably they’re using preact for a fairer comparison.
Re: Htmx vs. React: A Complete Comparison – Semaphore
#50Earlier quoted context omitted.
You'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.
Yes, 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".
Many languages do have sound type systems, and I would argue we should prefer those.