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

121–130 of 326 posts

Re: Moving from React to htmx

#121

Post by hungryforcodes »

qwertyzxcvmnbvw wrote: post #71
mediumdeviation wrote: post #56

Earlier quoted context omitted.

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.

That's not universally true in all areas for both countries though.

Re: Moving from React to htmx

#122

Post by halfcat »

nawgz wrote: post #53
thunky wrote: post #46

Earlier quoted context omitted.

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

What if combined with this?

https://htmx.org/examples/lazy-load/

Re: Moving from React to htmx

#123

Post by tannhaeuser »

recursivedoubts wrote: post #2

TLDR: - Took 2 months (21K LoC, mostly JavaScript) - No reduction in user experience - Reduced LoC by 67% (21,500 LoC to 7200 LoC) - They increased python by 140% (500 LoC to 1200 LoC), good if you prefer python to JS - Reduced JS dependencies by 96% (255 to 9) - Reduced web build time by 88% (40s to 5) - First load time-to-interactive was reduced by 50-60% (from 2-6 seconds to 1-2 seconds) - Much larger data sets we…

I think the value of markup-based templating approaches such as HTMX and SGML comes from enabling content authors to create dynamic document-oriented sites without having to deal with dangerous tools such as JS and the endless ways too shoot yourself and your visitors into the foot (through eg injections and other security issues). The difference between HTMX and SGML being that HTMX integrates templating as markup vocabulary extension while SGML brings syntactical templating at the markup declaration level. A developer, OTOH, might choose JS-heavy approaches to avoid limitations and learn new syntax/concepts, and to re-use existing knowledge from/to other projects. I don't know that speed of development is of primary concern.

Re: Moving from React to htmx

#124

Post by jiggawatts »

earthboundkid wrote: post #94
jiggawatts wrote: post #29

Earlier quoted context omitted.

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.

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.

Only if you stuff them full of megabytes of Javascript and pull down megabytes of JSON in order to display that static content.

The fact that my comment -- a factual statement about real-world performance I've achieved regularly -- is voted down and your off-by-an-order-of-magnitude reply is voted up speaks volumes about the state of the industry.

It's like a bunch of fat people being flabbergasted about the mere concept of mountain climbing. With what... your legs!? Up there!? Madness!

Re: Moving from React to htmx

#125

Post by stickfigure »

nkozyra wrote: post #98
stickfigure wrote: post #75

Earlier quoted context omitted.

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".

> That's more straightforward when your API looks like REST/RPC calls rather than "renders html templates to a string". How so? You're now dealing with two applications (or two parts of an application) that need to understand and access authentication as defined by "the app" If the same codebase handles auth across the board it's much simpler and more reliable.

From a security perspective, the client is 100% irrelevant. You might prefer to offer a good UX in the face of authorization failure, but that doesn't affect the security of your app one way or another.

Good APIs look like simple functions; they take certain very structured inputs (path, query params, headers, body) and produce a simple structured output (usually a json blob). They're usually well defined, limited in scope, often idempotent, and easy to write automated tests for.

HTML endpoints are more complex because they generally combine many different functions at once, rely on server side state like sessions, and generate large quantities of unstructured input. They tend to be hard to test exhaustively and it can be hard to reason about all the possible edge cases.

Re: Moving from React to htmx

#126

Post by canadianfella »

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…

No post body was provided.

Re: Moving from React to htmx

#127

Post by runald »

qwertyzxcvmnbvw wrote: post #71
mediumdeviation wrote: post #56

Earlier quoted context omitted.

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.

As someone living in one of those countries, I beg to differ. Cheap maybe, but mobile internet is neither fast nor stable.

Re: Moving from React to htmx

#128

Post by netheril96 »

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…

Even worse for Chinese users who have to browse many US sites with a VPN (e.g. me)

Re: Moving from React to htmx

#129

Post by edflsafoiewq »

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).

Re: Moving from React to htmx

#130

Post by nine_k »

jaytaylo wrote: post #28
jbverschoor wrote: post #20

Earlier quoted context omitted.

Oh god please let’s not go back to JSF

How was it worse than the current state of affairs of complexity with React? Bowser, npm, typescript, obfuscation, compressors, build pipelines.. it’s a lot. Life at the front-end today is so discombobulated, creating a bunch of backend APIs which will generally only be used and consumed by a single browser front-end. I’m genuinely curious, because I never used JSF except for a single school exercise

Frankly, with yarn, typescript, and a packaging / compressing tools of your choice, web frontend development is pretty pleasant and efficient these days. (To say nothing of using Elm, if you can afford it.) Typescript is particular is nice compared to, say, Python, and even to Java (though modern Java is quite neat.)

The only unpleasant part is dependency management, but you have the same, or worse, with Python or Ruby, and neither Java nor Go are completely hassle-free either.

Post reply on HN