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

71–80 of 326 posts

Re: Moving from React to htmx

#71

Post by qwertyzxcvmnbvw »

mediumdeviation wrote: post #56
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…

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…

Side note: in Thailand and the Philippines, at least, mobile internet is blazing fast and not more expensive.

Re: Moving from React to htmx

#72

Post by yawaramin »

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.

Because migrating to NextJS would have meant doing a rewrite of the entire backend which was already written in Python/Django and running in production. Migrating to htmx was much less risky.

Re: Moving from React to htmx

#73

Post by ksbrooksjr »

yawaramin wrote: post #68
ksbrooksjr wrote: post #60

Earlier quoted context omitted.

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

The article we're commenting on dedicates an entire section to talking about the dev team makeup and how it completely changed and unified the team approach to being fullstack. That's how thoroughly htmx changed the programming model.

You haven't disagreed with anything I said. My original comment says "Htmx is great for developers who need client side interactivity, but would rather not write any js". I'm sure a team of Python developers is enjoying not writing Javascript. My point is that you don't have to switch to a completely different paradigm to reap the performance benefits that the article lists.

Re: Moving from React to htmx

#74

Post by recursivedoubts »

miiiiiike wrote: post #66
recursivedoubts wrote: post #63

Earlier quoted context omitted.

I think this take does yourself a disservice: htmx is an extension of HTML and, in general, of the hypermedia model, and it is this model that should be contrasted with JSON data APIs. I think that you should learn JavaScript, and I certainly think you should learn HTML(!!!) and CSS. But I also think you should consider how much more can be achieved in a pure hypermedia model with the (relatively small) extensions to…

I’ve used htmx.

I'm sure you have.

Regardless of that, the idea that you learn htmx because don't want you to learn JavaScript is simply incorrect.

Rather, it's how you use JavaScript that should be considered.

Re: Moving from React to htmx

#75

Post by stickfigure »

0xCMP wrote: post #67
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…

I think anywhere you introduce more complexity, more ways for things to interact, it's inherently less secure without the additional work checking for both the App + the API being secure on their own.

There's no such thing as a secure "app". Only the API needs to be secure. That's more straightforward when your API looks like REST/RPC calls rather than "renders html templates to a string".

Re: Moving from React to htmx

#76

Post by hermanradtke »

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…

We have a set up like this at my job. The servers are based in the Pacific Northwest. We have users in Europe and India.

You can guess how awful the user experience is.

Re: Moving from React to htmx

#77

Post by flexterra »

ksbrooksjr wrote: post #60
flexterra wrote: post #43

Earlier quoted context omitted.

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

Validating data on the client and not doing it again on the server will lead to security vulnerabilities. At the very least you will end up duplicating that validation code.

Re: Moving from React to htmx

#78

Post by danielvaughn »

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/

Re: Moving from React to htmx

#79

Post by keizo »

jiggawatts wrote: post #29
keizo wrote: post #4

Earlier quoted context omitted.

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.

Well yea, but start trimming with the biggest wins first.

Re: Moving from React to htmx

#80

Post by firecall »

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 super reliable and has a well documented implementation path!

Post reply on HN