I've been so much time mourning the death of what I saw as the future of computing back in the microcomputer and early PC era, and blaming capitalism, Google, Apple, and the FOSS movement, that I hadn't actually considered the possibility that we'd alr...

Adrian Cochrane

@freakazoid O.K., you're going this direction: Yes, I think WASM/WebGPU as an opportunity allowing other cross-platform platforms to burst out of the web's chest & compete!

Charles U. Farley

The right way to avoid this nightmare future isn't to try to swim upstream, resisting these tools just because they will be (and are) being abused by capitalism. It's to use all of the tools available to us to build the future WE want.

As @alcinnz pointed out, the thing in common between WASM and WebGPU is that they're completely crossplatform. I think they're the future because they make it so we don't need to care what CPU or kernel the host uses. They also provide a more robust isolation model than any "raw" OS does. WASM/GC can even support capability-based security.

Instead of trying to fork or replace the Web, we should evolve it. We should embrace and extend the things capitalism produces that serve our purposes.

Microsoft famously invented "embrace and extend" as a strategy for beating FOSS, but my favorite example comes from Mozilla. While Google was struggling to get anyone to adopt NativeClient and Portable NativeClient, Mozilla made it so Spidermonkey could efficiently execute the code being spit out by an experimental C++ to JS compiler called Emscripten, creating AsmJS (I could be getting the exact history wrong, please feel free to correct me but I don't feel like researching it myself).

The advantage of AsmJS over NaCl and PNaCl is that it was part of the JS engine, so it had exactly the same API people already knew for web development. NaCl, on the other hand, used PPAPI, the same API that Chrome plugins used. That made it a lot harder to adopt in another browser and created a steeper learning curve for anyone who didn't already know how to write plugins (again I might have some details wrong; please feel free to correct me).

Eventually Google dropped NaCl and PNaCl in favor of making V8 able to execute AsmJS efficiently. They even did it without writing any AsmJS-specific code, which is pretty impressive. Eventually AsmJS got its own compact represenation very similar to PNaCl (which was based on LLVM bitcode). That dramatically improved loading times, the biggest disadvantage of AsmJS, which compressed well but still decompressed into very "fluffy" source code that the JS engine had to parse.

3/n

Charles U. Farley

And now to the thing that triggered this epiphany for me: this thread with @joepie91 I link to the end instead of the beginning, because I think it's the important bit and I'm not sure how much of the thread others will be able to see if they don't follow joepie91.

Sven Slootweg (@[email protected])

Content warning: personal venting

Pixietown (social.pixie.town)

Electron is probably the most spot-on example of this "embrace and extend" strategy. They're taking work that's already being done by the CEF project and using it to make a desktop application framework that gives developers access to all the "web technologies" they know and love, without having to implement a new browser from scratch.

Please read that whole thread before complaining about Electron. And then still don't complain about Electron to me.

4/n

Charles U. Farley

I also find Godot super interesting, in that it can produce binaries that use WASM and WebGPU to run in a browser without needing the developer to actually be able to write code.

My vision is something that encompasses the whole lifecycle from end-to-end: a development environment like Godot or Electron that lets people make programs, a runtime/container like Electron that instead of being included with every application instead can load its own package format. And some kind of distribution system for discovering and shipping packages.

On top of this we build our "component-based interface". Which will require a different security model than the Web currently uses, though we'll probably still use iframes and web workers for isolation.

We also need a way of storing data both locally and in arbitrary remote storage services. Preferably with standardized formats and transcoders for sharing common bits of information like contacts, calendar events, pictures and movies, etc.

5/5 for now. Discussion and feedback welcome! Except for complaints about Electron. Or toxic minimalism.

smallcircles (Humanity Now 🕊)

@alcinnz @freakazoid

There are multiple paradigm shifts that may be combined to a new all-encompassing one. There's the social web, local-first computing, polyglot programming and vendor-neutral components.

It could break the hegemony of both cloud, browsers, and big tech platforms (not just social media but all the Web 2.0 walled gardens).

Some notes I made on wasm: https://discuss.coding.social/t/wasm-component-based-development-wiki/367

smallcircles (Humanity Now 🕊)

@alcinnz @freakazoid

Btw, a huge ongoing "embrace & extend" is MS/Github and their encroachment into the developer toolchain and dev processes. Dev's on the MS cloud.

Press dot on a repo and get VSCode-in-the-browser. Gitops and directly spin up cloud environments. Is there still a need for git, or will it be encapsulated? Is there a need for anything local on your PC?

This is interesting area of attack for FOSS folks working in the new paradigms.

smallcircles (Humanity Now 🕊)

@alcinnz @freakazoid

Btw, Ian Hickson once expressed an interesting vision for the next web. He's now involved with Wasm Component Model.

See: https://social.coop/@smallcircles/110445148829899767

Also note .. @TauriApps is a very interesting alternative to Electron, in case you weren't aware. They collab with the Servo project, so you might use that as the webview.

Adrian Cochrane

@smallcircles @freakazoid @TauriApps I find this Hixie remark interesting: https://news.ycombinator.com/item?id=34622514
"I think my attitude to this stuff evolved after seeing that even with all the work we did with HTML, virtually nobody actually benefits from it."

I disagree with his loss of faith, I don't think things are this dire. But I reckon him pursuing this alternate vision will improve HTML by splitting off the app web!

Its a decent vision for the app web...

Charles U. Farley

@smallcircles Vscode in the browser is definitely a force to be reckoned with/coöpted.

Git's learning curve leaves a lot to be desired. I think its internal complexity might be too high compared to something like Pijul, but I don't know. We need to build on what we have and evolve the system rather than trying to build something from scratch, or we'll be stuck in Xanadu.

I do think version control should be built into the development environment, and it should understand the semantics of the language. This becomes especially necessary when you start getting into visual languages where the user isn't expected to understand the serialization of a program, UI element, etc.

@alcinnz

Charles U. Farley

@alcinnz He's vague about specifically how it's failed, though. Browsers' lacking a UI for alternate stylesheets seems like a chicken & egg problem that's easily fixable.

There were at least a couple of different attempts to make HTML/CSS/JS based mobile OSes: WebOS and the one Cory Ondrejka led at Facebook. Both failed because web apps couldn't be made responsive enough on a mobile processor at the time. But because the mobile device companies make so much money on distributing native mobile apps, there's no longer any incentive to advance the state of the web apps. Imagine if all the effort going toward "AI" went toward making web apps responsive on phones?

iOS is a lost cause, but I don't think anything stops us from turning, say, Vanadium into an awesome mobile app runtime. Though I think we should be looking to 5-10 years in the future, so as
@smallcircles said maybe Servo is the right renderer to be targeting?

Adrian Cochrane

@freakazoid @smallcircles As I said: I don't believe it has failed (outside the mainstream services), so I won't opine (again) on why it has.

Personally I'd rather not rely on faster hardware, I prefer faster software. And for apps like Hixie I reckon it'd be best to implement the rendering in-app inside the sandbox upon WebGPU & ARIA.

The DOM is an overly-complex API designed amongst hype misconstruing Java-like OOP as being universal. I'd like to give it up!

Charles U. Farley

@alcinnz We need to keep the DOM around to render web pages with JS that uses it, but nothing stops us from implementing it as a translation layer on top of a simpler API.

One challenge with WebGPU is that (I think) you just get a canvas. For component-based UIs we'd need more flexibility. Which could just be rendering to a transparent texture that then gets rendered as part of another element.

Mainly I don't want to be stuck with WIMP, but I could be persuaded it's not the long pole right now.

@smallcircles

Adrian Cochrane

@freakazoid My attitude is that most of those sites break sooner or later, due to dependencies which don't take as much care.

I think I'll stop engaging: The DOM is the main standard I blame the sad state of modern browsers upon, & I am not interested in any vision which keeps it around! I wouldn't consider it a paradigm shift!

I started engaging before I knew where you were going.

@smallcircles

Charles U. Farley

@alcinnz We have to be able to actually get there. Right now I'm envisioning using Servo or CEF. Implementing the DOM would be a massive undertaking, as you're well aware, but replacing it as well as all the applications that depend on it actually seems like a much larger undertaking, no matter how much simplification is possible along the way.

I'm looking at this entirely from the user experience angle, which includes application/component developers. People's biggest complaint about the DOM is inconsistent vendor support. But that's actually just a problem for web apps. It's not a problem with a local app for which you control the whole runtime.

If some alternative starts to coalesce and an ecosystem starts growing around it, I'll be all over that. But for now my plan is for the rendering stack to be mostly off the shelf. I know that's a bit surprising since I've spent a lot of time talking about rendering, but one of the things I realized over the course of that thought experiment (along with some code) is that it can only do anything to meaningfully improve the user experience as part of a much larger project.

One of the principles I'm hoping this can maintain is that individual parts of the stack should be able to be swapped out. So I'd definitely like to see the DOM eventually implemented on top of something better and then someday dropped entirely.

@smallcircles

smallcircles (Humanity Now 🕊)

@freakazoid @alcinnz

A very ambitious and impressive exploration is #Makepad. A live-editable UI toolkit, and the UI scripted as a Figma-like DSL, running 120 FPS in the browser.

Makepad is pre-alpha still. Need to watch the presentation vid on the website to see the power of the paradigm. See: https://makepad.nl

There's #Robrius where Makepad and other community projects focus on a complete app development experience with Rust.

Project Robius

Community for Multi-platform Application Development in Rust - Project Robius

GitHub (github.com)

Refurio Anachro

UI […] running 120 FPS in the browser.

What?! I... I just want a

where I can enter my data. If cut&paste still works, that'd be great!

Sorry, if I'm missing the point.

@smallcircles @freakazoid @alcinnz

smallcircles (Humanity Now 🕊)

@RefurioAnachro @freakazoid @alcinnz

No problem. At the level where new UI toolkits are built the metric is useful, so that ultimately we don't see sluggish, laggy UI esp. in more complex apps.