Comment by serbuvlad
13 hours ago
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.
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.
> In the olden days, you would be expected to use the UI toolkit provided by the OS
That’s still (IMHO) the best place to start.
This point came home recently in doing a little macro to load a directory of GeoJSON documents into QGIS.
You need to load the Python console to get the proper environment, and you can't just say logger.debug() to get a trace.
This is because QGIS runs in the Qt event loop.
Big cluebat: QGIS (qualitatively, and for the regular pythonista) is like doing everything via asyncio.
Ah, so: no wonder it's such a challenge.
Yeah, though I would probably paint this as a case where the logic of the application is very tied up the UI, which makes it generally quite difficult to access the functionality as a library (or e.g. from the command line). Some applications have things seperated out enough, but this is usually something you need to start with as a goal. Other applications do have a scripting interface which you can use to automate things, and this can work quite well, but sometimes it is still very tied to the UI (e.g. blender, where it is quite powerful but you are essentially still driving the UI from the commands instead of describing the actions you want. e.g. you need to change modes in order to perform certain actions).
> 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.
You are the one misunderstanding my point.
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.
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++.
3 replies →
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.
But libraries can be GET'ed from common URLs and cached!
For better user tracking!
> 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...
Yeah exactly. So does native. So what? Why is this a bad thing?
Native apps are downloaded upfront and the installation is largely separate accepted by users. Web users expect websites to download and be usable immediately.
2 replies →
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.