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

221–230 of 326 posts

Re: Moving from React to htmx

#221

Post by zarzavat »

flexterra wrote: post #27
ksbrooksjr wrote: post #25

Htmx is great for developers who need client side interactivity, but would rather not write any js. If you don't mind writing a bit of js however, you can't go wrong with Preact. Same api as React, but at a fraction of react-dom's bundle size. It looks like the minified source is even smaller than htmx (which is already very minimal) [1][2]. They've also packaged Preact in such a way that you don't need to add a buil…

The programming model is totally different when working with HTMX. The server returns HTML instead of a JSON API which is the usual solution when building apps with React/Preact and similar.

How do you implement, e.g. a sortable table if the server sends HTML rather than JSON? Have we gone full circle and gone back to jQuery?

Re: Moving from React to htmx

#222

Post by flexterra »

zarzavat wrote: post #221
flexterra wrote: post #27

Earlier quoted context omitted.

The programming model is totally different when working with HTMX. The server returns HTML instead of a JSON API which is the usual solution when building apps with React/Preact and similar.

How do you implement, e.g. a sortable table if the server sends HTML rather than JSON? Have we gone full circle and gone back to jQuery?

Here's the sortable example: https://htmx.org/examples/sortable/

IMHO something slightly more complex than this example (more client side stat) will require using something like React/Vue/Svelte. But there's no need to rewrite the whole FE. Just create a component that performs the rich client side interaction and use HTMX for the rest of your app. Win-Win.

Re: Moving from React to htmx

#223

Post by criddell »

devoutsalsa wrote: post #108
umvi wrote: post #105

Earlier quoted context omitted.

Just use vanilla html/js/css. For most stuff that's fine. React is good for web applications that require reusable components and have a lot of state to manage, but if you are building a personal site just use vanilla.

Vanilla JS definitely needs some discipline. I just made an app in vanilla JS for the first time in a while, and OMG it’s a rat’s nest XD

Have you ever tried writing a native client? I think the native client path is something that a lot of developers don't even consider these days. I think it's an area of great opportunity.

Re: Moving from React to htmx

#224

Post by hunterb123 »

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…

What's the issue with using Next/React to build static and SSR web pages?

React doesn't only work for SPA.

Re: Moving from React to htmx

#225

Post by ricardobeat »

lf-non wrote: post #186
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,…

It may be common when starting out, but we do have paths to optimize out of it. We can do code splitting, eager fetching js when page is idle, optimistic rendering when page is taking time etc. Unlike what a lot of people like to believe not every spa runs 20 megs of js on page load. Also the initial load time being a few seconds and then the app being snappy and interactive is an acceptable compromise for a lot of a…

> Unlike what a lot of people like to believe not every spa runs 20 megs of js on page load

This is not a new take, it's exactly what every die-hard SPA dev says. While 20MB is an exaggeration, the average web page size has ballooned in the past decade from ~500KB in 2010 to around 4MB today. And the vast majority of those pages is just text, there is usually nothing really interactive in them that would require a client-side framework.

Others will say 2MB, 4MB is not that bad, but that just shows how far out of touch with the reality of mobile internet they are. Start measuring the actual download speeds your users are getting and you'll be terribly disappointed even in major urban centers.

Re: Moving from React to htmx

#226

Post by zach_garwood »

beebeepka wrote: post #199
Glyptodon wrote: post #120

Expected this to be more interesting than a maybe fancier version of turbolinks. Am I missing something?

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.

Re: Moving from React to htmx

#227

Post by scns »

cloudking wrote: post #38

What is the best framework to build a high performance web application on? Specifically for building a UI to work with large sets of tabular data similar to a spreadsheet, e.g thousands of rows. Is Htmx up for this task?

Jane Street did something like that, incr-dom IIRC. They have very high performance needs since they do HFT.

Re: Moving from React to htmx

#228

Post by throwaway0asd »

doctor_eval wrote: post #103
throwaway0asd wrote: post #95

Earlier quoted context omitted.

> How do I combat such burnout? What works for me: don't waste time with frameworks . The web standards are simple to learn and are also wonderfully not opinionated.

I dunno, I took this advice and ended up rolling my own thing that looked an awful lot like a framework, but wasn’t as good because the framework authors are better at JS than I am. I’ve landed on Svelte+Typescript lately, and It’s Really Doing It For Me (tm). I think the trick is to find a framework or library that gets you, and just run with it.

Not using frameworks means more than the tools you pick (or make).

Re: Moving from React to htmx

#229

Post by ec109685 »

hunterb123 wrote: post #224
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…

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.

Re: Moving from React to htmx

#230

Post by ec109685 »

nickjj wrote: post #192
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…

> 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 rendered component from the server. I think what you're describing is a form of preloading content but it's not limited to React. For example: The baseline is: You click a link, a 100ms round trip happens and…

If the click causes a state change, it would be complicated to pre-render (but not apply) it before click.
Post reply on HN