3 ms·

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 a

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.

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.