I really hope this tech doesn't take off - the web has been so successful _because_ it was declarative and not imperative. Now we're going to be baking in all the subtleties of Chrome and/or Firefox's handling of callbacks in a language that was never really designed to run inside of a layout engine.
Yes, a declarative web API is _far_ harder to get right, but the web community has created an amazing long-term compatibility story. It _should_ be difficult to add things to the web-at-large precisely because it has to live, essentially, forever.
Respectfully, that's a stretch - WebAssembly + (display tech) is a completely different stack in the browser. Houdini is bolting on a bunch of imperative stuff directly inside the browser engine with knock-on effects up and down throughout all of the web umbrella technologies.
With a wasm+web hybrid, there's a clear separation between the imperative wasm bits and the declarative web bits, so you can even combine them in ways that allow both stacks to perform well.
Houdini is not that much different from CSS Shaders.
I don't consider it a stretch, as I see a future where Flash gets its revenge and HTML is only used to import the starting WASM module, like on those Qt WebAssembly demos.
I tried those too... after three seconds of waiting and watching the "Downloading..." message with no app loaded, I felt the same dreadful feeling I used to get when I'd see a Java applet. I'm sure there are some use cases that will benefit from this, but I'm bummed thinking about how much crap is going to be needlessly delivered in a clunky way if we return to that HTML-as-bootloader app paradigm.
I wrote a 'scratch off' card[1] using the CSS paintlet API a little while ago to see what it was like to work with. There were a few annoying quirks (basically Chrome only, lots of talk without much forward motion, not much that you can't do with a plain old canvas) but there's a lot of potential.
I feel like this page was designed to be ironically bad to mask the fact that it's actually just bad. Why make it so difficult to understand what's going on? Is this glitch page somehow part of the actual WC3 project?
Hahahah ZippyDB landing page is hilarious. At least on mobile, interactive text elements sitting on top of interactive text elements...making it both difficult to read AND difficult to interact with.
I don't think thats the same ZippyDB Facebook uses. Theirs is developed for internal use on top of RocksDB, not Redis. (at least any public info I could find out about it), this looks like a (purposeful?) name collision to cause confusion.
Honestly, it feels like the web is so bloated sometimes. Are the fundamentals really that difficult? We have raw CSS and at most we can have a layer above it that generates manage-able CSS (e.g. SASS). Why introduce all this un-needed complexity?
Can you give examples of what you consider to be the bloated web? From what I can tell, the most popular websites other than Youtube are still all text and images, but have enormous file sizes because of the million ad and tracking scripts working in the background.
Seriously, how long do we have to wait until the browser is just a language VM and a drawable surface and you supply your own programming language and layout engine?
Like, hey, this URL just points to say, a QT app, and then it runs in this "browser" window over the network. Where have I heard of this before...
Everything else just feels like loads of duct tape on top of an over-stressed document browsing paradigm. Just rip it out completely.
Recent efforts to strip browsers down to their core functionality, and provide a world where the current web is effectively userland code:
* web components
* service workers
* Houdini
Imagine a future where browsers just implement these low level concepts, and HTML is defined as an (open source/community) library that all vendors bundle as part of their browser.
And then, also consider how much overlap there is here with traditional operating systems. Your next device OS could be just another layer on top.
Yes, a declarative web API is _far_ harder to get right, but the web community has created an amazing long-term compatibility story. It _should_ be difficult to add things to the web-at-large precisely because it has to live, essentially, forever.