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

51–60 of 326 posts

Re: Moving from React to htmx

#51

Post by legutierr »

agrippanux wrote: post #36

I don’t understand why this effort was undertaken vs migrating to NextJS and accomplishing the same thing in half the time without needing to ramp up more Python.

I don't think the point here was to show how quickly they could migrate to another framework, but rather to show that HTMX is powerful enough to use for things like this.

The point seems to have been to show how you don't need to use React to build applications like this, so migrating to NextJS wouldn't have made any sense from that perspective.

Re: Moving from React to htmx

#52

Post by parhamn »

There are four main problems in the React SPA world:

- State management - hooks are awful for anything complex

- Packaging + Bundling - Webpack kitchen sink, JS/TS, browser vs node vs random runtimes, packaging vs bundling, etc

- Data/API binding - Adds distributed state to your data and the complexity that goes with that (cross dom reuse, caching, staleness, realtime updates, etc)

- SEO/Prehydrating - Mostly applies to landing/CRM/blog type things.

These 'old school' solutions help you avoid some of these issues in favor of relocating the complexity a bit (those templates in the talk are absolutely gnarly and I'm sure very bug prone) and reducing the experience. Also the API boundaries are blurred should you ever need one for non UI usage. Ignoring HackerNews taste for simpler websites, some complexity of UIs can and should only be captured with client sided javascript.

With that said, after a few years of things shifting around I'm really happy with the Typescript (lang) + Parcel (packaging) + MobX (state management) + Vercel (when server side rendering is needed). They've been really stable, no fuss, always work. Especially MobX for state, absolutely game changing for the dev experience.

As for the data binding problem, still sucks and my 4th attempt at solving it internally is still meh. This feels like it comes with the territory.

As much as I loved my working with Django/Jinja2/etc, I think theres a light at the end of this tunnel.

Re: Moving from React to htmx

#53

Post by nawgz »

thunky wrote: post #46
nawgz wrote: post #30

Earlier quoted context omitted.

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

Like this? https://htmx.org/extensions/preload/

Sort of. It’s more like when you create an object, you can display the object inline immediately with a JS layer, plus show some status attribute or however deep you like.

This explicitly only works with GETters and I can’t imagine how you can show async state with a tool like HTMX easily

Re: Moving from React to htmx

#54

Post by strife25 »

flexterra wrote: post #43
ksbrooksjr wrote: post #39

Earlier quoted context omitted.

Yea htmx definitely has a different programming model than an SPA style framework like React/Preact. I actually like the JSON api programming model where the backend is as simple as possible, and the frontend js/ts code is completely responsible for handling the UI, but I guess it's a matter of personal preference. The linked article is referring to a team switching from React to htmx though, so for them I'd imagine…

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.

Re: Moving from React to htmx

#55

Post by duxup »

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…

I’ve been exploring various alternatives and I’m certainly of the same mind as you.

It’s always trade offs and that’s fine.

What I find interesting/ frustrating is every framework or option likes to sell you on some numbers that are very nice but so specific they’re not the big picture. And/or talk about how they are different / better than another framework that I might not even be familiar with.

Technical pages now have their own confusing sort of developer marketing.

Re: Moving from React to htmx

#56

Post by mediumdeviation »

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…

For a real world example of this, GitHub uses server-side rendered fragments. Working with low latency and fast internet in the office, the experience is excellent. Trying to do the same outside with mobile internet, and even with a 5G connection, the increased latency makes the application frustrating to use. Every click is delayed, even for simple actions like opening menus on comments, filtering files or expanding collapsed code sections.

I'm actually worried about developers in developing countries where mobile internet is the dominant way to access the Internet and GitHub is now the de facto way to participate in open source, that this is creating an invisible barrier to access.

Re: Moving from React to htmx

#57

Post by hsbauauvhabzb »

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…

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 / popular frameworks gradually pruning their own dependency trees resulting from downstream pressure in the form of pull requests.

Re: Moving from React to htmx

#58

Post by tonto »

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?

this repo keeps track of various benchmarks on a data grid type app https://github.com/krausest/js-framework-benchmark eventually you may need to create "virtualized scrolling" (e.g. only rendering a subset of the total table to the screen at a time) which can hard to make seemless. possibly the benchmark is "too much info" to make a good choice, but it is an interesting resource.

Re: Moving from React to htmx

#59

Post by Void_ »

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…

I was just picking technology for my new landing page and was looking into Preact first.

I wanted basic SSR and things like that. Preact has a library called preact-cli for this. The last commit is from Aug 17.

I ended up with SvelteKit. It just felt much more alive. I don't love learning a new technology just for a landing page, but that was kinda fun.

Re: Moving from React to htmx

#60

Post by ksbrooksjr »

flexterra wrote: post #43
ksbrooksjr wrote: post #39

Earlier quoted context omitted.

Yea htmx definitely has a different programming model than an SPA style framework like React/Preact. I actually like the JSON api programming model where the backend is as simple as possible, and the frontend js/ts code is completely responsible for handling the UI, but I guess it's a matter of personal preference. The linked article is referring to a team switching from React to htmx though, so for them I'd imagine…

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.

According to the article we're commenting on, the programming model is not the sole reason for switching from React to Htmx. Look at the executive summary's bullet points. Four of them are related to performance (build time, time to interactive, data set size, and memory usage). Performance might not be the reason you personally use Htmx, but it's certainly put forward as an advantage in the article which we're commenting on (which is from the htmx team by the way).

I've often seen this meme repeated in debates that js frameworks require you to duplicate logic between the server and client, but most of the logic isn't being duplicated between the client and server, it's being moved from the server to the client. It's relocation, not duplication. Instead of your rails/django controllers deciding what html to render, that decision happens on the client. In this model your server is mostly just an authorization layer, and an interface between the user and the database. Hasura, Firebase, Firestore, Mongodb Realm, and several other products have been successfully built around this premise. You might not like the thick-client thin-server model, which is completely fine, but it's a somewhat subjective preference. The only objective criteria you might use to decide which approach to use is performance.

Post reply on HN