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.
> 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.
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:
I don't think that's true. Under the mutable UI trees, 60 times a second the entire UI is rendered from scratch in the OpenGL (or similar) layer. It seems to me it would be possible to completely skip that part by making a new React-like OpenGL renderer.
I agree with that idea. In my view I think Skia method calls are like assembly and virtual DOM is like a high level programming language. So I decided to try one https://github.com/Quamolit/ my original idea was to write in React way but generates operations that can be finished with Canvas API.
I found it quite hard to finish such a project though. Browser vendor are more likely doing the job of abstracting out hardware and OS powers so people can utilize. There's still much more effect to be done to create an FRP-like(functional reactive programming) system that everybody is happy with.
> (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.
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?
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.
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?
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.
Thanks for explaining. Doing everything top to bottom myself, my mind boggles at an organization where there are multiple "view developers." Nice to have that kind of resources!
Did you try Auto Layout with a flattened view hierarchy? Deeply nested view hierarchies are not really the best way to go if there are performance issues. You can get huge speedups by flattening things. I have a feeling this could even work within the ComponentKit way of doing things.
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."
We actually use GCD a lot. In components we use a background queue for allocating and measuring/laying-out component trees and then we punt them over to the main queue for "mounting" (attaching them to UIViews that we create or recycle and configure).
For the mem-models portion we also use GCD all over the place. However when we had mutable models (and used Core Data) we had data races, something GCD can't really help you. Moving to immutable models actually makes our system work really well with GCD because you can pass immutable objects around threads without much concern really.
For autolayout, we did some explorations and ultimately decided (especially for low-end devices) that having our layout calculations occur on the main-thread was too cpu-intensive for some of our more complex-layouts (which are quite common in feed).
Before mem-models we explored what the best cutting-edge practices were in using Core Data but ultimately we were using it as a cache and not as an ORM - wrong tool for the job.
Before components we looked at vanilla UIKit, re-approaching an MVC-style architecture given the lessons we had learned, and using Autolayout instead.
>we had data races, something GCD can't really help you.
Thank you so much for bestowing that insight. But I think you should read the docs on dispatch_barrier_sync() and dispatch_barrier_async() before claiming GCD couldn't have helped with the problems you were seeing in your code base.
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/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.
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.
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)
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.
> 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.
(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.
it is natural and a good company strategy. Let several teams to produce competing designs that solve a similar problem with different tradeoffs. Eventually one will win inside the company.
For example Google has many many competing data backend projects build on top of Big Table, emphasing different requirements.
And they can also branch out instead of wondering 'what if we didn't make React Native rely on JavaScript and instead just used Objective-C?'. Both approaches will have differing strengths and weaknesses and both teams (and hopefully future teams of new projects elsewhere) will have more knowledge and experience to learn from.
I think it’s quite amazing what Facebook/Instagram are doing. They are creating a legacy that will hopefully inform what Apple and Google do with their frameworks too.
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++."
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.
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
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?
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.