Alan Kay on web browsers, document viewers, Smalltalk, NeWS and HyperCard (2021)
donhopkins.medium.com
donhopkins.medium.com
You could just put your binaries up for the major OSs to access your data, and people could use them in a native context.
Alas, we're in the timeline without capability based security. where users can't just give a file to a program at runtime using a (powerbox) dialog.
What is the security model you propose?
With at least two examples, please. To help me understand.
https://en.wikipedia.org/wiki/Capability-based_security
For examples have a look at the "Implementations" section.
You explicitly give it permissions to access something: give it a document you want to edit, allow it to save a result at some location (without giving it an idea what else exists at that location), allow it to connect to certain hosts on the internet, but not others, politely decline a request to use your camera, etc.
Very much like you do with a web app running in your browser.
Your customer comes to the office comes and wants to use the printer while he’s there, so you use your capability to send them a capability that will give them access to the printer (b/w only still, they can’t get color because you can’t get color) for an hour. However their capability is restricted such that they will not be able to grant anyone else access to the printer
Take $5 from your wallet to pay for a sandwich. That bill is a capability.
You can't accidentally give away your car when you do it. You can easily delegate the giving of the $5 to someone else safely.
Example 2
Take a file on a floppy disk for an IBM XT and make a backup of it. You can hand that backup disk to anyone and your original is safe.
You can use that file with any random shareware disk from your user group meeting and in no way could it cause you any more loss than the disk in it is on.
A disk is a capability.
Example 3
You are asked your location. You reply correctly.
The answer does not allow you to be tracked forever.
Example 4
You have a 15 amp outlet. You can't take down the power grid by accident, nor burn down the house. The outlet is a 15 amp capability.
Mobile operating systems (aka modern personal computing) say hello.
There is no capability security on the OS level.
Otherwise Android wouldn't have a malware issue and iPhones wouldn't need to be locked up against third party apps.
You know, the same way that you ask for code review before merging to prod.
I've liked Wikipedia on that topic already in this thread. Please take a look.
And for bystanders, here's the Wikipedia link: https://en.wikipedia.org/wiki/Capability-based_security
My reasoning was that it would be rude to link to myself, to a comment that showed up at this time just on the same screen as this one.
But I guess you're right. A link would not hurt, but make it more easy to discover the mentioned content.
>Otherwise Android wouldn't have a malware issue and iPhones wouldn't need to be locked up against third party apps.
Android malware is not as bad as what is possible with Windows malware. Over the years Google has been cracking down and working to remove permissions that apps can use without the user knowing. Unless the app has an exploit for the operating system it can't do much harm to you. iPhones have allowed for third party apps since the very first iphone a decade and a half ago.
That's not capability-based security: you have to do that whichever model is in use. The ocaps come in when you use dependency injection (aka "function call") everywhere to pass in rights to make use of resources. Neither Android nor iOS are meaningfully object-capability based.
No, that would be mandatory access control. Completely different concept.
Please remember from the first commented:
>Alas, we're in the timeline without capability based security. where users can't just give a file to a program at runtime using a (powerbox) dialog.
This is literally how Android already works today. An app can not read a random file from the system. It has to open a file selector and you have to select a file before an app is able to read it.
That's not implemented on the OS level.
Yes, it is. The Storage Access Framework is a part of the operating system.
Generally speaking, capabilities are not asked for; that would be a permission.
Capabilities can be used to implement permissions, but that's not what is usually meant by 'capability-based security'. Capabilities are essentially just inputs; a GPS-reading capability would be anything we can read GPS data from (e.g. a callback; or a pseudo-file handle; etc.).
Security is enforced by choosing who is given a capability (like a URL); we can get extra security by minting new capabilities, and revoking those which should no longer have access.
Permissions are not required to "do" things; they are enforced elsewhere, to determine whether that thing should succeed or fail. For example, giving out URLs to search engines, then trying to have the server reject requests that we don't want (AKA 'closing the barn door after the horse has bolted')
The operating system uses both capabilities and permissions.
Regardless, this is all implementation details and for the user it is equivalent. There is the same principle of least privilege where apps are limited in what they can do.
No, that's still wrong.
The Android framework uses something that goes a little bit in the direction of capabilities.
But the Android framework / runtime runs (by now) on an OS (Linux) that is not capability safe.
> Regardless, this is all implementation details and for the user it is equivalent.
No, of course not.
On a capability secure OS your mouse driver can't read the disk or do network request. Even if you would find an exploit in the driver.
That's a completely different level of security!
It's a fact that there is still no capability secure OS out there in broad use. (Fuchsia could be the first that brings this concept into mainstream. But this will take time. Also Fuchsia isn't as strict as it could be, for different reasons).
No, that are two fundamentally different concepts.
A capability is something that needs to be hold and passed to every call. If you can't show the needed capability (because you don't own it, in the sense that you're holding a special kind of object in your hands) you can't preform an action. On the very basic level: You just can't call a function because it needs a parameter of capability type.
This is fundamental different to permissions. Permissions are checked by the called code. You don't need to "pass a permission" alongside the actual action you try to perform.
Please read up at least the Wikipedia page as you seem to have some severe misconception about this topic: https://en.wikipedia.org/wiki/Capability-based_security
Capability based security means that applications are very limited in what they can do by default and need to be given capabilities in order to do something. Yes, one way to give an application a capability is by representing that capability by a token, but another way to give an application a capability is by giving it a permission.
If you want the term to refer to a specific implementation ignoring that it is identical from the end user's perspective then I'm fine in conceding.
> A capability (known in some systems as a key) is a communicable, unforgeable token of authority.
That's verbatim the second sentence on Wikipedia!
That's not "an implementation detail", it's core of the whole concept.
> Capability-based security is to be contrasted with an approach that uses traditional UNIX permissions and Access Control Lists.
> Although most operating systems implement a facility which resembles capabilities, they typically do not provide enough support to allow for the exchange of capabilities among possibly mutually untrusting entities to be the primary means of granting and distributing access rights throughout the system. A capability-based system, in contrast, is designed with that goal in mind.
That's completely wrong.
The whole point of capabilities is that they're unforgeable.
You can't mint a capability! You need to get it passed "form above". Nobody can create capabilities from thin air (not even the OS kernel).
But I'm coming to the conclusion that you're only trolling. You refuse to look at the facts and definitions, and just repeat the same nonsense over and over. I'm done here as I obviously can't help you understand this topic.
seL4 is just the core of a micro kernel. The hard part would be to build an OS around that.
Don't get me wrong, WASM is a nice idea with some nice properties. But WASI isn't a real improvement to the status quo in general.
If you mean at the bottom of the wasm, the the answer is, those won't be legacy APIs. The direction we're heading is to provide POSIX compatibility as an emulation layer on top of a cleaner foundation, rather than just doing POSIX at the base layer.
If you mean that all Wasm engines today are implemented on top of traditional operating system APIs, then yes, that is how things will often work, but that's ok. What really matters is how the virtual platform works. We don't have to expose things like "the filesystem namespace" directly to wasm, even if it's present in the host. And if we don't expose "the filesystem namespace", then we don't have the associated problems, even if the underlying host has them.
What's that "cleaner foundation"?
Next thing is: POSIX is the legacy stuff. If it's there nothing will change.
And not even to mention that the stack is going to look something like:
Hardware >> Hardware emulating some ISA (e.g. x86) >> C abstract machine >> POSIX >> VM emulating some ISA >> "container" emulating POSIX >> WASM VM >> emulation of POSIX APIs >> legacy applications written for some ISA & POSIX
I call this construct "layers of madness"… ;-)
The goal is to build a new platform. Initially, that looks like adding layers on top of existing platforms (which, as you say, already have multiple layers). If we succeed, then we get to start taking out some of the layers.
Furthermore, capabilities are more fine-grained. Today an app will ask for your location and you get to choose yes/no. If you say yes, it has full access to the GPS forever until revoked, sometimes in the background. Give it network access and it has that forever as well, and it can send anything to anyone (including the GPS data you just gave it access to.)
Capability based security would allow you to give it access to the GPS for a limited time, or to give it access to a sensor spoofing service if it really needs that data. If you give it network access it would be for certain times, or it could only send data to a whitelist of servers.
Moreover you can restrict the app from sharing granted capabilities to other apps. Or vice versa, you can delegate apps to work on your behalf and share capabilities with other apps, which you can later centrally revoke or restrict.
It’s really a better security regime than what the major operating systems have ossified around.
And lest you think you can work around this by rooting your phone, an increasing number of actually useful apps refuse to run on rooted devices, "because security", and Google is actively helping this by making available an API that streamlines those checks.
Capability-based security is a good idea, but like all security technology, it only helps the owner of a device, and who is the owner of a device in any given context is a contested topic, with platforms, vendors, manufacturers and users all having a different opinion about it.
Sure, we all want that, but we’ve learned that trusting apps does not scale. Even if you like an app and trust it, it can be updated to break that trust. Capability based security puts you in control so you don’t have to rely on trust.
> But it shouldn’t be able to send that image to a destination unrelated to my use case.
Capability based security could do this, and you don’t have to trust anyone to implement that feature for you (or to not silently remove it via an update). You would create a capability that would require camera and network access. Any app that needs both resources could take such a capability and be restricted in where it can send photos.
Phones don't do capability based security. There's no way to say, here... you can have access to THIS photo, or this location, once, in an easy way.
On PCs, you have to trust the application to do what it says when it uses the system supplied dialog boxes to "open" files, etc. In a capability based system, that's not the case. The OS never trusts the application, ever.
"Give X permission to access Y forever" is not capability based security.
https://www.youtube.com/watch?v=kFRy4IwUNog
Phones do not do capability based security, they could, but they OS doesn't offer that as a possibility, we get the low rent knock-off imitation instead.
We keep layering more and more gloop on the web. It will always be a game of wack-a-mole.
It's like Windows requires TPM, but then gives itself permission to snoop at your files. Or we have oauth, but then github is cracked to reveal the private keys. And so on and so forth, etc. ad nauseam. The clowns at Microsoft, Facebook and Google simply can't be trusted. They've proven that time and time again.
Security is better obtained "via negativa" (to quote from Taleb). Be parsimonious in what you allow. Keep things simple. If you don't really need security, then don't have it.
What Java was trying to do with RMI, classloaders, etc was a lot closer to this vision because in that mechanism you could actually receive over the network a full object with both code and data, in which the actual underlying data structure was something you'd never seen before but it didn't matter as long as it implemented an interface you recognized, because the code to process the data came with it. This vision hit a number of practical engineering problems, most obviously security and less obviously the pervasive assumption of flat fast LAN-like networks that the CORBA/RMI/DCOM/etc people kept making.
The web won out over this vision partly because it was simple enough to reimplement. When Tim Berners-Lee didn't have the resources to take it to the full potential (not even having proper inline images) NCSA Mosaic took over, then Netscape took over from them, then Microsoft from Netscape, then Chrome/Safari from Microsoft. The history of the web is basically a history of failed business models up until Google decides to just subsidize the whole thing in order to drive search traffic.
The only major difference between what I was doing with RMI/CORBA and DCOM and now, is the tooling and the protocols.
Everything else, IDL files, schemas, boilerplate generation, client SDK to wrap boilerplate code,.... is just the same story with a different dressing.
REST works because it's stateless message passing (no object state), supports one-way connectivity (no dialback), the tooling was much better (no equivalent in RMI/CORBA/DCOM to a transparent cache or a load balancer), HTTP/1.1 is easy to understand and implement (or looks easy at least) so every language can have get on the stack very fast, it has auth systems that work, it's more layered/incremental because it leaves language and type system mappings to higher layers, and so on. Lots of valid reasons.
SPAs etc. are insanely complicated and complex attempts to bend this into something it's not, and can never be.
The reason people are so excited about WebGL and upcoming WebGPU is that they will be freed of constraints of this model (but forget about the constraints of doing low level graphics)
In all these years, accessibility has only been part of UAT for goverment related projects.
sure it's true that most countries only have for government related projects, but that doesn't mean that there aren't enough important markets where that isn't the case.
As per experience, anything that isn't legally binding usually ends up not being part of project requirements.
Not to mention that readers left to their own devices tend to chose stupid unoptimized color schemes and font sizes all the time, hurting their readability and lowering their reading times...
(of course for disabled readers it makes sense to be able to set to whatever suits them, but those also need sensible defaults for their case, perhaps even more so than abled readers, as it can be more difficult to them to change configurations)
... thus reducing their exposure to our content marketing texts and/or ads embedded on the page, thereby impacting our bottom line!
I think it's safe to assume most people capable of choosing "stupid unoptimized color schemes and font sizes" are also capable of iterating on their choice, or reverting to the better defaults, when they feel the reading experience of things they want to read worsens.
You'd be very surprised
This is wrong.
The first thing Gutenberg printed after the prestigious bible (which not only resembled previous bibles, but surpassed them all in respect of the regularity of the printing types), was the Donatus, Aelius Donatus' Latin Grammar book "Ars minor". This was a standard text book of the time. It was short (aprox. 30 pages) and extremly popular: There were at least 24 editions published until 1468.
From 1454/1455 we have indulgence certificates, which shows that the printing press was immediately used for cheap mass production, were "precious hand made things" were of minor improtance.
The next things Gutenberg printed (1455/1456) fell into the "news and politcal pamphlet" category: a 6 page long Calendar Against the Turkes ("Eyn manung der cristenheit widder die durken") and a 25 page long German translation of a papal bull also against the Turks.
It’s not that people didn’t catch on to the idea that the printing press could make books cheaper/more portable because they weren’t so laborious to create. That much was obvious about its utility.
Kay’s point as I remember was that, at least initially, automation of previous tasks is all they wanted to do with it. They got this great new machine that opened up tons of possibilities, but all they used it for was to make faster the same thing they were doing before. But we all know rather than saving some monks some time, what the printing press really did was fundamentally transform society. That’s what people missed, and it’s something people keep missing about transformative technologies, even today.
In his book Mindstorms (which every programmer needs to read), Seymour Papert makes the same observation about computers when they were introduced in classrooms; he says that instead of unlocking the full potential of those machines, educators just used them to automate activities they were doing before - times tables, essay writing, drawing graphs, etc. Very few people realized the potential at the time, and most still don’t.
How smart watches display the time, VST instruments (e.g, https://mixedinkey.com/captain-plugins/wiki/best-vst-instrum...), ebook "pages", on-screen keyboards, visual-coding environments that use a "cables" metaphor (e.g., https://twitter.com/robenkleene/status/1280182525013475330).
I actually think the lesson here is that if you can take a metaphor from the physical world, and can incorporate it's essence into your digital design, it'll probably improve your design. And I don't think the reason is because we're leaning on our familiarity with the physical world (too many purely digital designs have proved successful for that to be the case). I think the reason is simple: Our brains are evolved for the physical world, and we've had thousands of years to master building things with physical materials, so the human race has created truly fantastic interfaces in the physical world. If we can bring the essence of those designs into the digital world, we should.
[1] https://tinlizzie.org/IA/index.php/Talks_by_Alan_Kay
[3] https://vpri.org/writings.php
[4] https://tinlizzie.org/IA/index.php/Alan_Kay_at_Xerox_PARC_(1...
These attempts ran into problems around openness (one company did not want to promote another) and friction with resource contention of the host operating system. For example rich web media needed to be tightly coordinated with iPhone development for performance concerns and to force publishers to retool for mobile experience.
I don't think we have sacrificed so much in possiblity once you weight the constraints of the time and the world of possible today. Device monopoly and app store becoming what they became is probably not something the open web could have prevented even if there was more holistic vision for web tech up front.
Again, the inability to run untrusted code thwarts progress.
Imagine if you had to grant access to your wallet forever to spend a $5 bill. Cash would never become a medium of exchange.
We need general purpose computing that gives no access by default to anything. Just like me and my wallet.
If the web was being made form scratch today, it would probably start with a repurposed game engine.
It's not clear that this is true. Smalltalk and Hypercard existed before the Web. The Web started with static HTML because its vision was based on static documents, not apps.
That said, a network enabled Hypercard would have been a security nightmare. It was way too complex to secure given coding practices of the time. Heck, even "simple" web browsers had a reputation as a security weak point in the early days. There were no end to people who thought integrating the web browser with the OS was pure lunacy that was going to result in an endless string of compromised machines. Luckily "live desktop" and the like ended up being such weak features that they didn't have quite that much impact.
Fortunately OS and web browser developers didn't really consider that to be a big problem so they did it anyway and implemented a system that downloaded random code from the internet and happily executed it in a non-secure sandbox on top of an OS filled with exploitable security flaws. See: Java, Flash, JavaScript, webasm, PDF, canvas, etc.. Not that it mattered too much anyway since media and HTML renderers were already exploitable.
Doubtfully, for the same reason that VR is still looking for a general purpose problem.
Visual metaphors are great when demonstrated visually (e.g. in futuristic movies), but their information bandwidth sucks compared to text et al.
Or to put it another way, how many emojis would it take to convey the content of this post reliably?
Holy false dichotomy there, Batman!
VR had some problems in the first batch of devices with low resolution, but as resolution improves there's no reason why it can't be integrated as first-class in it.
There's no need for the structure of the text to be a long linear sequence. When you put together a sequence of more than a few paragraphs, it is convenient to group them into a text chunk under a headline; and in fact these chunks can be placed in non-linear structures such as trees and networks, which benefit from a visual representation. The 3D environment of VR would allow better manipulation of these structured text structures in space, compared to the limited 2D possibilities of minimaps and tables of contents.
Like the html canvas or webgl/webgpu?
I think it would be cool if you could encapsulate chunks of canvas drawings as components and have native dev tools for inspecting, debugging, etc.
Or were you mostly implying that the web would have been more immersive (3D) from the start.
I think more of a full flagged game engine. With all the bells and whistles.
> I think it would be cool if you could encapsulate chunks of canvas drawings as components and have native dev tools for inspecting, debugging, etc.
Have a look at how modern game engines with their editors work.
So does Unity and Godot.
I still hold that reinventing the underlying operating systems' text rendering and text input is almost always a bad idea. Some things this "game engine" would need to work with the underlying operating system to solve:
- Accessibility (screen readers, etc)
- OS-specific text kerning behaviour
- Ligatures (including for Arabic and Korean text)
- IME for Korean / Chinese / Japanese / etc.
- Right-to-left and left-to-right language support.
- Input events on every platform. There's about 20 keyboard shortcuts to interact with text on windows, macos and linux. They're different on every platform. iOS / Android are different again.
- Native scrolling
There's probably more. Its an obscene amount of work to reimplement this stuff correctly on top of a game engine-like API like Canvas. The browser already does almost all of this work and despite that its still a ridiculous hassle to implement web-native rich text editor components. (Though we may disagree on why).
As a developer, there are a lot of advantages to having your application behave in an identical way on every platform. But as a user, I don't actually want that. I want your application to fit in with the rest of my operating system. (Be it windows / macos / linux+GTK / iOS / Android).
Mind you, Raph Levien is smart and as I understand it, he disagrees with me on this. Here's a video of him talking about it: https://www.youtube.com/watch?v=zVUTZlNCb8U
First, browser engines do reimplement most of this stuff, though that's been an evolution, it used to be they relied a lot more on platform text layout, for example. And for the stuff that's not completely reinvented (accessibility), they have a put in a lot of work to make cross-platform abstractions. In many cases (interfacing with the compositor comes to mind), browsers are the only viable open source code bases you can read.
Second, to a large extent OS platforms are stagnating. UWP was going to be a big advance over the old WinAPI ways of doing things, but it ended up being a dud. SwiftUI has performance problems for a number of reasons, including the fact they're still using software rendering for a lot of stuff, and their compositor model requires allocating huge amounts of memory for intermediate textures for all their UI elements.
Third, the business structure around platforms requires them to each do things differently, which creates gratuitous incompatibility. You really only need one high quality library to do, say, text layout, rather than having slightly different and slightly incompatible versions on each platform. (And very few places are gratuitous incompatibilities more frustrating than GPU infrastructure)
So for these reasons, I do believe it's worth exploring a new cross-platform GUI toolkit. It is pretty speculative, though; there are lots of ways it could fail.
Game engines are decent at a lot of this stuff, of which of course GPU infrastructure (and graphics rendering in general) is quite good. Most of them could use work in the text department though :)
The amount of work to do this well is high. Probably (easily) measured in engineer-years. All to reimplement something that - janky as it may be - already exists in some form in web browsers. But as you say, worth it if we can pull it off. But it’s a common good. The hardest part in my mind would be figuring out how to fund a project like this.
My ideal application platform isn’t a video game engine. It’s probably something like electron, but with most of the browser stuff stripped out. (Dump javascript, the game pad api, midi, usb, Bluetooth, tab isolation, and probably the DOM. And use Houdini or something instead of CSS). And then I’d happily swap the rendering for pietgpu or whatever will perform the best on modern platforms.
Basic desirada: Small and light, fast, cross platform and platform-native look and feel everywhere. Accessibility, IME, localisation, rtl- and ltr- language support, and so on.
Mobile is still a big question. But solvable if sufficient engineer time was poured into it. It’s just a big project.
Now, I freely admit that many applications don't need that much performance. But I think having a toolkit that is optimized along those lines could be a good basis for doing work on the other things (developer experience) that make a toolkit great.
I think the Jetpack Compose guys have plans to multi-thread composition, and they already do it incrementally.
JavaFX has a reactive/observable properties framework where you can build chains of lazy computations which update only the part of the UI that needs to be changed, this is then propagated to a parallel render thread that runs concurrently with the app logic. They originally wanted to further parallelize the render thread via tiling, but never did so.
Performance problems obviously still occur, usually when trying to do complex layouts with lots of measurement.
Depends on the users I guess. Mine are really adamant that they want the exact same app no matter the OS. The OS is just a tool to launch actual productivity apps.
But than I read "Metaverse" on the front page. So it's something like Web3, I guess.
It's a little bit off-putting when someone jumps on the "Metaverse" train.
But OK, maybe I should have a second look despite this marketing stunt.
[1] https://www.youtube.com/watch?v=1s9ldlqhVkM
[2] https://scholar.google.nl/scholar?hl=nl&as_sdt=0%2C5&q=alan+...
[3] morphle at ziggo dot nl
I came to the exact same conclusion.
Modern browser work anyway like a game engine as that's the only way to be fast with rich interactive content.
https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-f...
We would just need to get rid of all the HTML / HTTP baggage (JS as such is OK-isch as scripting engine, but could be any other VM also of course; and CSS has great utility everywhere, so it's not web specific). Than switch to some sane RPC protocol for networking (as all the "RESTfull" stuff today is anyway only badly made RPC in disguise). Such client-server protocols are actually also already available in game engines because a lot of online games need super efficient real time communication. Efficient content distribution and client self-updates are also part of game engines.
I start to consider Godot as an application framework, to be honest.
A usual (completely self contained) GUI app with networking is only a few MiB, is supper snappy, and does not need much resources at runtime. The engine and it's editor is really nice to work with. You can finally again click together an UI with the editor. Like in the good old days.
RPC is a dumb protocol because it tries to abstract away the necessary aspects of "remote" as if they don't exist.
REST APIs done correctly are great because they expose the possibility of network failures and partitions, allow for idempotency (GET doesn't change stuff), caching and all of the other things that the architectural style offers.
RPC doesn't have that.
RPC is a broad concept, even farther from a protocol than REST, which is an architectural style.
> because it tries to abstract away the necessary aspects of "remote" as if they don't exist.
Generally, it does not. There are some languages/frameworks/other technologies that have been promoted on the basis of transparent RPC or distribution across machines, but that’s not the normal case of RPC.
> REST APIs done correctly are great because they expose the possibility of network failures and partitions, allow for idempotency (GET doesn't change stuff), caching and all of the other things that the architectural style offers.
More accurately HTTP has all that, and REST layered over HTTP gets it for free from HTTP, while many RPC approaches (though this is not inherent on “RPC”) over HTTP would, e.g., tunnel all actions over POST and reinvent distinctions between safe/idempotent/neither operations if handled at all, within the RPC protocol, and would require specialized caching mechanism for things that are cachable, not HTTP caches. Or, worse, do the same thing but tunnel over GET.
This is a brilliant prompt, for discussion / thought provocation.
My answer is: start with a reliable system for exchanging CSV files. Add a few extensions and boom, everything’s possible.
(Besides the insanity that correct parsing would need network access, it's mostly very sound).
The web is such a complicated mess right now that I wish we would revert to it being just a document-based format. That's why I'm interested in things like gopher. Gopher pages can look surprisingly good.
I ye olden days there were BBSs (Bulletin Board Systems). It is stateful and all the heavy lifting is done server-side.
Possibly. But I dont think such a “web” would be anywhere near as successful. It was critical for the success of the early web that anyone would write a webpage in notepad and link to other pages.
https://en.wikipedia.org/wiki/OpenDoc
Some good discussion from 2021: https://instadeq.com/blog/posts/why-opendoc-failed-and-then-...
https://apple.fandom.com/wiki/OpenDoc (the links at the end are better than the page)
https://www.wired.com/1997/03/closing-opendoc-a-great-leap-b...
truly incredible in a sense
I do very little on the web where I actually want there to be code running on my document.
Just some random examples, but how do you do your tax, pay your bills, buy/sell stuff online, make appointments etc?
Some things yes client side code makes sense, like an appointment finder, and that’s fine, but such things make up a tiny amount of my internet activity.
Or just a proper GUI framework not based on HTML.
Emphatically no. The absolute vast majority of those "polished dropdowns" are horrible to use, and break all possible platform conventions (for example, not accessible or usable with a keyboard)
> countless other controls you interact with every day require javascript.
Very few, if any, "polished controls" used on the absolute vast majority of web sites require javascript.
"Dropdowns are toggleable, contextual overlays for displaying lists of links and more. They’re made interactive with the included Bootstrap dropdown JavaScript plugin"
- don't follow platform conventions (don't trigger the actual system dropdowns with actual expected behavior)
- get cutoff by browser chrome when page is zoomed in (because you can't control that behavior from JS)
- default implementation's touch targets are too small
And that's for a framework which has had over a decade to make this work.
This is not to throw undue shade: they've done a very good job. But that's about as far as you can get.
I got one can do without the "polish I am used to". I'm generally fine with HTML form controls.
My problem with JavaScript frameworks is they are huge beasts that build their components out of non-semantic block elements. A button or text field is just a giant mass of divs and spans with events attached everywhere with one-off CSS. The browser is stuck doing tons of work in its single-threaded JavaScript engine to build and manage these components.
It's a lot of wasted memory and clock cycles to recreate a text field the browser already provides. It makes for a worse user experience, wastes my battery, and eats up my bandwidth. To me it's not polish but waste.
Regarding the massive nestings of divs. Well this is computer generated HTML. It is ugly as hell, but browsers are well geared up to deal with it, it doesn't create any serious performance issues unless taken to stupid levels. The other side of the coin, with this rather ugly generated HTML, is you get a human benefit, a time saving efficiency. You can spin up a web page with React/Bootstrap in a fraction of the time it took you in the 1990s.
If you think about that maybe you come also to some conclusions regarding the questions you just asked.
Maybe even Smalltalk in the 80s if Kay and company had foreseen the rise of the global internet back in the 70s.
Ironically, for all the fragmented wild ecosystem of webdev today, with a million different libraries & toolchains & frameworks, the web has maintained & iterated on a very consistent & coherent underpinning that is fundamentally cross-computer, that is globally connected via the url. Applications were always a lesser beast, damned by lower horizons, and if they dared to try to do more, were on their own with no other applications to interoperate across & on their own with their protocols. The web grew many UI development options atop consistent DOM and protocols, but the application had consistent UI development options across scattered connectivity protocols, if any (and often none).
Looking at the internet as an application delivery platform ignores that the web grew because it was both an application and content delivery system, interwoven, together, and infinitely remixable & extensible.
Personally I almost wish that the majority of sites out there didn't pretend like they need to be highly dynamic, interactive and inevitably wasteful experiences.
It had nothing to do with a quest for better performance. It had everything to do with ad impressions.
Why not both? Even if the former was the "public justification", AMP pages still performed better than bloatware-ridden websites that otherwise took 2-10 MB to load, not even mentioning the amounts of JS and the impact of it on performance, especially on mobile devices (as well as batter usage on those).
The only reason it performed better is because Google would preload over 1MB of Javascript needed to run AMP on its search page.
A cold start for AMP was barely better than most of the top sites that used it.
It was cheating, pure and simple.
Edit: IIRC it was also preloading the entirety of the search carousel, too. And you could get into the carousel only if you had an AMP page.
I wonder what he actual metrics are for how often that was used, what % of people chose one of the AMP results, because those were at the top of the list. That preloaded data might be common for most of AMP pages, which is much better than the mess of each site having different React/Angular/Vue bundle versions or even jQuery versions back in the day.
As a thought experiment, I wonder how much we could save on bandwidth, if all of the "popular" frameworks/libraries split their base code from each individual application's code (we already have code bundling, after all) and browsers included all of those packages of base code, preloaded.
Maybe even follow SEMVER as close as possible, so the browser can always ship the latest minor/patch release for a given major release, to cut down on space needed in the browser.
Something along the lines of:
<script src="/browser/react@18"></script>
<script src="/js/my-app-react-bundle.js"></script>
<script src="/browser/react@17"></script>
<script src="/js/my-older-react-bundle.js"></script>
After all, browser install sizes are already horribly bloated, a few dozen MB will hardly matter at this point, whereas each site needing 1-5 MB of JS is absurd, especially because those are re-downloaded for each of them, despite the fact that most sites out there use one of like 3-5 popular solutions.
My wife has a MacBook Air that doesn’t even have a fan.
This is incredible!
> enough maturity to implement essentially an entire operating system / virtual machine AS the browser
Yes, an operating system-- but one without user-facing persistence! Only per-application, networked, silo'd persistence, where the user sees a rendered form of data but not the data itself.
IMHO these two facts, that
a) Web browsers are BETTER than Linux, Windows, etc as an OS in a very important way, package management
and
b) They're missing one of the primary features of an OS, persistence
overshadow any other facts about them. What a strange tool they are.
You can copy and/or edit said data from that view as well!
Albeit the convention is clearly to not presume your browser app user will be interacting with their data at _all_ through the devtools, which I find regrettable but unavoidable with the current state of "computer literacy" and the state of "devtools-as-an-interface" (obviously the ergonomics aren't great for the average user today).
Eg take web forums (not this one since there's weird lisp stuff down there and I don't know how it works, but the average web forum).
On the app (server) side they have access to everything, all of your posts in nice beautiful structured SQL.
On the user side you have access to none of that, just HTML soup and maybe some cached stuff in the "Storage" tab, or maybe not.
> Albeit the convention is clearly to not presume your browser app user will be interacting with their data at _all_ through the devtools, which I find regrettable but unavoidable with the current state of "computer literacy" and the state of "devtools-as-an-interface" (obviously the ergonomics aren't great for the average user today).
I really like your use of "convention" and "presume" here, because I think that's the essential lens to view these things through. It's absolutely possible for an app to provide all of a user's data in a nice structured form in IndexedDB, that will just be rare because it's not the convention.
Back in the day, we didn't even have modems or compilers, let alone internet - so we would go to Ye Olde Computer Store and copy the disks of Fred Fish. That was how I got my first experience of Hack, which was great, and Emacs, which has always been a WTF for me.
I wonder if for some reason computer hardware had stopped getting faster and more complex at the stage of, say, a 25 MHz 486, how much different the world would be, or whether it would just force software to be consistently purged of cruft.
Back in the day there were several P-Code aware platforms.
Alan Kay shows the beauty of HyperCard (the “loser” in networked hypertext) vs Web. We had in HyperCard a visual hypertext app dev and reading environment that was trivially programmable / writeable in some very powerful ways for any determined user, using a GUI authoring tool. Now what do we have? Yet another Algol like programming language whose capabilities are severely constrained — and more importantly which is is not remotely a realistic user authoring environment, hell even paid professional programmers have trouble keeping up with JavaScript, the browsers as dev platforms, and the surrounding tooling/libs.
More broadly, it’s dismaying how rapidly and seemingly permanently our collective expectations as developers have fallen. Kay is right: What we have in the web stack is not enough and we should not settle.
A quote from Kay I enjoyed:
“You have to include all media that computers can give rise to, and you have to do it in a form that allows both “reading” and “writing” and the “equivalent of literature” for all users.
“Examples of how to do some of this existed before the web and the web browser, so what has happened is that a critically weak subset has managed to dominate the imaginations of most people — including computer people — to the point that what is possible and what is needed has for all intents and purposes disappeared.”
It’s also amazing what we settled for in networked computing when I read his notes in this system from 40 years ago:
“ perhaps the best early structuring and next stage design of Unix was Locus by Gerry Popek and his researchers at UCLA in the early 80s. Locus allowed live Unix processes to migrate not just from one machine to another on a network, but to a variety of machine types. This was done by combining the safety required for interrupts with multiple code hooks in each process, so an “interrupt” could allow the process to be moved to a different machine and resumed with different (equivalent) code. ”
My personal take on this is that need to make the data layer in computers transparent.
Files are currently opaque sets of bytes which need an application specific parser to interact with them. And when you have programs that can interact with a file, the only operations are read and write. Realistically, you can only have one program editing a file at once. Even having multiple programs reading a file at the same time is often a bit broken.
Instead, what if files were structured (think JSON or SQL). And instead of overwriting the file when you hit save, the application could send granular updates to the files’ content as edits happened. (Eg update Foo.bar.baz = 22, or the sql equivalent). And applications listen for changes in the data model, so another application (maybe on a different computer)! Can edit something in the file, and the changes get propagated live.
There’s all sorts of benefits to this:
- We can enable collaborative editing in all applications for free
- It’s super easy to make plugins for applications - just make another program which interacts with the data. No plug-in api needed.
- The Unix philosophy is strengthened because multiple small programs can work with the same data at once. We can split out IDEs into a lot more small tools.
- Users have lots of devices. This sort of thing would make data able to move between their devices in a way that’s transparent to the application. Like live collaborative editing Dropbox.
We need CRDTs to do it properly. But the technology behind that is more or less solved at this point.
Honestly I think the hardest thing will be getting OS people on board. I think it’s about time we shook up how the filesystem works. open/read/write basically haven’t changed in 50 years.
When Cairo fizzled, the database file system became a separate component called WinFS but didn’t result in any end-user product:
The OO database storage project was apparently Bill Gates's personal baby, so it didn't lack in executive support. That probably explains why the dream was kept alive for over a decade (Cairo started in 1991, WinFS was finally left out of Vista in 2006).
Steven Sinofsky's interesting online book "Hardcore Software" has some chapters about Cairo and later WinFS:
https://hardcoresoftware.learningbyshipping.com/p/020-innova...
"Cairo aimed to advance personal computing with dramatic changes in how we thought of files—rather than single files and folders, Cairo intended for files to have the capabilities of a database. Everything on your PC was to be stored in a database to easily search, find, and show relationships between items: files, email, contacts, photos, documents and more. Advancing storage was a long arc of innovation Bill favored.
"Ultimately, the human toll of Cairo was high in the sense that so many people spent so much time early in career working on a project that not only didn’t ship but was viewed as squandering resources, at best, and misguided at worst. It was a bit of a black eye for Microsoft among the press and analysts who believed Microsoft would deliver on the idea of object-oriented the way that NeXT had done but at scale. The magnitude of the project would leave many people with Cairo war stories for years to come. I wish I could say that the lessons learned would prevent another experience like this from happening, but that isn’t the case as we will see."
Collaborative editing is too much to bite off at once. The semantics of edit conflicts are very app specific and high level. You can get a long way by just hooking file IO in userspace.
I've been working in the collaborative editing space for over a decade at this point. So (predictably) I think it should be a day 1 feature. In my mind realtime collaborative editing is one of the main motivating use cases for this whole system - its one of the things we can't do with traditional local file based software architecture.
Based on my experience with collaborative editing I don't think you need a special app-specific conflict resolution strategy most of the time. I think about 95% of applications just need CRDTs for:
- Tables with editable values. (Or, equivalently, collections of JSON objects). I think an MVRegister is the way to go here.
- Text
And then the longer tail of apps need:
- Generic sequences (eg for the list of layers in photoshop)
- Rich text documents
- Text with conflicts (eg for Git)
For editing regular data, MVRegisters are the star of the show. MVRegisters - aka Multi-Value Registers usually just store a single value. If two users concurrently set it to different values, when you do a read operation you can either (consistently) choose a single winner, or present the application with all of the conflicting values and let it choose how to resolve the conflict. Its the best of all worlds in my mind - because conflicts are rare in practice, and this lets application developers start simple and make their apps more complex over time as they desire.
MVRegisters are also crazy simple to implement.
Even more maddening since AppleTalk was a simple, cheap and effective way to network Macintosh's.
For context: Alan himself invented WYSIWYG at Xerox PARC. He was present at "the mother of all demo's" by Douglas Englebart [9]. Ted Nelson who invented bidirectial hyperlinks 'outside of the file' and Xanadu [6,7] got Alan in touch with his future wife [2] and Alan was there at Apple when Bill Atkinson made Hypercard.
He mentions that when he told Tim Berners Lee about the much better previous designs of Douglas Englebart, Ted Nelson and Alan's group at Xerox PARC, Tim was chagrined (that he had not read any of the papers about earlier and much better designs of 28, 25 and 20 years before the WWW browser in 1993).
Of course Alan also discusses how the web should have been done. In short, it should be that when you click a hyperlink you load a virtual machine in a secure sandbox of a Operating System Kernel. The virtual machine would then render the (bitmap or vector) pages. Operating System 101, well known in 1965. Of course, Alan's team did implement this (several times). I can demo all this software if you contact me. I also give lectures on this.
Email me at morphle [at] ziggo [dot] nl for a video where Alan Kay, Douglas Englebart and Tim Berners Lee meet and talk about this at a forum discussion. You can ask me about anything related to Alan, Ted or Douglas, I maintain an extensive archive with all scientific papers, emails, talks, interviews and lecture video's.
Alan, Ted and Douglas worked closely together and where friends. TED's beautiful eulogy [3] for Douglas is a wonderful speech where he bitterly indirectly refers to the ignoring of Douglas' work by Tim.
Alan made a demo with Apple in 1987 on what the WWW should be able to do [4,5].
[1] Normal Considered Harmful https://youtu.be/FvmTSpJU-Xc?t=963
[2] Alan Kay's tribute to Ted Nelson at "Intertwingled" Festival https://www.youtube.com/watch?v=AnrlSqtpOkw
[3] Ted Nelson's Eulogy for Douglas Engelbart https://www.youtube.com/watch?v=yMjPqr1s-cg
[4] https://www.youtube.com/watch?v=9bjve67p33E
[5] https://www.youtube.com/watch?v=umJsITGzXd0
[6] https://www.youtube.com/watch?v=En_2T7KH6RA
[7] https://en.wikipedia.org/wiki/Project_Xanadu
With text-only browser I can fly around the www and consume information at a speed that is just impossible with a "modern" browser. No auto-loading resources, no pre-fetching, minimal headers, no user-agent, no cookies, no Javascript or CSS, and so on.
In the "modern" browser one ends up with an ever-growing number of tabs. In text-only browser I have no tabs. Yet I have a complete navigable browsing history of content URLs.^1 I have enhanced this with a TLS proxy that records every URL. In a "modern" browser any such comprehensive browsing history generally becomes a liability, along with cookies and too many other things. And the history would be cluttered with auto-loading URLs for no-content URLs that must be filtered out Too complex. Too much work.
I'm in textmode most of the time, the "modern" browser generally cannot operate there, so it is of limited utility. Even just the sizes of the binaries for "modern" browsers are absurd. Chrome is like 150MB. To try to compile a "modern" browser is, IME, more difficult than compiling an entire UNIX-like operating system. Many folks simply refuse to even try or just give up.
One can still download W3C's line mode browser from the 1990's, it will still compile and it still works. I use a curses-based browser but I still do many HTTP requests using nc or similar along with localhost-bound TLS forward proxy. HTTP/1.1 pipelining for bulk text retrieval is a favourite feature of the www and that cannot be done inside a browser.
1. "Content URLs" here means URLs pointing only to pages at the domainname I entered, pointing to pages with text content that I can read, not stock images, pixels, ad servers, telemetry and other garbage.
I personally use w3m for many things, including HN and viewing links from HN (if the website permits it).
It made me sad, particularly because an organization like that can't really afford Apple prices and yet they also can't afford an IT department which is probably why someone bought it originally figuring it would "just work".
I realize in principle I could've installed Linux on it, but didn't see any point.
My experience with small (non startup) organizations, meaning under a dozen people, is limited, but it's led me to believe that every role in that situation is like being a high level executive, only without the pay of a big corporation or an assistant (other than the volunteers...).
They might have had a place for me if I had been able to wrangle their hostile service provider, but doing technical things wasn't what they needed. I couldn't even start if all their servers and their network were under the control of someone who wouldn't talk to me.
They would've been happy if I could've dealt with their domains, and everything else related to IT, but at a administrative/managerial level - it was entirely about talking to people, and I was keenly aware I didn't know where to start.
The browsers didn't stuck being document viewers. HTML that stuck being a document format.
I cannot remember all the interactions and conversation topics I had two weeks ago or explain in detail how an issue got fixed or what its root cause was. It feels to me as if things happen so fast today, that my brain drops old information the moment I consider it done to make room for all the new information.
Is there a trick or technique to it [1] or is his brain wired differently with higher neuroplasticity?
=== [1] I do use bullet journaling for example. It helps to stay on top of the gazillion things that need my attention, but feel it makes matters worse in the regard as I offload stuff and my brain knows it can forget about it ever more.
Some stuff gets a lifelong spot in your brain, some are week long refugees.
When I get old(er), that's how I hope I'll be: delighting in new experiences, even when they're old.
Put it another way, your focus might just be elsewhere. Holding bags of knowledge perhaps in more disperse ways, or on other topics. But these conversations Kay has, and the thoughts and plans he's made around them... that's kind of his whole thing.
The difference between you and him is that you (rightfully) doubt your memory while he doesn't doubt his.
I think you are more likely to be correct than him.
I love how James gently humors the standards guy (P. Bono) who suggests he should have considered the glorious "CGI graphics model" (Core Graphics Interface) standard, and seems incredulous that he is "ignoring the standards" by choosing PostScript over his favorite standard of the day in 1985, CGI.
My favorite quote is: "There is really nothing new here. It's just putting it together in a different way." -James Gosling
SunDew - A Distributed and Extensible Window System, by James Gosling: Discussion
http://www.chilton-computing.org.uk/inf/literature/books/wm/...
5.4 DISCUSSION
Chairman - George Coulouris
Williams: What is the scope of the devices you are considering? I don't suppose you intend running the window manager on a graph plotter.
Gosling: The crudest display we are willing to accept is 1 bit per pixel black and white but we also support 8 or 24 bits per pixel colour or 4 bits per pixel black and white.
Williams: Essentially bitmap raster devices.
Gosling: Right - although when you get to grey scale devices, things stop behaving in a model that is comfortably compatible with RasterOp. You have got to be able to deal with antialiasing, such things as subpixel positioning begin to make sense. It makes sense to draw a character midway between two pixels because you can use antialiasing to shift the character over by subpixel amounts.
Bono: When you use the word PostScript, do you mean literally that PostScript is in some way your virtual machine instruction set? It has not been extended or generalized?
Gosling: It has been extended. It is a superset. We are committed to implementing everything in the PostScript telephone book that makes sense. They have a few commands that are particular to their storage allocation and to the fact that they are going to a printer and these are not implemented. We have imported some things that are peculiar to a display and a small number of incompatible changes to the language have been made which we spent a long time talking to the people at Adobe about to make sure that was reasonable. In particular, we added garbage collection and lightweight processes. There are very tiny ways in which the semantics of PostScript's memory allocation strategy shows through in the printer version because they have a quick and dirty storage allocation mechanism and that wasn't really useful in this system.
Bono: The virtual machine was not virtual enough.
Gosling: Right. When we made the generalization to multiple processes, their storage allocation mechanism just completely broke and so we had to use garbage collection instead and that necessitated some small semantic changes but they are not things you are likely to see. All of the important things such as how you specify a curve, whether you can render an image rotated 37 degrees, all of that is there or intended to be there.
Hopgood: How do you handle input?
Gosling: Input is also handled completely within PostScript. There are data objects which can provide you with connections to the input devices and what comes along are streams of events and these events can be sent to PostScript processes. A PostScript process can register its interest in an event and specify which canvas (a data object on which a client can draw) and what the region within the canvas is (and that region is specified by a path which is one of these arbitrarily curve-bounded regions) so you can grab events that just cover one circle, for example. In the registration of interest is the event that you are interested in and also a magic tag which is passed in and not interpreted by PostScript, but can be used by the application that handles the event. So you can have processes all over the place handling input events for different windows. There are strong synchronization guarantees for the delivery of events even among multiple processes. There is nothing at all specified about what the protocol is that the client program sees. The idea being that these PostScript processes are responsible for providing whatever the application wants to see. So one set of protocol conversion procedures that you can provide are ones that simply emulate the keyboard and all you will ever get is keyboard events and you will never see the mouse. Quite often mouse events can be handled within PostScript processes for things like moving a window.
Sweetman: How do windows relate to canvases?
Gosling: I did not use the word window because its overloaded with all kinds of semantics. Does it have a border? All that a canvas is, is a thing on which you can draw. It is not even rectangular.
Sweetman: Do you see canvases on your display?
Gosling: Yes you can. A canvas is a thing on which you can draw. It might be visible on some display and it might not. If it is visible, you can specify its position in a 2.5D coordinate system. It is opaque but you can get a transparent effect if you want something to show through a window, by cutting a hole in the window.
Williams: You say clients have to accept redraw commands. Is there any indication as to how soon they are supposed to do them?
Gosling: The client can ignore the request if it wants. The screen image will look a little funny. Or it can wait half an hour - it does not affect the integrity of the screen. It will affect the integrity of its window but nothing else because all the canvases are maintained in apparent isolation from each other.
Williams: Will the visual image just contain what was there before?
Gosling: You can do that, if you wish. For most applications it does not make any sense to retain the old bitmaps so you might as well just blow them away and replace them by whatever is most convenient - which is probably what was there before. There are some times when you would like to retain the old bits - that is there as an option. I really want to make it difficult for people to exercise that option as it is a very tasteless thing to do in general.
Bono: I hope I am not being overly opaque about this but it seems like I have a sense of deja vu in that it's a lot better way of doing what people did with display lists, where you sent things down to Vector Generals or whatever. They were little programs and there was some grouping structure but everything is done so much nicer now in the sense of having complete programs and a better set of primitives etc. Am I missing something from the model or is that really what is going on?
Gosling: One of the things that tended to characterize all the display list languages was that they tended to be tailored very much towards what the hardware could do. PostScript tries to stand back and say "I don't want to know what the hardware can do, I want to know what makes sense for the user".
Bono: What I would like people to do when they do look at standards, instead of ignoring them, is to look at, for example, the CGI work; this is a set of functions which some people claim is a good instruction set (forget the syntax for the moment, just look at the functionality). We would like to get some comment on whether it is a good set of functions and that is what you should be looking at rather than ignore the standards. All of this could be fitted in a standards context if we get it right.
Gosling: One could easily use the CGI graphics model for this instead.
Teitelman: The innovation here is not that we are using PostScript. The reason we chose PostScript is due to a lot of historical connections and proximity to the people who are doing it.
The interesting thing is that all these processes look as though they are executing in one of those old single address environments. It is a single user process that James has been able to implement lightweight processes in. You don't have lightweight processes in Unix systems, which you really need to implement realistic user interfaces.
Gosling: There is really nothing new here. It's just putting it together in a different way.
Rosenthal: It is worth bringing out a number of points about this style of window manager. There are some real limitations, though I think this is the way we should go.
Some help from the kernel is needed. This is easy in 4.2 which has a sensible IPC. It could be done in System V through shared resources etc.
A reliable signal mechanism is essential. The window manager has to stay up. It is the only routine for talking to the system and hence must stay alive. We have 100 systems running and only experience 1 - 2 crashes per week. This is good by Unix standards!
Applications cannot read pixels back - this is just too slow.
There must be a way to make the client think it has a real terminal, such as the 4.2BSD PTY device, otherwise all old programs misbehave.
There must be a mechanism for downloading application code into the window manager process, for example, rubber band line mouse tracking is done by a user level process.
There must be off-screen space in the window manager.
Examples of systems built in this way are:
BLIT [50]; Andrew (CMU)(see Chapter 13); VGTS (Stanford) [36]; X (MIT).
The BLIT system is successful - people wrote programs for it. I believe it is the only successful window manager for a Unix system.
Myers: Maybe that is because BLIT doesn't run a Unix operating system.
Rosenthal: Overall, it is a Unix software environment.
Williams: We should bear in mind that Rob Pike says that to do anything sensible using the BLIT, you need to write two processes which communicate: one running in the Unix host and one running in the BLIT, and this must be harder to do than, say, writing two programs which don't communicate.
1. For a long time now Chromium didn't support MathML. It's only coming back in the upcoming version.
2. Firefox's implementation of MathML is buggy: <http://0x0.st/o7HQ.16.mov>.
3. There is no CSS property to enable grouping of threes of digits in large numbers, so you need to put spaces into the markup, resulting in them being included when copied and search discovering completely different numbers than the ones you want to present.
4. And just try making this table reproducing the proper alignment of numbers in HTML: <https://practicaltypography.com/samples/number-grid-after.pd...>. It's hell.
Most of these architectures could probably be recreated on the web, if we cared to, if we thought they provided sufficient advantage. Projects like swf2js are surprisingly competent at playing Flash. But it's... just not a better medium, for users, for extension builders, or for developers. It did have some good tooling for creatives at least, but there are plenty of really good modern web tools with similar capabilities, they're just not as popular, not as important anymore, I'd argue because Flash was actually a pretty crude & raw interface builder that lacked much of the refinement, navigability, control, & capabilities we now take for granted.
There really aren't. Because the web can't even do animations properly. And Flash had a faster vector rendering model than SVG.
> I'd argue because Flash was actually a pretty crude & raw interface builder that lacked much of the refinement, navigability, control, & capabilities we now take for granted.
Ah yes, the refinement, navigability, control and capabilities of... what exactly do we take for granted? Where are these amazing tools that replaced flash and can be used for creatives, games, interactions...
But as always, the cheapest "solution" won.
Notably, the anti-web mob almost never bothers to articulate why it is they think the web is bad at all! This is another classic case, of inchoate disparagement, with no specific claims to be backed nor refuted.
I want to be a sponge, to embrace good ideas, to hear & listen to what people think might improve or enhance things. But there's rarely real problems cited (or there are gross mis-understandings), and much rarer still is a better path or possibility articulated. I'd love some genuine discussion of the web, but the silent majority seems ok-enough or better working the web regularly, and the protestors against the web tend towards blunt & undirected.
One conflict I do see as visible again and again is the expectation of what the web should be. There seems to be quite a lot of hostility to the web being a low level platform, to it not having a single consistent development style. This leads to a lot of "the web was never meant to do this!" sort of feelings, but that doesn't really argue whether this iterated adaptability the Document Object Model has spawned serves us well or poorly.
One thing that is true is that the DOM is a low level platform, that it's not higher level. It doesn't compactly solve all or even most of the problems. To me, this is the critical value of the web, that which makes it so much better & more powerful: that we are free to express multiple architectures, free to innovate our UI patterns & do so, while still keeping the same underlying bones. This has begat great cross pollination across many different tribes of webdevelopment, has continued to make the web a crossroads of development, where many ideas cross paths & new ventures, new trials are began. It compares versus near-literally everything else, where isolated communities come and go (even within corporate walls, e.g. Microsoft's GDI, WPF, Silverlight, WinUi, DirectDraw, WinRT, UWP/Uno, .NET MAUI, or GTK's major 1, 2, 3, 4, & Adiwata reworks), ideas for how to make interfaces rise & fall, never quite satisfying.
There's protests against the web being fast enough, but frankly it's horsepucky. The browser is intensely optimized & stunningly fast at all kinds of things. It does not however prevent mis-use, prevent bad code. Often installing ad-blockers (something not doable in apps note you) is enough to get users to lightspeed.
The web has made a great Bazaar, a great place for a conflux of possibilities, and has proven vastly malleable as a medium & platform, boosted so much further by it's connectivity-at-the-core versus applications which bolt-it-on, and given far greater reach than the developer-centric gui toolkits of yore. So much is possible here, and the great reverberating om keeps giving, keeps exploring. But, it feels like, so many just want the Cathedral, the one specific incarnation that is well shaped, that everyone can just do. I just hope we can have some discussions about what would make a good Cathedral, what properties & virtues it would have, because i think the Bazaar will probably ultimately accomplish those ends better, but if we can't engage & discuss, no one wins.
They articulate it all the times. Unfortunately "sponges" with their "reverberations of yore" are too enamoured with the sound of their own voice to hear that.
Meanwhile, as far as app development goes the web cannot even reach the heights of Turbo Vision from 1990s.
Just some of the reasons articulated in a Twitter-sized manner: https://news.ycombinator.com/item?id=34218520
> boosted so much further by it's connectivity-at-the-core versus applications which bolt-it-on
Tell me you know nothing about history without telling me you know nothing about history
1. Not layered in any meaningful way. Seen another way: you can't implement a web browser using web tech.
This matters because a typical way to write apps outside the web is to pick an opinionated high level platform that you think will do what you want, but if it turns out at some point to not quite work in one part of your app you can drop down to a lower level. You can use the operating system's text rendering but you don't have to, and if you don't for some reason you won't really lose much performance because you can use the same lower level APIs that the OS's own text rendering library uses. This ability to drop down a level when you hit the limits of an upper level is significantly limits development risk and makes planning easier, because you know you will always be able to do something, it's just a question of effort. On the web, if you hit the limits of the platform, you're just SOL.
2. GUI only paradigm. Useless for CLI apps, servers, etc. There's no deep reason for this beyond history, inertia, business models and so on.
3. No working notion of software components. This has actually got worse with time: web components got rolled back, plugins were removed, HTML includes don't exist. That's something ViolaWWW got right in 1992! The web's leading component technology is React which doesn't even come from browsers and browsers lack obvious features it could use to improve performance. See how Sciter doesn't even need ReactJS core at all because they've got a DOM extension that does DOM diffing and patching in C++, but regular browsers don't!
4. The DOM model is not high performance. It's highly optimized in Chrome for what it does but the DOM is an extremely complex and generic system that nonetheless fails to deliver modern and competitive widgets causing a high level GUI API to be treated as if it's "low level", even though it isn't. It can't really remove anything, so browser code is absolutely full of slow branches, lookups, workarounds and so on. If you take it as given then browsers are fast because Google and Apple invested so much into it, but if you take a step back and say "what's the best way to render documents and GUIs fast" then it's not that great.
5. The web is absolutely not malleable as a platform. It's not at all bazaar like. Take just one obvious pain point where some malleability would be nice - a malleable system would let you use non-JS languages! The web's current attempt at this is WebAssembly, which can't do anything useful unless you call into JS to do it, which imposes a large performance penalty vs native code and which doesn't even really work for anything higher level than C++ or Rust. If the web was malleable someone would have fixed that years ago, but in reality the web can only be changed by Google and only via a convoluted and opaque political process.
Don't get me wrong, the web gets a LOT right! There are dozens if not hundreds of lessons to learn from its success. But the critics do have concrete issues.
Unfortunately, they haven't. Google especially pushes them at every opportunity, and they are poisoning the web. E.g. Scoped CSS that covers about 80% of what web components are used for cannot progress because now it has to account for weird corner cases in the Shadow DOM.
Meanwhile none of the major and very few of the new frameworks view web components as a viable foundation. They still have multiple issues that will maybe someday be solved by throwing more and more Javascript at them (see how incompatibility with forms was "solved")
The DOM is not "low level", its the wrong abstraction. It feels low level to you because it is fundamentally hard to express the layout of a gui application in terms of a document layout.
Compare the HTML DOM to Android's XML layout. It is so much easier to work with Android's layout system. You can trivially do things like anchor element X to the left / right / top / bottom of element Y, without workarounds like display:inline and adding div upon div upon div to make things work right.
I could list out another dozen things that JS does poorly, but I don't think that would be very productive.
> The web has made a great Bazaar, a great place for a conflux of possibilities
The web has been successful in spite of its bad technology. The concept of the web and the internet is wonderful. And the reality of the web would be better than it is today if websites weren't so slow, bloated, and buggy.
Electron is popular because Chromium is an extremely well funded project that has a bullet-proof business model (more web apps = more crawlable html = more searches = more ad clicks). There are probably more than 1000 people working on it, many of whom are very senior and expensive engineers.
Does Electron make sense in the abstract, i.e. with unlimited resources and no business constraints, would we have ended up with apps shipping a full copy of a web browser with themselves for their UI rendering? Probably not, no. But does it make sense in the concrete, in a world where Google is willing to spend billions every year on a monolithic codebase that does things like optimizing text rendering, abstracting native APIs and so on, then give it away for free? Sure!
So you ask, if it's so bad why hasn't something else replaced it. Money is a big part of it. Yes, writing cross platform frameworks is hard, but it's not that hard. What matters is who is willing to fund it. Google has money, gives away lots of free beer, and that beer comes in the form of an HTML engine.
There were dozens of serious attempts at a remote GUI applications framework from the 70s to the 90s. HTML + JavaScript is the one that finally succeeded. It is not a coincidence.
Unlike all its predecessors it was conceived in a free software environment, and worked with both degraded and upgraded environments. It was fast-evolving enough for commercial interest, standardized enough for mass adoption, and trivially simple to author.
Yes, the web has grown complex beyond all reason and if you want to make a real state-of-the-art web app today you'll have to use an absurdly deep stack of tools. It's probably time to rethink things. But give credit where it's due. No other system would have even been _able_ to evolve like HTML + JavaScript has done.
You can implement a XServer in only a few MiB, that runs on a potato (as seen form today). Compare that to current web browser.
> Yes, the web has grown complex beyond all reason and if you want to make a real state-of-the-art web app today you'll have to use an absurdly deep stack of tools. It's probably time to rethink things.
It's long over due. We should get lost of all this "layers of madness".
> No other system would have even been _able_ to evolve like HTML + JavaScript has done.
How can you know that?
The problem is only, the market takes always the cheapest solution that barely works. And you can't compete with "free" (like in beer).
The absurdly deep stack of tools is the reason why the web has grown complex, not the solution to it. If front-end devs applied a bit of fucking YAGNI every now and then instead of churning out tutorial #193859812 on how to get set up in 10 minutes with a WXYZFooBarHyperCSSJS stack then get completely brick walled a few months into your project because now you're committed to tech that would take 15 years of study to actually understand, then front end would be perfectly fine.
DHTML is the greatest hack in all history.
It's almost unbelievable that we're using such a kludge for almost all user-facing application development today.
With still limited interactivity and terrible work-arounds (canvas).
And still with a data silo problem - (but not quite as bad as the data silos created by 'apps' on your devices)
The browser APIs we have today have legacy cruft, no question about it, but they also have all the good, and modern parts any other system for GUI and graphics would have. It's surprisingly complete today.
I think browsers suffer an "image" problem, where we just assume what's there is bad, for some reason. I'd be curious to hear specific shortcomings you encounter in your work.
Downloading an entire site is an existing strategy, what SPA means (single page application) and these are often terrible UX. You wait a lot for it to load, then it's clunky and the moment you navigate away by clicking a link, you lose a ton of your app state.
I've seen reflow happen with real GUIs when they're fetching tabular data (from the network or from disk) and the columns are flexible and stuff is too big. Or some frameworks love to hide scroll bars, so when those pop in, everything moves around a bit.
Unstyled content is rarer, because usually the styling information is compiled in, but sometimes that just pops in late too, more often when your computer is overloaded and storage and network are terribly slow. Sometimes you get a couple different revisions of splash screens as the thing starts up.
In that case, the Disable Javascript[0] addon might interest you.
[0] https://addons.mozilla.org/en-US/firefox/addon/disable-javas...
Regarding the browser internals being in JS: the UI option to turn off JS was about not running JS found on web sites. The browser internals are another matter.
Sorry for the late reply.
Actually, I am very much aware of this. Mostly because I default to browsing with JS disabled and don't enable it unless it's required for the content on a particular page.
Often times, I just don't even bother enabling JS on pages that require it and move on without viewing whatever "important" information that can "only" be displayed with JS.
So yes, I am aware of the overuse of JS. That said, I can't control what tools/frameworks website developers use to create their sites.
And since I am not a big fan of running arbitrary remote code on my devices, I choose to limit the ability of remote sites to do so.
Is that a solution? No. But asserting control over my devices is the only option I have.
Well, aside from raising a few tens of millions to start a web development training academy to teach the world's web developers that they shouldn't use JS to do simple things like displaying static text or images, and that all computing required should be done server-side and not on the client, unless the client affirmatively consents to such code running on their device.
Unfortunately, I'm guessing the VC world has little interest in such an endeavor.
As such, I'll continue to do as I do WRT JS. It's not great. Heck, it's not even good. But it allows me to at least attempt to retain control over my property (in this case, browser-capable devices).
I take other steps too, such as using DNS block lists (PiHole), egress filtering, browser containers/private tabs as well as various content blockers.
Those steps may turn out to be ineffective in the long term, but hopefully I'll be dead before that happens. I will continue to employ and tweak those methods until they aren't useful.
My devices should do what I tell them to do, not what web developers want my devices to do. While those things may be the same, I'd like to be able to decide that for myself.
For the truly brave and principled, you should be able to disable the HTML view completely, and browse the web entirely through the JavaScript debugger console, network log, DOM and CSS editor, JavaScript sources, breakpoints, scope, and call stack, by searching and opening up DOM elements and JavaScript objects and stacks as needed by clicking them in the outliner and typing JavaScript expressions into the console.
The first sentence is Alan Kay answered: “Actually quite the opposite..."
Looking past the poorly edited title this whole thing is clickbait answered with one question. No one really thinks all the interactivity we have in web pages is bad and implying that someone does for clicks is dishonest.
Everything can be done poorly or well. And because modern sites are often done so poorly, the power of interactivity is also seen poorly (it allows you to be worse than if you didn't have it).
This does push some people into contemplating restrictions or subsets of the web platform as a standard. Where you simply can't do the travesties we see on popular sites today.
There will always be poor examples, but they don't invalidate the concept.
Smart web pages, when done right, are an incredible time saver, and if you're not convinced, go visit, for example, the web page of your bank from 15 years ago on the Wayback machine.
More accurately it does NOT invalidate it, but points out we need that concept refined. There's no selective pressure for making a page well-designed, light. Google is trying to to put better designed sites higher up, but they can't hide good content only because it provides horrible bloated UX.
I'm not literally against JS? :D
This site has a length limit on the description field. The "..." is there to signify that something else is following. Is this new to you?
BTW, I was able to catch the updated title before the "unflag" action disappeared, so I was able to remove it. Thanks!
This forum is literally the epicenter of people who think that.
Ten Years of Window Systems - A Retrospective View, by Warren Teitelman:
http://www.chilton-computing.org.uk/inf/literature/books/wm/...
A Clipping Divider, by Robert F. Sproull and Ivan E. Sutherland:
https://dl.acm.org/doi/10.1145/1476589.1476687
I think a better title of this discussion would be simply "History of Window Systems", which is the title of David's blog posting that I linked to at the end, if you made it that far.
Alan Kay thanked David Rosenthal for writing up that History of Window Systems: "Your blog is a real addition to the history and context needed to really understand and criticize and improve today."
Or did you get that far? I guess if you didn't make it past the first 50 characters of the title, you probably didn't make it to the end where all the good stuff is.
DSHR's Blog: History of Window Systems:
https://blog.dshr.org/2021/03/history-of-window-systems.html
>History Of Window Systems: Alan Kay's "Should web browsers have stuck to being document viewers?" makes important points about the architecture of the infrastructure for user interfaces, but also sparked comments and an email exchange that clarified the early history of window systems. This is something I've written about previously, so below the fold I go into considerable detail. [...]
Also, David Rosenthal previously posted to Reddit in 23 years ago in 2000 to correct some misleading comments other people posted:
https://slashdot.org/comments.pl?sid=5311&cid=1075535
>I'm Dave Rosenthal. I worked on window systems for a long time. I was one of the authors of the Andrew window system, and NeWS. I did the first port of the X Window System to non-DEC hardware and was one of the team that got X11 release 1 out the door.
>This comment has good references, all worth reading. The Methodology of Window Management book is the record of a workshop in 4/85 - it has a lot of pointers to work further back, in particular a paper called "Ten Years of Window Systems" by Warren Teitelman, who was at PARC and then ran the Windows group at Sun. This describes many of the early window systems at PARC.
>I'm not going to try to write a complete history, but I do want to correct several misleading statements in the comments to this post. There were several streams of development which naturally influenced each other- broadly:
>- Libraries supporting multiple windows from one or more threads in a single address space, starting from Smalltalk leading to the Mac and Windows environments.
>- Kernel window systems supporting access to multiple windows from multiple address spaces on a single machine, starting with the Blit and leading to SunWindows and a system for the Whitechapel MG-1.
>- Network window systems supporting access to multiple windows from multiple address spaces on multiple machines via a network, starting from work at PARC by Bob Sproull & (if memory serves) Elaine Sonderegger, leading to Andrew, SunDew which became NeWS, and W which became X.
>Gosling & I & others at C-MU's Information Technology Center wrote the Andrew window system. We were all post-docs by then, not students. My memory is that it was working OK in the spring of '84.
>NeWS was not based on Display Postscript. Gosling built a completely independent (and much faster) implementation of PostScript from the specification that Adobe published as a book. This was SunDew. It was never a fully functional window system. NeWS was a ground-up re-write of SunDew, adding extensive multi-threading and garbage collection to the PostScript clone. My memory is that it was working pretty well by the summer of '86.
>Early versions of X were specific to bizarre DEC hardware. While I was working on NeWS at Sun I also did the first port of X10 to non-DEC hardware - to Sun 1,2 & 3 workstations. Experience from this and later ports of X10 was a major input to the redesign that resulted in X11, and this careful design has led to reasonably easy porting to X11 to a wide range of hardware.
>I'm not going to comment on the politics which have surrounded window systems, except to say that an individual's rankings of the importance of different technical, aesthetic or licensing features are no more than an individual's views. The market's view of the same features can be quite different without the operation of conspiracies or malign forces. It may simply be that the majority of customers don't agree with your priorities.
Original reddit discussion of "What GUIs Came Before X11?":
https://slashdot.org/story/00/05/04/1321234/what-guis-came-b...
Computers should have nothing more than text terminals, as Ken & Ritchie intended.
That way the world would be a better place without TikTok, Instagram, YouTube.
Odd statement because that same Bell Labs crew created Plan 9 as unapologetically bitmapped GUI, since even 30 years ago they already considered TTYs to be a smelly anachronism.