blog/2023/02/react-is-the-new-ibm/

[utterances-bot]

@chrlschn - React is the New IBM

You’ll never get fired for picking it, but it’s going to be expensive, bloated, difficult to get right, and joyless every step of the way.

https://chrlschn.dev/blog/2023/02/react-is-the-new-ibm/

[JackYoustra]

Some questions… Native: RN, via Expo, is the only serious JS mobile solution that I know of - it seems like a nice thing for a unified react framework, no? The graphs on “sites that use x” seem a bit skewed - if React is good because low learning curve, you’d expect apps that would be poorly written in any language to be poorly written in React, right? Is there a comparable comparison wrt cpu time and bytes? (also I think the graphs are flipped) The benchmarks are pretty bad, but a lot of that comes down to the difficulty of figuring out exactly what data dependencies are in callbacks. React forget’s presentation (s/o mofei zhang) seems to have much much better perf records in reactcon. The idea of pure rerendering is just… so much better! If you don’t model your programs functionally you lose a lot of the algebraic properties of your code - it’s why the iOS world’s most popular framework over SwiftUI (which is very similar to react’s model) is TCA, which is even more in the algebraic direction than react! https://github.com/pointfreeco/swift-composable-architecture Your core hangup seems to be a completely independent problem from UI frameworks: modeling state and UI independently is super hard! That’s why React isn’t the first-class solution for data modeling and there are lots of frameworks, Redux being the one most heard of. Facebook uses GraphQL via Relay for data modeling for this reason - you’re not supposed to shove all of your persistence into useState!

I guess the core part is: you disavow the usage of pure functions (and, by extension, declarative / functional programming for UI development). I ask: what is the alternative you have in mind?

[CharlieDigital]

The graphs on “sites that use x” seem a bit skewed - if React is good because low learning curve, you’d expect apps that would be poorly written in any language to be poorly written in React, right? Is there a comparable comparison wrt cpu time and bytes? (also I think the graphs are flipped)

The benchmarks are pretty bad, but a lot of that comes down to the difficulty of figuring out exactly what data dependencies are in callbacks. React forget’s presentation (s/o mofei zhang) seems to have much much better perf records in reactcon.

If you read these two paragraphs together, then it would be pretty obvious that React has a base performance issue because of the design of its render cycle. The former follows from the latter; React is simply harder to do well and make performant compared to peers.

The idea of pure rerendering is just… so much better! If you don’t model your programs functionally you lose a lot of the algebraic properties of your code

That's exactly what my users ask for: they want my code to be more algebraic. Just kidding: they want software that is stable and solves business problems.

...it’s why the iOS world’s most popular framework over SwiftUI

Could it be because it's made by Apple -- you know, those guys that own the platform?

Your core hangup seems to be a completely independent problem from UI frameworks: modeling state and UI independently is super hard! That’s why React isn’t the first-class solution for data modeling and there are lots of frameworks, Redux being the one most heard of. Facebook uses GraphQL via Relay for data modeling for this reason - you’re not supposed to shove all of your persistence into useState!

Give other tools a try and see for yourself. I've worked in a production capacity with React, Vue, Next, Nuxt, Astro, web components, and tons of vanilla. By far, React is the hardest to do well at scale whereas it is perhaps the easiest to do well in small apps.

I guess the core part is: you disavow the usage of pure functions (and, by extension, declarative / functional programming for UI development). I ask: what is the alternative you have in mind?

This statement is made as if there aren't already existing alternatives that are already delivering apps out there in the real world.

[JackYoustra]

If you read these two paragraphs together, then it would be pretty obvious that React has a base performance issue because of the design of its render cycle. That doesn't follow - you're complaining about an implementation that could be improved, not the actual architecture of React. If I can add React forget in a way that's completely backwards-compatible (iirc the plan?) and that brings the perf numbers up, then the architecture is sound, it's just the implementation is weird.

Which may be the case! If you need global high-performance, then maybe React isn't for you, but most customers don't really care that much about perf, they care, as you said, about features and stability, both of which are enhanced by having inline JSX, good state models, and the largest package ecosystem and employee networks.

That's exactly what my users ask for: they want my code to be more algebraic. Just kidding: they want software that is stable and solves business problems.

...? The purpose of algebraic declarative structures is stability, facebook didn't rewrite its whole site because one engineer said "category theory good" (and if they did, by god they would've just used elm instead of React). I could make the argument about literally any design framework (or CS theory in general) under the sun: after all, Win32 native apps are, by far, the smallest and most performant solution, but we've moved on because having portable algebras instead of native imperative layout systems is far far more maintainable and team-scalable. React seems to be the most scalable and feature-rich (what do large orgs use?) and the easiest to learn (what to independent people use?)

Could it be because it's made by Apple -- you know, those guys that own the platform?

TCA's not made by Apple... I mean, you'd figure that if it was unpopular, the leading framework used to enhance SwiftUI would go away from the declarative model into something less react-like. My point is TCA (NOT made by Apple, the community direction) actually goes way way harder into the algebraic direction because the code bloat and performance loss more than makes up for itself in composability, runtime stability, and testability.

Give other tools a try and see for yourself.

I have! Literally look at Vue (and nuxt by extension), they have prop state (useState), hierarchal state (useContext), and their best official state management library is pinia, which is just SAM Redux, something that React supports like ten different ways depending on the flavor that you want to use.

Hell, if we're talking about random benchmark optimality in this (it seems to be a big point in the post), you can't beat out something that doesn't go JS! Just go with yew, a rust SAM framework. Sure, perf will be bad until browsers add access to dom elements from wasm, but it'll probably have the best perf and size of any webapp type once that happens.

This statement is made as if there aren't already existing alternatives that are already delivering apps out there in the real world.

And yet, by your own account, React is by far the most popular and has the richest package ecosystem. Losing on technical margins is irrelevant: as you said, business decisions are made much closer to solutions. If I look at what I want in a company's tech stack, I have a few things in mind:

• Supported
• Well-tested
• Not too exotic (I want to be able to hire people)
• Able to fit my needs
• As much batteries included as possible
• As high-level as possible and still able to address the problem (mostly just speed)
• Encapsulating / generalizing / able-to-scale-to-multiple-devs-and-features

The only thing I can think of that would make React worse in solely pure tech is if someone magically had a better way of doing state reconciliation. That would really help the last point - it's a real big pain point to not be able to ergonomically swap between graphql / contexts and prop drilling - but the only choice you laid out that doesn't have a fundamentally similar component architecture as react is native web (and script-tag astro, although I only took a cursory glance)! Saying "pure functions hard and not as performant as literal pure imperative web" (something that definitely fails the last point) is true but not useful, you can hardly scale anything like that, and if you want a fast part of an app just eject and manage a div yourself or something.

[atilkan]

No one is getting fired for choosing alternatives. Maybe be objective and stop pushing React as a default so people can choose something based on DX and performance. And then maybe they can innovate (doubt).