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

231–240 of 326 posts

Re: Moving from React to htmx

#231

Post by recursivedoubts »

xutopia wrote: post #219
DannyPage wrote: post #213

Earlier quoted context omitted.

Hyperscript[1] pairs well with HTMX (as it should, it’s by the same group) and would fill those gaps. [1] https://hyperscript.org/

What are the advantages of Hyperscript over plain old Javascript?

a few:

- it is designed to be embedded directly in HTML

- it can listen for any event (unlike on* attributes)

- it has native support for CSS selectors: https://hyperscript.org/docs/#dom-literals

- it has async-transparency: https://hyperscript.org/docs/#async

- subjectively, it is easier to read than JavaScript, particularly for the short, light scripts it is designed for (toggling a class, etc.): `on click toggle .clicked on me`

hyperscript is more of a glue language than something I would recommend building an entire application out of (although people are doing that!)

Re: Moving from React to htmx

#232

Post by ec109685 »

hiyer wrote: post #210
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…

Would this not be a concern for React (and other SPAs) as well? I'm no UI expert, but from what I've seen of React/Vue UIs in previous companies, you still have to hit the server to get the data, though not the UI components. The difference in size between just the data in, say, JSON, and the entire HTML component would be very minimal considering both would be compressed by the server before sending.

There are frameworks that let you apply changes locally and (optimistically) instantly update the ui and asynchronously update server state. That is a win.

On the other hand, I have seen implementations of spa “pages” that move from a single fetch of html to multiple round trips of dependent API calls, ballooning latency.

Re: Moving from React to htmx

#233

Post by ec109685 »

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…

If you have non-html native mobile applications, you’ll need to have that complexity regardless of the techniques used to construct web page.

Re: Moving from React to htmx

#234

Post by ec109685 »

strife25 wrote: post #54
flexterra wrote: post #43

Earlier quoted context omitted.

The difference in programming model IS THE advantage of HTMX. Changing from react to preact is a perf optimization. If you are doing the SPA thing correctly you must duplicate business logic (data validation). Also when your API just sends "dumb data" (JSON) to the client, you are forced to make changes to the backend and frontend in lockstep.

+1 SPAs were a workaround to slow CPU servers serving millions of requests in the mind-2000s. Client computers were faster, so it made sense to push UX logic there. We've flipped things around. Servers are fast as hell for rendering HTMl. We can leverage that and re-focus the client on UI code that only it can do.

They were also in response native mobile applications and desire to have a single api tier for all applications.

That and the panacea of being able to run same javascript on server and client.

Re: Moving from React to htmx

#235

Post by larrymyers »

xutopia wrote: post #218

People forget that React can be used for just the complex components that require it. Your entire page need not be a React app just because you use it for one component. To me it's bonkers that all web sites seem to be moving towards SPA when they don't benefit from it at all and require so much frontend work when a little bit of simple HTML and Javascript could do most of the work. It feels like the whole industry i…

This is an excellent point. It's a philosophy that I think Astro gets right.

https://docs.astro.build/en/concepts/islands/

Combined with Preact instead React I think it allows for server content first, and sprinkling in interactive components as needed without much extra page size.

At the end of the day a good component based js framework makes it a lot easier to implement a lot of things client side.

Re: Moving from React to htmx

#236

Post by larrymyers »

ec109685 wrote: post #229
hunterb123 wrote: post #224

Earlier quoted context omitted.

What's the issue with using Next/React to build static and SSR web pages? React doesn't only work for SPA.

If that requires full client side re-hydration in order for those SSR pages to become interactive, then the user receives a worse experience.

It's also a bit shocking how much javascript and json get loaded client side to facilitate this hydration for Next.js.

Re: Moving from React to htmx

#237

Post by hu3 »

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.

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

Re: Moving from React to htmx

#238

Post by talideon »

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

Re: Moving from React to htmx

#239

Post by talideon »

kgeist wrote: post #151

Doesn't server rendering increase load on the server? I like to off-load as much processing to the user's browser as possible. We have ~1 million users and I like to think that when we off-load a lot of processing to the browser, we basically have 1 million servers for free.

Consider this: you're doing server side rendering whether it's JSON or HTML fragments you're sending across. They're just different serialisations of the same data. The problem that SPAs were meant to fix was that each update of the page meant a full rerender under the classic model rather than just rerendering those bits that had actually changed.

You're still going to be able to take advantage of those client machines to do rendering, but the difference is that with HTMX, you skip serialising JSON, so your clients aren't stuck doing unnecessary rendering. The load on the server is barely different, but the client has less to do.

Now, if you're doing an awful lot of data manipulation on the client, that's a different story.

Re: Moving from React to htmx

#240

Post by smrtinsert »

xutopia wrote: post #218

People forget that React can be used for just the complex components that require it. Your entire page need not be a React app just because you use it for one component. To me it's bonkers that all web sites seem to be moving towards SPA when they don't benefit from it at all and require so much frontend work when a little bit of simple HTML and Javascript could do most of the work. It feels like the whole industry i…

Resourcing for frontend is basically hiring for the superset of frontend tech. Once you have that team in place of course they'll use the tool that has the most options. It's a safe bet even if its not the best performance, and it's important on the resume.
Post reply on HN