Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx vs. React: A Complete Comparison – Semaphore

semaphoreci.com

Post reply on HN
Print view View original

31–40 of 88 posts

Re: Htmx vs. React: A Complete Comparison – Semaphore

#31

Post by SahAssar »

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 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.

Re: Htmx vs. React: A Complete Comparison – Semaphore

#32

Post by fendy3002 »

hankchinaski wrote: post #14
crooked-v wrote: post #13

Earlier 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

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 accessed by the caller / owner / parent. It can only be accessed by the component itself, or it's children if the component decided to pass it. In general, you'll use very few components with state in a single application unless you know what you're doing with it.

So about the data flow, generally data is handled (can be via state or state management libs, see later section) by higher ups (parent) component, and passed to it's children via props. Now the parent component, together with the the value passed, also pass function. The function can be called by the children to update the parents state.

As for data management, there's 2 way I usually handle it. First is using state management like mobx and passing it via several ways, usually using react context. State management libraries usually has section on this.

Second is to declare the data I needed on top most components (that's relevant to the data itself) via react context, and pass them either via props or make children access them via react context.

Re: Htmx vs. React: A Complete Comparison – Semaphore

#33

Post by a_wild_dandan »

Comparing 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 = () => Hello!`. 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.

Re: Htmx vs. React: A Complete Comparison – Semaphore

#34

Post by dkjaudyeqooe »

levkk wrote: post #3

We'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`.

https://github.com/hotwired/turbo

Re: Htmx vs. React: A Complete Comparison – Semaphore

#35

Post by koito17 »

crooked-v wrote: post #13
hankchinaski wrote: post #8

As 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.

> one-to-one syntactic sugar for a createElement call

Used to be, but you are right that JSX is a rather thin syntax over function calls. (The modern JSX transform now uses a _jsx and _jsxs call, depending on whether you are rendering a single child or an array of children).

See https://legacy.reactjs.org/blog/2020/09/22/introducing-the-n...

Re: Htmx vs. React: A Complete Comparison – Semaphore

#36

Post by levkk »

SahAssar wrote: post #19
levkk wrote: post #3

We'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`.

> 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?

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.

Re: Htmx vs. React: A Complete Comparison – Semaphore

#37

Post by whizzter »

hankchinaski wrote: post #14
crooked-v wrote: post #13

Earlier 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

I did also, many coming from classic programming that hasn't touched upon functional ways of thinking usually struggle since they're prone to shortcuts whereas React really likes you to keep everything as transformations (or as some would call it functional style).

Much React work these days is confined into components, people sadly over-do it also because they perceived Redux as overkill and try to shoehorn entire applications into core React hooks (that are mostly designed for smaller components or at most views).

This is needless when Redux (with Redux-toolkit) has recipies that solves the whole-app dataflow problems well (people have issues with Redux because their components got overly complex in the past by shoehorning component issues into Redux instead and now they're complicating things in the other direction).

First rule of not messing up React/Redux: Don't mutate data, 90% of messups I see with fresh people is breaking this. Everything should become transforms! To accomplish this the spread operator (...) in JS/TS along with map/reduce/filter are your biggest friends. (You can do optimizations but 98% of the time you won't work on big enough datasets that you need to do that)

Thus when you do setX (of state hooks) you set your transformed data, same with sending messages in Redux, your Redux reducer acts upon a message to transform the internal state.

Re: Htmx vs. React: A Complete Comparison – Semaphore

#38

Post by SahAssar »

levkk wrote: post #36
SahAssar wrote: post #19

Earlier quoted context omitted.

> 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?

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".

Re: Htmx vs. React: A Complete Comparison – Semaphore

#39

Post by sesm »

hankchinaski wrote: post #8

As 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

Now imagine how bad pre-react era frameworks were if the main selling point of React was “your SPA is now easier to reason about”.

Re: Htmx vs. React: A Complete Comparison – Semaphore

#40

Post by zaphar »

SahAssar wrote: post #31

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…

To 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.

Post reply on HN