4 ms·

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 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?
- etchalon 4y ago
  I'm having a hard time squaring this statement: > 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. with this: > 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.
  - h0l0cube 4y ago
    > I'm having a hard time squaring this statement Would you like to point out where I'm mistaken? Or are you just feigning superiority? DOM objects can have exactly one parent, many children, and cannot have cycles (i.e, no parent can be itself or a child). It's very specifically a tree[0] of components. I'll take the L here if I can learn something from you. So tell me, with accuracy, how HTML/DOM is not a component tree? And then extra points as to why this different data structure is inherently less performant. [0] https://en.wikipedia.org/wiki/Tree_(data_structure) https://en.wikipedia.org/wiki/Tree_(data_structure)
    - etchalon 4y ago
      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

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?

etchalon 4y ago
I'm having a hard time squaring this statement: > 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. with this: > 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.
- h0l0cube 4y ago
  > I'm having a hard time squaring this statement Would you like to point out where I'm mistaken? Or are you just feigning superiority? DOM objects can have exactly one parent, many children, and cannot have cycles (i.e, no parent can be itself or a child). It's very specifically a tree[0] of components. I'll take the L here if I can learn something from you. So tell me, with accuracy, how HTML/DOM is not a component tree? And then extra points as to why this different data structure is inherently less performant. [0] https://en.wikipedia.org/wiki/Tree_(data_structure) https://en.wikipedia.org/wiki/Tree_(data_structure)
  - etchalon 4y ago
    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