alt Hacker NewsComing 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.
Replies
> 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.
Probably the decisive difference is that the web needs to be delivered over network, while the OS is installed once and then is just there. If everyone needs to download your very special implementation of an otherwise pretty common type of widget, it becomes a nuisance and a waste of bandwidth.
> 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 web has a gazillion libraries...
I always wonder if there could ever be a new css variant with less features that nevertheless can do everything that can be done today. Then you could imagine a migration where unnecessary CSS has to be implemented by poly fills and frameworks will be shamed into using the stricter subset
>For a functionality that can be composed out of existing APIs in a performant way, we do not add it in the platform
Why do standard libraries implement sorting and common data structures when they can be made from existing programming language features? The point of a platform isn't to expose the most minimal interface possible. It's to make it as easy as possible for people to use the platform.
GUI development in general is quite complex. You _can_ in principle compose a GUI from even simpler components: keyboard/mouse/touch events and blitting pixels to a screen, but this leaves you to do almost everything yourself. This is not only more work but also means there's a lot less consistency from GUI to GUI.
In the olden days, you would be expected to use the UI toolkit provided by the OS, which was designed to provide a consistent and complete implementation of each GUI element, which not only made things easier to navigate for users but also provided things like customizable theming and accessibility features more or less 'for free'. Nowadays it's much more like a free-for-all, and every application is just a little bit different, sometimes on purpose, sometimes just by accident. Accessibility is a complete crapshoot.
The web is similar. The people pushing for using 'the platform' are trying to capture exactly the same set of advantages as the old-school OS UIs, as well as the additional complication that we have a much more diverse set of devices with UIs nowadays.