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.
> there are only three platforms: Blink/V8; WebKit/JavaScriptCore; and Geko/SpiderMonkey.
You’re misunderstanding the terminology here. The platform being talked about is the World-Wide Web and you are listing three implementations of the client part of the platform.
I think you have the causality incorrect. There aren't fewer implementations because the standard is complicated; the standard is the product of the browser wars, when well-resourced browser implementors differentiated themselves by adding behavior to anemic/underspecified standards. Browser vendors did, to their credit, co-operatively add a lot of common/similar behavior and then work to standardize it--that's healthy standards growth. But a lot of the size of the standard is because they all wanted to add different capabilities to entice users.
A standard that's the product of feature competition between pre-existing nonstandardized behaviors is doomed to be huge. See also: AMQP, C++.
The browser wars are long gone, and there is no technical reason why the standards each browser added had to be complex per-use-case builtins instead of composable primitives.
In any case, that is what happened.
And now new projects like Ladybird take a decade to arrive, even with AI, because of the immense amount of stuff in the platform.
> standard that's the product of feature competition between pre-existing nonstandardized behaviors is doomed to be huge.
> The browser wars are long gone, and there is no technical reason why the standards each browser added had to be complex per-use-case builtins instead of composable primitives.
Browser vendors couldn't see the future. Each was doing their best to stand out from the crowd with limited budgets and schedules. Hence JS being as odd as it is.
With hindsight it's clear it could've been better. And now with today's mono-culture there is an opportunity to drop some of the legacy cruft and rethink a modern web. Or even just slimmer Electron-like solutions using an ideal subset as better primitives.
I really wish something like FirefoxOS had gained traction. Because unlike Android, it could make native apps so much more open an approachable. In theory at least.
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.
JimDabell · · focus · HN ↗
You’re misunderstanding the terminology here. The platform being talked about is the World-Wide Web and you are listing three implementations of the client part of the platform.
serbuvlad · · focus · HN ↗
There ARE ONLY THREE implementations of the client platform.
I would like for there to be a hundred, and there would be if the platform was simpler, but its not, so there won't.
zbentley · · focus · HN ↗
A standard that's the product of feature competition between pre-existing nonstandardized behaviors is doomed to be huge. See also: AMQP, C++.
serbuvlad · · focus · HN ↗
In any case, that is what happened.
And now new projects like Ladybird take a decade to arrive, even with AI, because of the immense amount of stuff in the platform.
> standard that's the product of feature competition between pre-existing nonstandardized behaviors is doomed to be huge.
None of the Unixes are this bloated.
paulryanrogers · · focus · HN ↗
Browser vendors couldn't see the future. Each was doing their best to stand out from the crowd with limited budgets and schedules. Hence JS being as odd as it is.
With hindsight it's clear it could've been better. And now with today's mono-culture there is an opportunity to drop some of the legacy cruft and rethink a modern web. Or even just slimmer Electron-like solutions using an ideal subset as better primitives.
I really wish something like FirefoxOS had gained traction. Because unlike Android, it could make native apps so much more open an approachable. In theory at least.
serbuvlad · · focus · HN ↗
The web is uniquely capable (aside from raw OpenGL et. al) at rendering any UX designer's vision.
Almost all alternatives to the web that I've seen make aesthetic impositions, and are therefore non-starters.