

AsyncDisplayKit – iOS framework that keeps complex user interfaces responsive - robert-boehnke
http://asyncdisplaykit.org/

======
coldcode
I have no desire to layout everything in code (I know some people like this, I
don't) so it's not very interesting to me. It would seem to require you to
write your app in a completely different way. I wonder what debugging would be
like with it, given that threaded code is always more painful. It might be
more interesting once people release actual apps with it (outside of FB).

~~~
tsycho
Most iOS UI at Google is laid out in code as well. It makes it much easier to
review code, see diffs, and have multiple people working on the same part of
the app without causing crazy merge conflicts.

~~~
acmecorps
Yeah. I acknowledged that storyboard is easier and faster for simple to
moderate UI, but merging using git/vcs is horrible. Plus, it's difficult to
build cool animations with those.

------
jamesgpearce
Full blog post announcing the framework is here:
[https://code.facebook.com/posts/721586784561674/introducing-...](https://code.facebook.com/posts/721586784561674/introducing-
asyncdisplaykit-for-smooth-and-responsive-apps-on-ios/)

------
LeoNatan25
The flip side of something like this is that it creates a "floaty" feeling,
due to delaying UI update for several runloop passes (jumping from one queue
to another). Sometimes this is more acceptable but often it is not. If you
played with Paper, and felt it was "floaty", now you know why. If it didn't
bother you, I guess you are less sensitive to this. Not to say this library is
useless, like most things, when not abused, good can come from it.

~~~
ScottGoodson
Curious to better understand what you mean—in my experience, this is not true
at all. All touches / gesture handling are direct manipulation with no delays
at all. All the asynchronously-prepared content is rendered in advance with a
large offscreen buffer, so in general it should be done rendering before it's
onscreen. In the cases where you scroll really fast and get to something that
hasn't finished rendering, the alternative in a regular app architecture is to
simply stutter (block the UI) until it's done rendering.

This framework can be used in very flexible ways, such as "try to render
everything offscreen, but if it's going to come onscreen and hasn't finished
yet, block and wait for it to be done". Even that approach will result in a
much more responsive feel while ensuring that you have the same guarantees as
a synchronous UI about content being finished rendering when it is visible.

------
ortuman
Awesome stuff, though it's a pity autolayout cannot be used along with this
framework. Anyway, it's worth to take a look.

~~~
mazerackham
Seriously, is autolayout actually used by a lot of people? I tried doing
something semi-complex a few weeks back and I spent hours fighting with it.
Then I spent 10 minutes writing 10 lines of code and it worked.

When you finally grok it, does it become worth it?

~~~
ggamecrazy
Once you "get" doing AutoLayout you will never want to go back. I'm speaking
as a guy who swore up and down to frames. All it takes is doing some adaptive
stuff for 3.5, 4, 4.7 and 5.5 inch screens to make you want to jump out your
window.

By the time you create a good system to get the frames to work with an
adaptive layout, you just implemented a poor man's version of AutoLayout.

Just my $0.02. I think it saves me a lot of time. I try to avoid AutoLayout in
IB and just use code, either a third party DSL or apple's own visual format
language.

~~~
acmecorps
How do you do animations with autolayout? Isn't it kinda hard compared to
frames?

~~~
solomone
It's actually easier depending on the animation you want to do. You can set an
NSLayoutConstraint to an IBOutlet and then change it's constant in an
animation block.

------
cmyr
It's really neat to see facebook's iOS team releasing so much of their work.
This framework is probably not going to be that relevant to tons of use-cases,
but even if you'll never use it you'll probably get a lot out of looking at it
closely and thinking about why it makes the decisions it does.

------
ryandrake
On Safari, the entire site seems to have no content and just re-directs to
itself in a loop over and over: meta http-equiv="refresh" content="0;
[http://asyncdisplaykit.org"](http://asyncdisplaykit.org")

~~~
jamesgpearce
it's now launched; thanks for your patience :)

------
rgbrgb
Very cool! This bears quite a resemblance to the way React.js constructs a
virtual DOM so that it can optimize drawing. Do you guys have a way you're
benchmarking performance improvements? Are you just looking at time spent on
the main thread?

~~~
ScottGoodson
Yes, there is a broad similarity: abstracting away from performance or
threading limitations of common UI building blocks. However, React has a
declarative, single-directional data flow model. AsyncDisplayKit is
imperative.

Declarative code is great for a lot of things, but interactivity and
animations are definitely not one of them. Also, ASDisplayNode was designed to
be as similar as possible to UIView (also imperative).

We don't have a benchmark suite, largely because it is so easy to use
Instruments to do CPU traces and look for any chunks of main thread work that
threaten frame drops.

------
ldn_tech_exec1
Would it be possible to build an alternative to AutoLayout that works with
AsyncDisplayKit? How could it this be done?

------
ratsimihah
Doesn't seem available either on Github or Cocoapods yet.

~~~
spicyj
The GitHub page is up now.

~~~
ratsimihah
Thanks!

