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.
> 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.
Native apps are downloaded upfront and the installation is largely separate accepted by users. Web users expect websites to download and be usable immediately.
Almost every website I visit has massive pop-ups I have to dismiss. Clearly a cached fat library GET would be less annoying than what I already put up with.
I'm not actually a web dev and I think they would gain more from having a big standard library but I'm fairly sure the actual decision makers at the companies that own these websites don't agree with either of us.
They basically want to squeeze every bit of performance from the things that they think don't bring business value so that they can afterwards burden these websites with every advertising, tracking, compliance, cool animation (from their POV), etc library and tool on the planet. Basically bloatware.
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.
oblio · · focus · HN ↗
The web has a gazillion libraries...
serbuvlad · · focus · HN ↗
oblio · · focus · HN ↗
serbuvlad · · focus · HN ↗
oblio · · focus · HN ↗
They basically want to squeeze every bit of performance from the things that they think don't bring business value so that they can afterwards burden these websites with every advertising, tracking, compliance, cool animation (from their POV), etc library and tool on the planet. Basically bloatware.