3 ms·

In a discussion about the performance tradeoffs inherent in abstractions, you seem to be implying you don't understand why a tree of say, NSViews, would be more

In a discussion about the performance tradeoffs inherent in abstractions, you seem to be implying you don't understand why a tree of say, NSViews, would be more performant than the process of parsing text markup, converting that markup into a tree which in turn may/would have a component tree attached, which may include a mixture of platform-provided components and internal components, maintaining state between the DOM's tree, the component tree and potentially platform components in a highly-dynamic environment which has to expose and allow for mutations on it's internal state to an interpreted runtime. I'd recommend reading through WebCore, from the WebKit project, as its some of the most readable CPP you'll find, and should give a sense of why that implication is naive: https://github.com/WebKit/WebKit/tree/main/Source/WebCore https://github.com/WebKit/WebKit/tree/main/Source/WebCore

h0l0cube 4y ago
Of course the best thing to do when you have an unwinnable argument is to change the argument, but I'll move with you. > converting that markup into a tree The web is indeed dynamic. It means any cache-misses for webpages will require re-parsing. Could be substantial compute depending on the size of the page, but not necessarily – the vast majority of the delay of a webpage is network. But we're talking a web app here. If it is something visited often (as one would use an app), it's a cache-hit, if it's occasional usage, it's analogous to downloading an app again, but much faster and without having to jump to the app store to do it. > which in turn may/would have a component tree attached Read my earlier comment. Component trees are not a point of difference here. > maintaining state between the DOM's tree Once again, not a point of difference. DOM manipulation is component tree manipulation, much the same as what's happening under the hood in SwiftUI and Jetpack Compose. > to an interpreted runtime Once again, if you're not using an app often, there's a cache-miss and the code will need to be re-parsed, but that's the trivial 'download cost' of the app. Once parsed it's JITable byte code much like Dalvik on Android. > I'd recommend reading through WebCore That's cute. Given this whole thread I'd wager you've never read it before, let alone grokked it any of it. You're probably capable of doing so, and you're welcome to, but I'll make no pretense of having read it or intending to. Caching and execution of dynamic JS was a difficult problem, but one that has received a lot of attention. Similarly caching of dynamic HTML and CSS. These performance problems are fortunately the purview of specialized developers building one of the 3 browser engines in popular use and complexity well abstracted from the developer. There is one main drawback, which you haven't mentioned yet, that is memory and storage. But once again, because it's cached, it's very easy to 'eject' a web app from storage (e.g. using an LRU policy). But of course the elephant in the room is that many popular 'native' apps are just Ionic/Electron ports[0], because people gave up waiting for PWAs to be supported fully by mobile OS and browser engine teams. I've used 1Password, Spotify, Slack, Signal, etc. built on HTML/CSS/JS and I don't experience jank, because the performance problems have been solved. You might retort, "But they aren't dynamically loaded", to which I'd point you to back to the concept of caching. [0] https://en.wikipedia.org/wiki/List_of_software_using_Electron https://en.wikipedia.org/wiki/List_of_software_using_Electro... And with that, I'm done here.
- etchalon 4y ago
  I didn't move the argument. The thread started with your comment: > Can you make an argument as to why a browser can't provide a native-like experience? And behold, I explained why. Every abstraction you layer onto a stack has a performance tradeoff. You essentially rebutted by saying "we can make things faster" and ... no one said we couldn't. Your second rebuttal is essentially, "Well, things are fast enough for me!" Which ... OK.
  - h0l0cube 4y ago
    > "we can make things faster" I said they are fast now for the reasons specified. > "Well, things are fast enough for me!" Which ... OK. They're 60+ fps. Fast enough for everybody.

h0l0cube 4y ago

Of course the best thing to do when you have an unwinnable argument is to change the argument, but I'll move with you. > converting that markup into a tree The web is indeed dynamic. It means any cache-misses for webpages will require re-parsing. Could be substantial compute depending on the size of the page, but not necessarily – the vast majority of the delay of a webpage is network. But we're talking a web app here. If it is something visited often (as one would use an app), it's a cache-hit, if it's occasional usage, it's analogous to downloading an app again, but much faster and without having to jump to the app store to do it. > which in turn may/would have a component tree attached Read my earlier comment. Component trees are not a point of difference here. > maintaining state between the DOM's tree Once again, not a point of difference. DOM manipulation is component tree manipulation, much the same as what's happening under the hood in SwiftUI and Jetpack Compose. > to an interpreted runtime Once again, if you're not using an app often, there's a cache-miss and the code will need to be re-parsed, but that's the trivial 'download cost' of the app. Once parsed it's JITable byte code much like Dalvik on Android. > I'd recommend reading through WebCore That's cute. Given this whole thread I'd wager you've never read it before, let alone grokked it any of it. You're probably capable of doing so, and you're welcome to, but I'll make no pretense of having read it or intending to. Caching and execution of dynamic JS was a difficult problem, but one that has received a lot of attention. Similarly caching of dynamic HTML and CSS. These performance problems are fortunately the purview of specialized developers building one of the 3 browser engines in popular use and complexity well abstracted from the developer. There is one main drawback, which you haven't mentioned yet, that is memory and storage. But once again, because it's cached, it's very easy to 'eject' a web app from storage (e.g. using an LRU policy). But of course the elephant in the room is that many popular 'native' apps are just Ionic/Electron ports[0], because people gave up waiting for PWAs to be supported fully by mobile OS and browser engine teams. I've used 1Password, Spotify, Slack, Signal, etc. built on HTML/CSS/JS and I don't experience jank, because the performance problems have been solved. You might retort, "But they aren't dynamically loaded", to which I'd point you to back to the concept of caching. [0] https://en.wikipedia.org/wiki/List_of_software_using_Electron https://en.wikipedia.org/wiki/List_of_software_using_Electro... And with that, I'm done here.

etchalon 4y ago
I didn't move the argument. The thread started with your comment: > Can you make an argument as to why a browser can't provide a native-like experience? And behold, I explained why. Every abstraction you layer onto a stack has a performance tradeoff. You essentially rebutted by saying "we can make things faster" and ... no one said we couldn't. Your second rebuttal is essentially, "Well, things are fast enough for me!" Which ... OK.
- h0l0cube 4y ago
  > "we can make things faster" I said they are fast now for the reasons specified. > "Well, things are fast enough for me!" Which ... OK. They're 60+ fps. Fast enough for everybody.