Coming from a more general programming view, I find web development extremely odd. In general programming we tend to find a small set of abstractions which we can use in a composable way to cover our problem space.
For example, to interact with the VFS, we have read()/write(). When we add more APIs, it can be to enable a new paradigm, like epoll(), or for performance, like readv()/writev(). For a functionality that can be composed out of existing APIs in a performant way, we do not add it in the platform, but leave it instead to the domain of libraries. This separation has immense values, as it makes platforms easy to implement. A Linux filesystem, for example, needs to implement only 10 or so functions.
The web seems to be perfectly composable too, out of <div>, <span>, <p> and a small subset of CSS, but doing this is considered an anti-pattern, and you're supposed to reach for the platform to find the closest thing to what you need, whereas reaching for a library or composing yourself is frowned upon.
The result is that there are only three platforms: Blink/V8; WebKit/JavaScriptCore; and Geko/SpiderMonkey. With many things only working or working well on Blink/V8.
And implementing a new platform is a titanic task.
Look - even coming from a spot where I mostly agree that the end spot isn't wonderful and the standards are probably too complex, I think this glossed over the "conceptual shift" that has happened for browsers.
Browsers got complicated because they weren't seen as a platform to ship code to... They were seen as document renderers.
There wasn't anything to "compose with" for a meaningful history of browser development. You shipped a document (html) with some optional styling, and the browser handled EVERYTHING.
JS was a very minimal, underpowered, runtime that was decidedly NOT the thing to use for any real composition that resembled backend/desktop coding. The tools of the time for that were flash and activeX and silverlight.
Javascript was just a thing you used if your checkout form needed to be more complex than normal, or you wanted to show off a bit.
---
Then Ajax came along in the early 2000s, sites got increasingly complex and interactive during the web 2.0 push, js got progressively more powerful (to the point where the js runtime is functionally not that far off a real OS in complexity and capability) frameworks hits the scene, and people finally had the right tools to actually implement a single page app using web tools.
---
So...
1990 to 2005: Browser is solely a document renderer, every new cool thing has to be implemented by the browser.
2005 to 2015: Browser is mostly a document renderer, but you can do cool new interactive things, and you needed to paper over lots of rough patches with js.
2015 to 2025: Browser can ship meaningful applications that run entirely in the client, and the "document" model has faded a bit (although it's definitely NOT gone) while new complexity largely lives in expanded system access and capabilities (ex - usb access, crypto, complex networking, async processing, web-assembly, etc).
---
The challenge is that people who want the "document" model still want it all implemented by the renderer, and there's enough historical momentum there that you basically can't undo it without starting from scratch to deliver applications instead of documents.
Further (and this one is entirely on you) the real comparision isn't "unixes" it's a graphical env. So compare the complexity and attitude to win32 dialog apis, QT, etc...
Often they also ship with a huge library of components built in. Because the users of those systems don't really want a canvas they have to render everything on... rendering is hard. Rendering performantly is really hard.
> Further (and this one is entirely on you) the real comparision isn't "unixes" it's a graphical env. So compare the complexity and attitude to win32 dialog apis, QT, etc...
Yes these entirely fit the platform/library hard distinction model.
The platform is the small API to create windows, recieve input events and get an OpenGL/Vulkan/DirectX/Metal surface to draw to, as well as the graphics library itself, which is similarly based on primitives.
Everything above that is a library.
> Because the users of those systems don't really want a canvas they have to render everything on... rendering is hard.
Qt isn't a "system". libQt5 Core + Gui + Widgets + Qml is roughly 20MB on a Linux system I can readily check. This is way more than lean enough to ship with every app and even to download-on-first-use and cache for a web app (assuming it was ubiquitous and many websites would want to pull it from cache).
What the system gives is exactly a canvas to render stuff on.
serbuvlad · · focus · HN ↗
For example, to interact with the VFS, we have read()/write(). When we add more APIs, it can be to enable a new paradigm, like epoll(), or for performance, like readv()/writev(). For a functionality that can be composed out of existing APIs in a performant way, we do not add it in the platform, but leave it instead to the domain of libraries. This separation has immense values, as it makes platforms easy to implement. A Linux filesystem, for example, needs to implement only 10 or so functions.
The web seems to be perfectly composable too, out of <div>, <span>, <p> and a small subset of CSS, but doing this is considered an anti-pattern, and you're supposed to reach for the platform to find the closest thing to what you need, whereas reaching for a library or composing yourself is frowned upon.
The result is that there are only three platforms: Blink/V8; WebKit/JavaScriptCore; and Geko/SpiderMonkey. With many things only working or working well on Blink/V8.
And implementing a new platform is a titanic task.
horsawlarway · · focus · HN ↗
Browsers got complicated because they weren't seen as a platform to ship code to... They were seen as document renderers.
There wasn't anything to "compose with" for a meaningful history of browser development. You shipped a document (html) with some optional styling, and the browser handled EVERYTHING.
JS was a very minimal, underpowered, runtime that was decidedly NOT the thing to use for any real composition that resembled backend/desktop coding. The tools of the time for that were flash and activeX and silverlight.
Javascript was just a thing you used if your checkout form needed to be more complex than normal, or you wanted to show off a bit.
---
Then Ajax came along in the early 2000s, sites got increasingly complex and interactive during the web 2.0 push, js got progressively more powerful (to the point where the js runtime is functionally not that far off a real OS in complexity and capability) frameworks hits the scene, and people finally had the right tools to actually implement a single page app using web tools.
---
So...
1990 to 2005: Browser is solely a document renderer, every new cool thing has to be implemented by the browser.
2005 to 2015: Browser is mostly a document renderer, but you can do cool new interactive things, and you needed to paper over lots of rough patches with js.
2015 to 2025: Browser can ship meaningful applications that run entirely in the client, and the "document" model has faded a bit (although it's definitely NOT gone) while new complexity largely lives in expanded system access and capabilities (ex - usb access, crypto, complex networking, async processing, web-assembly, etc).
---
The challenge is that people who want the "document" model still want it all implemented by the renderer, and there's enough historical momentum there that you basically can't undo it without starting from scratch to deliver applications instead of documents.
Further (and this one is entirely on you) the real comparision isn't "unixes" it's a graphical env. So compare the complexity and attitude to win32 dialog apis, QT, etc...
Often they also ship with a huge library of components built in. Because the users of those systems don't really want a canvas they have to render everything on... rendering is hard. Rendering performantly is really hard.
serbuvlad · · focus · HN ↗
Yes these entirely fit the platform/library hard distinction model.
The platform is the small API to create windows, recieve input events and get an OpenGL/Vulkan/DirectX/Metal surface to draw to, as well as the graphics library itself, which is similarly based on primitives.
Everything above that is a library.
> Because the users of those systems don't really want a canvas they have to render everything on... rendering is hard.
Qt isn't a "system". libQt5 Core + Gui + Widgets + Qml is roughly 20MB on a Linux system I can readily check. This is way more than lean enough to ship with every app and even to download-on-first-use and cache for a web app (assuming it was ubiquitous and many websites would want to pull it from cache).
What the system gives is exactly a canvas to render stuff on.