4 ms·

How can this possibly be true? Web UI frameworks are built on top of the browser platform, and browsers are built on top of native desktop platforms, so aren't

How can this possibly be true? Web UI frameworks are built on top of the browser platform, and browsers are built on top of native desktop platforms, so aren't native desktop platforms inherently more flexible than web UI frameworks?

redxdev 6y ago
Browsers largely aren't taking advantage of native UI frameworks (aside maybe from the window chrome and basic controls). Aside from the minimum required to get an OpenGL context (or whatever graphics tech) onto the screen they don't need to build on native UI. Sure, they're technically building on top of the native UI frameworks, but only by completely ignoring all of their functionality.
fauigerzigerk 6y ago
I am by no means an expert in graphics architectures so I'm sure someone will be able to explain this better and more correctly than I can. But as I understand it, "native" is itself a layered stack of APIs as you can see in this diagram: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CoreAnimation_guide/Introduction/Introduction.html https://developer.apple.com/library/archive/documentation/Co... UIKit/AppKit is layered on top of Core Animation which is layered on top of Metal. Skia, the 2D graphics library that Chrome's rendering engine uses, is built on top of Metal (or at least transitioning to Metal from OpenGL on macOS). So browsers have the same flexibility in principle as native UI toolkits and they are just as close to the metal. There is no inherent disadvantage. But flexibility is a double edged sword. It includes the ability to diverge from the platform look & feel. So that's where the debate has been raging on for decades. In terms of performance I think any debate about optimisation of UI stacks pales in comparison to the question of where the data lives, who generates it, and how it gets to the CPU/GPU for processing and display.
- saagarjha 6y ago
  Saying that "both use Metal and have layers in between therefore they are largely at the same place" doesn't really work, because the abstraction layer that they expose is at a vastly different place and the internal pipeline for both is also very different.
zepto 6y ago
You are completely correct. If people want to use web technologies on the desktop, there is Electron. The converse is not true.
- johannes1234321 6y ago
  The converse is webassembly+webgl. There are different cases where i.e. SDL-based games are being ported to "Web" also Qt provides WebAssmebly support.
- noahtallen 6y ago
  Right, but only for macOS. I imagine most Swift/SwiftUI development targets iOS, where web is really the only other target available.
  - zepto 6y ago
    There’s nothing stopping you from using web technologies to develop iOS apps in exactly the same way. Quite a few of the ‘cross platform’ toolkits work this way.
pier25 6y ago
Can you run SwiftUI on Windows or Android?

redxdev 6y ago

Browsers largely aren't taking advantage of native UI frameworks (aside maybe from the window chrome and basic controls). Aside from the minimum required to get an OpenGL context (or whatever graphics tech) onto the screen they don't need to build on native UI. Sure, they're technically building on top of the native UI frameworks, but only by completely ignoring all of their functionality.

fauigerzigerk 6y ago

I am by no means an expert in graphics architectures so I'm sure someone will be able to explain this better and more correctly than I can. But as I understand it, "native" is itself a layered stack of APIs as you can see in this diagram: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CoreAnimation_guide/Introduction/Introduction.html https://developer.apple.com/library/archive/documentation/Co... UIKit/AppKit is layered on top of Core Animation which is layered on top of Metal. Skia, the 2D graphics library that Chrome's rendering engine uses, is built on top of Metal (or at least transitioning to Metal from OpenGL on macOS). So browsers have the same flexibility in principle as native UI toolkits and they are just as close to the metal. There is no inherent disadvantage. But flexibility is a double edged sword. It includes the ability to diverge from the platform look & feel. So that's where the debate has been raging on for decades. In terms of performance I think any debate about optimisation of UI stacks pales in comparison to the question of where the data lives, who generates it, and how it gets to the CPU/GPU for processing and display.

saagarjha 6y ago
Saying that "both use Metal and have layers in between therefore they are largely at the same place" doesn't really work, because the abstraction layer that they expose is at a vastly different place and the internal pipeline for both is also very different.

zepto 6y ago

You are completely correct. If people want to use web technologies on the desktop, there is Electron. The converse is not true.

johannes1234321 6y ago
The converse is webassembly+webgl. There are different cases where i.e. SDL-based games are being ported to "Web" also Qt provides WebAssmebly support.
noahtallen 6y ago
Right, but only for macOS. I imagine most Swift/SwiftUI development targets iOS, where web is really the only other target available.
- zepto 6y ago
  There’s nothing stopping you from using web technologies to develop iOS apps in exactly the same way. Quite a few of the ‘cross platform’ toolkits work this way.

pier25 6y ago

Can you run SwiftUI on Windows or Android?