3 ms·
Other commenters have pointed to SwiftUI being declarative as a big part of this problem, but I take a more nuanced view: the problem is actually that SwiftUI i
by georgelyon 4y ago
Other commenters have pointed to SwiftUI being declarative as a big part of this problem, but I take a more nuanced view: the problem is actually that SwiftUI is a complexity-hiding abstraction. Specifically it hides the complexity of when UI is refreshed and how it is refreshed.
This results in a situation where engineers who don’t have a clear understanding of how it works resorting to essentially guesswork to try and fix performance issues. Now, there are certainly folks who do have a deep understanding of how SwiftUI works but that group is likely small and the situation isn’t helped by middling documentation and SwiftUI being closed source.
An analogue to this can be seen in something like SQL, which is a (somewhat) declarative specification for queries that is also complexity-hiding. SQL, wielded by a novice, can be pretty slow (just one ill-advised join would likely do it), but would still “work”. The difference with SQL is that there is a plethora of literature about how to write it in a way that results in fast queries and many of the consumers of SQL are open source so enterprising engineers can dig down and figure out what a particular query is doing and why something is slow. We’ve also invested a ton of resources in creating engineers who can write good SQL.
I’m interested to see how SwiftUI progresses in these regards.
Unrelated addendum: The author should look at the drawingGroup API. This could significantly speed up the drawing of the month grids on refresh by caching the resulting rasterized view instead of repeatedly redrawing it.
- terhechte 4y agoI really like the SQL comparison. I'll remember that the next time I have to explain a non-iOS developer why a given piece of SwiftUI code is flaky or slow.
- alin23 4y agodrawingGroup is exactly what I was looking for, thanks a lot! I didn’t know this was added to SwiftUI.
- georgelyon 4y agoI’m happy this worked for you. This in itself is an interesting anecdote about documentation quality. I knew this API existed but forgot the exact API and searches for “caching SwiftUI rasterized view” and similar queries did not return this API (which, for the record, isn’t exactly what it does…) . I eventually found it in a roundabout way but had I not been pretty sure it existed, I would probably have given up.
- andrekandre 4y ago> This in itself is an interesting anecdote about documentation quality. apple used to make these great deep-dive pdfs for new frameworks like core data, quartz (core graphics), even obj-c itself that explained many nuances and caveats of each subsystem/framework... imho i think swiftui could use a good doc like that
- pixelrevision 4y ago“Programming guides”! Those were so awesome because they explained the whole system. The core graphics one was an absolute lifesaver when I started working with iOS. Apples UI a frameworks seemed way more complex than anything I’d ever worked with before but once I understood the layers they started to click. I don’t know what I would have done with a bunch of class guides with patchy comments.
- andrekandre 4y agosame here, i would have been totally lost without them as well... read them end-to-end when i started out and never regretted it
- migueldeicaza 4y agoThe SQL comparison is a great illustration
- madeofpalk 4y agoI think Swift UI's more concrete problem is that it just doesn't have a sufficiently mature enough API with the right mix of low level primitives and higher abstractions. Say whatever you want about modern web development, but I think React/JSX + HTML/CSS has proven you can use a declarative model to build complex user interfaces.
- georgelyon 4y agoThis could be taken to support my point. There is a MASSIVE amount of literature on the internet about how to do this, and it's reasonably straightforward to see what is happening with the DOM when you use these frameworks. Likewise, a novice developer can create something that causes scrolling to stutter or other performance problems pretty easily in this world. Take on the other hand, some of SwiftUI's more advanced features, like PreferenceKey which are extremely under-documented (the generic sounding name doesn't help either). Of course folks are going to struggle to do more complex things. I wonder how much the situation would be helped if the thing you searched for help allowed in-line SwiftUI examples, like you can do on the web. Playgrounds is kind of that thing but you aren't searching a repository of playgrounds for documentation.
- quxbar 4y agoI think the web developer's toolkit has benefitted from competition - every browser prioritizes supporting dev tools because that's the only way to get more sites to support your particular quirks. people building web frameworks competed for developers ruthlessly, because starting to learn a new framework is only a few search queries away, and a great deal of effort has been made to improve the overall developer experience.
- chunkyguy 4y agoThis is what I really like about Flutter. It's well designed with different layers of complexity and convenience tradeoffs. And yes, also open source. Watch this talk from one of the core developers about the design https://www.youtube.com/watch?v=dkyY9WCGMi0 https://www.youtube.com/watch?v=dkyY9WCGMi0
- silvestrov 4y agoMost databases have an "EXPLAIN PLAN" so you can see which (if any) indexes the database use and how tables are joined. So this is much better than Swift.
- mariodiana 4y agoI feel like it is a mistake to bring what is effectively React to native development. Browser-based web apps are basically punching above their weight class. Compared to the power of native UI's, the browser is broken. React understood this and created two innovations: 1. The Virtual DOM 2. The reactive UI Now, I'm no expert, but Number 1 seems like a terrific idea; and Number 2 seems like it's needed in order to implement Number 1. But, to my thinking, a reactive UI is a big problem of leaky abstractions, which is what I think you're saying. To me, iOS/macOS UI development needed neither the baby nor the dirty bathwater. I feel like the whole thing is a mistake. As a programmer, I want control over updating the UI.
- com2kid 4y agoReact is terrible at reactive[1] UIs. You have to do a lot of work to tell react what to not rerender. Of course things generally work if programmers aren't careful, but the UI gets slower and slower over time as more features are added and more repaints are done. VDom is one of those arguable things, plenty of frameworks are faster than React w/o a vdom, and some frameworks are faster than React and also use a VDom. [1] Arguably react is not even that reactive, you have to manually wire up everything yourself.
- MH15 4y agoYou have this backwards no? The virtual DOM is needed in order to support Reactive UI, in most cases (svelte comes to mind as an exception).
- mariodiana 4y agoI think you're right, now that I think about it again.
- georgelyon 4y agoFor the record, you do have fairly fine grained control over what updates when with SwiftUI. The issue is that this isn’t obvious to new developers, nor is it easy to understand what tools to use to fix issues once you understand what is happening.