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