4 ms·

As a 'somewhat' outsider (having found interest in the web mainly via asm.js and WASM) my take on the framework mess is this: It's all about problems with the

As a 'somewhat' outsider (having found interest in the web mainly via asm.js and WASM) my take on the framework mess is this: It's all about problems with the DOM, specifically about three problems: it's too opinionated, too inflexible and on top baked into browsers. Javascript frameworks try to provide solutions to those problems, but they can only hide them, not fundamentally fix them. Because they can only implement their idea of how a 'perfect DOM' would look like by adding more code layers on top of it, but not replace it. The alternative is to do everything yourself in a canvas, but now 90% of the browser's features are useless, because they are all integrated with the DOM. And that is the root of all problems: the browser lacks a proper API layer model where the low level layers (2D canvas, WebGL, WebGPU) sit at the bottom, medium level layers (e.g. for text, image and vector rendering, a layout engine and an accessability API) sits in the middle, and on top of everything the DOM. Instead all we have is either too inflexible and too high level (the DOM) or too low level for many tasks (WebGL or WebGPU). Same for audio btw, there should be a low level streaming API at the bottom, a medium level 'mixer API', and WebAudio should only come in on top of those (or even kicked out of the browser and implemented in a JS or WASM library). ...of course this all means: lets get even more Javascript and WASM into web pages, which will anger the 'web boomers' greatly I guess :D

civilized 4y ago
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
- 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.
actionfromafar 4y ago
Yes, the browser is like a cool operating system you only can access from VBA in a Word Document. :-)
satvikpendem 4y ago
You're exactly right. Ian Hickson, who wrote the HTML5 spec and is now the team lead on Flutter, notes this exact sentiment as well in the below piece, where like you said, we should have the different rendering layers you're talking about, with low level layers in WASM and canvas at the bottom and high level APIs at the top. Flutter actually works the same way, so I can see where he got this influence. Note his comments on the HN thread in particular where he talks about how the web essentially "failed" as an application platform and is only held up by modern frameworks which essentially have to work around its limitations with virtual DOMs and polyfills. As we go towards more and and more languages supporting WASM and wanting UI, such as Rust with iced, we should have a common set of components and APIs so that each language is not building their own custom components in WASM, which would defeat the point of interoperability, at least at the UI layer. And you're right about the web boomers, the HN thread shows them very angry indeed ;) https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696
- tambourine_man 4y ago
  That's an interesting discussion, thanks for linking, but I was very disappointed by Ian. I guess that makes me a web boomer, regardless of my age.
  - satvikpendem 4y ago
    Hah, looks like you're not alone based on what others have said on that thread about Ian not wanting to support features like navbars and instead wanted to support things like asides that really most people don't use. What makes you disappointed by Ian, just curious?
    - tambourine_man 4y ago
      Disregard for the web, its accessibility, openness. The guy was there at the sausage factory.
      - satvikpendem 4y ago
deleted 4y ago
[deleted]
foul 4y ago
Plus, you have to fight a lot with canvas and resource usage, compared to spitting markup with events around in the DOM

civilized 4y ago

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
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.

actionfromafar 4y ago

Yes, the browser is like a cool operating system you only can access from VBA in a Word Document. :-)

satvikpendem 4y ago

You're exactly right. Ian Hickson, who wrote the HTML5 spec and is now the team lead on Flutter, notes this exact sentiment as well in the below piece, where like you said, we should have the different rendering layers you're talking about, with low level layers in WASM and canvas at the bottom and high level APIs at the top. Flutter actually works the same way, so I can see where he got this influence. Note his comments on the HN thread in particular where he talks about how the web essentially "failed" as an application platform and is only held up by modern frameworks which essentially have to work around its limitations with virtual DOMs and polyfills. As we go towards more and and more languages supporting WASM and wanting UI, such as Rust with iced, we should have a common set of components and APIs so that each language is not building their own custom components in WASM, which would defeat the point of interoperability, at least at the UI layer. And you're right about the web boomers, the HN thread shows them very angry indeed ;) https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696

tambourine_man 4y ago
That's an interesting discussion, thanks for linking, but I was very disappointed by Ian. I guess that makes me a web boomer, regardless of my age.
- satvikpendem 4y ago
  Hah, looks like you're not alone based on what others have said on that thread about Ian not wanting to support features like navbars and instead wanted to support things like asides that really most people don't use. What makes you disappointed by Ian, just curious?
  - tambourine_man 4y ago
    Disregard for the web, its accessibility, openness. The guy was there at the sausage factory.
    - satvikpendem 4y ago

deleted 4y ago

[deleted]

foul 4y ago

Plus, you have to fight a lot with canvas and resource usage, compared to spitting markup with events around in the DOM