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

211–220 of 326 posts

Re: Moving from React to htmx

#211

Post by germandiago »

hnbad wrote: post #187

This again? From the first page of the documentation: With that in mind, consider the following bit of HTML: Click Me! We've been through this back in the Angular days (and even before that: remember Knockout?). Implementing your template language as DOM attributes does not make it HTML. Not to mention the examples using "hyperscript", aka a "human readable" DSL for DOM manipulation and event handling also stuck in H…

You are right about changingsupport for niche but...

if the tool is easier to understand probably it is also less massive and easier to interact/find workarounds when needed than if you work on top of several layers + huge dependencies. At least that is my experience and why, in the face of choice and when it makes sense, I would choose htmx over React.

It is easy to understand and a thin layer you can figure out even what it is doing under the hood. I cannot say the same about React, which is much more complicated. Sure it has good use cases. But it is more difficult to understand and potentially drags a lot of deps inside.

I see every dependency on an app as introducing some risk: the more of them, the worse. They can break, they can go unmaintained, you can have a trnsitive dep that is compatible with one package but incompatible with another (this happened a lot to me with node) and that propagates recursively. It can be a hell to the point that making things work can get difficult.

So at the end, if you can do something with a couple of deps and some htmx/standard web stuff and a bit of hyperscript or similar here and there, chances that things will keep working for the years coming are higher. Also, if something gets outdated there is a tiny layer to replace you can do it more easily.

Re: Moving from React to htmx

#212

Post by germandiago »

firecall wrote: post #80
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?

Totally unfashionable answer: I use 'Rails 6.x and datatables.net. The system manages call-logs for a call centre with WFH staff. It's doing thousands of calls a day. The tables are 'endless' pagination reporting tables. It's hosted in Sydney, AU. And used by staff around the world. It has the advantage of being extremely robust on the dodgiest of old PCs with poor internet connections. So not fashionable, but it's s…

Your solution looks like the right way to do it to me. At least in your case.

Re: Moving from React to htmx

#213

Post by DannyPage »

edflsafoiewq wrote: post #129
danielvaughn wrote: post #78

Some years ago, a bright guy created something called 7 GUIs. It’s a collection of seven problems that all UI systems must successfully implement, and it was intended to act as a guide for comparisons. Unfortunately I think the author has passed away, but it would be interesting to see it rekindled and used for baseline comparisons like these. https://eugenkiss.github.io/7guis/

I don't think Htmx is a good fit for those. I wouldn't want a server roundtrip for any of them (except maybe part of CRUD).

Hyperscript[1] pairs well with HTMX (as it should, it’s by the same group) and would fill those gaps.

[1] https://hyperscript.org/

Re: Moving from React to htmx

#214

Post by sfusato »

If your React SPA can be replaced by htmx, I would say you've chosen the wrong technology from the start. Certain type of applications require a SPA architecture, but most simply don't.

Re: Moving from React to htmx

#215

Post by adamckay »

pier25 wrote: post #114
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.

Use the right tool for the job. Obviously Gmail is a much better fit for React/Vue/etc than HTMX. Gmail is the perfect use case for an SPA but most web apps don't need to be an SPA.

> Gmail is the perfect use case for an SPA

Is it really, though?

It's a paginated list of emails, some drag-and-drop functionality, buttons for some ajax functionality.

It works reasonably well, but it doesn't need to be so high Javascript compared to Google Docs or maps.

Re: Moving from React to htmx

#217

Post by thunky »

nawgz wrote: post #160
halfcat wrote: post #122

Earlier quoted context omitted.

What if combined with this? https://htmx.org/examples/lazy-load/

With respect to showing a loader, it’s a solution. Not fully sure I understand the mechanism - is it based on the class or does all content of the div with hx-trigger get replaced? Or even worse is the image still there with opacity 0? However, this doesn’t solve the optimistic rendering situation at all. In general the approach of HTML over the wire clearly seems barred from solving that, you need a client layer for…

IIUC I think it's possible, but maybe a bit clunky. Htmx let's you choose the swap target, and you can replace any part the page, not just the section that triggered the swap. You can also replace multiple targets.

https://htmx.org/attributes/hx-swap-oob/

Also, there's nothing stopping you from writing a bit of JS to handle something htmx can't do.

For example, the initial GET could return two partials, one hidden by default until a user action triggers a JS swap while htmx performs the request and eventually replaces the div again along with any other out of band div(s).

Re: Moving from React to htmx

#218

Post by xutopia »

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 is Reactifying everything because they're scared that if they don't they won't look professional.

Re: Moving from React to htmx

#219

Post by xutopia »

DannyPage wrote: post #213
edflsafoiewq wrote: post #129

Earlier quoted context omitted.

I don't think Htmx is a good fit for those. I wouldn't want a server roundtrip for any of them (except maybe part of CRUD).

Hyperscript[1] pairs well with HTMX (as it should, it’s by the same group) and would fill those gaps. [1] https://hyperscript.org/

What are the advantages of Hyperscript over plain old Javascript?

Re: Moving from React to htmx

#220

Post by earthboundkid »

jiggawatts wrote: post #124
earthboundkid wrote: post #94

Earlier quoted context omitted.

15ms to who? I’ve never had that kind of latency on a cold connection. My pages have an LCP of around 600ms, and it’s hard to push it much lower because even static pages on a CDN end up taking 400ms to connect and download.

15 ms to anyone in the same city or on the same local network in an office setting. 50 ms to anyone in the same country, ideally lower. Global reach is a different problem because of physics. However, front pages of web pages tend to be largely static and can be staged in various geo-distributed regions. In other words, distributed via a CDN.. > even static pages on a CDN end up taking 400ms to connect and download.…

My site is a static page hosted on a CDN with less than 80KB of JavaScript.

If you’re testing local network times, you’re just fooling yourself. None of your visitors are seeing that time, so it’s irrelevant.

What’s your URL? I’d love to throw it into webpagetest.org and take a look.

Post reply on HN