Live data from Hacker News

Moving from React to htmx

htmx.org

31–40 of 326 posts

Re: Moving from React to htmx

#31
This is a really beautiful approach IF you don't need mobile. If you do need mobile, then you may be better served (pointlessly) running React on web and re-using all of the logic/fetchers, etc for React-Native on mobile IMO.

Your other option would be to do something like 37 Signals and render web with htmx (or in their case Hotwire) and server-render mobile too, but wrap the web views with a thin native mobile navigation layer to make it feel more native.

Very jealous if your project is web-only - this can work wonderfully and be incredibly efficient! I've been thinking about this a lot recently and also just blogged about it (https://nikodunk.com/2022-05-10-the-tech-stack-for-maximum-e...).

Re: Moving from React to htmx

#32
post #6

One reason I prefer doing React is that retrofitting existing React stuff for React Native is better/easier than embarking on React Native from scratch.

I would argue that most “apps” built with React Native don’t need to be apps at all, they are better as websites. The majority of these apps are about placing the existing product into the App Store for discoverability, and encouraging users to be “locked” into the app at the expense of a worse customer experience. A web app, in a browser, automatically has support for opening multiple pages as multiple tabs, bookmar…

How would we even know what most React Native apps are like to… know this?

Re: Moving from React to htmx

#33

This is a really beautiful approach IF you don't need mobile. If you do need mobile, then you may be better served (pointlessly) running React on web and re-using all of the logic/fetchers, etc for React-Native on mobile IMO. Your other option would be to do something like 37 Signals and render web with htmx (or in their case Hotwire) and server-render mobile too, but wrap the web views with a thin native mobile navi…

Efficient for dev time, not so sure about mobile app size, RAM usage, or response time.

Re: Moving from React to htmx

#34

This is a really beautiful approach IF you don't need mobile. If you do need mobile, then you may be better served (pointlessly) running React on web and re-using all of the logic/fetchers, etc for React-Native on mobile IMO. Your other option would be to do something like 37 Signals and render web with htmx (or in their case Hotwire) and server-render mobile too, but wrap the web views with a thin native mobile navi…

If the hypermedia approach really grabs you, you could pair an htmx-based web application with a HyperView-based mobile application:

https://hyperview.org/

Re: Moving from React to htmx

#35
post #4

Earlier quoted context omitted.

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

I hear you, but YouTube takes 6+ seconds for me to load and it does not seem to hold them back. For most, not all, optimizing page load time is time probably best spent elsewhere. This is is no way to impugn htmx, because with htmx you seem to kill many birds with one stone.

Youtube is kind of unique in that nothing (currently) even comes close to replacing it for the average youtube user.

Re: Moving from React to htmx

#37

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.

In the React ecosystem, Remix.run embraces a much simpler approach than Next.js.

Re: Moving from React to htmx

#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?

Re: Moving from React to htmx

#39

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.

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 it would've been a much easier transition if they'd just added a Webpack alias[1] that replaced React with preact/compat, rather than switching to a completely different UI paradigm.

[1] https://preactjs.com/guide/v10/getting-started#aliasing-in-w...

Re: Moving from React to htmx

#40

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?

A spreadsheet is probably not amenable to the hypermedia approach because of the complicated inter-dependencies between arbitrary parts of the screen. You don't want to gate those updates on a hypermedia exchange.

I would look at writing either a custom solution or one of the big reactive libraries like vue.js for something like this.

Post reply on HN