4 ms·

The key point is this: > significantly more potential for performance improvements in the frameworks "Hand-crafted" imperative code will always have more pote

The key point is this: > significantly more potential for performance improvements in the frameworks "Hand-crafted" imperative code will always have more potential, but most code is not this sort of code, and most engineers probably don't have the skillset to be able to do this, at least not when traded-off with implementing features and shipping customer value (no criticism, this is likely the right trade-off). Declarative code shifts that control to the platform owner where they can improve things for everyone. Apple has a significant vested interest in this, I'd say more so than React, as people blame their iPhone for being slow, or their browser, but not React or SwiftUI. I'd also suggest that most declarative UI frameworks I'm familiar with have been in higher level languages such as JS, HTML, or QML, or things that run in a browser environment. I'm not sure we've seen something that's in a relatively performant, compiled language, for an environment that assumes reasonable graphics performance. Apple are explicitly targeting 60fps here, it's clear performance is a first class concern, rather than just an afterthought, and this is the most convincing case for a declarative UI framework achieving it that I've seen.

jerf 4y ago
I would separate your post into two things: One is the idea that declarative interfaces can be faster, and the other is that Apple is dedicated to fast interfaces. The former, as you are seeing from several other posters, is not a new thing, and is in my opinion a history of continual and significant failure. It is so consistent that I now have an almost visceral revulsion to people singing me the song about how wonderful "declarative" can be, which is sort of ironic because they intend the opposite. Calling something "declarative" is one of the strongest signals that a technology is going to be a pain in the ass to use. (In fact I'm sitting here racking my brains for a stronger one and I'm not sure I can come up with one. "Enterprise-ready" perhaps? Maybe "Hosted by the Apache project", which often indicates a quality project but one that is definitely going to be a real pain.) The real reason this will go fast is that Apple is prioritizing speed. I also was concerned about your comment above "developers mostly express the "how" – put this control at these coordinates etc." So far as I know, that is a strawman; no modern UI toolkit works that way. The web has had a major influence on them and every major toolkit has a more web-like layout available (and I am collapsing history here for simplicity, I am aware that relative layouts were available before the web, but the web definitely made them all step it up another notch, further consolidated by interface diversity between touch & mouse & screen sizes). If anyone using a major modern toolkit is dropping text at a particular coordinate, that's on them using the toolkit incorrectly, the toolkit has long since stopped forcing that. What the toolkit needs in order to do what you're talking about is basically the DOM for the thing it is displaying right now (for whatever the toolkit calls that concept). It is not particularly a problem for the toolkit if that DOM is built by imperative code or by some 'declaration'. It probably will end up supporting both anyhow, because how the DOM tree gets built isn't the important part. Basically identically to how a browser functions, it doesn't matter to the browser (as a UI renderer) whether the DOM it is working with was built "imperatively" or "declaratively" or "reactively" or "purely functionally" or anything else; the DOM has what the browser UI needs to render quickly, and to the extent it has troubles rendering quickly, the solution is more information in the DOM for the browser to chew on and use in its decisions, not a rewrite in how the DOM is generated. Declarativeness is entirely irrelevant here, in some sense because regardless of how you get there, the DOM-equivalent is already by its nature guaranteed to be "declarative".
smaudet 4y ago
Eh, I don't think it has to do with being "hand crafted". I think the notion of declarative is some flawed bunk - to tell the framework "what" to do you need to specify "how" - removing the how and pretending you will magically infer the intention is a recipe for disaster. "and most engineers probably don't have the skillset to be able to do this" The irony being declarative languages require a higher bar of skills to use well, without the UI falling over. "implementing features and shipping customer value" Again, you can build bad code fast, but eventually more garbage is just more garbage, you have to go back and "fix" it or the value proposition shrinks faster than value added by new features.
- tracker1 4y ago
  If I want an input box to flow to fill the width from its starting point to the right side of the window/display minus a margin... what's so bad about the UI tooling handling this? I mean, I've worked with tools where it's a lot of work to maintain that simple thing, that you wind up doing over, and over again... What value does it really add in spending even a half hour (often more) just handling layout reflows... we're talking about computers in your hand that are more powerful than super computers a couple decades ago, and faster than desktops even a decade ago. It isn't a new problem, HTML solved it relatively well several decades ago now... not that HTML has been the pinnacle of performance, it's been pretty damned effective at delivering a layout/form that can scale to the user without excessive effort.
  - smaudet 4y ago
    That's not what declarative is, though, "imperative" or OO frameworks have layout managers (too). There is some confusion, i.e. a spectrum (declarative first or imperative first, somewhere in the middle), about what is meant by declarative e.g. this article mentions android as "imperative" https://medium.com/everything-full-stack/declarative-ui-what-how-and-why-13e092a7516f https://medium.com/everything-full-stack/declarative-ui-what... While this one claims android is by default declarative. http://www.cberr.us/tech_writings/essays/declarative_vs_programmatic_ui.html http://www.cberr.us/tech_writings/essays/declarative_vs_prog... Having a DOM or element tree with layout applied doesn't make you declarative, this is more what is meant by declarative: https://en.wikipedia.org/wiki/QML https://en.wikipedia.org/wiki/QML or https://www.solidjs.com/examples/counter https://www.solidjs.com/examples/counter I.e. "low code" coding with little actual behavior specified.
robenkleene 4y ago
> "Hand-crafted" imperative code will always have more potential, but most code is not this sort of code, and most engineers probably don't have the skillset to be able to do this, at least not when traded-off with implementing features and shipping customer value (no criticism, this is likely the right trade-off). This trade-off sounds like declarative frameworks make it easier for bad developers to make mediocre software while making it impossible for great developers to make great software?
- tracker1 4y ago
  Depends on the definition of "great" ... if you're a company building a one-off app that only a couple people are ever going to use, do you want efficient, and lower cost to build/deploy getting the job done, or do you want "great"? And would you be willing to pay out of your own pocket for others to do that work? I'm all for software quality and craftsmanship. I think far too often, far too many corners are cut, and there are often huge projects which have been poorly written. That said, it really depends. Most people only use a handful of one-off apps. But most apps are one-offs. The developer time is far more costly than the resources to run the app, or the time of the people using the app, generally speaking. Saving 0.01 seconds may make things seem smoother, but it's not really going to make the person using the app more effective.
  - robenkleene 4y ago
    I'm not saying every piece of software needs to be great, just that not having the tools to be able to aloe great software at all is a problem (and I'd argue that's the direction Apple is headed in today, i.e., I don't think Apple's tech is a good choice to build another Sketch https://en.m.wikipedia.org/wiki/Sketch_(software) https://en.m.wikipedia.org/wiki/Sketch_(software) today).
- danpalmer 4y ago
  In my experience SwiftUI gets the right balance here. For a few hero screens we were able to implement what we wanted, with the performance we wanted, in non-idiomatic but not-bad ways. For almost the entirety of the rest of the app SwiftUI pretty much did the right thing without much work and gave us a performant app essentially for free. In our previous UIKit app so many screens had edge cases where the engineers implementing it hadn't had time to optimise for particular ways of using it, and the whole thing felt a bit janky to use. Not criticising the work they did, but the tradeoffs were such that we didn't have time to polish that much. Declarative frameworks can either make it easier for bad developers to make mediocre software while limiting great developers, or, with the right tradeoffs that I believe SwiftUI does well, they can allow bad (or time-constrained) developers to make pretty good software, while leaving the door open for great deveolopers (or more highly resourced teams) to make great software.

jerf 4y ago

I would separate your post into two things: One is the idea that declarative interfaces can be faster, and the other is that Apple is dedicated to fast interfaces. The former, as you are seeing from several other posters, is not a new thing, and is in my opinion a history of continual and significant failure. It is so consistent that I now have an almost visceral revulsion to people singing me the song about how wonderful "declarative" can be, which is sort of ironic because they intend the opposite. Calling something "declarative" is one of the strongest signals that a technology is going to be a pain in the ass to use. (In fact I'm sitting here racking my brains for a stronger one and I'm not sure I can come up with one. "Enterprise-ready" perhaps? Maybe "Hosted by the Apache project", which often indicates a quality project but one that is definitely going to be a real pain.) The real reason this will go fast is that Apple is prioritizing speed. I also was concerned about your comment above "developers mostly express the "how" – put this control at these coordinates etc." So far as I know, that is a strawman; no modern UI toolkit works that way. The web has had a major influence on them and every major toolkit has a more web-like layout available (and I am collapsing history here for simplicity, I am aware that relative layouts were available before the web, but the web definitely made them all step it up another notch, further consolidated by interface diversity between touch & mouse & screen sizes). If anyone using a major modern toolkit is dropping text at a particular coordinate, that's on them using the toolkit incorrectly, the toolkit has long since stopped forcing that. What the toolkit needs in order to do what you're talking about is basically the DOM for the thing it is displaying right now (for whatever the toolkit calls that concept). It is not particularly a problem for the toolkit if that DOM is built by imperative code or by some 'declaration'. It probably will end up supporting both anyhow, because how the DOM tree gets built isn't the important part. Basically identically to how a browser functions, it doesn't matter to the browser (as a UI renderer) whether the DOM it is working with was built "imperatively" or "declaratively" or "reactively" or "purely functionally" or anything else; the DOM has what the browser UI needs to render quickly, and to the extent it has troubles rendering quickly, the solution is more information in the DOM for the browser to chew on and use in its decisions, not a rewrite in how the DOM is generated. Declarativeness is entirely irrelevant here, in some sense because regardless of how you get there, the DOM-equivalent is already by its nature guaranteed to be "declarative".

smaudet 4y ago

Eh, I don't think it has to do with being "hand crafted". I think the notion of declarative is some flawed bunk - to tell the framework "what" to do you need to specify "how" - removing the how and pretending you will magically infer the intention is a recipe for disaster. "and most engineers probably don't have the skillset to be able to do this" The irony being declarative languages require a higher bar of skills to use well, without the UI falling over. "implementing features and shipping customer value" Again, you can build bad code fast, but eventually more garbage is just more garbage, you have to go back and "fix" it or the value proposition shrinks faster than value added by new features.

tracker1 4y ago
If I want an input box to flow to fill the width from its starting point to the right side of the window/display minus a margin... what's so bad about the UI tooling handling this? I mean, I've worked with tools where it's a lot of work to maintain that simple thing, that you wind up doing over, and over again... What value does it really add in spending even a half hour (often more) just handling layout reflows... we're talking about computers in your hand that are more powerful than super computers a couple decades ago, and faster than desktops even a decade ago. It isn't a new problem, HTML solved it relatively well several decades ago now... not that HTML has been the pinnacle of performance, it's been pretty damned effective at delivering a layout/form that can scale to the user without excessive effort.
- smaudet 4y ago
  That's not what declarative is, though, "imperative" or OO frameworks have layout managers (too). There is some confusion, i.e. a spectrum (declarative first or imperative first, somewhere in the middle), about what is meant by declarative e.g. this article mentions android as "imperative" https://medium.com/everything-full-stack/declarative-ui-what-how-and-why-13e092a7516f https://medium.com/everything-full-stack/declarative-ui-what... While this one claims android is by default declarative. http://www.cberr.us/tech_writings/essays/declarative_vs_programmatic_ui.html http://www.cberr.us/tech_writings/essays/declarative_vs_prog... Having a DOM or element tree with layout applied doesn't make you declarative, this is more what is meant by declarative: https://en.wikipedia.org/wiki/QML https://en.wikipedia.org/wiki/QML or https://www.solidjs.com/examples/counter https://www.solidjs.com/examples/counter I.e. "low code" coding with little actual behavior specified.

robenkleene 4y ago

> "Hand-crafted" imperative code will always have more potential, but most code is not this sort of code, and most engineers probably don't have the skillset to be able to do this, at least not when traded-off with implementing features and shipping customer value (no criticism, this is likely the right trade-off). This trade-off sounds like declarative frameworks make it easier for bad developers to make mediocre software while making it impossible for great developers to make great software?

tracker1 4y ago
Depends on the definition of "great" ... if you're a company building a one-off app that only a couple people are ever going to use, do you want efficient, and lower cost to build/deploy getting the job done, or do you want "great"? And would you be willing to pay out of your own pocket for others to do that work? I'm all for software quality and craftsmanship. I think far too often, far too many corners are cut, and there are often huge projects which have been poorly written. That said, it really depends. Most people only use a handful of one-off apps. But most apps are one-offs. The developer time is far more costly than the resources to run the app, or the time of the people using the app, generally speaking. Saving 0.01 seconds may make things seem smoother, but it's not really going to make the person using the app more effective.
- robenkleene 4y ago
  I'm not saying every piece of software needs to be great, just that not having the tools to be able to aloe great software at all is a problem (and I'd argue that's the direction Apple is headed in today, i.e., I don't think Apple's tech is a good choice to build another Sketch https://en.m.wikipedia.org/wiki/Sketch_(software) https://en.m.wikipedia.org/wiki/Sketch_(software) today).
danpalmer 4y ago
In my experience SwiftUI gets the right balance here. For a few hero screens we were able to implement what we wanted, with the performance we wanted, in non-idiomatic but not-bad ways. For almost the entirety of the rest of the app SwiftUI pretty much did the right thing without much work and gave us a performant app essentially for free. In our previous UIKit app so many screens had edge cases where the engineers implementing it hadn't had time to optimise for particular ways of using it, and the whole thing felt a bit janky to use. Not criticising the work they did, but the tradeoffs were such that we didn't have time to polish that much. Declarative frameworks can either make it easier for bad developers to make mediocre software while limiting great developers, or, with the right tradeoffs that I believe SwiftUI does well, they can allow bad (or time-constrained) developers to make pretty good software, while leaving the door open for great deveolopers (or more highly resourced teams) to make great software.