I've been recently wondering if there's another, better way. The big usability win of the web is that you can run applications without installing anything. Is there a way we could build a new platform that would get us the advantages of the web without all the awful cruft?
I'm imagining starting with webassembly for sandboxing. We can then expose through to webassembly a useful set of API primitives from the underlying OS for text boxes, widgets and stuff.
Apps would live in a heavily sandboxed container and because of that they could be launched by going to the right URL in a special browser. We could use the same security model as phone apps - apps have a special place to store their own files. They have some network access, and can access the user's data through explicit per-capability security requests.
That would allow a good, secure webapp style experience for users. But the apps themselves would feel native (since they could use native UX primitives, and they would have native performance).
Developers could write code in any language that can compile to webassembly. We could make a bundler that produced normal applications (by compiling the app out of the sandbox). Or we could run the application in a normal web browser if we wanted, by backing the UX primitives with DOM calls, passed through to WASM.
The original usability win of the web was that anyone could put up some text with pictures and links and anyone else could see it. It was proto-Facebook. I think of the evolution of the web as a sequence of technologically trivial but socially innovative changes in format: from static pages to timestamped blog posts, aggregating multiple blogs in a feed, allowing comments and so on. That's the vision laid out in Clay Shirky's writings about social software, as true today as ever before. And unlike the "semantic web", that vision naturally leads to a wealth of semantic information (like friend graphs) which is tremendously useful.
Hopefully that explains why "API primitives exposed to webassembly" feels to me like thinking about the web from the wrong end. The social end is what makes the web tick. It could be built with tinkertoys for all I care.
What is the essential difference between the success of browsers and the failure of X-Windows and Java applets?
For my money its that Java applets and X-Windows didn't have a distribution mechanism and security model. They simply didn't do anything I couldn't already do with desktop apps and HTML.
Also, frankly, they were kind of slow and not very good. I think thats the biggest problem with this sort of idea - the breadth of surface area for GUI toolkits is crazy huge. Building something that works well, and works cross-platform is a seriously huge amount of work.
Discovery. This is the essential difference. And this is mostly based on semantic features of html.
www has 3 main ways of discovery that alternative technologies didn’t offer: 1) search (leading you to correct info in the site, instead of just to a landing page. 2) overview pages, short summary with links to the actual info (google news, etc), 3) deep hyperlinks that everyone can easily discover (browser url) and provide elsewhere (email, Facebook posts, twitter posts, etc).
The first one is very much based on the semantic qualities of html, where google can crawl a page and make some educated guess about what the page is about.
Biggest problem with mobile apps is that discovery is completely channeled through commercial app stores.
I would like to see an alternative web tech stack that doesn’t skip the discovery part. Web assembly with canvas for example is completely useless for a search crawler.
> What is the essential difference between the success of browsers and the failure of X-Windows and Java applets?
Timeline is one of the key ones. According to chrome task manager (because browsers need task managers now) the page I'm typing this reply on the contains a text area and your comment is consuming 30MB of RAM. Back when Java applets were getting their reputation for being slow I would have been lucky to have a computer with 32MB of RAM, 8 and 16MB were still common at that time. Now there were some other things that made applets awful, but if they were introduced today they wouldn't seem nearly as bad as we remember, on the same computer this page would be clunky.
For x-windows, it was never really a contender because there was no MS compatibility, but the potential was there.
How are you crossing the bridge from webassembly to having access to the native UX primitives? Are you directly making C calls to native libraries like win32?
I'm imagining starting with webassembly for sandboxing. We can then expose through to webassembly a useful set of API primitives from the underlying OS for text boxes, widgets and stuff.
Apps would live in a heavily sandboxed container and because of that they could be launched by going to the right URL in a special browser. We could use the same security model as phone apps - apps have a special place to store their own files. They have some network access, and can access the user's data through explicit per-capability security requests.
That would allow a good, secure webapp style experience for users. But the apps themselves would feel native (since they could use native UX primitives, and they would have native performance).
Developers could write code in any language that can compile to webassembly. We could make a bundler that produced normal applications (by compiling the app out of the sandbox). Or we could run the application in a normal web browser if we wanted, by backing the UX primitives with DOM calls, passed through to WASM.