Is WebAssembly the Return of Java Applets and Flash?
words.steveklabnik.com
words.steveklabnik.com
Flash was more like using Premiere where you just edited your timeline with a bit of interactivity sprinkled over it, no movie editor ever had to get his hands dirty with some kind of scripting language or low level file formats just to edit a movie.
I had a lot of "oh wow" moments at the end of the 90's and beginning of the 00's with Flash. It was like the web was warped into the future. Nowadays you can achieve the same but not as elegant. It kind of reminds me of how PC's had to catch up with the Amiga for years. Perhaps starting with Wing Commander things were really on par or better, almost 8 years later.
Flash was like using poor quality native apps, which was a step backwards from a browser.
Link me to the most user-hostile Flash-based web page you can find, and I'll watch a ten year old hour-long video presentation from a Gnash developer explaining their 100-year plan to ship a usable open Flash runtime alternative.
Flash didn't have any of that, and was much slower to load than modern JS websites.
And this is not some student's first approach at modern web technologies, its fucking YouTube from google. They can't get their shit working on their own browser. I have yet to see an SPA with a convincing UX that's more than just some wannabe webdev's "about" page.
That is because following the standard semantics of the Web in Javascript is easier than breaking it, while for Flash it was the other way around. Of course that does not mean that every JS powered page is good, or that every Flash powered one was bad, and ironically it does mean that the more JS, the worse it tends to be, but the more Flash, the better it used to be.
Building a usable experience in Flash was possible, but sufficiently difficult that almost none did.
Building a usable experience in JS is significantly easier than it was in Flash, though sadly still seems to be sufficiently difficult that too few do. The ratio of usable JavaScript apps is a lot higher than it was for flash, but is still a minority. It is at least an improvement though, if an incremental one.
At the start of 2005, I was helping lead a team build a highly interactive experience for a major car company using Macromedia Flash and Flex 2. When we launched the site we had full cross-browser pixel accuracy, fully supported URL deep-linking, bookmarking, page history navigation, web crawling, keyboard navigation, screen reading support, interactive video, highly animated experiences and even had fully integrated web mapping using a beta version of Microsofts first interactive map tech (it eventually became branded as Bing maps).
What we built then was possible only because of Flash, there was no way we could have created the complete experience in JS/HTML/CSS. Granted, we could have done a lot of it in native web tech (and in some cases, we had to under the hood), but to make it fully pixel accurate cross-browser would be tripled the dev & testing time. On top of that, some of the features would have been impossible without Flash.
Let's recall where we were in 2005. Chrome was still 3 years away (it was released in 2008), Firefox was still version 1.0 (1.5 didn't release until Nov. of that year), Gmail was just released into beta (you had to have a friend to get access), Google Maps was still in an experimental beta and was truly pushing the boundaries of what JS/HTML could do. The browser history API didn't exist so we had to do crazy iFrame hacks to create deep-links and history (this was true of any app, no matter what tech). There was no video in browsers without a plugin (HTML5 spec wasn't finalized until Oct. 2015). There was no such thing as CSS animations, they got their first release in Firefox 5 (June 2011).
So, were Flash apps trash? Absolutely, but not all of them. That's like claiming that modern browsers solve it all. We still have massive load times (look at how much time and effort is put into optimizing content delivery), the cross-browser and backward compatibility is a nightmare, and way more of a challenge then it ever has been. In some ways, modern web development is much better than Flash development was, but to be perfectly frank, we have a LONG way to go. Honestly, we haven't caught up to where Flash was 14 years ago.
But, we are getting there for sure. I can see why Steve Klabnik is so excited about WASM. I can envision where it is going and it reminds me of where Flash was trying to go before it was slaughtered by Adobe. It's an exciting time for sure, but we should also look back at where we came from and instead of just stating Flash is trash and it caused the web to be terrible, we should also look at what it did right and what it allowed us to create before we throw it out with the bathwater.
So... nice one there, green user. You really got'em!
But Flash games were a boon. Everyone with an idea was able to make it into a game. I spent a lot of time playing games in Kongregate and similar sites. Many were really interesting, well worth the effort of sifting through the rip-offs and trash.
https://www.youtube.com/watch?v=LeKX2bNP7QM
The internet speeds were much slower then, the difference mattered a lot. Also note, from the description:
"Sadly, it's not possible to replicate the pop-up mouse-overs from the "Special Edition" - though I was able to append the "deleted scene" presented in that version. If you want to see that version - or the "Fire BAD!" flash video game where you attempt to extinguish flames on James Hetfield (tragedy + time = humor), you'll have to find the original .SWF files and have a way to play them."
I don't think more than a handful of the games and little videos that I enjoyed as a kid on newgrounds and addicting games would have been made had they not had such a low barrier to creation.
I do kernel/firmware development now, so I'll be the first to admit that this value proposition isn't valid for all domains. But sometimes, for some use cases, just having a simple to use scripting environment is totally the way to go. Particularly if it's sandboxed well and can't really harm the end user.
In those days there was no notion of SPA or other contemporary well-established patterns for online interaction.
I authored several commercial sites using Shockwave and the like and it enabled us to give clients the ability to author media-rich and design-heavy presentations in a fashion they were familiar with from card decks applications. At the time doing so in a 'sexy' way made them stand out.
It was a cul de sac, but it was a worthwhile direction to test in terms of UX.
That it was proprietary was weighted differently in those days. The world was dominated by closed standards and open source was still vestigial especially in commercial applications.
Not arguing with you about the rest. As a web developer I still haven't made a website in the last 5 years that was as visually impressive as my Flash projects from before, and sometimes I miss the visuals....
But people forget that the AWESOME intro that you wait two minutes of loading to see... is only cool the first couple times. Many many people where losing 5 minutes of loading time, just to visit websites that they used EVERY day.
By virtue of being installed on 98% of all computers, Flash video was a de facto standard video target. One that could be played on Linux without getting into legal grey areas too!
Without Flash looming over them, IE would never have supported cross-platform video - this would have been Microsoft undermining the WMP format.
I think that we would have gotten there eventually, but probably not as fast. The close - but not quite good enough - implementation of video in Flash was as much of a catalyst as it was a crutch to lean upon.
I agree with you that it's a little sad that amateur animation fell a bit out of vogue, but the tools are right there for anyone whos interested to pick up.
I have memories of being wowed by what creative people could do with flash in the 90s and I would not call that amateur animation. I think the problem (1) is we currently seem to be lacking in tools that let people skilled in the visual arts create things without knowledge of the mechanics, so to speak. It's like if in order to write a great song someone would first have to understand how a musical instrument is built. I would not call Amanda Palmer or Lee Ranaldo amateur yet I bet they probably can't build their own instruments.
(1) I must make the disclaimer that for a couple of decades already I've been working only on the backend, so I may surely be missing part of the picture here.
Edit: Fixed footnote mark.
And I know there are still issues. Given today's speed, issues are more about security and accessibility.
My point was just that the artists using flash to create good content were not amateur animators.
Edit: My point was wrong as it was based on a misunderstanding of the use of the word 'amateur' by the person I was replying to.
I spent hundreds of hours in Photoshop as a teen, but I likely would’ve have bothered with it at all if it weren’t easily piratable.
That's a problem generally with cloud services. Pricing is mostly done considering some countries and contexts, but totally ignoring other. With physical equivalents some years ago, local distributors made deals with their home offices to adjust for this, but that's not something usually done anymore.
Even now html/J's can't do all of the things and most of the things that you can do, are not as fast. While browsers are stuck with legacies to uphold. Flash had no dom to worry about, untyped language (as3) or had css holding it back.
General argument was flash sucks because people make terrible content with it. Which is like saying I hate having hands because I trip things over.. so no limbs = no mess PERFECT.
In turn I think it helped push native apps. Since plain Js/html app just sucked in comparison when it comes to experience and capabilities.
Flash should have been open sourced. Hopefully with webgl and web assembly someone can step in and create something similar
Taking a step back, man what a different world it was back then. I'd fire up MS Frontpage or Macromedia Dreamweaver and go to town. The expectations have changed on the maintainability, usability, and functionality parts so I understand why we are where we are today. Both I do miss those simple days.
Steve Jobs and browser security holes killed Flash, and no current open web platform covers all the use cases mxml and AS3 covered for cross-browser development. I could analyze audio channels, run lightweight process concurrency via green-threading, store user files, do i81n translation, streaming websockets and work with actual binary data types in the browser in 2006. I could trigger actions based on events in video and audio streams. I had consistently applied css with animations across components in 2006. I had reusable web components in 206. It's now 2018 and we still don't have cross-browser support for all of that. Oh, and I could run my app on the desktop in offline mode and in the browser.
Security was an issue. Looking back now, I think an Android-like permissions scheme is what it, and the browser, needs to fulfill the promise of write once run anywhere that the browser and the web tends to make.
It was heavily based off ES5, which really helped launch my Javascript abilities forward at the time. I was sad to see it go and ended up working with other technology that never felt as fun.
I remembered recently that Haxe was initially based off of MTASC (something I used in the later AS3 days), and checked it out. It's quite a stable ecosystem that feels very familiar in syntax. Add in HaxeFlixel, and it's almost like Flash never left.
flash was a good tool for the websites they used to create, usually graphics and animation heavy websites low on interactivity. they used the export function to generate the swf including the html index page to embed it.
over the years focus shifted more and more to dynamic websites with content generated from databases and they were mostly lost there. dynamic content (loaded by http requests from databases) in flash usually turned into a huge pain in the ass after a while. for those projects we switched to a traditional website model where dynamic content mostly wasn't loaded into flash, instead it was a html-by-php website where flash animations replaced header jpegs (i.e. animated passive content).
so, in our case, flash was a good replacement for animated and slightly interactive but not dynamically generated content.
A lot of users did, too. But it was usually along the lines of "Oh, wow. This page has flash. Well, I guess I'll go get a Coke while the Flash plugin loads into the browser and my computer can't go anything else. If I'm lucky, the whole thing won't crash and take all my work with it by the time I get back."
We romanticize the past.
Java applets OTOH had the exact experience you describe. Those were absolutely terrible.
Not really. Action Script has always been close to Javascript/JScript.Net and now Typescript, it is the same syntax. In fact ActionScript 3 was supposed to be the template for ECMASCRIPT 4, before it was abandoned.
Not Adobe Edge was killed dead, it was not rolled into Adobe Animate. Edge did export animation with jQuery and DOM element, while Adobe Animate exports animations in pure canvas.
But it would still come with many of the drawbacks.
is supposed to be an implementation of the Flash VM in typescript, But it can't even run in latest Firefox browser anymore apparently and no commits from 2 years.
But that's also true of an application which relies on WebAssembly (or JavaScript): it loses all the benefits of the web, because in a very real sense it's no longer a web site, but is instead a program running in a web page.
WebAssembly or JavaScript, neither is document-oriented; neither is linkable; neither is cacheable. It's Flash, all over again — except at least with Flash one could disable it and sites were okay. with WebAssembly & JavaScript, every site uses them for everything, meaning we get to choose between allowing a site to execute code on our CPUs, or seeing naught but a 'This page requires JavaScript' notice.
It is the return of Flash, and that's a bad thing. We thought we'd won the war, but really we just won a battle.
(Edit: Typos. I should know better than to post from my phone by now. Grrr...)
[EDIT]: Steve is right of course, and I misspoke here, "WASM is still able to drive the DOM" is closer to what I meant to say.
What difference do you see?
Apps are apps.
Sometimes both are in the browser.
It'd be great if all "documents" had an HTML version, with minimal JS. For accessibility, searching, deep linking, etc.
In the ancient web world, the site author wrote HTML to describe the data she wanted presented and the browser took care of making it accessible. But authors (especially companies) wanted detailed control of how their sites looked, so they turned to flash etc.
JS has long been re-playing this trend in slow motion -- moving away from web pages being interactive documents presented by the GUI app called browser and towards them being stand-alone GUIs like in flash.
Sure, there's "fuckAdblock" but that shortly spawned "FuckFuckAdblock". It's a whole different case when the very browser prevents the content from being tampered with.
It would be an interesting experiment to transpile a less complex browser, like Arachne, over to WASM as a proof of concept to demonstrate how awful this kind of future would be. (Yet another "if I had some free time" wishes... >sigh<)
WASM is really just a cleaner, faster, more elegant way of running alternative languages to JavaScript in the browser. It replaces transpilers that turned languages like Java or Go into ugly basically machine code JavaScript blobs. It will save bandwidth and improve performance but otherwise doesn't change much. Note that transpiled and uglified JavaScript is already "closed source," so nothing changes there. Anything can be obfuscated.
I am however scared that HTML will go the way of Gopher. Why would anyone care to maintain boring hypertext documents when we can have app of the day. Marketing departments everywhere tend to turn the web into Blinkenlights.
How many support documents of more than 15-20 years ago are you able to still find using the old links? So many sites are working as dumb front-ends for a database.
The information retrieval and persistence over time is not something many worries about.
The cat is for sure out of the bag. I just hope what was still can survive.
JS or Wasm can't create documents by themselves, they still need a DOM. Even if it's a 2D canvas or some WebGL canvas, it's still a DOM element. Or even if it's just an iframe that loads some blob, on the top level it's still a DOM element. And as such it can be inspected and controlled.
Not if the content is decrypted by EME that's not fully controlled by the browser.
I would assume that it will take a while for tooling in any other language to get to a javascript level. I think WASM will mainly be support for the latter. Do some excessive calculations.... and yeah, excessive Blinkenlights.
I hope so too, but as a member of predatory and territorial species, the cat will most likely keep on killing everything else around it.
WebAssembly enables load-time and run-time (dlopen) dynamic linking in the MVP by having multiple instantiated modules share functions, linear memories, tables and constants using module imports and exports. In particular, since all (non-local) state that a module can access can be imported and exported and thus shared between separate modules’ instances, toolchains have the building blocks to implement dynamic loaders.
The code is fetched via URLs so you can link to it in that sense, too.
It's also cacheable: https://developer.mozilla.org/en-US/docs/WebAssembly/Caching...
The point was more that once webpages become applications running on the client (think single page apps), the natural document metaphor of web pages and the tooling built on it (hyperlinks, forward/back, bookmarks, history) falls apart unless you do extra work to ensure that experience is maintained.
But not everything needs to be a document. Sometimes the thing you're working with really is an application and not a document.
To me, one of the biggest problems with the current web is that we've commingled "app stuff" and "document stuff" so badly that browsers have been forced to become a shitty, inferior X-server (or Operating System outright), instead of being really good browsers. Browsers for browsing is great... browsers as a UI remoting protocol, is a bit janky.
"clickable"
Because you certainly can link to the wasm and js code that come with webassembly instantiateables.
Would I complain if I could run a full version of Word or Excel in the browser? The browser would become a universal interface in another way and decrease our reliance on particular operating systems.
I for one would, because the browser is an absolutely shitty interface. You're still forced into "there are tabs, which contain sandboxed documents" model of use. Interoperability is nonexistant, integration with machine capabilities is superficial and completely opaque to the user, the data model is hidden (where is my localStorage equivalent of the file browser again?), everything assumes you're constantly connected - it's a corporate wet dream, but for individuals, it's a nightmare.
Creating mobile and/or offline first exoeriences for individuals isn't a pipe dream, it was possible and happened in the 90's when connectivity (dialup) informed content (largely offline or downloaded).
I'm not looking at replacement, only reasonable substitutes, which I think will become useful similar to using Google docs on mobile and web.
The Firefox developer tools have a "storage" tab that lets you inspect the content of various databases associated with a website.
Perhaps Web Assembly will drive this power usage down. But as it stands now, I actively avoid more than one of these app-on-browser products at a time.
In half cases like that, stuff like sorting, list comparison, deduplication are done in a way that will score low mark even by standards of first year university program.
This is telling of web development industry's approach to doing business.
The most horrid examples of "LAMP sweatshops" of 10 years ago pale in comparison to what the industry has devolved into these days.
My own experience being an involuntary webdev for 3 years left me with following impressions:
1. Webdev is the largest commercial development niche in the whole tech industry. Everything else pales in comparison. It is also about making money quickly. A webapp or even a promo page SPA for a major consumer brand these days can cost up to $100k easily. $100k does not seem a lot to most people here, but such money can be well offered for a 1 month project for a team of of 6-8 professionals.
2. The industry is dominated by shops with 20 to 30 people headcount. Web dev studios generally don't scale much above that because of talent flight. Loss of a single senior dev who supervises hordes of lowest tier mule coders is often the end of a business for most of companies.
3. People from "big dotcom" world are near oblivious to ways of small web dev shops. For people who began their careers at 60k a year internships, getting into shoes of a person who does coding for 30k a year is impossible.
4. Talent flight and turnover is real.
5. This is all about really expensive quick and dirty code.
6. "The big dotcom" type of companies tried time and time again to tap into the market to extract rents, and with exception of Macrovision nobody ever succeeded. This is the reason Adobe is lobbying for unusable, unwieldy APIs in hopes of selling tooling for it.
Right now my mobile device is often tapped by Javascript that insists on running in the background.
By replacing it with a poor simulacrum of an operating system. Browser APIs are an inefficient subset of libc and bsd sockets offer.
And they provide near-zero interoperability with native applications. No filesystem access (beyond the clunky save-one-file dialog), no CLI, no IPC, nothing. That means browsers are building on top of operating systems while not interoperating with them.
This is a step forward not backwards. The security model of allowing apps access to your full filesystem (assuming your user has access) is flawed. It leads to apps storing data in funny places, reading files they shouldn't, and general mayhem. Requiring the user to explicitly allow the app to access the file is a good thing.
There are some use cases that are hard to support (like being able to open all the files in a folder). But people are working on a solution.[1]
> No IPC
WebRTC while not the same and far more overhead (due to TCP sockets vs OS level sockets) can function very much like IPC. And there is nothing stopping a process running in a different browser (or even no browser at all) to connect to a webapp using WebRTC locally.
Additionally, if a new window is opened by Javascript and both pages are in the same domain + port (or subdomains of the same domain and you have access to the parent domain) you can communicate between the windows with simple Javascript function calls. And since browsers are moving towards a 1 process per window setup this is essentially IPC.
> That means browsers are building on top of operating systems while not interoperating with them.
While I can't argue with that. So is X Window. The abstraction between app and OS is a thick gray line not a thin black one.
[1] https://developer.mozilla.org/en-US/docs/Web/API/FileSystemD...
Most apps being limited to their little part of the filesystem is not a problem. The problem is, now as a user, I can't access those files. I can't view them in a form that suits me, I can't use other applications to operate on them. The true form of the data is forever hidden from me, a secret of the application that "owns" it.
Your are neglecting the option of exposing a limited subview of the filesystem like containers do.
> But people are working on a solution.[1]
The big red box on top says it's not on standards-track.
> WebRTC while not the same and far more overhead (due to TCP sockets vs OS level sockets) can function very much like IPC.
Can I send open file descriptors like I can with unix domain sockets? Can I share memory for low-latency atomics? Futexes?
> So is X Window.
Maybe if you're remoting X, few people do that these days. In practice X applications have access to the same machine that they are drawing on.
I'm still optimistic that new forms of applications will emerge from this. There are serious pieces needing fleshing out, like file access.
The insecure interoperation between browsers and operating systems perhaps can be reimplemented through a newer more secure interface like wasm or the api.
The only example I can think of is the Twine engine for Interactive Fiction.
https://github.com/mozilla/BrowserQuest
Doesn't work in Safari.
Wasm will almost certainly lead to UI frameworks for the Web. JS people try very hard to get similar stuff, but the language is just not good enough; at the same time the desktop people that have this stuff is claiming for some way to use the same on the Web. People are already working on those frameworks, by the way.
For the commenters that seem to have some underlying fear that WASM apps will be another incarnation of a "window in a window" or some horrible bitmapped graphics pane that does not fit into the web model:
WASM is just a CPU. It's a bytecode format for expressing low-level, high-performance programs. It comes "batteries not included"--intentionally. By batteries, I mean APIs. WebAssembly modules must import everything they need from the outside. When embedded in JS and the Web, the first and still primary use case of WASM, that means modules can import functionality from both JS and the Web, and call literally anything that JS can call. That means WASM can (though still somewhat clunkily) manipulate the DOM, WebGL, audio, service events, etc, through all of the same APIs that JS can do. There is nothing that prevents a WASM app from looking and feeling exactly like something written in JS.
To reiterate: WASM does not require you to drop down to canvas or render fonts yourself. You can call out to JS or direct to WebAPIs! (again, it just happens to be clunky to do this from C++.) But other languages are working on bindings that make this much nicer. Rust anyone? :)
What WASM gives the web is a proper layer for expressing computation. The APIs and paradigms that build on top of WASM are independent, swappable, interposable, by design. Because it's a layer for computation, and a low-level one, it is by nature language-independent. As Steve mentioned, adding languages to the web one by one does not scale. Thus WASM.
The fear isn't that it requires that. The fear is that it enables that.
The web is, and has been over the past two decades, in the constant state of war over control between publishers and consumers. People - and especially businesses - making pages would like to have 100% control over how the webpage/app looks and is being used. But the users would like to have some control over what they're viewing too[0].
The most widely known battle in this war is the battle for ad-blocking. The publishers want you to view lots of ads. You want just the content, without any of the ads. So far, the technology (and economics) favors the user, but it's not a given.
The balance of control on the web was always maintained by the technologies on which the web standardized on. Pure HTML, or even HTML+CSS, strongly favours the user. JavaScript tilts the balance significantly towards the publishers, as now they can (and do) generate content with code, which renders the page difficult to interpret and modify on the user end. One of the biggest complaints about Flash was how shitty the pure-Flash/mostly-Flash webpages were. That's not an intrinsic problem of Flash - this happened, because Flash gave the publishers too much control. And publishers (again, especially businesses) will use (and abuse) any control they're given.
The fear here is, that WASM against tilts the control in favour of publishing, which will lead to abuse and web becoming a much worse place for the consumers. If WASM will, by virtue of efficiency, enable publishers to embed a browser they control within the page, the publishers will use this, because this would single-handedly eliminate most ad-blocking, userscripting and scrapping efforts.
--
[0] - and the power users, like myself, would like to have 100% of that control - think of how much better the web would be if the data was always published in machine-readable format, without tons of bullshit paginations and stylistic choices to scroll and click through. For instance, when looking for current weather, I want to input my location and a time span, and get weather data. I want to be able to script that. I don't want to waste time looking at ads, pretty pictures, non-relevant text and links.
But on the other hand, I can't help see the enormous potential of a proper assembly language for web. Web technologies have felt like a massive hack for decades: tools designed for basic text formatting and a bit of interactivity which have been stretched in extreme ways to meet the needs of the modern web. Web applications are the most widely used software on the planet, and if you ask me it's about time developers will have the freedom to develop them in the language which makes the most sense for the task at hand rather than the only one which is available. And I am quite keen to see what kinds of new things will be possible when the ceiling is significantly raised for performance optimization.
So I have really mixed feelings here. On the one hand, I appreciate the power WASM gives. On the other hand, I don't trust the majority of companies on the web to use that power responsibly.
I feel the same way. But those ads are there because that's the entire business model of people putting weather data out there for free. On most free sites, ads aren't just a sideshow, they're the driving engine. Take away the ads, and there goes the business model.
What we need is some other way to pay for the weather data. Maybe this could be a service provided by your ISP, like NTP or DNS. Or some third party subscription service. Or maybe even taxpayer funded. But if you're using a service that relies on ads as their revenue model, then expect to put up with ads. They're part of the deal.
For those worried about the "all WASM" pages looking like the old "all Flash" pages of yore, consider that Flash and Java applets had their own UI stack and WASM does not. The closest WASM has to that is OpenGL, but you've been able to make all-OpenGL apps with pure JavaScript for some time and it hasn't taken over the web with terrible sites yet. WASM code can interact with the DOM. I guess we could worry about native C/C++ GUI toolkits being ported to WASM, but the web community gets what you deserve for making Electron a thing.
I don't like JavaScript in general but I don't see how WASM is any worse, and if anything it's quite a bit better.
Pretty much every AAA video game of a certain period would have been using scaleforms Flashplayer for their user interface.
No, the compiler maybe, Action Script maybe, but not the player. The player is entirely closed source and there is no open spec for the player. Or you need to show it to me.
> there was more than just the Adobe Flash Player as implementations.
Only Adobe's implementation could run all swf files. Scaleform was not an alternative flash player. Any attempt at creating an alternative and feature complete flash player failed.
Flash the tech is not open, at all.
So someone makes a game, and they use this very useful WASM library over here. Only that library exploits spectre or meltdown to steal data. Or maybe it just silently hoses your machine by targeting the new WebGL shaders? Or any myriad number of other things.
Let me be explicit. There are changes in WASM specifically made that render spectre and meldown mitigations useless. (ie-Browser makers put in spectre and meltdown mitigations, and changes in WASM allow WASM content to get around those mitigations.) Developers cheer the changes, because they make WASM more useful, and to be fair, browser mitigations of spectre and meltdown type bugs make WASM far less performant. But changes which render those mitigations useless are dangerous no matter what your opinion is on how useful WASM should be.
Edit: Should probably mention that the upcoming changes include threading and shared memory. Implemented in a way that enables CPU side channel attacks. (Probably because there is no other way to get threading and shared memory without everything slowing to a crawl, but still.)
Could you be more specific? I implemented Chrome's Spectre mitigations for WASM and I'm not sure what you are referring to.
> Should probably mention that the upcoming changes include threading and shared memory.
These only give you a high-resolution timer mechanism--which you have to build yourself and is possible in JS with SharedArrayBuffer before. So WASM is no worse in this respect.
Some time in the (near?) future those vulnerabilities will just be a footnote in some history book and having to support mitigations forever (due to backwards compatibility) probably isn't the best thing to encode into a standard.
I'm sure some intrepid security researcher will find some new Vulnerability of the Day which can also be exploited through wasm and then they will need to add mitigation to the standard yet again ad nauseam until it becomes some giant bloated unusable mess for which we'll need yet another standard.
I think so, and the managers at Adobe and Sun must be kicking themselves for not somehow getting their runtime more open, modular, and standardized now that we see write once run anywhere with a few system hooks is all we need.
Then again... It was a different world in the mid 2000s. The web standardization process? Ha, what was that?
On a side note, I'm seeing more articles pointing out that WASM runs in the JS VM. Doesn't negate the whole advantage of speed for WASM?
> managers at Adobe and Sun must be kicking themselves
Both tried. As I recall Sun were blocked by Microsoft, and Flash was bundled as standard with Netscape from about 2001 onwards. Steve Jobs killed that stone-dead when he point-blank refused to support it on iDevices.
Adobe AIR beat things like Electron and PhoneGap to market by years. IMHO the issue with Adobe is this insistence on 'open' still having various vary opinionated elements. Adobe Air for example had a lot of good ideas but still attempted to evangelize Flash and ActionScript. I _think_ MS is trying to pivot of that grave now with .NET Core. Time will tell if the Mono-to-Wasm or .NET Core Native projects have legs.
I was so very excited about Adobe Air and wrote a production application with it in 2009.
I _think_ a sweet spot for WASM data processing. The data visualization space should explode once I can with data in the browser at near native speed.
Sun thought that they had something like that with Java Apps ~20 years ago, except they forgot to make installation and UX compelling, and the memory requirements were unacceptable for the time.
It basically means that WASM has the same safety/security model as the JS VM. Just like JS, it is compiled to native code (I'm simplifying a bit, of course) before being executed. However, where JS is one of the languages with the most complicated semantics around, which makes it really, really hard to compile efficiently, WASM has extremely simple semantics and is designed to be really, really easy to compile efficiently.
Well, here's a benchmark of asm.js JavaScript versus WebAssembly in a real world application:
https://pspdfkit.com/blog/2018/a-real-world-webassembly-benc...
The WebAssembly version outperforms the asm.js version.
Over time you do more of your own thing and you or someone else splits these two pieces of code into three smaller ones. Like the LLVM backend that can be fed by a C or C++ frontend.
As webasm becomes a competitive advantage you should expect to see people split up their javascript VM into three pieces, and Javascript and Webassembly running as peers instead of guest and host.
In a very small way, we kind of saw a similar thing with JSON. JSON was just a strict subset of Javascript and you could emulate it on old browsers with a linter in front of an eval(). Now it’s its own thing.
It runs on the JS sandbox, but it can not be efficiently emulated by the JS CPU. VM is an ambiguous term.
Browser developers are talking about running JS in the Wasm VM. That will probably be reasonable very soon.
Browsers removed Flash support, they might end up rendering Wasm useless by putting it behind loads of permission warnings.
There's also the chance it'll end up lacking as it is and it'll end up being a useless appendage that gets killed off.
I think the reason Browser removed Flash was more because it was an absolute security nightmare for the Browser vendors and they had to fully rely on Adobe to patch the worst of it.
Wasm on the other hand leverages the Javascript VM so browsers don't have that problem. And they don't depend on an external vendor either.
Upcoming changes to WASM include threading and shared memory. Unless browser makers implement those features in a manner that slows the machine to a crawl, WASM certainly will be getting some security warnings. Either because security minded organizations will disable it, or because browser makers will be honest and up front about the risks with those features. (There will be either security implications, or performance implications because they implemented the new features in a secure fashion.)
Eh, (P)NaCL had a very strong sandboxing and verification story.
Wasm is, basically, NaCL in a form that Mozilla and the non-googles etc could accept. There are small implementation differences but the details are all non-important. It was all political. If they had accepted NaCL we'd have had what we have with wasm only we'd have had it years ago.
Naaah it really doesn't seem small. Details are important.
NaCl comes from the plugin world (NPAPI → PPAPI), while wasm comes from the JS world ("removing the JS from asm.js"), and most existing JS engines have been able to just reuse their codegen/backend parts.
PNaCl was based on a bad idea: "let's make a stable subset of LLVM IR". LLVM moves quickly, if you have a stable subset you'll eventually have to translate it to actual updated LLVM IR anyway. And good luck to anyone who wants to implement a simple small interpreter for that!
wasm is really simple — just a close-to-metal abstract machine. No included libc, no bindings to any particular platform (there might be DOM/etc. bindings in the future, but on top of wasm, not right in the core spec).
It’s only a “political thing” if you don’t think that autonomy gives us diversity, or that diversity gives us more unique ideas to consider.
If we went with NaCL then everyone but the dominant player would be playing catch-up forever, worse than they already will be.
Accepting NaCl without accepting PPAPI would not have been very useful. Accepting PPAPI was a non-starter without a lot more work than Google was willing to put into it.
EDIT "does" - and of course it's flawed but the "story" is pretty great :-D
People used to say that you couldn't do strong process isolation because it would be unworkably slow.
And then Google Chrome demonstrated that was a falacy. People actually flocked to chrome because it was faster, despite it using multiple processes and isolating plugins.
NaCL built on that - it's security model was strong process isolation and verification that the code run in that isolated process couldn't 'escape'.
Mozilla is still kinda in denial re process isolation.
Isn't that exactly what Electrolysis[0] was for?
WASM enables nothing. It just makes a particular subset of JavaScript slightly faster.
EDIT: I'm not talking about Canvas. That isn't part of WASM.
I kind of miss the days of the HTML/HTTP-only web.
My point exactly.
The author is making the wrong comparison. WASM is JavaScript all over again, and, the HN NoScript crowd aside, that's not going anywhere soon.
And… comparing Flash to V8? I'm having trouble finding modern benchmarks, but Flash is based on ActionScript, which is related to JavaScript. JavaScript has V8, which is a world-class JIT with Google's engineering talent behind it. I'd be very surprised if Flash's JIT was competitive with V8. At least as of 2011 it wasn't [1].
I didn't make any claims about Java Applets or Flash performance.
Is the end result from the user perspective the same? I don't know. I'm just little worried that it might be.
Raw WebGL isn't going to give you any of that. And listening for any interaction events at all is going to necessitate the DOM.
I don't doubt WASM will end up with something similar, but it's also something that's possible with JS today, there are a bunch of JS game engines that render to WebGL and perform very well.
Web assembly does, as far as I understand it.
http://example.qt.io/qt-webassembly/SensorTagDemo/SensorTagD...
Then there is this gallery demo:
http://example.qt.io/qt-webassembly/quickcontrols2/gallery/g...
The right sidebar right now doesn't scroll with standard mouse wheel. I had to scroll it using mouse drag.
By just sending part of the necessary binary logic to the user, it is ensured they can't easily be independent of the provider or create their own solution.
If someone doesn't see what I'm talking about, then read about the AGPL; it exists to prevent what I'm talking about.
Superficially, it is a shame Mozilla is working on this technology. However, it's official goal is to advance "The Web"©® which uses above mentioned effects to lead to centralization and lack of freedom for users.
WebAssembly and some other modern browser features are the basis for the massive centralized providers we have today. That "The Web" leads to decentralization is a lie.
Also you shouldn't need access to code to create your own solution. Many people have been reverse engineering or borrowing from ideas in the compiled world. When I copy something I like I don't typically look at their code, I focus on the functionality and break down what its doing so i can reimplement it.
The fact you are focusing on centralization is basically saying "i can't steal someone eases code". The web promised to be free and open and that had nothing to do with whether or not you could read the javascript.
Most modern javascript on site is rather unreadable due to being transpiled anyways. There is still an option to use plain javascript instead of WASM. Just like now you can use plain javascript instead of transpiling it.
> have been reverse engineering
Reverse engineering some HTML is not difficult. Minified JS is much more difficult. A 50MB blob of WAMS is just too time consuming.
> The web promised to be free and open and that had nothing to do with whether or not you could read the javascript.
On the contrary, making it 100x times more difficult to understand what a website is doing is terrible for security, compatibility, inclusiveness (good luck making a braille terminal for WASM-only websites or using them on a very slow uplink)
This had and has everything to do with it. Please, read what you have just written, and think.
Mozilla is bathing itself in it's image of standing for a free and open world. The truth is that it's business in "The Web" is creating the groundwork for a closed and non-free world. This hypocrisy cries out deafening.
Like I said we can already pretty much transpile our code to practically speaking, an unreadable state.
Companies can already choose to make their code closed source and transpile it. If there goal is to make it more closed they can do that now.
WASM doesn't change that. People can still make their code open source, they can still write in plain javascript. Its really no different. Instead we are giving people options and the ability to have more performant apps in the ones that require it.
(Furthermore, many apps that would use WASM probably have a significant server-side part as well that is not necessarily open source.)
There's no technical way to enforce that code is shipped to people in an easily readable/editable format: JS or wasm or machine code can all be equally difficult to consume. Enforcing this requires a human solution, and that is exactly why viral copyleft licenses exist (including the AGPL you reference).
Unreadable, non-free JavaScript is used to reach a goal. That goal is to withhold the source from the users to bind them to the service. This leads to centralization, power imbalances, and thus attacks on the freedom and sovereignty of the users.
WebAssembly is a technology to achieve the formerly stated goal easier and more convenient. Of course, some people will be interested in that and work on it.
Mozilla is working on this. So far so good (or bad). The issue arises when you combine this fact with the self-portrait of Mozilla as the one defending the rights and freedom of the users.
WebAssembly is a technology to achieve better performance on the web, and that as a side-effect happens to achieve withholding the source easier.
Actually, it's pretty much like minifiers. And I guarantee you: the main reason most people are using minifiers is to improve performance, not to hide the source. That just happens to be a side effect.
All of these benefits come without a significant cost to user freedom because the cost has already been paid, and will always be paid no matter the underlying technology: companies will always ship obfuscated code if they feel that's important. (Also, I suspect most minification is driven by bandwidth and page speed concerns.)
Lastly, I don't think wasm is actually noticeably more convenient: shipping wasm requires a compilation step, just like minifying JS.
I just hope that complex features such as multithreading or garbage collection don't become a mandatory component of the base VM. A complete, JITable-Implementation in RPython is now just about 3k LOC.
Some disagree: https://www.eff.org/deeplinks/2017/09/open-letter-w3c-direct...
Obviously it’s better in aggregate than the web of applet and flash times, though.
Still, Wasm seems unique in a few ways :
- languages like rust have emerged to help address the browser issues of the past in other technologies
- wasm can exist in the front or back end, in variety of languages but complies to one bytecode like the jvm.
- wasm appears increasingly capable for both front-end or backend development, while not insisting on either.
- wasm is the first standard I can remember where all the browsers (Chrome, Microsoft, Firefox, Apple etc) agreed on a baseline. This is much different than one company building flash, java, etc.
Java applets and flash existed at a time when the html standard wasn't capable of rich frontend experiences, or deep backend.
It's quietly an increasingly promising time, and my hope is the progress continues to gain momentum.
I’d argue users are an even more important part of the equation. If the UX sucks, no one will use it and you’ll have implemented an empty spec.
Now the question is, who will make the first major framework on top of WASM, and for which language?
I bet you know which language I'm betting on ;)
That said, I don't think a framework is really the thing; I think JavaScript users using wasm in libraries is a much bigger growth area for wasm, at least in the short term.
I'd expect the reverse to happen as well to some degree since currently backend devs are somewhat "forced" to take on JS if they want to do any frontend work. Or does that seem less likely to you?
I think the “backend dev migrates” case is less likely, in a purely math sense. The number of backend devs forced to do front end is smaller than the number of frontend devs.
Flash (and Shockwave director the first web 3d platform) actually were Java applets when they first came out then they switched to ActiveX plugins which really did have a good run of innovation on the web. Microsoft jumped on that to push ActiveX and Flash timing was just right as Microsoft was doing everything possible to kill off Java applets in as well as other platforms like Quicktime and Real Player.
We owe lots of web interactivity to plugins and mostly Flash. I think with Chrome killing plugins there is a slight gap in platforms like Flash that push innovation, Java Applets never really took hold and were hampered by Microsoft as well as being slow. Microsoft even tried to make their own Flash in Liquid Motion in late 90s and again in 2005ish with Silverlight, just before mobile took off which changed everything. Mobile killed off plugins as much as Chrome did.
Flash did lots of good things well or the best. Vector animation is one, SVG is pretty good now but Flash was still better. Flash for gaming and video was the best on the web for a long time. Flash was great for hitting web services/remoting before AJAX was as solid. Flash pushed using JSON data over XML though it could do both before javascript well. Flash was the original web sockets. Flash revolutionized interactivity, games and video. Flash made Youtube possible. Flash had display list and DisplayObjects that were like an early virtual dom. Flash was a market standard that the main goal was pushing interactivity forward and needed to to survive, Java applets did not keep up and it is harder to do with standards as they are slow.
WebAssembly may be another Flash/Java Applet go round but plugins and now wasm can help push things forward as plugins did for many years. wasm may help that missing piece on mobile since it is just javascript in the end.
Flash was a great interactive platform when under Macromedia and some under Adobe but Macromedia was really better at managing the development/technology platform that it was. Microsoft was going to buy them once before Adobe got them. Adobe let Flash languish a bit and they lost the hold.
Flash is actually partly responsible for pushing web standards forward in html5, video, webGL, canvas, SVG even JSON and AJAX because they were all innovated on in Flash then brought to the browser. Flash with ActionScript3 even pushed forward javascript ECMA standards. AS3 was based on ES4 which Microsoft, Yahoo and others teamed up to kill, I think it was a solid ECMA version and quite fun and very readable and much like TypeScript [1].
I am a bit sad Flash is gone and wasn't looked after correctly by Adobe, if Macromedia stayed around it may have gone different and WASM would be Flash. However Flash ended up stuck in software rendering land for too long and buggy with security holes that didn't keep up on desktop nor was it ready for mobile. Adobe essentially sent both Director and Flash out to pasture (and Freehand/Fireworks which were good), but we still need something pushing innovation and standards are slow to do that, apps have somewhat become that in place of plugins like Flash today and wasm may help.
[1] https://www.reddit.com/r/javascript/comments/34ps9z/why_was_...
For those remembering the web in the early 2000s, the Flash-only designer-based websites were the norm for restaurants, luxury brands; it was a designer wet dream, to allow him to design animation enabled and pixel perfect "web sites" without dabbling with HTML and JS code
The web is a better place due to Flash and Macromedia did a killer job, I wish Adobe had kept it going better. Originally I was attracted to Flash 3/4 for making cartoons, Flash was where I launched my first game (and hundreds more) and got lots of fun game/interactive/video work from it. I probably work in games/dev today due to Flash (mainly Unity now, another Flash inspired tool). I loved AS3 as well, great iteration of javascript and only ES4 implementation that was kicked to the curb unfortunately. Flash was awesome all the way to the 2007ish Papervision 3d days (Three.js by mr. doob [1], part of Papervision team along with great designers like Carlos Ulloa [2] and people that work at Unity now like Ralph Hauwert [3], takes Papervision's place) but then Adobe let Flash languish in lacking hardware rendering support and eventually mobile and apps killed it due to native/hardware rendering support, Chrome put the final punch in by changing plugin support. Though HTML5, Canvas, WebGL, SVG, web video, web audio and even wasm is a direct result of the innovation from Flash. Flash even got big in entertainment like video, games and lots of web cartoons still use Flash today for animation (Adobe Animate now) [4] though many use ToonBoom/USAnimation (also inspired by Flash) [5][6].
Sites like joe cartoon, newgrounds, praystation, thefwa etc were all part of it and Youtube jumped on Flash video, big parts of internet history are due to Flash.
Flash was one of those rare tools that attracts interactive/creative designers and interactive/creative developers. I don't know that there is another tool/platform that was as attractive to design and development. Adobe Animate is still around but the Flash community was awesome and attracted all types of creative people.
Flash was so much more than a buggy plugin in the end, it was a great interactive, vector based entertainment and content creating system overall end to end. Flash/Animate is still out there today but not as integrated. Adobe Animate is the same but can export to apps and html5/canvas/webgl. There are also open source tools that can do flash like but not as integrated as well for designers in OpenFL [7], Haxe [8] and lime [9].
[3] http://www.marketwired.com/press-release/flash-3d-vet-ralph-...
[4] https://en.wikipedia.org/wiki/List_of_Flash_animated_televis...
[5] https://www.toonboom.com/company/customer-productions
[6] https://en.wikipedia.org/wiki/USAnimation
[7] http://www.openfl.org/ + https://github.com/openfl/openfl
so flash-like maybe and probably a step in the right direction, you can then code in sdl/qt/gtk/etc.
For games I would say it makes sense to code the UI as well in WASM.
I don't have an illusion though, it will be abused by devs heavily in the near future who dislike CSS/JS/DOM.
then js is to bind components to each other.
>Java was owned by Sun Microsystems, Flash was owned by Adobe. But why does this matter?
This is the reason corporate sponsors of WASM banish flash and, while at the same time, promote WASM.
Agreeing of course, after trying to do it on their own and then realizing they were thinking a lot of the same things.
Remembering now the Monty Python's "What have the romans ever done for us" scene...