5 ms·

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

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

kkarimi 4y ago
Agreed. If it was cocoa Apple wouldn’t ditch their old ways to create a clone of react approach
brundolf 4y ago
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
- deleted 4y ago
  [deleted]
- adzm 4y ago
  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.
  - brundolf 4y ago
    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
    - acemarke 4y ago
      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.
      - pcthrowaway 4y ago
        > 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.
        azemetre 4y ago
        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 https://npmtrends.com/mobx-vs-redux-vs-xstate
systemvoltage 4y ago
> 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.
hgsgm 4y ago
It's not smug to observe that someone ported MVC to JavaScript. It's a lot of work to build.
- jonkoops 4y ago
  Except it's not MVC.
  - pier25 4y ago
    React would be the V in MVC, no? I mean, even Vue takes its name from that (pronounced "view").
    - lmm 4y ago
      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.
      - mpweiher 4y ago
        Well, the role of Controllers in (real) MVC is actually pretty limited.
        lmm 4y ago
        At that point you're defining MVC so broadly as to be meaningless.
        mpweiher 4y ago
        No, I am using the original definition of MVC. https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-index.html https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-in...
- dan-robertson 4y ago
  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.
atwood22 4y ago
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.
- epicureanideal 4y ago
  Why are they abandoning it? Could you please share reasons in as much detail as possible? Very interested to know.
  - ardit33 4y ago
    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.
    - hbn 4y ago
      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-dQYoC3VVu https://youtube.com/playlist?list=PLpGHT1n4-mAsxuRxVPv7kj4-d...
    - interactivecode 4y ago
      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 https://hellobeam.com
EGreg 4y ago
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
mpweiher 4y ago
You might want to listen to Pete Hunt, one of the creators of react.js: https://futureofcoding.org/episodes/011 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.
- zethraeus 4y ago
  > 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/UserExperience/Conceptual/AutolayoutPG/VisualFormatLanguage.html)/declarative-thing-of-choice 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
wruza 4y ago
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.
winter_blue 4y ago
> 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 https://news.ycombinator.com/item?id=15209814 [2] Now partially mitigated by TypeScript.

kkarimi 4y ago

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

brundolf 4y ago

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

deleted 4y ago
[deleted]
adzm 4y ago
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.
- brundolf 4y ago
  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
  - acemarke 4y ago
    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.
    - pcthrowaway 4y ago
      > 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.
      - azemetre 4y ago
        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 https://npmtrends.com/mobx-vs-redux-vs-xstate

systemvoltage 4y ago

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

hgsgm 4y ago

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

jonkoops 4y ago
Except it's not MVC.
- pier25 4y ago
  React would be the V in MVC, no? I mean, even Vue takes its name from that (pronounced "view").
  - lmm 4y ago
    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.
    - mpweiher 4y ago
      Well, the role of Controllers in (real) MVC is actually pretty limited.
      - lmm 4y ago
        At that point you're defining MVC so broadly as to be meaningless.
        mpweiher 4y ago
        No, I am using the original definition of MVC. https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-index.html https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-in...
dan-robertson 4y ago
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.

atwood22 4y ago

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.

epicureanideal 4y ago
Why are they abandoning it? Could you please share reasons in as much detail as possible? Very interested to know.
- ardit33 4y ago
  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.
  - hbn 4y ago
    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-dQYoC3VVu https://youtube.com/playlist?list=PLpGHT1n4-mAsxuRxVPv7kj4-d...
  - interactivecode 4y ago
    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 https://hellobeam.com

EGreg 4y ago

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

mpweiher 4y ago

You might want to listen to Pete Hunt, one of the creators of react.js: https://futureofcoding.org/episodes/011 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.

zethraeus 4y ago
> 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/UserExperience/Conceptual/AutolayoutPG/VisualFormatLanguage.html)/declarative-thing-of-choice 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

wruza 4y ago

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.

winter_blue 4y ago

> 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 https://news.ycombinator.com/item?id=15209814 [2] Now partially mitigated by TypeScript.