Hacker News Reader

Comment by hombre_fatal | Hacker News Reader

> When I first saw React.js, I had a quick glance and thought that it was cool, they finally figured out how to do a Cocoa-like MVC UI framework in JavaScript.

So smug that it's hard to take seriously.

Especially when even Apple is switching to SwiftUI, something that is the opposite of Cocoa and more similar to React.

Though I wonder how someone with both Cocoa and React experience looks at React and goes "Oh, it's the old-school Cocoa way of doing things!"

This blog post reminds me of HN four years ago when everyone had their little smug epithet about Javascript and web developers, those idiots who are too amateur to see the beauty of Cocoa and winforms or whatever most of us are happy to swap with something better.

View on HN

Agree that it's phrased really smugly and that detracts from the message, but important to note it's dated 2018, at which time React was very different than it is today and SwiftUI didn't exist yet

I'd argue that React is pretty much the same now as it always has been. The ecosystem has matured and grown for sure but even the basic API has remained pretty much stable.

Hooks didn't exist yet, for one, as mentioned in the Dan Abramov quote at the bottom:

> we’re adding a stateful function API as a preferred alternative to classes soon

Class components were the focus at the time, and are now all-but-deprecated. Also, Redux was still very popular in practice, which it isn't so much now (partly due to hooks)

That's a pretty big change in the way people use React, which certainly informs a discussion like this

I'd have to disagree with this on a couple levels.

Yes, hooks change the way we write React code in some ways, but in a lot of other ways nothing has changed. We still write components that accept props, have state, and return UI descriptions as JSX elements, and those components may cause side effects after a render is completed. Conceptually, the core principles of React are still exactly the same, and hooks didn't change that.

Additionally, Redux is still by far the most widely used state management tool for React apps. My rough estimates are that 45-50% of React apps use Redux, whereas Mobx and XState are around 10-15%.

I'll agree that Redux is not as "popular" as it once was, which is due to a number of factors. It was heavily overused early on, and the ecosystem has expanded to include a lot of other great tools that overlap with some of the use cases for Redux. But, "modern Redux" with Redux Toolkit is much easier to learn and use than the legacy hand-written patterns, and we get highly positive feedback on a daily basis from folks who tell us they enjoy using RTK. (In fact, RTK by itself has more downloads than Mobx, XState, or React Query.) So, that tells me Redux will continue to be widely used for a long time.

> My rough estimates are that 45-50% of React apps use Redux, whereas Mobx and XState are around 10-15%

Curious how you arrive at these estimates? I would have thought fewer than 30% of React apps started in the last year or so use Redux, but of course, many still do, perhaps a higher percentage of apps that were built >2 years ago do (you could argue these are more mature, so they've "grown into" redux, though you could also say they're legacy and preceded newer React capabilities and tooling)

I don't have a strong inclination one way or the other, and have been toying with introducing Redux (or some other kind of state management) for the app I work with, but my understanding from the general sentiment of the threads/projects I follow is that market share of Redux has fallen in the last year or 2.

Just looking at download trends redux is literally in a class of its own. What I do wonder is how often people are abusing context, state, and reducers to make their own terrible state managers rather than using redux? I bet that number is higher haha.

https://npmtrends.com/mobx-vs-redux-vs-xstate

Good question!

The really short answer is: mostly looking at NPM download stats, Github "depended by" numbers, and random polls on Twitter.

Which are all _horribly_ flawed metrics, but they're also all we have to go by.

I wrote a couple longer comments on Reddit a while back that went into more details on some of the numbers and the potential flaws in using them:

- https://www.reddit.com/r/reactjs/comments/lcgqnd/state_manag...

- https://www.reddit.com/r/reactjs/comments/skbyb1/the_most_po...

and unfortunately you asking me about this is tempting me to turn those comments into a blog post with some additional thoughts :) (I.... may actually try to do that tonight or tomorrow. If you're interested, keep an eye on my blog at https://blog.isquaredsoftware.com .)

I'll definitely agree that Redux usage has peaked in _relative_ terms, although as you can see from the download numbers it seems to still be growing in _absolute_ terms. Also it's entirely possible that fewer new projects are choosing Redux.

Then again, how do we even count "usage" in the first place? I've seen Web3 app boilerplate repos that include Redux Toolkit. If 1000 people clone that repo and play with it, how do we compare that usage conceptually vs one app using Mobx that's been around for years and has a bunch of developers working on it daily?

As I've pointed out in a number of podcasts and articles: I'm not trying to convince people they _must_ use Redux, or even that they _should_ use Redux. I just want people to be aware that modern Redux is way easier than legacy Redux, that Redux _is_ still widely used and is a viable choice, and what some of the tradeoffs are when using Redux or any other state management library.

I've actually been trying to get the community to come together and work on a centralized site that would list tools in different use cases and categories such as state management, styling, data fetching, and build tooling, describe purpose / use cases / tradeoffs for each tool, and have that as a recognized resource for people to use when researching what to use for a project. You can see the original RFC discussion and prototype site here:

- https://github.com/markerikson/react-community-tools-practic...

- https://react-community-tools-practices-cheatsheet.netlify.a...

Sadly I haven't had time to push this forward, and it needs to have more people involved and helping fill out content on the various topics (not just me).

Hiya. As mentioned in my other comment, I decided to write up a blog post about all the different potential metrics you can use to estimate package market share, flaws with those metrics, and how I use them to guesstimate React state management lib market share (Redux et al):

https://blog.isquaredsoftware.com/2022/07/npm-package-market...

The biggest takeaway here is that based on these numbers, I'm actually going to have to revise my "45-50%" estimate that I've been throwing around for the last couple years down to about "33%". React downloads have continued to go through the roof, and they've finally separated more of a gap from React-Redux downloads. There's also a surprisingly large differential in terms of Github "dependent repo" numbers.

That said, Redux is most definitely still the most widely used state management lib by a mile.

My main guesses for the changes are that more folks _are_ just using React state and no separate state library, and possibly some influence from number of learner repos.

If your goal is to increase RTK adoption, rather than being reactively defensive whenever someone writes something remotely negative about Redux, may I suggest focusing on the highly positive feedback you mention? Writing up case studies on how RTK helped solve concrete problems, instead of being summoned anytime someone is wrong about Redux on the internet…

Anyone judging Redux differently if it has a 15% or 45% market share is making decisions based on the wrong parameters anyway.

I've debated throwing together a docs page with a bunch of quotes and links to people saying how much they enjoy using RTK, but I've got enough other stuff on my plate that it hasn't been a priority.

For what it’s worth, a lot of developers I know who work on complex iOS applications have more or less abandoned SwiftUI after trying it.

Why are they abandoning it? Could you please share reasons in as much detail as possible? Very interested to know.

It is fine for small toy apps (think the calculator), but it is missing a lot of functionality to build a full fledged app. Think collections, which is the backbone of most apps.

UIKit is very mature and has evolved to a really good UI platform. SwiftUI is not even close to unseat it. Maybe in few years it will mature as well, but for now UIKit is the way to go.

I only ever played around with making a toy app while following along with Stanford's Swift UI course[1], and even just the basic things I was doing there, I ran into multiple frustrating/confusing bugs.

As if it wasn't difficult enough to wrap your head around learning it in the first place, running into bugs makes it even harder because you think you're doing something wrong until you finally ask online and get told by people more knowledgeable than you, "I don't know why that's happening, wrap your view in a container and it'll work"

[1] https://youtube.com/playlist?list=PLpGHT1n4-mAsxuRxVPv7kj4-d...

At Beam[0] we are building a web browser that uses SwiftUI almost everywhere except for the text editor.

So far its been great to build UI and animations with. Each release gives SwiftUI more apis and features, so there are less and less older style apis to wrap in SwiftUI ourselves.

[0] https://hellobeam.com

Those scroll effects are quite janky on iOS btw

It takes quite a bit to wrap your head around the SwiftUI way of doing things. I think a lot of people get frustrated and throw in the towel. I'm sure React is the same story.

And while you can't do everything in SwiftUI, it's pretty solid and capable now. I only have a couple things using AppKit in a large macOS project.

You might want to listen to Pete Hunt, one of the creators of react.js:

https://futureofcoding.org/episodes/011

17:30

"The core idea with react, and this is the only thing that matters, so don't view components as a react innovation. Components have been around forever. You build any sort of native application on Windows or macOS or iOS and there's a notion of component, some call it a view or whatever, but the idea of composing components out of other components has been around since the dawn of time.

I don't know why we weren't doing it on the web. I think we were just, I don't know, being stubborn or something. But that's not a new innovation."

Hmm...sounds just a bit like what they were trying to achieve was something along the lines of "Cocoa for the Web".

But what does he know?

¯\_(ツ)_/¯

Anyway, he does go on to say that the core innovation is having the UI be a pure function of some state. But that's the part that isn't actually true. It ain't a pure function. See Dan Abramov's comment:

Support for local state and side effects is absolutely a core feature of React components and not something we avoid for “purity”.

So if it's not a "pure function" of the state, then it's some mapping of the state. All UI is some sort of mapping of the state, otherwise it's not really a UI.

Hmm...

So being a "pure function" of the state is not the innovation, because it isn't true, and being some mapping of the state is also not the innovation, because all UI is a mapping of the state.

Hmm...

So what is the actual innovation? It is more or less directly and visibly expressing the UI in code. And since all our languages are essentially procedural (functional, OO) that means expressing the UI as a procedure (function/method).

And so the "pure function of the state" turns out not to be a feature of this model, but a (squishy) requirement. Because in order to make the UI definition a procedure, you have to re-run that procedure at arbitrary times (and ideally also run it partially). And so the requirement is "sufficiently pure that we can re-run it".

And that is an innovation, and it's kinda cool. But it does break down rather quickly, which is why all these frameworks keep iterating, and iterating, and iterating.

> since all our languages are essentially procedural (functional, OO) that means expressing the UI as a procedure (function/method).

I understand 'functional' to be used as the direct contrast to 'procedural'! Is that not your understanding?

> So what is the actual innovation? It is more or less directly and visibly expressing the UI in code.

The 'visibly' part here doesn't really actually hold true, does it? Once you've componentized your <swiftui/react/html/[VFL](https://developer.apple.com/library/archive/documentation/Us...>, it's probably not super visibly understandable.

The best definition i can think of for declarative UI frameworks is probably something closer to 'frameworks that optimize for your ability to make a pure function representing state'.

(After all `[[UIViewController alloc] init]` does indeed purely say 'you have view controller' — that's just not super granular!)

In this light, isn't SwiftUI just a setup more optimized in this direction

That isn’t innovation either, it’s just game developers who are too busy to tell us immediate mode gui stories all day. The only innovation it has is solving the problem natural to the web only – dom changes suck, amplified by a historical lack of a cell concept (which is a core disaster). They partially “fixed” that by diffing vdoms. Everything else is just opinionated bargain on top of that.

Interesting, what is a “cell concept”?

Basically an element without its own geometry that renders in multiple locations on the screen. E.g. if a dom table (or a grid) has 10 columns x 1000 rows, it must have 10k real td (div) elements. A table in most desktop frameworks will only have 10 cells which will be rendered at multiple (visible only) y-positions. When you scroll, they render a few in advance on a scroll-cache surface. This saves memory and reduces reflow pressure because a framework knows the geometry of a cell.

Of course if a table (any collection really) contains differently looking items, it may have more than 10 cells, and rendering controller may choose between them based on which row/column is rendered.

React mentions in their docs a plugin which simulates exactly that (forgot the name, something like react-dynamic-scroll).

Also, some frameworks use cells to render active elements basics, e.g. an input without a frame, or a check mark cell without a background. This helps to make controls editable without instatiating a real input/check/button element at the coordinates of a cell. This makes every button in a container a single button which signals clicks to its container, which based on x,y knows which item that is and signals rendering controller that item X was “clicked on the button B”.

Wow, I've been trying to come up with a way to do this on the web for a while now, but haven't cracked it yet. Had no idea it was a common thing in other UI technologies.

Here is the react docs part: https://reactjs.org/docs/optimizing-performance.html#virtual...

Click on the links, there are live examples.

> You build any sort of native application on Windows or macOS or iOS and there's a notion of component

> Hmm...sounds just a bit like what they were trying to achieve was something along the lines of "Cocoa for the Web".

More like native UI for the web? I'd take your point if he only mentioned macOS or iOS. Check your bias!

It should ring at least a bit of nonsense when something that was already perfect gets better every year and grows more methodics around it non-stop.

> Especially when even Apple is switching to SwiftUI, something that is the opposite of Cocoa and more similar to React.

Well, that's hardly a counter argument. The core argument should be whether "SwiftUI is better than Cocoa", and not whether a Big Tech company is switching to it unless we are in a popularity contest.

> about Javascript and web developers

I’ve heard that the original React was built in SML, rewritten in OCaml, and later transcribed to JS (and now is developed in ReasonML)[1].

We shouldn’t downplay the unmitigated[2] disaster of language design that JavaScript (and more broadly, the engineering disaster that dynamic typing) is.

Just the fact that React was/is created by a person who is functional, static, strongly typed language aficionado is a testament that good things in the JS world comes simply because of its entrenched status due to being the only directly supported language in browsers — not because of anything inherently good about JS.

[1] https://news.ycombinator.com/item?id=15209814

[2] Now partially mitigated by TypeScript.

Agreed. If it was cocoa Apple wouldn’t ditch their old ways to create a clone of react approach

It's not smug to observe that someone ported MVC to JavaScript. It's a lot of work to build.

Except it's not MVC.

React would be the V in MVC, no?

I mean, even Vue takes its name from that (pronounced "view").

There are no controllers in the react way of doing things, or at least no separation between view and controller if that's your perspective.

Well, the role of Controllers in (real) MVC is actually pretty limited.

At that point you're defining MVC so broadly as to be meaningless.

No, I am using the original definition of MVC.

https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-in...

There were a lot of “MVC in JavaScript” frameworks before react. I don’t think that’s really a useful description of react or of the work or idea involved.

Backbone and Marionette were MVC for the web, and they have basically died out. React is a child of the Flux architecture philosophy, also developed by Facebook. [1]

[1] http://fluxxor.com/what-is-flux.html

EDIT: I lied, React came first. Still, they have a lot of similarities, being developed by the same company.

MVC examples in this article do not represent MVC in Cocoa. E.g. last time I checked cocoa tables were bound to array controllers, which controlled filtering, available actions etc. Not to bare models. Older-style cocoa mvc rendering was also based on the view<->controller connection, which may act as a “store” or do something more sophisticated, depending on what you write in delegate methods. These comparison graphs always involve some “head & shoulders” vs “grey regular shampoo” style narrative.

Well yes: Apple MVC also isn't really MVC. See:

https://blog.metaobject.com/2015/04/model-widget-controller-...

However, sufficiently MVC for the purposes of the post.

The article points at issues with “regular MVC” which do not exist in Cocoa way of doing it. So no, not sufficiently.

None of my articles points at issues with "regular MVC"

> React is a child of the Flux architecture philosophy

FWIW, this isn't actually the case.

React was first announced in 2013:

- https://en.wikipedia.org/wiki/React_(JavaScript_library)

The "Flux Architecture" was first announced a year later, in 2014:

- https://youtu.be/nYkdrAPrdcw

React's original influences were things like Facebook's internal PHP-based UI definition layers:

https://reactjs.org/blog/2016/09/28/our-first-50000-stars.ht...

The React architecture is very different from MVC.

And now four years later they accepted the web developers but now are having smug epithets about Web3 developers, those idiots who are too idealistic to accept the beauty of Web2’s centralized model

Reply on news.ycombinator.com