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...

smallcircles (Humanity Now 🕊)

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.