This situation reminds me days when we, at W3C HTML5 WG, were trying to sneak SQL specification into HTML5 "umbrella". And one particular flavor of it - the SQLite's SQL as it was defined at the moment of writing.
Haven't got through for many good reasons as we know.
As of GPU exposure to the Web ...
It makes sense only when we will have stable and unified GPU abstraction. As for now DirectX.12, Vulcan and Metal are close but different.
Like the WebGL that is (more or less unified) OpenGL. But even that looks too foreign to HTML/CSS/script - immediate mode rendering in architecturally retained display model of web documents.
And conceptually: HTML5 umbrella is large but not infinite.
3D rendering is too far from HTML "endless flat text tape" model.
I remember those <applet> days when browser was used as a component delivery platform for stuff that does not fit into DOM and structured yet styled text. That was conceptually the right way "to grasp the immensity".
These days, with WebAssembly, we have another incarnation of the <applet> idea and I think GPU functionality belongs to it rather than to HTML. GLSL to be expressed in WebAssembly bytecode terms but not in JS.
Web standards have to be backward compatible and I doubt that current still ugly GPU paradigms will survive on the long run. Like tomorrow someone will come with practical voxel based system instead of current abstract vector ones, what will we do?
> Like tomorrow someone will come with practical voxel based system instead of current abstract vector ones, what will we do?
For one thing, any new approach will still have to solve the same problems around data transfer and formats that make up a lot of current APIs.
And for another, no matter how good this hypothetical new approach is, the old one will still be around to handle existing content and workflows forever anyway.
The SQL situation is a bummer. It made sense to avoid a monoculture, but indexedDB is a near-useless wreck due to its terrible performance and it has no meaningful querying primitives at all so you get to implement them yourselves and the performance is even worse.
Wish we could've just had two SQL implementations. There are other ones out there - Microsoft ships JET and an embeddable version of MSSQL, someone could've embedded postgres or something. As-is people who care about performance are just going to compile SQLite down to wasm/asm.js and run it in a worker.
Canvas is immediate mode rendered and already breaks through the DOM. There are also popular movements to make the DOM appear more as an immediate mode abstraction (React). In contrast, most retained mode 3D abstractions are seen as pretty bad.
The majority of game engines scene graphs are retained mode 3D abstractions.
Everyone thinks that they can do better with an immediate mode API, then we start building some kind of data structure to track down what needs to be drawn and when, with the result being similar to the traditional joke of half-implemented Lisp or ORMs, but applied to retained mode rendering.
Sure, some experts manage to get it right, and those are the ones that get to write AAA game engines, but many don't.
>> The majority of game engines scene graphs are retained mode 3D abstractions.
... but they are not built on an abstract retained mode API. That would be the wrong level of abstraction for a Web API that people can build on properly. I think that's the point here.
Unfortunately, Web APIs tend to be far too high level while missing out on low-level hooks, like the disaster that is Web Audio (and media playback in general).
Everyone needs their own retained mode API for sure, it’s just too different to generalize. Ideally, you would want to take your model and directly turn that into your UI, adding dependency tracing or domain knowledge to handle invalidation. React and it’s ilk make it easier to do just that.
> "This situation reminds me days when we, at W3C HTML5 WG, were trying to sneak SQL specification into HTML5 "umbrella". And one particular flavor of it - the SQLite's SQL as it was defined at the moment of writing. Haven't got through for many good reasons as we know."
Can you elaborate on the arguments against a dialect of SQL being available for use with local storage? I can only think of arguments in favour of it. Would be good to understand the grounds on which the idea was dropped.
The lesson of the Web is that when you expose some interface for people to use, they will start depending on documented features, undocumented features, and downright bugs of the first popular implementation. Second and subsequent implementations will need to spend a bunch of time reverse-engineering those bugs so they can be documented and reliably implemented in future so that existing websites keep working.
The only alternative is to make sure all new interfaces have multiple, popular implementations simultaneously, so that authors can't afford to take advantage of bugs in one implementation. This is the sort of activity you see in WHATWG these days.
The problem with "a SQL dialect" being available for use on the Web is that every browser intended to use SQLite as the backend. Nobody wanted to invest the time and effort to write a second, compatible, equally-reliable implementation; nobody wanted to exhaustively research and document bugs and flaws in that specific version of SQLite; nobody wanted to commit to back-porting security fixes from later versions, or forward-porting the required bugs to later versions.
And since nobody wanted to do the work to make it possible, using SQL for local storage remains impossible.
The W3C attempted to say version X.Y.Z of SQLite will be the SQL standard for the web, mandating 1) that it be frozen in time 2) that the only way to be compliant was to put SQLite into all browsers, bit for bit, there would be no other way to be compliant.
As much as I wanted it, and was bummed that Mozilla protested so much, they were/did/are doing the right thing by saying that SQLite cannot be used as a standard, it isn't a spec.
What one can do, is compile SQLite to emscripten or wasm, or write a SQL engine in JS and use that in the browser. That is totally fine.
As someone who works on a product which compiles SQLite to JS to read a SQLite based file format in the browser - this is a terrible, terrible “solution” and doesn’t scale for files larger than X MB, where X is the device dependent limit based on memory available to the browser.
HTML and CSS are slowly losing ascendancy as the main render surface for web apps. The canvas provides a standard pixel buffer for both JS and compiled applications, making HTML's limitations no longer a restriction.
It's not about eye-candy, the Web has become an application platform (against all resistance) and it can't thrive on standards bodies to deliver every bit and piece required. Even in 2018, web applications are shunned by many professionals for their poor quality and performance.
A lot of HN comments dismissed my prediction[1] that WebAssembly will bring opaque "compiled applications" that treat the canvas as a "standard pixel buffer", allowing adblocking CSS and request filters to be bypassed.
A lot of people seem to be focusing on the benefits of new technological changes ("no longer a restriction"), when they should first be concerned with the potential risks that change will create.
>my prediction[1] that WebAssembly will bring opaque "compiled applications" that treat the canvas as a "standard pixel buffer", allowing adblocking CSS and request filters to be bypassed.
They could already do that. It's called serving the whole page as an image
I don't believe that's true for any modern browsers. They all use hardware accelerated rendering in the common case of drawing to a canvas that will be composited on-screen, and make a copy into process memory only when you access the pixels with a call like getImageData().
What are you talking about? You’re able to access random pixels, yes, but first you need to copy them to normal RAM. Canvas 2D and WebGL are both hardware accelerated.
I’ve actually noticed a return recently to simple “HTML native” UI design on the web. Not as many people trying to emulate an “OS native” experience by adding a bunch of extra DOM elements to render borders and effects and such.
Eh, not for WebGL it won't. Nobody even implements DX other than high-powered desktop GPUs.
Will it live on? Sure, we will still have games and Xboxes. But if you're going to pick a standard that can work on mobile and desktop, there is no contender other than Vulkan.
2. Both of them... If you are gamer, you are going to Steam (and Valve is not a friend of the Windows store idea). I'm not happy with this situation either, as I prefer GoG, and GoG is a distant second.
3. Doom, Wolfenstein II, F1 2017, The Talos Principle from the other side of genre spectrum or the upcoming Star Citizen. Vice versa is more true, there's no DX12 game worth playing, that's not also Vulkan game.
1. Not everyone is rich enough to buy flaghship phones.
2. Lots of gamers just use XBox or PS4 (no Vulkan there). And on PC, not everyone uses Steam. Plus Microsoft already started to be more agressive regarding games on Windows 10, with Age of Empires remaster being the first example.
3. Well it is a matter of taste, not everyone craves for FPS, then there is also the small matter that Vulkan is not supported on XBox anyway, while DX 12 is. With much better developer tooling.
1. Then a game console is not much relevant either.
2. Age of Empires is Microsoft's game in the first place. Of course they will want their assets to use their technologies. 3rd party adoption is a rounding error. On the PC, except for 1) hardcore indie games players and 2) games locked to the publisher's platform, everyone uses Steam. In the second case, where the games are exclusive to a publishing platforms (Origin, Uplay), they have similar attitude to Windows store as Steam.
Windows store is an existential threat to them. They will ignore it as long as possible.
3. Sure, that's why I mentioned The Talos Principle (a puzzle game). Xbox API will be handled exactly as PS API is.
As of GPU exposure to the Web ...
It makes sense only when we will have stable and unified GPU abstraction. As for now DirectX.12, Vulcan and Metal are close but different.
Like the WebGL that is (more or less unified) OpenGL. But even that looks too foreign to HTML/CSS/script - immediate mode rendering in architecturally retained display model of web documents.
And conceptually: HTML5 umbrella is large but not infinite. 3D rendering is too far from HTML "endless flat text tape" model.
I remember those <applet> days when browser was used as a component delivery platform for stuff that does not fit into DOM and structured yet styled text. That was conceptually the right way "to grasp the immensity".
These days, with WebAssembly, we have another incarnation of the <applet> idea and I think GPU functionality belongs to it rather than to HTML. GLSL to be expressed in WebAssembly bytecode terms but not in JS.
Web standards have to be backward compatible and I doubt that current still ugly GPU paradigms will survive on the long run. Like tomorrow someone will come with practical voxel based system instead of current abstract vector ones, what will we do?