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

Moving from React to htmx

htmx.org

Post reply on HN
Print view View original

241–250 of 326 posts

Re: Moving from React to htmx

#241

Post by mrcus »

wwweston wrote: post #146
MatthiasPortzel wrote: post #41

Earlier quoted context omitted.

The slippery slope that scares me (as a React developer) about htmx (or Hotwire.dev, in particular is the one I was looking at), is that you start making the assumption that the client's internet is fast. There was demo that showed it normally takes ~100ms to click a mouse, and if you attach to the on-mouse-down, then by the time the mouse has been released (100ms later), you can have already fetched an updated rende…

> you start making the assumption that the client's internet is fast. The most common trajectory for react and other SPA framework apps is to also make this assumption, waving away the weight of libraries and front-end business logic with talk of how build tools are stripping out unused code so it must be light, while frequently skipping affordances for outright network failure that the browser handles transparently,…

On a transatlantic flight I recently had the displeasure of browsing over a satellite connection. A lot of sites simply never loaded, even though the connection speed was reasonable. The multi-second latency made these sites that loaded tens to hundreds of resources completely unable to render a single character to screen.

Re: Moving from React to htmx

#242

Post by Ducki »

hu3 wrote: post #237
hnbad wrote: post #189

Earlier quoted context omitted.

I think you're talking past each other: the problem isn't assuming the client's internet is fast, the problem is assuming the client's internet is stable. If you replace most interactions that could be resolved client-side with a network transaction, you're betting on the client's internet being not just reasonably fast but also very stable. When I'm on the go, my internet is more likely to be fast than stable.

> The problem is assuming the client's internet is stable. Yep. This is the major drawback of backend-dependent interactions. This is what scares me away from amazing technologies such as ASP.NET Core Blazor Server where I can code my frontend in C# instead of JavaScript. If only Blazor Wasm wasn't so heavy. 4mb of runtime DLLs is a bit off-putting to any use but intranet LOB applications.

Recent versions trimmed it down to about 1mb.

Re: Moving from React to htmx

#243

Post by pier25 »

talideon wrote: post #238
pier25 wrote: post #111

I was expecting something that would blow me away... but honestly that UI is not super sophisticated. You could solve that with vanilla or jQuery. Obviously React (or any of the modern libs/frameworks) would be overkill for that. IMO this video reinforces the idea that for personally simple stuff I'd rather just use jQuery (or rather CashJS) or even vanilla.

That's exactly why HTMX was a good fit for this: it covers exactly the kind of Interaction patterns you'd find yourself writing in vanilla JS where React is overkill, except without having to write all that JS. Though I don't know why you'd bother with jQuery these days unless you had to deal with ancient browsers: venerable as it is, it's obsoleted itself as just about everything it did is now covered by browser API…

> is now covered by browser APIs

I've never understood that argument. You could always do what jQuery does with vanilla JS. How could it be otherwise?

The point of jQuery is productivity. Even today, a jQuery-style API saves you from writing a lot of code.

Re: Moving from React to htmx

#244

Post by stickfigure »

richbell wrote: post #139
stickfigure wrote: post #125

Earlier quoted context omitted.

From a security perspective, the client is 100% irrelevant. You might prefer to offer a good UX in the face of authorization failure, but that doesn't affect the security of your app one way or another. Good APIs look like simple functions; they take certain very structured inputs (path, query params, headers, body) and produce a simple structured output (usually a json blob). They're usually well defined, limited in…

The operative word being good , which most APIs unfortunately aren't. You could make the exact same argument about APIs that you made about HTML endpoints, and vice versa. The problem, imo, is that writing a fronted is a lot harder for many people than writing a backend and they tend to spend more time on the front-end. Security is hard, especially when most developers are ignorant or negligent about basic best pract…

Maybe it helps if you think of it this way:

An application can be very imperfectly thought of as having two bodies of logic, frontend logic and backend logic. In an SPA, if you secure the backend logic you are safe no matter what mistakes are made in the frontend. When rendering server-side HTML, the frontend logic and backend logic both run in a privileged security context. The attack surface area is larger.

Re: Moving from React to htmx

#245

Post by solardev »

Winsaucerer wrote: post #155
hsbauauvhabzb wrote: post #57

Earlier quoted context omitted.

What security issues does server rendering solve? I resent that every website needs to be an SPA, but from a security perspective I’ve concluded that the clearer line in the sand that SPA application architectures creates is better than the security challenges that can result from server side rendering. Navigating the risks around the NPM supply chain is another story, but I suspect it will be solved by large / popul…

Here's one I've experienced. Suppose you have a table of customers, and you want to show an extra column of data on that page showing total orders, if and only if the viewer of that table has the manager role. With an SPA, you'll be building an API (perhaps a 'REST' one, or GraphQL) to expose all the data required, such as customer name, email, etc, as well as the extra 'total orders' field iff they have the manager…

Can't the backend decide which fields to send back in a JSON, the same way it would decide which HTML columns it would've rendered?

The front-end can pass a user role with every request and render whatever the backend sends it into a table.

Re: Moving from React to htmx

#246

Post by robertlagrant »

MatthiasPortzel wrote: post #41
andy800 wrote: post #12

Earlier quoted context omitted.

> as you reach a more “app like” experience with multiple layers of state control on the front end you need to reach for a front end JS framework I think that if you fully embrace HTMX's model, you can go far further than anticipated without a JS framework. Do you really need to be managing state on the client? Is it really faster to communicate via JSON, or protobuf, whatever, rather than atomic data and returning j…

The slippery slope that scares me (as a React developer) about htmx (or Hotwire.dev, in particular is the one I was looking at), is that you start making the assumption that the client's internet is fast. There was demo that showed it normally takes ~100ms to click a mouse, and if you attach to the on-mouse-down, then by the time the mouse has been released (100ms later), you can have already fetched an updated rende…

I wouldn't assume a fragment is any bigger than the raw data when it's compressed.

  { "things": [
    { "id": 183,
      "name": "The Thing",
      "some date": "2016-01-01",
    },
    { "id": 184,
      "name": "The Other Thing",
      "some date": "2021-04-19",
    },
  ]}
Vs

  
    183The thing2016-01-01
    184The other thing2021-04-19
They seem extremely similar to me.

Re: Moving from React to htmx

#247

Post by wwweston »

hnbad wrote: post #189
wwweston wrote: post #146

Earlier quoted context omitted.

> you start making the assumption that the client's internet is fast. The most common trajectory for react and other SPA framework apps is to also make this assumption, waving away the weight of libraries and front-end business logic with talk of how build tools are stripping out unused code so it must be light, while frequently skipping affordances for outright network failure that the browser handles transparently,…

I think you're talking past each other: the problem isn't assuming the client's internet is fast, the problem is assuming the client's internet is stable. If you replace most interactions that could be resolved client-side with a network transaction, you're betting on the client's internet being not just reasonably fast but also very stable. When I'm on the go, my internet is more likely to be fast than stable.

Your comment dovetails with my primary point: how an app serializes or renders data is entirely trivial compared to planning for network availability issues when it comes to app function and user experience.

GP asks: "is it ever acceptable to round-trip to the server to re-render a component that could have been updated fully-client side?" This is a question that's oriented around what is generated on the server and pushed over the wire rather than the fact that there is a network call at all.

If the network is not stable, a typical 1st-load-heavy SPA-framework will make... a tenuous network call returning JSON with iffy chances of success instead of a tenuous network call returning an HTML fragment with iffy chances of success.

Re: Moving from React to htmx

#248

Post by beebeepka »

zach_garwood wrote: post #226
beebeepka wrote: post #199

Earlier quoted context omitted.

The htmx guys self promote here all the time. Their selling point is "no js" for slightly interactive demo apps. 10/10 times is just them openly bashing the rest of us for not using their tech.

He seems like a reasonable fellow, and I've never seen him bash anybody, even people openly hostile to his library.

I don't know the guy but every htmx thread is filled with js bashing. It's like their main selling point.

This technology is not great for complex GUI. You can downvote even more now.

Re: Moving from React to htmx

#249

Post by nikodunk »

jakebasile wrote: post #216

As an aside, the author of this project is also the author of grugbrain.dev, the most wonderful and accurate software development site I've ever encountered.

Wow!! This site made me laugh a few times while collecting these great lessons. Very well written!

Re: Moving from React to htmx

#250

Post by dorongrinstein »

htmx is a great library. I can see a back-end-for-front-end pattern where a thin 'UI' layer emits the html/js/css based on orchestrating calls to REST/GraphQL APIs - where those already exist, or where having an API makes sense for native apps on mobile for example.

To serve html to htmx sites closer to the caller/user, a developer can run the backend on something like https://controlplane.com (disclosure - I run Control Plane) where a request from Australia is served from Sydney and a request from New York is served from aws-us-east-2 for example.

In short, htmx looks great because of the simplicity. I am sure it will be used by a lot of developers. Nice work!

Post reply on HN