5 ms·

This seems like a really important fundamental observation. I hope other folks with different perspectives see this and weigh in.

horsawlarway 4y ago
At the risk of being a tad snarky... What does OP think is underpinning the browser's implementation of the DOM? Or Audio, for that matter? Those low level apis exist, and they could be exposed, but there's a whole lot of reasons they aren't. To list a few... 1. The browser is handling all of the platform differences for you. The issue with low level control is... you have to understand the low level details, and those tend to be architecture & platform specific. Blink in chrome is just neatly hiding the fact that under the hood it's got considerable differences for each platform. It's having to deal with OpenGL, Vulkan, DirectX, etc. And they are ALL different. So if I use the intermediate DOM layer Chromium provides, I get immediate support for 6 platforms (Windows, Linux, Mac, ChromeOS, Fuchsia, Android) plus unofficial support on BSD (at least OpenBSD and FreeBSD). Using the low level api... I don't have time to write a website, I'm too busy trying to read graphics api docs. 2. There is huge value in having a selection of premade utilities to work with - The honest answer is that most websites are just forms. Microsoft knew that most apps are forms way before the web (WinForms). So if you really just need to have the user enter some data, and then see a new page a framework that provides you with those tools is a huge win. This is why things like QT, WinForms, and the DOM exist - they give you an easy way to quickly make forms. Of the three - the DOM is by far my preferred. It's actually an insanely capable engine for forms. 3. The last (and arguably most important) point is that the browser is enabling you to run untrusted 3rd party software. It's not giving that software low level access because it's sandboxing your system from it to give you at least a modicum of trust that you can open a webpage and not have your whole machine compromised. Low level access is powerful, flexible, and complex. I don't want a site to be able to access my microphone or files or usb devices without control over it... because I click random links on sites like HN all day long.
- cassianoleal 4y ago
  Yeah that's really it. The browser is essentially a cross-platform VM, not entirely unlike the JVM or BEAM. In the end, you get somewhat a least-common denominator since it's abstracting so much. It's both constraining (you don't get the full power of the platform(s) you're building for), and enabling (you get to build once, run everywhere).
- flohofwoe 4y ago
  > 1. The browser is handling all of the platform differences for you. ...these "low level browser APIs" would still be regular Javascript web APIs which hide the differences between operating systems (that's the whole point of the browser after all!). E.g. WebGPU can still be considered a low-level API (when compared to other web APIs, but of course slightly higher level when compared to native APIs it sits on: D3D, Vk and Metal). Such wrapper APIs are not exactly rocket science, they can be both efficient and safe, yet still abstract over platform differences. > 2. ...most websites are just forms ...this is a fundamental difference in opinion I guess. I see the web mainly as an open app distribution platform, not as a library for documents. > 3. ...about trust... See point 1 about WebGPU. Safety aspects aside, you can look at game engines on how to build cross-platform APIs without giving up performance. In the end, most operating systems offer the same services in slightly different flavours, and it's possible to wrap those OS services in cross-platform APIs without too many compromises (after all, Windows, Linux, macOS, iOS and Android are all sitting on top of the same hardware anyway)
  - deleted 4y ago
    [deleted]
  - horsawlarway 4y ago
    > Such wrapper APIs are not exactly rocket science, they can be both efficient and safe, yet still abstract over platform differences. I would suggest this is not nearly as easy as you claim. Game engines are actually fine example of exactly what I'm talking about - Unreal might have an abstraction that wraps over system differences, but to access low level apis devs bail on it. Take a recent game: Atomic Heart. Built with Unreal Engine 4, which claims to support: Windows, macOS, and Linux PCs; PlayStation 4, PlayStation 5, Xbox One, Xbox Series X, and Nintendo Switch; and iOS and Android mobile devices. Platforms that they actually released on? Xbox Series X|S, Xbox One, Windows 10/11, PS4/5. Why? Because the abstraction turned out to not abstract so well, and they didn't bother to do the platform work required for the others. Does it run on Linux? Sort of... it runs on linux presenting the same abi as Windows through proton/wine. And even then, they have a ton of reported issues with performance (stuttering, frame drops, screens failing to load, unable to pause) on xbox consoles. Which they've explicitly spent time and effort on making sure the game at least sort of works. --- Basically - No, this sort of abstraction is hardly easy. Realistically, it's right on up there with rocket science. Last note: What hardware do you think an M1/2 mac is running on? Or an iphone? Or an old BSD machine? Or a Windows machine? Because I've spotted about three different entire ARCHITECTUREs there (x86, x64, ARM64). Not even accounting for differences based with the GPU (or lack thereof). The OS is already trying pretty hard to paper over those differences for you as a application developer... So I'm excited to see where we get with webGPU, but if you think it's equivalent to a low level api... I'm not really sure I agree. Plus it's explicitly not functional on... basically anything right now. Take a peak: https://caniuse.com/webgpu https://caniuse.com/webgpu
- jen20 4y ago
  I agree with almost all of your post, but some nitpicks: > Microsoft knew that most apps are forms way before the web (WinForms) Windows Forms was initially released in early 2002 with .NET Framework 1.0, which _also_ shipped ASP.NET Web Forms (which was a crime against HTTP) - but the forms analogy for Windows apps goes back much further - at least to Visual Basic in the early 90s. > So if I use the intermediate DOM layer Chromium provides, I get immediate support for 6 platforms You get the ability to display things to users of those and interact with those users, not support for them as platforms.
  - horsawlarway 4y ago
    Fair point on the windows forms analogy going back farther, and overlapping with the web by the 2000s. I was ~5 in 95, so it gets a bit hazy farther back. > You get the ability to display things to users of those and interact with those users, not support for them as platforms. I'm not clear on the distinction you're trying to make here. The browser functions as expected on those platforms (with the usual caveats around hardware capabilities limiting some use-cases). I'm targeting the browser to get wide support.
mike_hearn 4y ago
Over the past year or two I've been working on a (currently theoretical) design for a kind of pseudo-competitor to the web that's based on that observation. The fact that the web ignores most rules of platform design (because it was never meant to be one) isn't really a new observation. Most platforms build their higher level APIs on top of their lower level ones, so you can always drop down a level if the higher levels aren't working for you. You've got a widget toolkit but you can render your own and if you do you aren't losing anything else because you're using the same lower levels as the OS widgets. So why doesn't HTML work that way? Partly path dependency, partly philosophy and partly the difficulty of sandboxing low level code, as the sibling comment observes. However, the latter has been getting easier with time as operating system kernels improve their sandboxing abilities. It's also not always necessary. Do I care if Slack or Hacker News is sandboxed? Not really. Some sandboxing is nice just for peace of mind against security exploits but I do actually trust these brands and don't think they're going to exploit me. A more aggressive sandbox is useful when following links to random unknowns like people's blogs, but the web's design doesn't recognize that such a thing as gradients of trust exist. An alternative approach would be to reject the attempt to write a giant spec for all of computing, and instead embrace competition, diversity and layering. Start with a small core that knows how to download files and compose them together. It can fetch native apps into an HTTP cache, update them efficiently, execute them and delete them when the cache gets full. At that bottom layer the core enforces the platform's native security mechanisms (code signing, GateKeeper, SmartScreen etc). Then allow people to create native sandboxing apps that can be composed with other code to run that other code inside kernel level sandboxes. Responsibility flows downwards, so it's the sandboxing app that takes the risk of being blocked as malware if it fails in its core duty. Then you can compose VMs with the kernel sandboxing apps, and at each layer of the cake you're exposing IPC APIs that allow apps to e.g. allow their GUI to be embedded in a browser-style tabbed WM, to abstract and sandbox the platform's native accessibility APIs, to support form auto-fill and all the other features you might want. Such a thing would be quite different to the web, for example it would naturally support command line apps and servers. It would also be less centrally planned, as the core would mostly be a kind of dependency resolver that ensures components can be connected together across sandboxed IPC boundaries and provides some level of UI sharing beyond the native window manager. The spec would be minimal - the downside is the user-agent would be less generically powerful because you aren't forcing everything into a single model, the upside is the spec would actually be implementable because it's not trying to do anything. The design I've got also allows for document formats, crawling/indexing, authentication and other things that are useful to have in a web competitor, but there's no space to go into all that right now. The biggest problem is one of incentives. Google's bottomless pockets makes browsers fat but also kills any incentive to compete, as there's no obvious way to pay for the maintenance of any alternative. Having a small and tight core spec helps, but someone still has to do some work. Apple solve it by selling hardware but nobody else has a workable economic model.

horsawlarway 4y ago

At the risk of being a tad snarky... What does OP think is underpinning the browser's implementation of the DOM? Or Audio, for that matter? Those low level apis exist, and they could be exposed, but there's a whole lot of reasons they aren't. To list a few... 1. The browser is handling all of the platform differences for you. The issue with low level control is... you have to understand the low level details, and those tend to be architecture & platform specific. Blink in chrome is just neatly hiding the fact that under the hood it's got considerable differences for each platform. It's having to deal with OpenGL, Vulkan, DirectX, etc. And they are ALL different. So if I use the intermediate DOM layer Chromium provides, I get immediate support for 6 platforms (Windows, Linux, Mac, ChromeOS, Fuchsia, Android) plus unofficial support on BSD (at least OpenBSD and FreeBSD). Using the low level api... I don't have time to write a website, I'm too busy trying to read graphics api docs. 2. There is huge value in having a selection of premade utilities to work with - The honest answer is that most websites are just forms. Microsoft knew that most apps are forms way before the web (WinForms). So if you really just need to have the user enter some data, and then see a new page a framework that provides you with those tools is a huge win. This is why things like QT, WinForms, and the DOM exist - they give you an easy way to quickly make forms. Of the three - the DOM is by far my preferred. It's actually an insanely capable engine for forms. 3. The last (and arguably most important) point is that the browser is enabling you to run untrusted 3rd party software. It's not giving that software low level access because it's sandboxing your system from it to give you at least a modicum of trust that you can open a webpage and not have your whole machine compromised. Low level access is powerful, flexible, and complex. I don't want a site to be able to access my microphone or files or usb devices without control over it... because I click random links on sites like HN all day long.

cassianoleal 4y ago
Yeah that's really it. The browser is essentially a cross-platform VM, not entirely unlike the JVM or BEAM. In the end, you get somewhat a least-common denominator since it's abstracting so much. It's both constraining (you don't get the full power of the platform(s) you're building for), and enabling (you get to build once, run everywhere).
flohofwoe 4y ago
> 1. The browser is handling all of the platform differences for you. ...these "low level browser APIs" would still be regular Javascript web APIs which hide the differences between operating systems (that's the whole point of the browser after all!). E.g. WebGPU can still be considered a low-level API (when compared to other web APIs, but of course slightly higher level when compared to native APIs it sits on: D3D, Vk and Metal). Such wrapper APIs are not exactly rocket science, they can be both efficient and safe, yet still abstract over platform differences. > 2. ...most websites are just forms ...this is a fundamental difference in opinion I guess. I see the web mainly as an open app distribution platform, not as a library for documents. > 3. ...about trust... See point 1 about WebGPU. Safety aspects aside, you can look at game engines on how to build cross-platform APIs without giving up performance. In the end, most operating systems offer the same services in slightly different flavours, and it's possible to wrap those OS services in cross-platform APIs without too many compromises (after all, Windows, Linux, macOS, iOS and Android are all sitting on top of the same hardware anyway)
- deleted 4y ago
  [deleted]
- horsawlarway 4y ago
  > Such wrapper APIs are not exactly rocket science, they can be both efficient and safe, yet still abstract over platform differences. I would suggest this is not nearly as easy as you claim. Game engines are actually fine example of exactly what I'm talking about - Unreal might have an abstraction that wraps over system differences, but to access low level apis devs bail on it. Take a recent game: Atomic Heart. Built with Unreal Engine 4, which claims to support: Windows, macOS, and Linux PCs; PlayStation 4, PlayStation 5, Xbox One, Xbox Series X, and Nintendo Switch; and iOS and Android mobile devices. Platforms that they actually released on? Xbox Series X|S, Xbox One, Windows 10/11, PS4/5. Why? Because the abstraction turned out to not abstract so well, and they didn't bother to do the platform work required for the others. Does it run on Linux? Sort of... it runs on linux presenting the same abi as Windows through proton/wine. And even then, they have a ton of reported issues with performance (stuttering, frame drops, screens failing to load, unable to pause) on xbox consoles. Which they've explicitly spent time and effort on making sure the game at least sort of works. --- Basically - No, this sort of abstraction is hardly easy. Realistically, it's right on up there with rocket science. Last note: What hardware do you think an M1/2 mac is running on? Or an iphone? Or an old BSD machine? Or a Windows machine? Because I've spotted about three different entire ARCHITECTUREs there (x86, x64, ARM64). Not even accounting for differences based with the GPU (or lack thereof). The OS is already trying pretty hard to paper over those differences for you as a application developer... So I'm excited to see where we get with webGPU, but if you think it's equivalent to a low level api... I'm not really sure I agree. Plus it's explicitly not functional on... basically anything right now. Take a peak: https://caniuse.com/webgpu https://caniuse.com/webgpu
jen20 4y ago
I agree with almost all of your post, but some nitpicks: > Microsoft knew that most apps are forms way before the web (WinForms) Windows Forms was initially released in early 2002 with .NET Framework 1.0, which _also_ shipped ASP.NET Web Forms (which was a crime against HTTP) - but the forms analogy for Windows apps goes back much further - at least to Visual Basic in the early 90s. > So if I use the intermediate DOM layer Chromium provides, I get immediate support for 6 platforms You get the ability to display things to users of those and interact with those users, not support for them as platforms.
- horsawlarway 4y ago
  Fair point on the windows forms analogy going back farther, and overlapping with the web by the 2000s. I was ~5 in 95, so it gets a bit hazy farther back. > You get the ability to display things to users of those and interact with those users, not support for them as platforms. I'm not clear on the distinction you're trying to make here. The browser functions as expected on those platforms (with the usual caveats around hardware capabilities limiting some use-cases). I'm targeting the browser to get wide support.

mike_hearn 4y ago

Over the past year or two I've been working on a (currently theoretical) design for a kind of pseudo-competitor to the web that's based on that observation. The fact that the web ignores most rules of platform design (because it was never meant to be one) isn't really a new observation. Most platforms build their higher level APIs on top of their lower level ones, so you can always drop down a level if the higher levels aren't working for you. You've got a widget toolkit but you can render your own and if you do you aren't losing anything else because you're using the same lower levels as the OS widgets. So why doesn't HTML work that way? Partly path dependency, partly philosophy and partly the difficulty of sandboxing low level code, as the sibling comment observes. However, the latter has been getting easier with time as operating system kernels improve their sandboxing abilities. It's also not always necessary. Do I care if Slack or Hacker News is sandboxed? Not really. Some sandboxing is nice just for peace of mind against security exploits but I do actually trust these brands and don't think they're going to exploit me. A more aggressive sandbox is useful when following links to random unknowns like people's blogs, but the web's design doesn't recognize that such a thing as gradients of trust exist. An alternative approach would be to reject the attempt to write a giant spec for all of computing, and instead embrace competition, diversity and layering. Start with a small core that knows how to download files and compose them together. It can fetch native apps into an HTTP cache, update them efficiently, execute them and delete them when the cache gets full. At that bottom layer the core enforces the platform's native security mechanisms (code signing, GateKeeper, SmartScreen etc). Then allow people to create native sandboxing apps that can be composed with other code to run that other code inside kernel level sandboxes. Responsibility flows downwards, so it's the sandboxing app that takes the risk of being blocked as malware if it fails in its core duty. Then you can compose VMs with the kernel sandboxing apps, and at each layer of the cake you're exposing IPC APIs that allow apps to e.g. allow their GUI to be embedded in a browser-style tabbed WM, to abstract and sandbox the platform's native accessibility APIs, to support form auto-fill and all the other features you might want. Such a thing would be quite different to the web, for example it would naturally support command line apps and servers. It would also be less centrally planned, as the core would mostly be a kind of dependency resolver that ensures components can be connected together across sandboxed IPC boundaries and provides some level of UI sharing beyond the native window manager. The spec would be minimal - the downside is the user-agent would be less generically powerful because you aren't forcing everything into a single model, the upside is the spec would actually be implementable because it's not trying to do anything. The design I've got also allows for document formats, crawling/indexing, authentication and other things that are useful to have in a web competitor, but there's no space to go into all that right now. The biggest problem is one of incentives. Google's bottomless pockets makes browsers fat but also kills any incentive to compete, as there's no obvious way to pay for the maintenance of any alternative. Having a small and tight core spec helps, but someone still has to do some work. Apple solve it by selling hardware but nobody else has a workable economic model.