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

21–30 of 326 posts

Re: Moving from React to htmx

#21

Post by jaredcwhite »

gardenhedge wrote: post #14

I consider this an alternative development approach neither better or worse than what it is trying to replace. The winner in recent approach, imo, is Remix Run.

For literally every developer on the planet who is not an expert JavaScript developer—or who doesn't wish to be—this is undoubtedly a better development approach. Saying "Remix is the winner" doesn't really move the needle. It's still JavaScript, still React—just with some work pushed to the server instead of the client.

The contract of the web is that while the client-side language in use may not be up to the discretion of the developer (recent evolutions in WASM notwithstanding), the server-side language/framework/OS/etc. can be literally anything which speaks the protocol of HTTP/HTML/etc. JS frameworks for years have repeatedly broken that contract with the claim that we must accept it for…well, "reasons". If it turns out most of those reasons are bupkis—more a matter of preferences than requirements—then we must stop breaking the contract. JS as a server-side language should _get in line_ alongside all the other languages out there.

Why privilege it if we don't need to?

Re: Moving from React to htmx

#22

Post by infamia »

endisneigh wrote: post #16

serve side rendering is ideal, but at the end of the day what matters these days is developer productivity. a better question is how long it takes to make something like gmail with htmx vs. say react. you might say most apps are not gmail, and you'd be correct. so then you say, ok what about something like wikipedia? easy enough. then you start adding all of this javascript and it becomes a mess.

Interesting you mention Gmail, that's one of the examples given in the Layers Tutorial for Unpoly, which is a batteries-included take on the basic ideas behind HTMX.

https://unpoly.com/tutorial

Re: Moving from React to htmx

#23

Post by sergiomattei »

A note I’ve internalized lately: there is a middle ground.

You can write excellent, lightweight React apps by simply writing semantic HTML and taking advantage of the platform (declarative form validations, a simple CSS pipeline, etc). It doesn’t have to be madness in the front-end.

NextJS, in particular, keeps the build pipeline quite simple.

Re: Moving from React to htmx

#25

Post by ksbrooksjr »

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 build step to use it [3].

[1] https://unpkg.com/browse/htmx.org@1.8.2/dist/

[2] https://unpkg.com/browse/preact@10.11.2/dist/

[3] https://preactjs.com/guide/v10/getting-started#no-build-tool...

Re: Moving from React to htmx

#27

Post by flexterra »

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.

Re: Moving from React to htmx

#28

Post by jaytaylo »

jbverschoor wrote: post #20
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…

Oh god please let’s not go back to JSF

How was it worse than the current state of affairs of complexity with React? Bowser, npm, typescript, obfuscation, compressors, build pipelines.. it’s a lot. Life at the front-end today is so discombobulated, creating a bunch of backend APIs which will generally only be used and consumed by a single browser front-end.

I’m genuinely curious, because I never used JSF except for a single school exercise

Re: Moving from React to htmx

#29

Post by jiggawatts »

keizo wrote: post #4
recursivedoubts wrote: post #2

TLDR: - Took 2 months (21K LoC, mostly JavaScript) - No reduction in user experience - Reduced LoC by 67% (21,500 LoC to 7200 LoC) - They increased python by 140% (500 LoC to 1200 LoC), good if you prefer python to JS - Reduced JS dependencies by 96% (255 to 9) - Reduced web build time by 88% (40s to 5) - First load time-to-interactive was reduced by 50-60% (from 2-6 seconds to 1-2 seconds) - Much larger data sets we…

Speed is the big one for me. 2-6+ seconds is insanity for anything.

I would argue that 1-2 seconds is not impressive either.

It's like seeing people breaking rocks with hand tools being impressed with a bigger mallet.

I used to aim for 15 millisecond cold load times, which is apparently unheard of these days even for front pages with entirely static content.

Re: Moving from React to htmx

#30

Post by nawgz »

andy800 wrote: post #12
samwillis wrote: post #7

Love htmx and this talk is a brilliant run down of where it works well. But as always it’s about choosing the right tool for the job. Server rendered pages/fragments solve so many issues around security and time to develop a product, however it only gets you so far. Ultimately I think the decision when choosing a stack comes down to how much state you need to managed in browser. The vast majority of sites needs very…

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

I think that if you’re building tools and you want to do anything nice like optimistic rendering it’s not possible in HTMX, so I always wonder what kind of user experience is actually delivered on an HTMX app
Post reply on HN