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

71–80 of 88 posts

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

#71

Post by throwanem »

SahAssar wrote: post #63
throwanem wrote: post #59

Earlier quoted context omitted.

I 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…

I think we agree, or maybe you misunderstood what I meant?

We agree, yeah. My argument is just that if you're accurately describing the argument that 'levkk is making, then 'levkk's isn't a meaningful argument: doesn't really do anything to indict one language or the other, at least if I've correctly understood serde's usage in what appears very much the identical use case.

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

#72

Post by arandomusername »

hermiod wrote: post #28
rrr_oh_man wrote: post #26

Earlier quoted context omitted.

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.

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

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

#73

Post by avtar »

KatrinaKitten wrote: post #68
recursivedoubts wrote: post #64

htmx is not 2k, sadly it is 15k: 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

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

Parent was referring to bundle sizes:

- https://bundlephobia.com/package/react@18.2.0

- https://bundlephobia.com/package/react-dom@18.2.0

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

#74

Post by KatrinaKitten »

avtar wrote: post #73
KatrinaKitten wrote: post #68

Earlier quoted context omitted.

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

Parent was referring to bundle sizes: - https://bundlephobia.com/package/react@18.2.0 - https://bundlephobia.com/package/react-dom@18.2.0

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

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

#75

Post by fendy3002 »

jonnycoder wrote: post #44
fendy3002 wrote: post #32

Earlier quoted context omitted.

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…

I just learned React/Nextjs for a take home coding interview assignment. I used useState a few times. Why would I need redux when there’s useState and useContext? 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.

Don't use redux alone, use redux toolkit or mobx which are more simpler and newer. Sure, you don't need them and can be replaced with useState instead.

They shine when you need / can separate the business logic with ui. Think about state management as "backend" for your frontend.

What props they have, whether a function will change which props, etc, are belonging to state management. Heck, even the state management can be done in separate project by different team.

The best thing, in a bigger org / bigger project, you can have 2 state management code. One is mock, for frontend to develop, which has no dependency with servers, and another is the real one, that really call the backend server for real data.

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

#76

Post by arandomusername »

a_wild_dandan wrote: post #33

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 requir…

> 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('Hello!')!

> 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

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

#77

Post by imetatroll »

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…

I couldn't agree more. Without showing specific approaches for handling errors, there is too much uncertainty around whether or not htmx is actually a good approach. It doesn't matter how rare an error is. They happen and have to be addressed.

What happens, for instance, if the the request times out?

Also, the main reason, I feel, for actually wanting to use react is if you have an application with data that has a complex relationship with the UI. I don't know the technical term for this unfortunately, but the idea is that state management through, say, redux allows data changes to propagate throughout the UI. HTMX doesn't appear to address this at all. In fact, it seem like very brittle relationships between htmx elements are established. It is equivalent to a jquery + id nightmare.

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

#78

Post by infogulch »

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?

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

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

#79

Post by recursivedoubts »

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…

There are different sorts of errors with respect to htmx:

1) application errors (e.g. bad data in a form)

These should be dealt with the "normal" way: rerender the form with error messages on them. Most good server side frameworks w/ form integration make this easy, and you can see an example of that here:

https://htmx.org/examples/inline-validation/

2) server errors

These are things like 500-level errors, 404s, etc. In this case htmx does not swap by default, but you can modify that behavior if you'd like to have it swap (and retarget, etc.)

3) network errors

On network errors, htmx triggers events such as htmx:sendError, that you can handle and show an error message, etc.

By and large we get almost no support issues around error handling: it is fairly obvious how to make things work if you are familiar with traditional web applications and more complicated things like connectivity issues are handleable via events, which isn't complicated either.

One thing that does occasionally bite people is when server-side frameworks respond with a 422 response code for application-level errors and try to rerender a form with those error messages. By default htmx will not swap that response since it is not a 200-level response code. You can modify this behavior here:

https://htmx.org/docs/#modifying_swapping_behavior_with_even...

If I had it to do over again, I would consider making 422 responses swap by default.

Regarding the "resubmit" warning, that doesn't apply to htmx-powered applications because AJAX operations don't naturally end up in the history chain. This means that the Post-Redirect-Get pattern isn't needed.

Error handling isn't a particularly hard aspect of htmx. What is hard is adjusting your mindset to the hypermedia approach, particularly if you are very deep into reactive programming. And there are applications that this approach is not suited for:

https://htmx.org/essays/when-to-use-hypermedia/

However, when your application is well suited for the approach, htmx (or similar approaches) can be a very big win:

https://htmx.org/essays/a-real-world-react-to-htmx-port/

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

#80

Post by yawaramin »

imetatroll wrote: post #77
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…

I couldn't agree more. Without showing specific approaches for handling errors, there is too much uncertainty around whether or not htmx is actually a good approach. It doesn't matter how rare an error is. They happen and have to be addressed. What happens, for instance, if the the request times out? Also, the main reason, I feel, for actually wanting to use react is if you have an application with data that has a co…

> What happens, for instance, if the the request times out?

htmx triggers an event: https://htmx.org/events/#htmx:timeout

Then you, the developer, optionally handle that event and show a message to the user (if you want).

Post reply on HN