4 ms·

> It's because the user experience on them is terrible compared to native … because there’s perverse incentives to keep it that way

threeseed 4y ago
No it's because the web was designed for web pages. It was not designed for highly dynamic, fluid, responsive experiences.
- h0l0cube 4y ago
  Lots of platforms have exceeded their original use cases. It’s like saying *nix wasn’t designed to host desktop GUIs, so we should make a whole new operating system to afford that purpose.
  - timeon 4y ago
    That is just analogy not argument.
    - h0l0cube 4y ago
      Okay then. Can you make an argument as to why a browser can't provide a native-like experience? (Aside from perverse motivations.)
      - etchalon 4y ago
        Ignoring that HTML, CSS and JS have specific performance tradeoffs that allow for flexibility and universality, I'd go with "because I can't name any cross-platform tooling that has ever felt as good as a platform-native alternative".
        h0l0cube 4y ago
        Certainly that’s a fallacious argument of a different kind. > specific performance tradeoffs But you don’t specify. Android is built upon the JVM which is affected by GC pauses much the same as JavaScript, but the performance issues are solvable in the browser as much as they have been in the ‘native’ Android domain
        etchalon 4y ago
        I don't see how it's fallacious, and I specifically set aside the performance tradeoffs as I knew the retort would end up being almost exactly what you posted. I'm also not sure why I'd have to list the tradeoffs on a forum of developers. They're self-evident. HTML and the DOM are always going to be a less efficient representation of an interface than a component tree. CSS is always going to be a less efficient manor of appearance specification than direct properties on a component object. JavaScript is always going to be less efficient than something compiled down to machine language. Each adds several layers of abstraction, processing and adaptions that add overhead. That's their whole point. It's not exactly something you can "debate".
        h0l0cube 4y ago
        Okay, I might be making an appeal to authority here, but I've been a mobile developer for 10 years, a web developer for 2-3 years, and I've done perf with C++/Asm for years of my career, so know that I'm not coming from a place of naivete on either performance or mobile/web development. > HTML and the DOM are always going to be a less efficient representation of an interface than a component tree Is the DOM – from which is derived from HTML – not also a component tree? Is it a graph or some other topology I'm not aware of? When you specify a design in Interface Builder, Android xml, or even the DOM-differ-like SwiftUI + Jetpack Compose how is the topology different? Check a DOM object, it's a node with children. > CSS is always going to be a less efficient manor of appearance specification than direct properties on a component object. Property inheritance is definitely a thing on both Android and iOS. I'm sure you could confect especially non-performant CSS, but at large it isn't taking up great deal of compute. I've definitely seen weird constraint issues on Interface Builder cause glitches and pauses (and even crashes) on iOS. > JavaScript is always going to be less efficient than something compiled down to machine language Javascript can be compiled down to machine language, using the JIT. Similarly Android is compiled down to Dalvik/Java-like byte code and run on a JIT. Is Android not native? Or is it some No True Scotsman kind of thing?

threeseed 4y ago

No it's because the web was designed for web pages. It was not designed for highly dynamic, fluid, responsive experiences.

h0l0cube 4y ago
Lots of platforms have exceeded their original use cases. It’s like saying *nix wasn’t designed to host desktop GUIs, so we should make a whole new operating system to afford that purpose.
- timeon 4y ago
  That is just analogy not argument.
  - h0l0cube 4y ago
    Okay then. Can you make an argument as to why a browser can't provide a native-like experience? (Aside from perverse motivations.)
    - etchalon 4y ago
      Ignoring that HTML, CSS and JS have specific performance tradeoffs that allow for flexibility and universality, I'd go with "because I can't name any cross-platform tooling that has ever felt as good as a platform-native alternative".
      - h0l0cube 4y ago
        Certainly that’s a fallacious argument of a different kind. > specific performance tradeoffs But you don’t specify. Android is built upon the JVM which is affected by GC pauses much the same as JavaScript, but the performance issues are solvable in the browser as much as they have been in the ‘native’ Android domain
        etchalon 4y ago
        I don't see how it's fallacious, and I specifically set aside the performance tradeoffs as I knew the retort would end up being almost exactly what you posted. I'm also not sure why I'd have to list the tradeoffs on a forum of developers. They're self-evident. HTML and the DOM are always going to be a less efficient representation of an interface than a component tree. CSS is always going to be a less efficient manor of appearance specification than direct properties on a component object. JavaScript is always going to be less efficient than something compiled down to machine language. Each adds several layers of abstraction, processing and adaptions that add overhead. That's their whole point. It's not exactly something you can "debate".
        h0l0cube 4y ago
        Okay, I might be making an appeal to authority here, but I've been a mobile developer for 10 years, a web developer for 2-3 years, and I've done perf with C++/Asm for years of my career, so know that I'm not coming from a place of naivete on either performance or mobile/web development. > HTML and the DOM are always going to be a less efficient representation of an interface than a component tree Is the DOM – from which is derived from HTML – not also a component tree? Is it a graph or some other topology I'm not aware of? When you specify a design in Interface Builder, Android xml, or even the DOM-differ-like SwiftUI + Jetpack Compose how is the topology different? Check a DOM object, it's a node with children. > CSS is always going to be a less efficient manor of appearance specification than direct properties on a component object. Property inheritance is definitely a thing on both Android and iOS. I'm sure you could confect especially non-performant CSS, but at large it isn't taking up great deal of compute. I've definitely seen weird constraint issues on Interface Builder cause glitches and pauses (and even crashes) on iOS. > JavaScript is always going to be less efficient than something compiled down to machine language Javascript can be compiled down to machine language, using the JIT. Similarly Android is compiled down to Dalvik/Java-like byte code and run on a JIT. Is Android not native? Or is it some No True Scotsman kind of thing?