Live data from Hacker News

Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

misago-project.org

41–50 of 224 posts

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#41

Earlier quoted context omitted.

I've found this to not be true at all. You can do quite a lot with just HTMX. Any client-side Javascript™ you strictly need can often be done fairly minimally with Locality of Behaviour (LoB).

LoB isn't going to reconcile Chat Messages rendering state and Notifications. Their dependent state by nature. HTMX largely seems to ignore this reality. In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists.

[deleted]

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#42
post #39

Earlier quoted context omitted.

This just shows that despite the 1.6M/m budget, you did not have people who could do react correctly. React.hydrate have existed since React 0.4 (2013, that is over 13 years ago) and Gatsbyjs was released over a decade ago around 2015. But while first render is of course important, now everything else is more expensive with htmx because you have to generate HTML on the server, on top of your usual fetch pipeline. Yes…

Yes but why bother with React, Hydrating pages at all if you can do something simpler? What advantages does React provide here? HTMX tools are simpler while providing straightforward thinking around html fragment caching, whole page caching. React just gives a runaround way of doing everything. I'll remind you React was built so that people could continue watching a streamed video while they navigated on a page. Most…

Because "simple" is transient at best and a lie at worst.

But for more details, see the sibling comment:

https://news.ycombinator.com/item?id=49069477

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#45

Earlier quoted context omitted.

I've found this to not be true at all. You can do quite a lot with just HTMX. Any client-side Javascript™ you strictly need can often be done fairly minimally with Locality of Behaviour (LoB).

LoB isn't going to reconcile Chat Messages rendering state and Notifications. Their dependent state by nature. HTMX largely seems to ignore this reality. In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists.

> In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists.

Which makes it even more ironic that in the 10 years since React was announced in 2013 and when I quit Facebook, they never managed to fix the original state synchronization bug that they demonstrated in the original React announcement for more than a few months at a time at best.

I'm sure technically it wasn't a singular bug over the years and the causes were complex, but React did fuck all in relation to the unread message counter being correct.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#46
post #33

Earlier quoted context omitted.

How does React fail for high traffic pages? It is amazing that you would suggest I don't understand HTMX "systems" and then go make such assertion. I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go. I looked into htmx and it is very much a second attempt at angular 1.0, which I did use for some good half…

Angular being basically the same HTMX is nonsense and you should know better. Say you have a huge Google Ads budget burning up on those landing pages. Make one version with React and one with HTMX. Open Lighthouse and see performance difference. First page renders are much slower with React. Page load is slower and this makes a huge difference in mainland USA where people are still on 3G speeds on their budget phones…

The only nonsense here is ignoring that React.hydrate have existed since React 0.4 (2013, that is over 13 years ago) and Gatsbyjs was released over a decade ago around 2015.

The gist of it continuously seems to be that people who think HTMX Great, know very little about good frontend engineering.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#47
post #31

Earlier quoted context omitted.

Why would react fail for higher traffic pages? If it's a traditional React SPA, you can use a versioned bundle with immutable caching and each user only has to download your bundle when you release an update or they use a new browser. You will need to think about how you handle spikes in traffic when you do a release, but even then users won't all load your page immediately after you bump the version. Most of the tim…

I had landing pages using React on a 1.6M/m budget. The loading times on cell phones in mainland USA meant we had people cancelling the loading of pages. When we converted to straight up cached HTML we saw a huge increase in full page loads. People weren't cancelling the page load and surfing back anymore. You cannot argue that React is extremely heavy and also adds a lot of time between first render. Test a normal H…

> loading times

What does React have to do with loading times of a page? React does not contribute to that at all other than having to download the JS runtime, which with Preact is 3KB.

> You cannot argue that React is extremely heavy and also adds a lot of time between first render

Yes you can! In no world would React itself add enough render time to make people navigate back, even if running on a computer from the 90s!

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#48

I think HTMX is a great fit for forum software. Forum websites mostly deliver non-interactive content in the form of text and maybe some audio, video, or image content. All of this can be represented as HTML and CSS. With HTMX you can do partial rendering and live updates via server-sent events. This gets you most of the way to the "client side" feel where things load dynamically based on user actions. The only prope…

> The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX.

That's how interactivity has always worked.

Server-side render everything + ship interactivity via js on top of it.

I feel like most of the web developers forgot that React/Vue/etc solve a specific problem: single-page application.

This is a very narrow and specific problem: navigating from page to page not causing full page reloads.

But the web has changed since SPAs were needed in major ways:

1. the average device and connection is insanely faster than 10-15 years ago. Receiving and rendering content is not the problem it once was in the age of 2g connections and limited hardware mobile devices. Even the very low end phone from few years ago has nowadays 0 problems loading and parsing few hundred kbs of html and js.

2. Web technologies moved at all levels. Server technologies, cloud ones, browser ones. React and company are solving problems that barely belong to the modern web.

In short: today you can have an app-like, spa-like experience even out of fully server-side rendered applications. While also benefitting from shipping much less code to the client.

There's a very minimal amount of websites and applications out there that benefit, and aren't crippled by these rendering libraries: those that vastly leverage offline capabilities of the platform and want to keep working regardless of internet being available. I'm talking the notions and linears.

But bar from those, still working with this React slop is just not good for the user. Even multi billion companies hiring leetcode ninjas can't get acceptable user experience and performance out of those libraries, and it's not a coincidence: they keep forcing the wrong tool for the wrong problem.

They keep living in 2018 and at the end of the day the only excuse for those react/angular+tailwind slop is that there's an entire generation of developers that doesn't know anything else and has long lost any proper engineering skill (if there is any) in finding the right tool for the problem. This is a familiarity issue, not sound technical decisions. It's the "you can't go wrong with oracle/mysql/ibm", but actually you can, and it shows.

What's worse: it's incredibly cheap to experiment different solutions and approaches via LLMs in 2026, but people keep slopping the same monstrosities.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#49
post #29

Earlier quoted context omitted.

> Hypermedia is what to web apps what XML is to programming languages. I have no idea what this means. The World Wide Web itself is quite literally hypermedia. The fact that a lot of front-end frameworks appear hell bent on ignoring this fact doesn't make it any less true. > Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management..…

> You may have stabilised on JSX, "we" have not. Just about any reputable sources puts the combined market share of React, Vue, Angular 2+, and Solid well above 80%. So I am not sure what "we" you are talking about.

This is ignoring the React Native and Flutter prominence on App Stores as well.
Post reply on HN