5 ms·

Curious how you address the counter argument: That in practice declarative UI has historically been slower than coordinate-based systems? E.g., we're talking he

Curious how you address the counter argument: That in practice declarative UI has historically been slower than coordinate-based systems? E.g., we're talking here about SwiftUI vs. AppKit, but there's the long history of slow interfaces with HTML/CSS. Based on the historical evidence I'm familiar with "declarative UI = slow" is just something I assume to be true now. For that to change, declarative UI frameworks have to stop talking about how they could be fast, and start actually being fast. (I'm also just very sensitive to latency, and I've watched new declarative UI frameworks rise in popularity, while at the same time the latency in the software I use increases, so in my head they're linked.)

mariusmg 4y ago
The theoretical performance improvments of declarative UIs are just.....theoretical.
- stephc_int13 4y ago
  Same observation here. I remember a time, not so long ago, when serious people were advocating JITed languages (Java, C#) for performance workload because the JIT was theoretically able to produce better code for the platform given it had full knowledge of the architecture and execution context.
  - smaudet 4y ago
    For (long running) data stream workloads, JIT does have an auto-profiler benefit. It doesn't preclude writing code well.
    - P5fRxh5kUvp2th 4y ago
      For long running workloads with consistent usage patterns it has a benefit. It is not merely enough to be long running, that is a requirement, but not enough by itself.
    - int_19h 4y ago
      Are there any studies measuring it on real-world workloads?
danpalmer 4y ago
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".
hajile 4y ago
It's all about the baseline. Baseline declarative has "good enough" performance while the same money/time investment into imperative UI will get you worse performance. It's only when you've poured in a lot more resources into the imperative version that you start to see it overtake the declarative version. This problem is illustrated well by InfernoJS. When the JS framework benchmark was first released, the vanilla (imperative) version blew away all the frameworks on the list. InfernoJS came along and beat the vanilla performance, so they updated the vanillaJS version. They went back and forth a few times with InfernoJS constantly upping the game and them looking at what Inferno was doing to get ideas into improving their performance further. Today, the vanilla version is faster, but only by a little and only after a bunch of rewrites. Meanwhile, the InfernoJS declarative code didn't change a huge amount. The underlying framework did most of the updating. This means that Inferno would be fast on a second project while vanilla would once again start off slow and have to find ways to optimize their specific app all over again. Only the most demanding companies and legacy apps will continue with anything other than SwiftUI once it has improved a bit. Saving all those dev man-years while giving up just a little bit just isn't a tradeoff that most companies (even big ones) are willing to make.
- robenkleene 4y ago
  I'm not familiar with Inferno JS, but it appears to be based on the DOM, which is fundamentally declarative (i.e., flow-based layout rather than coordinate-based layout)? I.e., correct me if I'm wrong, but that doesn't sound like a pure enough way to compare declarative vs. imperative if it's built on a declarative foundation?
  - hajile 4y ago
    Yes and no. The DOM is declarative internally, but the fastest way to use it is imperative where you manually create nodes one at a time, update properties on those nodes individually, and string them together one command at a time. The effect for the programmer isn’t so different from a series of draw calls except that it’s more sensitive to individual updates tanking performance which requires even more consideration from the imperative programmer. To me, the best comparison is between an AOT language with manual memory (eg, C) vs a JITed language with garbage collection (eg, Java). In theory, the JIT can provide equivalent or even faster code, but that’s not generally the case in practice. The GC isn’t generally faster, but it is safer and easier. Some companies need their software written in C, but Java is good enough for most given the productivity gains. In theory, runtime inference could dynamically improve performance of declarative systems beyond what AOT imperative code can do, but in practice, companies don’t invest the resources to make this happen. At the same time, not having to manually manage the output to ensure garbage doesn’t creep in accidentally greatly improves developer productivity.
valcron1000 4y ago
Elm is really fast when it comes to rendering web interfaces
zarzavat 4y ago
Building UIs with coordinates is hard and effortful. Because of this, you have no time to make it slow. Building the same UI declaratively is much easier. And a simple UI is fast. But because it was so easy to make it, now you have extra development time to make it slower (by adding extra features).

mariusmg 4y ago

The theoretical performance improvments of declarative UIs are just.....theoretical.

stephc_int13 4y ago
Same observation here. I remember a time, not so long ago, when serious people were advocating JITed languages (Java, C#) for performance workload because the JIT was theoretically able to produce better code for the platform given it had full knowledge of the architecture and execution context.
- smaudet 4y ago
  For (long running) data stream workloads, JIT does have an auto-profiler benefit. It doesn't preclude writing code well.
  - P5fRxh5kUvp2th 4y ago
    For long running workloads with consistent usage patterns it has a benefit. It is not merely enough to be long running, that is a requirement, but not enough by itself.
  - int_19h 4y ago
    Are there any studies measuring it on real-world workloads?

danpalmer 4y ago

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

hajile 4y ago

It's all about the baseline. Baseline declarative has "good enough" performance while the same money/time investment into imperative UI will get you worse performance. It's only when you've poured in a lot more resources into the imperative version that you start to see it overtake the declarative version. This problem is illustrated well by InfernoJS. When the JS framework benchmark was first released, the vanilla (imperative) version blew away all the frameworks on the list. InfernoJS came along and beat the vanilla performance, so they updated the vanillaJS version. They went back and forth a few times with InfernoJS constantly upping the game and them looking at what Inferno was doing to get ideas into improving their performance further. Today, the vanilla version is faster, but only by a little and only after a bunch of rewrites. Meanwhile, the InfernoJS declarative code didn't change a huge amount. The underlying framework did most of the updating. This means that Inferno would be fast on a second project while vanilla would once again start off slow and have to find ways to optimize their specific app all over again. Only the most demanding companies and legacy apps will continue with anything other than SwiftUI once it has improved a bit. Saving all those dev man-years while giving up just a little bit just isn't a tradeoff that most companies (even big ones) are willing to make.

robenkleene 4y ago
I'm not familiar with Inferno JS, but it appears to be based on the DOM, which is fundamentally declarative (i.e., flow-based layout rather than coordinate-based layout)? I.e., correct me if I'm wrong, but that doesn't sound like a pure enough way to compare declarative vs. imperative if it's built on a declarative foundation?
- hajile 4y ago
  Yes and no. The DOM is declarative internally, but the fastest way to use it is imperative where you manually create nodes one at a time, update properties on those nodes individually, and string them together one command at a time. The effect for the programmer isn’t so different from a series of draw calls except that it’s more sensitive to individual updates tanking performance which requires even more consideration from the imperative programmer. To me, the best comparison is between an AOT language with manual memory (eg, C) vs a JITed language with garbage collection (eg, Java). In theory, the JIT can provide equivalent or even faster code, but that’s not generally the case in practice. The GC isn’t generally faster, but it is safer and easier. Some companies need their software written in C, but Java is good enough for most given the productivity gains. In theory, runtime inference could dynamically improve performance of declarative systems beyond what AOT imperative code can do, but in practice, companies don’t invest the resources to make this happen. At the same time, not having to manually manage the output to ensure garbage doesn’t creep in accidentally greatly improves developer productivity.

valcron1000 4y ago

Elm is really fast when it comes to rendering web interfaces

zarzavat 4y ago

Building UIs with coordinates is hard and effortful. Because of this, you have no time to make it slow. Building the same UI declaratively is much easier. And a simple UI is fast. But because it was so easy to make it, now you have extra development time to make it slower (by adding extra features).