7 ms·

ComponentKit by Facebook: A React-Inspired View Framework for iOS

149 points by saniul 12y ago

bsimpson 12y ago
> (Don't confuse ComponentKit with React Native, a framework for building apps in Javascript.) As long as they can't describe it without citing React, this is going to confuse people. At the very least, the logline should mention Obj-C/Swift/Cocoa to differentiate the projects.
- fnordsensei 12y ago
  Indeed! I am for one quite confused. So this is native to Obj-C, right? Unlike React Native, which is not native, I guess? Can it in any way be made to interact with React Native or are they two completely different technologies (i.e., does React Native render to ComponentKit)? Why do Facebook need both? When do they use the one over the other? Why?
  - bsimpson 12y ago
    Ben commented on another thread yesterday. ComponentKit is similar because it follows Facebook's philosophy for UI, but came about before React Native was attempted. (Hence, it's written in Apple's native Obj-C as opposed to React's JS.) React Native came after some successful experiments later and isn't as mature.
- hackerboos 12y ago
  This isn't even doing diffs, it has nothing to do with React. I think the clarification is purely because both projects run on mobile.
sam-mueller 12y ago
I like the steady stream of innovative projects coming out of facebook as of late, but I can't help but feel like there's quite a bit of overlap in their initiatives. Just the fact that there's a footnote about how this isn't react-native illustrates my sentiments exactly.
- spicyj 12y ago
  You're right that there's some overlap: > It may surprise you to hear that the Components library I’m describing is not React Native, but a separate project. > Why the distinction? It’s simple: React Native hadn’t been invented yet when we rebuilt News Feed in Components. Everyone at Facebook is excited about the future of React Native, and it’s already been used to power both Mobile Ads Manager and Groups. > (from http://www.objc.io/issue-22/facebook.html http://www.objc.io/issue-22/facebook.html) (I work on React.) We're going full steam ahead on React Native, but this is a slightly more mature project and we figured it made sense to release it for people who (for whatever reason) can't or aren't ready to adopt React Native yet. ComponentKit is also more mature and powers the most important part of the Facebook iOS app so it's virtually guaranteed to be rock-solid, whereas React Native has only been used in production for a few months.
  - prabhasp 12y ago
    Would be great to note this somewhere on the component kit site.
    - adamjernst 12y ago
      Will do shortly.
  - ngoel36 12y ago
    Any word on when React Native is being released? :)
    - spicyj 12y ago
      :) I think our current story is "by June 10". https://twitter.com/Vjeux/status/578311560583520256 https://twitter.com/Vjeux/status/578311560583520256
      - ngoel36 12y ago
        Any way to get early access for a huge React fan?
RussianCow 12y ago
This is a great idea, but the fact that it's implemented in Objective-C++ is a deal-breaker for me since I'm starting to use Swift in my iOS projects. From the docs: "ComponentKit is built on Objective-C++. There is no easy way to interoperate with Swift since Swift cannot bridge to C++."
- Osmium 12y ago
  You can still do it, it just presents an extra hurdle, e.g. see this project on integrating OpenCV into a Swift project: https://github.com/foundry/OpenCVSwiftStitch https://github.com/foundry/OpenCVSwiftStitch So it is possible.
- elviin 12y ago
  Isn't C++ a way to adopt React/Components across different mobile platforms?
- drhdylan88 12y ago
  tambourine_man mentioned this above, but at the end of the video they said that the next version would be in swift.
Osmium 12y ago
Interesting justification of their choice of Objective-C++ here: http://componentkit.org/docs/why-cpp.html http://componentkit.org/docs/why-cpp.html Anyone else have an opinion on this? Seems unusual for a iOS framework, especially going forward, but the reasons sound sensible enough.
- bdarnell 12y ago
  I'm a fan of objective-c++ because it gives you some nice tools to cut down on verbosity (e.g. https://github.com/viewfinderco/viewfinder/blob/master/clients/ios/Source/UIView%2Bconstraints.h https://github.com/viewfinderco/viewfinder/blob/master/clien...) and c++ is the best language for a core library shared between iOS and Android. However, it does have drawbacks, especially the limited swift interoperability. Build times are also a headache, since many of the features apple has been adding to improve build performance do not work in obj-c++ mode.
- dirtyaura 12y ago
  Properly designed C++ library using templates and macros can lead to surprisingly terse application code - not your standard STL/Boost template syntax mess. I've seen it in one of our gaming frameworks, and in e.g. Google's C++ unit testing framework. However developing the library code itself requires some serious C++ template fu and the abstraction leaks to the library user in the form of complex error messages. Strategically used, like in this case, it certainly leads more succint and readable code than pure Objective-C alone.
- tambourine_man 12y ago
  They're changing to Swift in the next version. (He mentions it at the end of the video)
  - MrGando 12y ago
    That makes sense, I don't understand how those two constructors are equivalent, it seems that he's missing a couple of parameters in the C++ version.
hartator 12y ago
Is this react native or is it a side project?
- hartator 12y ago
  My bad, was explicit written on the website: "(Don't confuse ComponentKit with React Native, a framework for building apps in Javascript.)"
- evv 12y ago
  It's used in Facebook's flagship product, so you can't really call it a side project.
giulianoxt 12y ago
Great initiative by the Facebook team. Anyone knows if there's a similar framework for Android? (declarative description of the UI, rendering based on immutable models, single data flow, etc)
- crazychrome 12y ago
  https://github.com/zserge/android-virtual-layout https://github.com/zserge/android-virtual-layout
perishabledave 12y ago
For those interested, Facebook had a good talk about this at Scale 2014: https://www.youtube.com/watch?v=XhXC4SKOGfQ https://www.youtube.com/watch?v=XhXC4SKOGfQ [edit] I just realized the video is linked on the front page of the frameworks website.
ics 12y ago
For all those focusing on the Objective-C++ aspect, I suggest watching the talk. - Faster (potentially? actually?) - Safer, because Objective-C gives too many chances to crash at runtime - They "can't wait" to port to Swift, so don't fret.
i_s 12y ago
This technology looks great. It is too bad Facebook doesn't have their own platform like iOS or Android. It's becoming pretty clear that they have a much better handle on UI technology than Apple, Google, Microsoft, or anyone really. Them creating a logical functional UI API on top of messy imperative APIs is very helpful, but even better would be if that was not necessary.
- volaski 12y ago
  I think it's not because who's better or worse, but because of how their interest is aligned with focusing on this problem than Apple.
- deleted 12y ago
  [deleted]
- cgcardona 12y ago
  > It's becoming pretty clear that they have a much better handle on UI technology than Apple, Google, Microsoft, or anyone really. Can you explain what you're thinking here? In what way(s) specifically? Thanks.
- eddieplan9 12y ago
  > a logical functional UI API on top of messy imperative APIs But without the "messy" imperative API, the functional UI cannot be built. This applies to all functional UI frameworks. It's funny that one of React's core ideas is to ditch the now old functional/declarative paradigm that is template languages and allows you to use imperative JavaScript to directly build up a virtual DOM.
  - i_s 12y ago
    Imperative coding may be useful to for implementing the API, but that does not mean it is necessary to expose an imperative API to developers. For example, in the browser, W3C and the browser vendors could have exposed a React-like API, implemented via an imperative internal C++ API, but instead they just gave us the DOM. I'm not saying that to complain, just to illustrate that how an API is implemented doesn't have to dictate the API you expose. > It's funny that one of React's core ideas is to ditch the now old functional/declarative paradigm that is template languages and allows you to use imperative JavaScript to directly build up a virtual DOM. Its agnostic about how you build up the virtual DOM, but it is common to it in a functional way, for example: this.props.searchResults.map(this.renderSearchResult)
aboodman 12y ago
Man, Facebook is just crushing it with the open source UI libraries recently.
chuckcode 12y ago
Not sure if I feel jealous or aghast that they are going to rewrite everything because apple launched swift... Must be amazing to work someplace with those kinds of developer resources
natch 12y ago
This looks really cool. However, there were a couple odd things about the talk. If you're going to spend so much time talking about managing mutation of data in a multithreaded environment, you should at least mention GCD and explain why it doesn't figure in the list of possible solutions to the problem. But the talk proceeded as if GCD did not exist, listing a few straw man bad solutions, but not the obvious go-to solution, GCD. Does the team consist of outsiders to the platform? Similarly with Auto Layout. Why no mention? Very odd. It sounds like the back story might be (just smelling this, no proof) that the developers are really smart, but were making the classic mistake of fighting the frameworks, and not having a good time, rather than learning the recommended way (GCD, Auto Layout, etc.) since they came from other backgrounds. Basically it's NIH syndrome. Fortunately, what they came up with does look very nice... I can't wait to try it out. But I wish I knew what they would have to say about working WITH the frameworks that are provided, with tools like GCD and Auto Layout... how do those not solve these problems?
- marcosero 12y ago
  They mentioned why they ditched Auto Layout on obj.io "If we switch to Apple’s Auto Layout APIs, we can do a little better: 34 lines of code. There is no longer any math or duplication — hurrah! But we’ve traded that for a different set of problems: Auto Layout is hard to set up, is difficult to debug, and suffers from poor runtime performance on complex hierarchies." http://www.objc.io/issue-22/facebook.html http://www.objc.io/issue-22/facebook.html
- adamjernst 12y ago
  Actually ComponentKit is built on GCD! https://github.com/facebook/componentkit/blob/master/ComponentKit/DataSources/Common/CKComponentPreparationQueue.mm#L141-L142 https://github.com/facebook/componentkit/blob/master/Compone... GCD is fantastic—one of my absolute favorites. We're trying to solve a problem one level above that: exposing an API that doesn't require every view developer to know the details of managing GCD queues and updating a UICollectionView. As for Autolayout, it's very powerful but isn't performant enough for layouts as complex as Facebook's News Feed. We tried it first before developing ComponentKit.
joshuak 12y ago
Anyone have a sense of how this compares with QML? QML is declarative (comparable?), and is cross platform which seems better out of hand.
EGreg 12y ago
Is MVC really as bad as all that? I lost him when he quickly breezed through suddenly adding more arrows in all directions on the screen. Why would an inner View updating its height trigger a change to the Model?

149 points by saniul 12y ago

> (Don't confuse ComponentKit with React Native, a framework for building apps in Javascript.) As long as they can't describe it without citing React, this is going to confuse people. At the very least, the logline should mention Obj-C/Swift/Cocoa to differentiate the projects.

fnordsensei 12y ago
Indeed! I am for one quite confused. So this is native to Obj-C, right? Unlike React Native, which is not native, I guess? Can it in any way be made to interact with React Native or are they two completely different technologies (i.e., does React Native render to ComponentKit)? Why do Facebook need both? When do they use the one over the other? Why?
- bsimpson 12y ago
  Ben commented on another thread yesterday. ComponentKit is similar because it follows Facebook's philosophy for UI, but came about before React Native was attempted. (Hence, it's written in Apple's native Obj-C as opposed to React's JS.) React Native came after some successful experiments later and isn't as mature.
hackerboos 12y ago
This isn't even doing diffs, it has nothing to do with React. I think the clarification is purely because both projects run on mobile.

sam-mueller 12y ago

I like the steady stream of innovative projects coming out of facebook as of late, but I can't help but feel like there's quite a bit of overlap in their initiatives. Just the fact that there's a footnote about how this isn't react-native illustrates my sentiments exactly.

spicyj 12y ago
You're right that there's some overlap: > It may surprise you to hear that the Components library I’m describing is not React Native, but a separate project. > Why the distinction? It’s simple: React Native hadn’t been invented yet when we rebuilt News Feed in Components. Everyone at Facebook is excited about the future of React Native, and it’s already been used to power both Mobile Ads Manager and Groups. > (from http://www.objc.io/issue-22/facebook.html http://www.objc.io/issue-22/facebook.html) (I work on React.) We're going full steam ahead on React Native, but this is a slightly more mature project and we figured it made sense to release it for people who (for whatever reason) can't or aren't ready to adopt React Native yet. ComponentKit is also more mature and powers the most important part of the Facebook iOS app so it's virtually guaranteed to be rock-solid, whereas React Native has only been used in production for a few months.
- prabhasp 12y ago
  Would be great to note this somewhere on the component kit site.
  - adamjernst 12y ago
    Will do shortly.
- ngoel36 12y ago
  Any word on when React Native is being released? :)
  - spicyj 12y ago
    :) I think our current story is "by June 10". https://twitter.com/Vjeux/status/578311560583520256 https://twitter.com/Vjeux/status/578311560583520256
    - ngoel36 12y ago
      Any way to get early access for a huge React fan?

RussianCow 12y ago

This is a great idea, but the fact that it's implemented in Objective-C++ is a deal-breaker for me since I'm starting to use Swift in my iOS projects. From the docs: "ComponentKit is built on Objective-C++. There is no easy way to interoperate with Swift since Swift cannot bridge to C++."

Osmium 12y ago
You can still do it, it just presents an extra hurdle, e.g. see this project on integrating OpenCV into a Swift project: https://github.com/foundry/OpenCVSwiftStitch https://github.com/foundry/OpenCVSwiftStitch So it is possible.
elviin 12y ago
Isn't C++ a way to adopt React/Components across different mobile platforms?
drhdylan88 12y ago
tambourine_man mentioned this above, but at the end of the video they said that the next version would be in swift.

Osmium 12y ago

Interesting justification of their choice of Objective-C++ here: http://componentkit.org/docs/why-cpp.html http://componentkit.org/docs/why-cpp.html Anyone else have an opinion on this? Seems unusual for a iOS framework, especially going forward, but the reasons sound sensible enough.

bdarnell 12y ago
I'm a fan of objective-c++ because it gives you some nice tools to cut down on verbosity (e.g. https://github.com/viewfinderco/viewfinder/blob/master/clients/ios/Source/UIView%2Bconstraints.h https://github.com/viewfinderco/viewfinder/blob/master/clien...) and c++ is the best language for a core library shared between iOS and Android. However, it does have drawbacks, especially the limited swift interoperability. Build times are also a headache, since many of the features apple has been adding to improve build performance do not work in obj-c++ mode.
dirtyaura 12y ago
Properly designed C++ library using templates and macros can lead to surprisingly terse application code - not your standard STL/Boost template syntax mess. I've seen it in one of our gaming frameworks, and in e.g. Google's C++ unit testing framework. However developing the library code itself requires some serious C++ template fu and the abstraction leaks to the library user in the form of complex error messages. Strategically used, like in this case, it certainly leads more succint and readable code than pure Objective-C alone.
tambourine_man 12y ago
They're changing to Swift in the next version. (He mentions it at the end of the video)
- MrGando 12y ago
  That makes sense, I don't understand how those two constructors are equivalent, it seems that he's missing a couple of parameters in the C++ version.

hartator 12y ago

Is this react native or is it a side project?

hartator 12y ago
My bad, was explicit written on the website: "(Don't confuse ComponentKit with React Native, a framework for building apps in Javascript.)"
evv 12y ago
It's used in Facebook's flagship product, so you can't really call it a side project.

giulianoxt 12y ago

Great initiative by the Facebook team. Anyone knows if there's a similar framework for Android? (declarative description of the UI, rendering based on immutable models, single data flow, etc)

crazychrome 12y ago
https://github.com/zserge/android-virtual-layout https://github.com/zserge/android-virtual-layout

perishabledave 12y ago

For those interested, Facebook had a good talk about this at Scale 2014: https://www.youtube.com/watch?v=XhXC4SKOGfQ https://www.youtube.com/watch?v=XhXC4SKOGfQ [edit] I just realized the video is linked on the front page of the frameworks website.

ics 12y ago

For all those focusing on the Objective-C++ aspect, I suggest watching the talk. - Faster (potentially? actually?) - Safer, because Objective-C gives too many chances to crash at runtime - They "can't wait" to port to Swift, so don't fret.

i_s 12y ago

This technology looks great. It is too bad Facebook doesn't have their own platform like iOS or Android. It's becoming pretty clear that they have a much better handle on UI technology than Apple, Google, Microsoft, or anyone really. Them creating a logical functional UI API on top of messy imperative APIs is very helpful, but even better would be if that was not necessary.

volaski 12y ago
I think it's not because who's better or worse, but because of how their interest is aligned with focusing on this problem than Apple.
deleted 12y ago
[deleted]
cgcardona 12y ago
> It's becoming pretty clear that they have a much better handle on UI technology than Apple, Google, Microsoft, or anyone really. Can you explain what you're thinking here? In what way(s) specifically? Thanks.
eddieplan9 12y ago
> a logical functional UI API on top of messy imperative APIs But without the "messy" imperative API, the functional UI cannot be built. This applies to all functional UI frameworks. It's funny that one of React's core ideas is to ditch the now old functional/declarative paradigm that is template languages and allows you to use imperative JavaScript to directly build up a virtual DOM.
- i_s 12y ago
  Imperative coding may be useful to for implementing the API, but that does not mean it is necessary to expose an imperative API to developers. For example, in the browser, W3C and the browser vendors could have exposed a React-like API, implemented via an imperative internal C++ API, but instead they just gave us the DOM. I'm not saying that to complain, just to illustrate that how an API is implemented doesn't have to dictate the API you expose. > It's funny that one of React's core ideas is to ditch the now old functional/declarative paradigm that is template languages and allows you to use imperative JavaScript to directly build up a virtual DOM. Its agnostic about how you build up the virtual DOM, but it is common to it in a functional way, for example: this.props.searchResults.map(this.renderSearchResult)

aboodman 12y ago

Man, Facebook is just crushing it with the open source UI libraries recently.

chuckcode 12y ago

Not sure if I feel jealous or aghast that they are going to rewrite everything because apple launched swift... Must be amazing to work someplace with those kinds of developer resources

natch 12y ago

This looks really cool. However, there were a couple odd things about the talk. If you're going to spend so much time talking about managing mutation of data in a multithreaded environment, you should at least mention GCD and explain why it doesn't figure in the list of possible solutions to the problem. But the talk proceeded as if GCD did not exist, listing a few straw man bad solutions, but not the obvious go-to solution, GCD. Does the team consist of outsiders to the platform? Similarly with Auto Layout. Why no mention? Very odd. It sounds like the back story might be (just smelling this, no proof) that the developers are really smart, but were making the classic mistake of fighting the frameworks, and not having a good time, rather than learning the recommended way (GCD, Auto Layout, etc.) since they came from other backgrounds. Basically it's NIH syndrome. Fortunately, what they came up with does look very nice... I can't wait to try it out. But I wish I knew what they would have to say about working WITH the frameworks that are provided, with tools like GCD and Auto Layout... how do those not solve these problems?

marcosero 12y ago
They mentioned why they ditched Auto Layout on obj.io "If we switch to Apple’s Auto Layout APIs, we can do a little better: 34 lines of code. There is no longer any math or duplication — hurrah! But we’ve traded that for a different set of problems: Auto Layout is hard to set up, is difficult to debug, and suffers from poor runtime performance on complex hierarchies." http://www.objc.io/issue-22/facebook.html http://www.objc.io/issue-22/facebook.html
adamjernst 12y ago
Actually ComponentKit is built on GCD! https://github.com/facebook/componentkit/blob/master/ComponentKit/DataSources/Common/CKComponentPreparationQueue.mm#L141-L142 https://github.com/facebook/componentkit/blob/master/Compone... GCD is fantastic—one of my absolute favorites. We're trying to solve a problem one level above that: exposing an API that doesn't require every view developer to know the details of managing GCD queues and updating a UICollectionView. As for Autolayout, it's very powerful but isn't performant enough for layouts as complex as Facebook's News Feed. We tried it first before developing ComponentKit.

joshuak 12y ago

Anyone have a sense of how this compares with QML? QML is declarative (comparable?), and is cross platform which seems better out of hand.

EGreg 12y ago

Is MVC really as bad as all that? I lost him when he quickly breezed through suddenly adding more arrows in all directions on the screen. Why would an inner View updating its height trigger a change to the Model?