
Is WebAssembly the Return of Java Applets and Flash? - Vinnl
https://words.steveklabnik.com/is-webassembly-the-return-of-java-applets-flash
======
dep_b
The thing about Flash was that it was pretty WYSIWYG and a lot of creative
people flocked to it because it had strong multimedia capabilities. Personally
I kind of missed the part where you could build really nice looking stuff
without much technical expertise, nowadays you need to know all about CSS,
Polyfills and JS quirks so there's always this limitation where you have to
understand pretty technical stuff early on to get something done.

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.

~~~
code_duck
To me, flash was like the past, or a warped vision of the distant future. The
interfaces people created had visual appeal, but that’s all they had. It
lacked all of the usability that I was used to finding on webpages, and
therefore made for a very frustrating experience. No bookmarking, no back and
forward, no right clicking to open a new tab, frequent superfluous sound,
major security holes, long loading times. I would hardly call any of this
elegant. As a user, I was thrilled when people stopped using flash.

Flash was like using poor quality native apps, which was a step backwards from
a browser.

~~~
smofnoopttzzaaa
To me, JavaScript is like the past, or a warped vision of the distant future.
The interfaces people created had visual appeal, but that’s all they had. It
lacked all of the usability that I was used to finding on webpages, and
therefore made for a very frustrating experience. No bookmarking, no back and
forward, no right clicking to open a new tab, frequent superfluous sound,
major security holes, long loading times. I would hardly call any of this
elegant. As a user, I was thrilled when people stopped using JavaScript.

~~~
d4l3k
There are some bad JS websites, but most of them do have proper bookmarking
since pretty much every web framework supports adding multiple pages including
forward and back navigation. Browsers are also good enough to handle #links as
well within a SPA app. Also, they tend to have faster than typical loading
times for navigation within the site.

Flash didn't have any of that, and was much slower to load than modern JS
websites.

~~~
iforgotpassword
Just no. I'm on latest chrome on android 6 and when I browse search results on
YouTube, then click a video and hit back I expect that the scroll position
within the results is restored. Instead when I hit back I only see the red top
bar and a loading spinner and a moment later the results show up again and I'm
at the top of them. Because we don't have nice paged results anymore, but this
hip and ubercool dynamically extending page of results and everything.

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.

~~~
lucideer
> _this is not some student 's first approach at modern web technologies, its
> fucking YouTube from google_

It's sad that Google is revered by the developer community as a role model for
software engineering because their frontend web work has—at least for the last
~10+ years—always been terrible and a really great example of worst practice.

Gmail's early HTML version is possibly the last faded memory of a quality
frontend product coming from Google. Everything they've created since the
advent of GWT has been aggressively anti-user and anti-interop. Gmail took a
long time to get full browser support and a longer time to play will with back
buttons, etc.—meanwhile the Gmail interface has slowed and bloated with each
iteration; the latest bordering on unusability on my very new midrange laptop.
Wave never worked in anything but Chrome, the same is true of the early
iterations of most of their large newly released products over the years. The
Google homepage provides a totally inconsistent experience across browsers—on
mobile I see three different results views in three different browsers, two
are Blink-based! Why doesn't search by image work on mobile? We're thankfully
no longer lumped with the distaster desktop experience the was Google Instant
Search.

Similarly, Microsoft and Apple don't have great histories here. When looking
for good development practices, you should always look at the example set by
companies that _need to compete_. Monopolies don't need usability.

~~~
catdog
Ironically google landed its initial success with (and maybe partly because
of) an ultra minimalist website focused to the task. They seem to have
forgotten that and now they have bloat everywhere. Instead of reducing it they
put a lot of resources into developing technologies to deliver that bloat more
efficiently.

~~~
lucideer
> _Instead of reducing it they put a lot of resources into developing
> technologies to deliver that bloat more efficiently._

Efficiency has a lot of different definitions depending on whom the efficiency
is "for". I would say Google put a lot of resources into increasing the bloat
(adding abstractions) in order to automate the creation and maintenance of
their services. They are the pioneers of removing humans from the equation:
they're using ML to create their maps, instead of the previous focus on humans
driving around with cameras, they have a notorious lack of human-intervention
customer service for most of their paid services, even GWT which I mentioned
above removed human JavaScript devs (admittedly in order to allow Java devs to
write it, but unlike other transpilers—e.g. Typescript/Coffeescript—which
produce a relatively readable direct JS equivalents, GWT is heavily abstracted
and the output isn't in any way representative of what a human would create).

------
eadmund
> If you built an applet in one of these technologies, you didn’t really build
> a web application. You had a web page with a chunk cut out of it, and your
> applet worked within that frame. You lost all of the benefits of other web
> technologies; you lost HTML, you lost CSS, you lost the accessibility built
> into the web.

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.

~~~
EvanAnderson
I envision horrible "all WASM" websites, just like the old "all Flash"
websites, that won't have accessibility, won't be able to be linked to, etc.
Worse, I envision this as being another step in the ad blocker arms race.
Inevitably there are going to be websites that package an entire WASM-based
browser that will need to be used to access the site, nullifying client-side
ad and script blockers. I can see the pitch now-- "Keep your existing website
but add our tools to prevent ad blockers!"

(Edit: Typos. I should know better than to post from my phone by now. Grrr...)

~~~
Eridrus
This is a criticism that would be more suited to the Canvas API than the WASM
API. WASM is still meant to drive the DOM API which is still as introspectable
as before.

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

~~~
steveklabnik
I agree with your first sentence, but not your second: wasm is meant to access
all platform APIs, not just the DOM ones. Canvas is part of the platform as
well.

~~~
pault
I think we will start to see a lot of all-in-one frameworks that use wasm for
constraint based layouts so people don't have to learn CSS. I hope I'm wrong
but I can definitely imagine something like this coming from the enterprise
java/.net types.

~~~
lmm
I sure hope we do. CSS has had 20 years and is still the most error-prone way
of doing layout I've ever seen.

------
titzer
The OP is really spot on.

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.

~~~
TeMPOraL
> _To reiterate: WASM does not require you to drop down to canvas or render
> fonts yourself._

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.

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

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.

~~~
TeMPOraL
That's a fair point, and a prelude to a much larger discussion about business
models on the web. Suffice it to say, I'd happily accept some deal for
compensating the data provider - be it ads, micropayments, or even regular
subscriptions - if the resulting data was available in a) machine-readable
form, and b) decluttered form on the webpage, so that I could read it
efficiently (possibly with support of userscripts/userstyles). As a bonus,
such sensible data display will save the provider's bandwidth costs, as on the
typical site, 90+% of transferred bytes are not part of the content.

------
Sir_Cmpwn
I'm typically sharply critical of the web, but I think this comparison is kind
of silly. The biggest problem with Java Applets and Flash is the security
issues, which were largely caused by giving web pages access to a second, less
secure sandbox. WASM stays in the same sandbox as the rest of the web. Flash
also had the problem of being proprietary and non-standardized with only one
implementation, something WASM does not suffer from.

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.

~~~
Marazan
Flash player had a open access spec and there was more than just the Adobe
Flash Player as implementations.

Pretty much every AAA video game of a certain period would have been using
scaleforms Flashplayer for their user interface.

~~~
nostalgeek
> Flash player had a open access spec and there was more than just the Adobe
> Flash Player as implementations.

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.

~~~
Marazan
The player is closed source but the SWF spec is open.

[https://www.adobe.com/devnet/swf.html](https://www.adobe.com/devnet/swf.html)

------
vturner
WASM itself isn't Java, Flash, or Silverlight, but isnt it another step in the
ongoing multiyear process of replicating the features of those technologies in
a way that they tried to accomplish: compile to one format and run it on
multiple platforms?

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?

~~~
rusk
I think it's a step forward in that it's more integrated into the platform.
Remember when TCP/IP used to be an add-on for an operating system?

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

~~~
Ari_Ugwu
Some companies have all the right ideas and for whatever reason still can't
execute.

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.

[https://en.wikipedia.org/wiki/Adobe_AIR](https://en.wikipedia.org/wiki/Adobe_AIR)

~~~
vturner
Remember when Adobe AIR was going to come to Android? That would have been an
amazing write once run anywhere experience.

~~~
joshtynjala
You can build Android apps (and iOS too!) with Adobe AIR today. In fact, it's
been possible since about 2010.

------
mattmanser
Seems very premature to say the Wasm has "won" when it's only just come out.
People were saying Flash had "won" when all the browsers had it embedded by
default a decade ago.

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.

~~~
zaarn
Wasm doesn't need permission warnings since by default the sandbox is very
restrictive.

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.

~~~
bilbo0s
"...Wasm doesn't need permission warnings since by default the sandbox is very
restrictive.."

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

~~~
loukrazy
How is threading or cross thread shared memory a security risk?

~~~
swiley
Rowhammer/specter

~~~
zaarn
Rowhammer doesn't need either shared memory or spectre and spectre is largely
eliminated by browsers running as much as possible in different threads and
then relying on OS protections, there isn't much remaining risk

~~~
bilbo0s
"...spectre is largely eliminated by browsers running as much as possible in
different threads and then relying on OS protections..."

???

Do you mean Meltdown?

Spectre is the evasive one. New variants are being found even up to today.
SpectreRSB is a rather nasty one that was found 3 or 4 days ago. (Or rather,
they _told_ us about it 3 or 4 days ago for instance.)

Anyway, point is, there _are no_ OS protections against variants of Spectre.
I'm not sure how there even _could_ be, some of these variants have been known
publicly for 3 or 4 days as I said. So right now trying to patch Spectre is a
lot like playing Whack-a-Mole. Personally, I think we'll end up having to live
with CPU side channel attacks for the foreseeable future. People will just
learn, probably the hard way, not to download untrusted executable code.

Of course, that tendency to say "no" on the part of consumers will probably
impact WASM. But that should be expected.

------
willvarfar
> Wasm has a really strong sandboxing and verification story that others
> simply did not.

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.

~~~
rusk
As did Java ...

EDIT "does" \- and of course it's flawed but the "story" is pretty great :-D

~~~
willvarfar
the Java and Flash approach was software-implemented security contexts and
managers, running the VM in the same process as the browser.

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.

~~~
Sean1708
> Mozilla is still kinda in denial re process isolation.

Isn't that exactly what Electrolysis[0] was for?

[0]:
[https://wiki.mozilla.org/Electrolysis](https://wiki.mozilla.org/Electrolysis)

------
colanderman
Isn't the answer really, "no, because WASM doesn't allow you to do anything
you couldn't already do with JavaScript"? I don't think anyone would complain
about Applets or Flash if the only way they could interact with the web page
was through the DOM.

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.

~~~
readittwice
Not sure if I agree. I would still say that WASM enables new types of
applications. Of course you could have compiled all that new WASM applications
to asm.js or even JS as well. But it would've been slower: maybe even unusable
slow. That's why I think WASM enables new types of applications. It's the same
as in the past where faster JS engines enabled richer web applications like
GMail, etc. Now we get games in the browser and large native applications like
AutoCAD.

~~~
colanderman
I don't doubt the claim that a Java Applet can be faster than JavaScript, but
I haven't ever seen a modern high-performance web application written as a
Java Applet. The CAD stuff, games, etc., are always Flash (EDIT: when they
aren't JavaScript). So the comparison is really Flash vs. JavaScript.

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

[1] [https://habr.com/post/121997/](https://habr.com/post/121997/)

~~~
readittwice
My answer was in reply to "WASM enables nothing". I argue that WASM is faster
than JS, therefore it enables new applications.

I didn't make any claims about Java Applets or Flash performance.

~~~
colanderman
Ah sorry I thought you were replying to "no-one would complain about Flash or
Java Applets".

I don't disagree that WASM is faster than JS; in fact I make that point myself
in several comments. My point is that WASM's speed does not enable it to be
abused like Flash in a way that JavaScript cannot be, because JavaScript is
_already_ as fast as (in fact faster than) Flash thanks to modern JITs like
V8. The reasons that WASM is not the "new Flash" must therefore be the same
reasons that V8 + Canvas are not.

------
pritambarhate
I also worry that WASM will just bring another era of non-standard Flash and
Java Applet like UI design. Just check this QT demo:

[http://example.qt.io/qt-
webassembly/SensorTagDemo/SensorTagD...](http://example.qt.io/qt-
webassembly/SensorTagDemo/SensorTagDemo.html)

Then there is this gallery demo:

[http://example.qt.io/qt-
webassembly/quickcontrols2/gallery/g...](http://example.qt.io/qt-
webassembly/quickcontrols2/gallery/gallery.html)

The right sidebar right now doesn't scroll with standard mouse wheel. I had to
scroll it using mouse drag.

~~~
xigency
This is actually terrible.

------
nemetroid
Discussion on the blog post to which this is a follow-up:

[https://news.ycombinator.com/item?id=17525858](https://news.ycombinator.com/item?id=17525858)

------
madez
WebAssembly is yet another approach to withhold the source of programs from
the ones that interact with it.

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.

~~~
kalcode
This is a pretty ridiculous response. There have been compiled languages way
before interpreter/jit ones and these didn't halt the advancement of
programming and programming communities, especially the sharing code and ideas
part.

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.

~~~
madez
There are people that lobby for closed source and distribute closed source,
and there are people that lobby for floss and libre software. And then there
are hypocrites.

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.

~~~
Vinnl
Mozilla is also realising that the web needs to compete with native apps as
well. Note that it's even easier to hide the source of native apps.

(Furthermore, many apps that would use WASM probably have a significant
server-side part as well that is not necessarily open source.)

~~~
superkuh
At least native applications are something static you can verify. With web
'apps' like, say, anything based on electron, the end user has no control
about what code is run. Instead the 'app' just pulls down and runs whatever
the company/etc wants you to run dynamically and differently every time with
the permissions you gave originally.

~~~
Vinnl
Your mention of Electron is the perfect example of why this is no different
for native apps. Of course, on mobile this is usually mitigated through app
stores, but there is no reason similar mechanisms could be introduced for the
web if this really turns out to be problematic.

~~~
superkuh
Electron is not a native app. Electron is a browser web app marketed as a
native application.

~~~
nostalgeek
Chrome browser is only 50% of Electron. The other 50% is a complete nodejs
distribution which allows access to the OS filesystem, network, anything Java
or .NET can do on a desktop... So no, it's not just a browser web app.
Electron is absolutely native to the OS is runs on.

------
Dolanator11
No, not by a long shot. Remember how much time it took for an elaborate Flash
animation to load? Sometimes you had to wait for more than a minute before
anything even rendered on the page. And Java applets.. were a joke. A
Frankenstein approach to embedding applications in the browser. By contrast,
Wasm IS Javascript, even if the source code might be from another language,
it's a target for compilation. It will only be able to do whatever the browser
allows it to do, ie access Web APIs, work with the DOM or just do computations
that don't output anything UI-wise. This is not the return of badly executed
and badly thought-out plugins, this is "native applications in the browser"
done right.

------
WorkLifeBalance
Would it be possible to run the flash plguin/runtime in wasm to get the
benefits of flash (easy to produce, a lot of legacy content) with the sandbox
of wasm?

~~~
steveklabnik
In theory, yup! I haven't seen anyone try it though.

~~~
sebazzz
That is only up to Adobe or the developers of that other OSS flash
runtime/reimplementation.

~~~
kodablah
Not too sure. You can probably lift it to LLVM bitcode, e.g. with [0], and
compile back to WASM. But yes, not sure of the specific the DLL calls.

0 -
[https://github.com/trailofbits/mcsema](https://github.com/trailofbits/mcsema)

------
codezero
> That being said, the web standards process is healthier than its ever been

Some disagree: [https://www.eff.org/deeplinks/2017/09/open-
letter-w3c-direct...](https://www.eff.org/deeplinks/2017/09/open-
letter-w3c-director-ceo-team-and-membership)

Obviously it’s better in aggregate than the web of applet and flash times,
though.

~~~
steveklabnik
One failure does not mean the whole process is bankrupt.

~~~
codezero
Agreed, and I realize that your point was (I assume) more about the historic
hot mess.

~~~
steveklabnik
That’s also true. :)

------
j45
Wasm follows flash, java (applets) , jvm and even Javascript in the sense of
being one codebase that will run on multiple platforms and potentially
delivering on promises of the past.

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.

------
kowdermeister
Everybody who complained about JS the only language of the web should be
extremely happy about WASM.

~~~
fulafel
For most high level languages, JS is for the foreseeable future a much better
compilation target than WASM.

------
mrfusion
Remember when restaurant menus were in flash and you couldn’t open them on
your phone!

~~~
PretzelFisch
You could run flash on android.

~~~
artmageddon
Not all of us used Android when Flash was available for it

------
craftoman
WebAssembly is only the payback of any low level programming languages to
JavaScript. Truth is, there should be opening positions so they could eat some
pieces of the big pie too cause all those JavaScript kids became rock stars
for no reason.

------
jhabdas
If anyone wants to take a quick look at running a WASM app to take your
understanding from theoretical to applied look no further than Fabrice
Bellard's excellent BPG Image format and the JS decoders which build for
asm.js and wasm.

------
tambourine_man
> But implementers are important; they control the web.

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.

------
tboyd47
Klabnik makes a strong case for WASM here, and one I haven't really seen
anywhere else.

Now the question is, who will make the first major framework on top of WASM,
and for which language?

~~~
steveklabnik
Thank you!

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.

------
GenericsMotors
Wonder what its effect on the popularity of Javascript will be, given that it
can be used as a compilation target for pretty much any language (?).

~~~
steveklabnik
I'd look to the server side; JavaScript is still quite popular there even
though you can use any language.

~~~
GenericsMotors
Isn't that just a side effect of frontend devs being able to use their
existing JS knowledge serverside?

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?

~~~
steveklabnik
By that logic, they will also stick to JS instead of using WebAssembly. So,
same result.

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.

------
thermodynthrway
Java Applets were before their time. It took JS/HTML the good part of a decade
to catch up functionality and performance-wise

------
drawkbox
In a way yes. However there is other tech like WebGL, Canvas, web audio, web
video etc, even apps, that make up good portions of what Flash brought, where
WebAssembly is the compilation part of that and brings other languages into
the mix as the source for the outputted wasm/asm. It also brings faster native
runtime and hardware rendering capabilities when combined with other tech.
Flash and Java never had native nor good hardware rendering support, the
latter which was what ultimately killed Flash and the transition to mobile.

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_...](https://www.reddit.com/r/javascript/comments/34ps9z/why_was_es_4_skipped_but_typescript_is_taking_all/)

~~~
marcodave
Let's not forget that Flash-the-creation-studio-application was hugely
successful with amateur animators, which provided content for sites like
Newgrounds et al. Such artists were enabled to produce animations without
dabbling with programming.

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

~~~
drawkbox
Yeah Flash was amazing at attracting both developers and designers and led to
awesome games and some really innovative interactive experiences.

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

[1] [https://threejs.org/](https://threejs.org/)

[2] [https://helloenjoy.com/](https://helloenjoy.com/)

[3] [http://www.marketwired.com/press-release/flash-3d-vet-
ralph-...](http://www.marketwired.com/press-release/flash-3d-vet-ralph-
hauwert-joins-unity-technologies-1544586.htm)

[4]
[https://en.wikipedia.org/wiki/List_of_Flash_animated_televis...](https://en.wikipedia.org/wiki/List_of_Flash_animated_television_series)

[5] [https://www.toonboom.com/company/customer-
productions](https://www.toonboom.com/company/customer-productions)

[6]
[https://en.wikipedia.org/wiki/USAnimation](https://en.wikipedia.org/wiki/USAnimation)

[7] [http://www.openfl.org/](http://www.openfl.org/) \+
[https://github.com/openfl/openfl](https://github.com/openfl/openfl)

[8] [https://haxe.org/](https://haxe.org/)

[9] [https://github.com/openfl/lime](https://github.com/openfl/lime)

------
titzer
Thanks again, Steve, for a very clear and sober explanation of this. It's like
you're inside our heads! You grok.

~~~
steveklabnik
You're very welcome!

------
nostalgeek
TLDR; no, because WebAssembly use browser API, when Flash and Applets do not.
There is nothing that can be done in WASM that cannot be done with Javascript
API wise, whereas Flash was able to do socket programming 10 years before
webosockets and peer-to-peer 15 years before WebRTC.

------
fixermark
One can only hope.

------
bluetwo
Yes.

------
bosaisi
No.

------
jlebrech
you could technically rasterise your ui/video/content to a canvas at 60 fps.

so flash-like maybe and probably a step in the right direction, you can then
code in sdl/qt/gtk/etc.

~~~
kowdermeister
Which is precisely the reason it be used as utility libraries. Most CRUD apps
should remain JS/DOM based.

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.

~~~
jlebrech
i'd love to write markup that uses actually ui element names, even maybe no
markup but also allow css for theming purposes.

then js is to bind components to each other.

~~~
kowdermeister
A bit late, but React is your perfect match then :)

------
rgomez
Is this article's title clickbait?

~~~
steveklabnik
I had a conversation with someone about this on Reddit yesterday
[https://www.reddit.com/r/programming/comments/91s3pa/is_weba...](https://www.reddit.com/r/programming/comments/91s3pa/is_webassembly_the_return_of_java_applets_flash/e30ns6d/)

~~~
Vinnl
Perhaps an alternative that is more reflective of the actual content would be:
Why WebAssembly is not the return of Java Applets and Flash.

------
AnIdiotOnTheNet
Yes, absolutely. The only significant difference is that it isn't a plugin.

~~~
Drakim
One other big difference is that it's not owned by a single private company.
Adobe tried to monetize certain flash 3d features at some point, but was
rebuked so they withdrew their plans.

~~~
AnIdiotOnTheNet
Alright, I'll give them that. However, I think this will, like it has with the
rest of the web, lead to differences in how each browser handles the spec,
various browser-specific extensions, etc. In that way, it's actually worse
than having one company behind it.

~~~
j45
Wasm is the first major thing I can remember all the browsers agreeing on in a
very long time, or ever.

Agreeing of course, after trying to do it on their own and then realizing they
were thinking a lot of the same things.

~~~
SquareWheel
>Wasm is the first major thing I can remember all the browsers agreeing on in
a very long time, or ever.

Uh, flexbox, grid, fetch, service workers, even shadow DOM...? The cooperation
between browser vendors has been exceptional over the last five years.

~~~
j45
Are any of those as large and potentially as broad as wasm?

~~~
SquareWheel
For frontend devs, sure.

------
baybal2
>Other technologies were owned by companies

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

