Alan Kay on “Should web browsers have stuck to being document viewers?” and a discussion of Smalltalk, HyperCard, NeWS, and HyperLook

https://donhopkins.medium.com/alan-kay-on-should-web-browser...

>Alan Kay answered: “Actually quite the opposite, if “document” means an imitation of old static text media (and later including pictures, and audio and video recordings).”

We have, but not by choice, I miss my native apps, even though ChromeOS Platform pays the bills.

> booked tickets for a flight or bought a home or a car or watched a cat video

Would you install a native app to book a flight? One for each company? Download updates for them every now and then, uninstall them when you run out of disk space etc

I can ask the same question about every other activity we do in these non-native apps.

I have installed all them on the phone, so yes.

Unfortunely several of them are glorified webviews.

I am old enough to have lived through the days Internet meant a set of networking protocols, not ChromeOS Platform.

And on those days hard disks were still bloody expensive, by the way.

> I have installed all them on the phone, so yes.

Isn't your phone providing a sandbox, a distribution system, a set of common runtime services, etc to get these native apps functional?

You don't have to squint your eyes to realize that this thing we call "document browsers" are doing a lot of the same work that Apple/Google are doing with their mobile OSes.

You mean like Windows Store, Mac App Store, apt, yum/dnf, emerge,....?

All the OS frameworks that are available across most operating systems that don't fragment themselves into endless distributions?

> don't fragment themselves into endless distributions?

My dear Lord! In what world are you living in?

Take a look at all of the "mobile apps" you installed on your phone and tell me which of those would ever devote any resource to make a apt/rpm repository for their desktop applications.

Even the ones that want to have a desktop application can not figure out how to reliably distribute their software. The Linux crowd itself is still at the flatpak vs AppImage holy war. Mark Shuttleworth is still beating the snap horse.

The Web as a platform is far from ideal, but if it weren't for it I would never been able to switch to Linux as my primary base OS and I would have to accept the Apple/Microsoft/Google oligopoly, just like we are forced to do it at the mobile space.

In the world we build for ourselves, a worse is better mentality world.

> a worse is better mentality world.

Seems like your preferred world is the totalitarian "choose any color you want as long as it is black" one, where everything is perfectly optimized and perfectly integrated into a single platform.

> > a worse is better mentality world. > > Seems like your preferred world is the totalitarian "choose any color you want as long as it is black" one, where everything is perfectly optimized and perfectly integrated into a single platform.

Idk, I have a feeling they would be anti systemd too

I am not so sure. Both Pottering and pjmlp are German.

While I live in DACH region, my passport carries another flag.

Yep, think different.

I don't know if you are serious or just trying to evade the discussion.

Two questions:

1) What is the primary OS for your desktop?

2) Would you sincerely make the argument that a world where everyone submits to a single design (Apple-style) would be better than an "organic" world where the barrier of entry is lower, but less "optimal"?

1) Windows or macOS, depending on the project or customer provided hardware

2) Yep, the Year of Linux Desktop already happened, it is a VM hosted on 1)

(2) reads like "to be free, first you need to submit yourself to the Overlords".

I will take the minor inconvenience of having to run web apps over the dystopia you are willing to subject yourself to in the name of "optimization", thank you very much.

> The Web as a platform is far from ideal, but if it weren't for it I would never been able to switch to Linux as my primary base OS

As my old IT teacher said: you can use the browser on any OS. She also implied it requires no special skills, which is true if you are limited to the browser for the majority of the time.

So... are you saying that you are able to use Linux because all you are using is the browser?

> are you saying that you are able to use Linux because all you are using is the browser?

No, I am saying that the browsers provide a fallback for the applications that I need but do not have a native counterpart, and therefore I am not stuck with Windows or MacOS.

Without the web as a platform, I'd have to leave Linux the moment I got to a job that required Slack/Jira/Teams.

You're doing all these things with web apps also, it's just that the browser orchestrates it for you.

But for some reason this takes 20M lines of code, which creates a moat that prevents browser competition.

Any sufficiently-capable graphical application runtime* contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a web browser.

(* including every web browser)

I have wanted to try Chrome for the longest time but I cant justify overspending (you need a lot of memory for the modern web) and not being able to install half the Linux apps I would want OOTB (out of the box is a big deal for me).

I am still shocked Google has not rubbed two brain cells together and built a serious Google ChromeOS version for developers with a real desktop environment and real access to Linux, and keeping the browser as sandboxed as they have. I would spend top dollar on such a laptop. Heck it could come with an easy way to install Android Studio, and native apps for things like Hangouts or whatever they call it now.

That's literally ChromeOS now, it comes with a terminal built in and you can run any Linux apps

Without doing too much fancy stuff can I just run Zed or JetBrains IDEs?

Back when I tried to daily-drive a Chromebook Pixel it was, like, one flag in the settings app to enable Crostini and run whatever (GNU/)Linux program my heart desired, and that was many years ago; can't imagine it's gotten any harder (especially now that even Android is starting to offer similarly-turnkey Linux app support through the newfangled Terminal app).

Yes you can run them, they work well.

document browser, document reader, printed paper, paper form, return to sender... those are all in the same concept space*

"virtual machine" is clearly not

that said, i love WASM in the browser, high time wrapping media with code to become "new media" wasn't stuck solely with a choice between JS and "plugins" like Java, Flash, or Silverlight

it's interesting to look back at a few "what might have been" alternate timelines, when the iPhone was intended to launch as an HTML app platform, or Palm Pre (under a former Apple exec, the "pod-father") intended the same with WebOS. if a VM running a web OS shows a PDF or HTML viewer in a frame, versus if a HTML viewer shows a VM running a web OS in a frame...

we're still working on figuring out whether new media and software distribution are the same.

today, writing Swift, or Nim, or whatever LLVM, and getting WASM -- I agree with you, feels like a collective convergence on the next step of common denominator

* note: those are all documents and document workflows with skeuomorphic analogs in the same headspace, and newspaper with "live pictures" has been a sci-fi trope for long enough TV news still can't bring themselves to say "video" (reminding us "movie" is to "moving" as "talkie" was to "talking") so extending document to include "media" is reasonable. but extending that further to be "arbitrary software" is no longer strictly document nor media

So you are telling me I can now directly render from WASM into the viewport of the browser with a11y? Nope, then it’s still restricted to interacting with the DOM through JS or or renderings to a cavas with no a11y support or significantly worse dx for a11y because you would need to render a screen reader only document layout ontop of your actual UI, instead of just handing the browser an interaction tree and allowing it to do what is needed for screen readers.

You can write Wasm bindings to the native UI toolkit of your choice and render with that. It doesn’t have to be in the DOM.

You understand why that is exactly pointless…

I could write those exact same bindings for my language that I will compile to wasm and then use the current WASI interface, but even that is pointless because at that point I have written a native app, what good reason would I need to run it through an emulator, specifically when a modern OS is already sandboxing things.

If I am targeting the browser my above point stands, unless the DOM is already a reasonably decent API for what needs to be built(it probably isn’t, it’s the best example you can get of horrible API design in my opinion) then I will need to build something ontop of that, prime example being react.

So I need to run my code in an interpreter, having built data structures to generate a document in an eDSL, which creates other data structures, which then calls into another API, which then calls into the OS/hardware layer.

When what I want to do, is call into the OS/hardware layer directly…

> what good reason would I need to run it through an emulator, specifically when a modern OS is already sandboxing things.

One good reason would be that “Which OS specifically?” is a question with at least 4-5 mainstream answers (and even more not-so-mainstream answers). That's what motivated the push from WWW-as-a-bunch-of-interconnected-documents to WWW-as-a-bunch-of-remote-hosted-apps in the first place: to be able to develop and deliver applications without having to worry quite so much about the client platform.

WASM is in this regard analogous to the olden days of Java/Silverlight/Flash, with many of the same tradeoffs (and some of the rough edges filed down due to lessons learned around browser integration and toolchains and such).

The discussion here was building bindings for the OS layer, which means to explicitlY worry about the client platform.

When using the web I have my own issues with that platform, or more specifically using wasm in it since it is literally useless for building web based applications over JS/TS. It is being targeted more as a library platform which gets called into from JS than being an actual “assembly “ language.

>> You understand why that is exactly pointless…

I don't understand any such thing.

Modern OS sandboxing doesn't give you memory safety from Wasm's memory model or the capability-based security of WASI.

>> When what I want to do, is call into the OS/hardware layer directly…

If that's what you want to do, then I'm not sure what we're even discussing in this thread. The only safe way to run such code is with a hypervisor.

The entire point was that WASM just calls to the existing C functions, the ones you would call from literally any language.

If you care about memory safety then use a “memory safe” language that guarantees the exact same thing as what you thing WASM guarantees except without all the pointless overhead or running a sandboxed interpreter inside a sandboxed operating system process, it is actually just pointless complexity at that point.

For native development WASM gives no benefits, the only useful parts that WASM might bring literally hasn’t been standardised because it’s a real hard problem to solve and has no use in browser.

So wasm is designed for the browser and unless you only intend to embed a library in your existing JS application it is pointless because you are still restricted to the DOM.

While web apps make sense, those are pretty weak examples. Booking and buying are pretty document-based and need to run little to zero external code. The cat video isn't technically a document but upgrading a photo to a video is not a very big change and doesn't require any external code at all.

Well, that's my point. The modern purpose of the browser is for applications, and for very good reasons, namely to abstract away the OS. The problem is that the design of the browser is for documents, and is really unsuitable for applications. Applications need a UI toolkit that takes a rectangle and renders the button, whatever into it. But you can't even get a proper rectangle with DOM: a div is 100% width, which is usually not what you want, but a span is this strange thing that makes sense for text, but not for a button or slider. So everything has "display: inline-block;", which then overrides the div or span part, so that it doesn't even matter which you pick. You can't even center something vertically without doing a web search, although I guess these days you use flexbox. Flexbox at least is the equivalent of Qt or Swing's layouts.

Mind you, I think WASM is the best thing that has happened to the browser, but that's because I think the HTML/DOM is completely unsuitable for apps, and I hate developing with it so much that I won't do it, even if I have to switch careers.

I think WASM is a reasonable start to a proper virtual machine. But I think what we need is a "browser" that presents a virtual machine with a virtual monitor(s), virtual chunk of contiguous memory, virtual CPU(s), virtual networking, virtual filesystem, and basic drawing primitives, that executes WASM. The "browser" part would be that you can use a URL to point to a WASM program. The program would see itself as being the only thing on the machine (see, basically generalization of the OS process concept into a machine). The user would be able to put limits on what the virtual network can access, what parts of the OS filesystem the virtual filesystem could access, how many real CPUs (and a cpulimit) the virtual CPUs get, etc. So, sort of like a containerized Plan9. I would be happy to do this myself, but I just don't have the spare time to do it, so unless someone is willing to fund me, I'll hope someone sees this and catches the vision.

Using WASM in the web browser is a workaround.