Apple vs Oranges: A complete comparison.
Both are fruits though. Similarly these are also both front end library/framework.
Htmx vs. React: A Complete Comparison – Semaphore
21–30 of 88 posts
Re: Htmx vs. React: A Complete Comparison – Semaphore
#22As 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
what about jsx? i find it an amazing mix of html and js
and what kind of data management do you mean? for a SPA most people use react query in place of redux these days, otherwise with something like remix you don't need any external data lib
Re: Htmx vs. React: A Complete Comparison – Semaphore
#23As 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
JSX is just one-to-one syntactic sugar for a createElement call ( 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.
React `createElement` is not the same as `document.createElement`. The exact behavior of react elements still has a lot of complexity IMO. A react element is not analogous to a DOM element. It's more like a factory for creating a DOM elements. You can put the same react element in a document twice, no problem. That doesn't work for DOM elements. That's just the tip of the iceberg.
Re: Htmx vs. React: A Complete Comparison – Semaphore
#24We'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`.
Sure, that's true. Under the same rule, C also isn't typed because void pointer casts are possible.
Re: Htmx vs. React: A Complete Comparison – Semaphore
#25Earlier quoted context omitted.
JSX is just one-to-one syntactic sugar for a createElement call ( 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.
i just struggle with hooks, data management, how data flows in between components etc etc
You 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!
Re: Htmx vs. React: A Complete Comparison – Semaphore
#26React 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
#27Re: Htmx vs. React: A Complete Comparison – Semaphore
#28React 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?
That'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.
Re: Htmx vs. React: A Complete Comparison – Semaphore
#29Earlier quoted context omitted.
JSX is just one-to-one syntactic sugar for a createElement call ( 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.
React `createElement` is not the same as `document.createElement`. The exact behavior of react elements still has a lot of complexity IMO. A react element is not analogous to a DOM element. It's more like a factory for creating a DOM elements. You can put the same react element in a document twice, no problem. That doesn't work for DOM elements. That's just the tip of the iceberg.
This is because you define what you want the components result to be. But not how to do it.
The return of a component render is a description of more work to do. When that’s done is up to reacts scheduler.
Once react has rendered a tree it then commits it to the dom.
Manipulating dom elements at runtime is imperative work. Doing it server side you get the same declarative capability as react, but no runtime behaviour.
React elements not being 1:1 with the DOM is what enables us to also target native, tuis, and so on.
Re: Htmx vs. React: A Complete Comparison – Semaphore
#30Earlier quoted context omitted.
JSX is just one-to-one syntactic sugar for a createElement call ( 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.
i just struggle with hooks, data management, how data flows in between components etc etc
Data flows top down, from parents to nested children, either explicitly via props or made available as context by parent providers. If data needs to be sent upwards, the parent component must send down a callback which the nested component can call.
Hooks are frankly something that you just have to put work into learning though as they can’t be succinctly explained. It’s worth the effort though.
Where ordinary programming paradigms result in tangled and messy state, and pure functional paradigms try to pretend state doesn’t exist and stick it all in a monad, hooks provide a framework to handle state in a way that composes much like pure functions do.