It seemed crazy and old school to me to have the UI stuff that IB generates stored in XML - I definitely thought it should generate the same code that you would write to do it programmatically.
Also, the code for building UIs programmatically has been so unnecessarily complicated. Like building a collection view with all the functions needed and boilerplate code compared to the few lines we saw in the demo.
This seems so simple and declarative. It makes me feel a lot better about my future as an app developer. Thanks again!
Most good ideas are old school. Data is more powerful than code because it can be analyzed in more ways - for instance, you can extract all the UI and text from an app, localize and re-insert it, then verify the UI won't break, all without having to execute the app.
If it's all in code you may not be able to get to some of the views or even know it's there. This is called the rule of least power - an example of getting it wrong is C++ iostreams.
Of course I'm sure SwiftUI has solved this.
It's no surprise that XML seemed more attractive when your alternatives were Java or, even worse, Objective C. But really both options are absolutely terrible.
Thankfully we are very slowly making some steps forward again with Swift.
SwiftUI is using new Swift features sort of similar to Haskell's "do" notation, which isn't actually itself monads.
Honestly, if not for SwiftUI, I find developing interfaces in Android to be infintely faster than either fighting Apple's Interface Builder or building things by code in Swift.
Though Kotlin has an interesting looking DSL for doing that named Anko.
Well you know, Cocoa and its predecessor OPENSTEP were built on the idea of using IB to compose interfaces out of actual objects that then got "freezed" into a file. So, no code at all, that was the idea.
Building views programmatically was the old school way even back then. ;)
What is so astonishing about SwiftUI is that it's simultaneously the most impressive looking visual GUI builder I've ever seen... and the most terse, diff-able syntax I've ever seen. I can't think of anything that has combined these two properties quite so successfully.
The idea behind Interface Builder is that it writes the class instances and their properties using NSCoding, and they're decoded at runtime and assigned to your IBOutlets just as if you had initialized them in code, set their properties, and assigned them to instance variables yourself. XIBs were introduced with OS X Leopard as a text-based way to store the files in source control, but they're still compiled into binary NIBs when the project is built. You're not supposed to hand-edit the XML.
It must be so much fun to work on a project that impacts so many developers. Thanks again!
FTD's syntax isn't nearly as nice as SwiftUI, but there's many similarities.
https://github.com/Shopify/FunctionalTableData
Purely for our own vanity - did Apple engineers take any inspiration from FTD? Or just independently set out to solve the same problems we had?
Apple is famous for making great on-stage demos that collapse once they're faced with the real-world (eg: basically anything related to having a great xcode experience)
Still learning about compose.
Who knows... With Chris Lattner at Google and Google adopting Swift for TensorFlow, I could well imagine Swift eventually working on Android (or something newer).
Edit: Also, thank you!
I thought they were crazy strict and would, like, fire people for posting on forums or Twitter
@State var model = Themes.listModel
@observable model = new MyListModel();(Semantics aside, either way this behavior is implemented in React via useState or setState, MobX has nothing to do with it)
Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire “Lambda: The Ultimate…” series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.
On his next walk with Qc Na, Anton attempted to impress his master by saying “Master, I have diligently studied the matter, and now understand that objects are truly a poor man’s closures.” Qc Na responded by hitting Anton with his stick, saying “When will you learn? Closures are a poor man’s object.” At that moment, Anton became enlightened.
setState is a totally special container for data; while it technically lives in a class member (this.state), it can only be modified via setState. It isn't observable, so much as setState just internally triggers a render directly.
useState is different because your state lives out somewhere in React's core framework, associated with your function only through a value and a callback. It doesn't live in your function's local scope itself, because it would get lost if it did. It's very weird and funky because the whole point of non-class components is for them to be pure functions which have no state. useState is this shortsighted workaround for that self-imposed limitation.
Redux, finally, is different because its new states are determined as a pure function of the current state and some change. It's the polar opposite of MobX's mutable-observables pattern. Neither is strictly better, but they're as different as can be.
That said, @State seems most identical to useState -- it provides an observed value which you use $/.binding to update.
> It's very weird and funky because the whole point of non-class components is for them to be pure functions which have no state.
That's a false assumption, that's not the "point" of functional components. Functional components were always pure simply because there was no way to make them stateful. There are distinct benefits for using stateful functional components over classes -- mainly less boilerplate and abstractable/re-usable state functions.
Practically nothing, especially since it is stored in objects and the code uses a lookup table to figure out which ones are part of your function's "this" (essentially), IIRC from reading the code. The similarity to how one implements objects/classes has been good for some laughs.
[EDIT] in "React Hooks" specifically, I mean.
This is the sort of thing that will become clearer as real developers start using it. And I'm sure Apple will learn a lot as people start building bigger apps with it.
Almost no large scale app uses storyboards for most of their ui....
So I end up doing both. The problem (and I've seen this for many years with other similar systems), is that you have to become relatively comfortable with both approaches, so you can make informed decisions about when to flip back and forth. When can I do this with IB even though it's a teensy hacky vs when should I just subclass UIView and take over layoutSubviews and friends?
That's been my experience at least. YMMV.
In the keynote it was mentioned that SwiftUI would work across all Apple products.
Will it work on previous versions or only the latest iOS/macOS/etc?
If you’re at WWDC stop by the labs and say hi!