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

251–260 of 326 posts

Re: Moving from React to htmx

#251

Post by nikodunk »

recursivedoubts wrote: post #34
nikodunk wrote: post #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 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/

This is super interesting - thanks for sharing!

Re: Moving from React to htmx

#252

Post by nikodunk »

paulryanrogers wrote: post #33
nikodunk wrote: post #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 navi…

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

Definitely! Wasn't considering the other 3 in this discussion. The most efficient for all of these is most likely a native app everywhere, and all the complexity/duplication that brings.

Re: Moving from React to htmx

#253

Post by padjo »

pier25 wrote: post #243
talideon wrote: post #238

Earlier quoted context omitted.

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

> is now covered by browser APIs I've never understood that argument. You could always do what jQuery does with vanilla JS. How could it be otherwise? The point of jQuery is productivity. Even today, a jQuery-style API saves you from writing a lot of code.

The biggest boon of JQuery back in the day was that it abstracted over all the browser variances, which were far more numerous at the time.

Also many APIs simply didn’t exist(e.g. querySelector).

Now that browsers are much mor standards compliant and there are much better APIs it feels like the rationale for jQuery has shrunken to pretty much zero

Re: Moving from React to htmx

#254

Post by richbell »

stickfigure wrote: post #244
richbell wrote: post #139

Earlier quoted context omitted.

The operative word being good , which most APIs unfortunately aren't. You could make the exact same argument about APIs that you made about HTML endpoints, and vice versa. The problem, imo, is that writing a fronted is a lot harder for many people than writing a backend and they tend to spend more time on the front-end. Security is hard, especially when most developers are ignorant or negligent about basic best pract…

Maybe it helps if you think of it this way: An application can be very imperfectly thought of as having two bodies of logic, frontend logic and backend logic. In an SPA, if you secure the backend logic you are safe no matter what mistakes are made in the frontend. When rendering server-side HTML, the frontend logic and backend logic both run in a privileged security context. The attack surface area is larger.

> In an SPA, if you secure the backend logic you are safe no matter what mistakes are made in the frontend.

If. The problem I've observed is that people treat the backend as a dumb pipe for data and focus entirely on the frontend.

> When rendering server-side HTML, the frontend logic and backend logic both run in a privileged security context.

This isn't necessarily a bad thing. Business logic happening in a protected and opaque context means it isn't exposed and easy to reverse engineer or manipulate. An extremely common vulnerability on SPAs is "get a list of all the $STUFF user is allowed to see from endpoint A, then get all the $STUFF from endpoint B and filter out all the results they shouldn't see" because everything is still visible to the client; that exact same (suboptimal) logic is inherently more secure on the server. Another common one being "are we logged in or should we redirect?" Conversely, rendering content on the server makes it a lot easier to prevent certain vulnerabilities like CSRF.

That's not to say that I think SPAs are bad and AJAX is good, I just find the argument that SPAs are more secure if you secure the backend dubious. A SPA with an insecure backend can be just as insecure as a backend rendering HTML because the weak-point is the backend itself.

Edit: You could perhaps argue that SPAs are indirectly better from a security perspectiv because text serialization is safer than binary serialization. Though any serialization is still a potential weakness.

Re: Moving from React to htmx

#255

Post by meekaaku »

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…

I do case (a) like this with SPA. Call to /orders (or any endpoint) will check roles/permissions and runs the proper query. A normal user will get [{name, email}], but a manager will get [{name, email, num_orders}]. A normal user call will not have the COUNT(*) from orders part anyway in SQL query (which is expensive). Only a manager's call will have that part. Most likely number of managers will be less than users, so the users get faster results. The results are returned to front end and if the {num_orders} column exists, it is rendered. Front end doesnt have to bother with any access control logic.

For the server-side rendered page, what seems to me is you are running same query for normal users and managers, which is fine too, but removing that num_orders column.

Ultimately in both cases, the access control logic happens on the server, and frontend don't have complicated access control logic anyway. My point is, with SPA also we can get the same server-side benefits, atleast in this case. Or am I missing something?

Re: Moving from React to htmx

#256

Post by rwalle »

Throwaway23459 wrote: post #115

Speeding up the build could be done in other ways, were they using esbuild or something fast previously? Probably not. The memory usage saving is really not a big deal, load up your favourite news web page and look at the memory it chews up in comparison. As for the preference implied for python over js, that's fine, but the choice is not binary, typescript is my preference for a React project, for example. Reduction…

Agreed. More details are necessary to understand the potential benefit of such rewrites.

And to be honest 21K LOC is not a big project. I can imagine that as project grows even larger, there will be problems that htmx cannot or is difficult to handle, and I'll be curious about how that would work out.

Re: Moving from React to htmx

#257

Post by rchaud »

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…

React has a self perpetuating marketing machine. From boot camp courses to YouTube how-tos and frequency plof appearance in job description requirements, people end up hiring React developers who want to build the sites in React.

Re: Moving from React to htmx

#258

Post by password4321 »

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.

> The server returns HTML

So back to ASP.NET WebForms update panels?

Re: Moving from React to htmx

#259

Post by branko_d »

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?

If these rows are even mildly interactive, I’d use MobX + React.

Re: Moving from React to htmx

#260

Post by panoply »

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…

I actually have a module that I built ti loads pages using such an approach (prefetch). In my take, I refined Pre-fetching to be triggered a few different ways. You can fetch on hover, proximity (ie: pointer is x distance from href), intersection or by programmatic preload (ie: informing the module to load certain pages). Similar to Turbo, every page is fetched over the wire and cached so a request in only ever fire once. It also supports targeted fragment replacements and a whole lot of other bells and whistles. The results are pretty incredible. I use it together with Stimulus and it's been an absolute joy for SaaS running projects.
Post reply on HN