
Universal Binaries Using WASM - grey-area
https://github.com/wasmerio/wasmer
======
adrianN
This talk was really prophetic [https://www.destroyallsoftware.com/talks/the-
birth-and-death...](https://www.destroyallsoftware.com/talks/the-birth-and-
death-of-javascript)

~~~
IshKebab
Maybe prophetic in the sense of "people really wanted this for years and it
has finally been implemented". People have been talking about it since at
least when NaCl debuted in 2011.

~~~
dijit
“If I had asked people what they wanted, they would have said faster horses.”
- Henry Ford

JavaScript by itself is not a “nice” language, I would ask what the root of
your request is: an easy garbage collected language that is ubiquitous?

~~~
derefr
This "long-held fervor" that culminated in WASM started back before Node.js
existed, so back then, "Javascript" was just a thing browsers did (except for,
say, Windows Scripting Host's support of it.) The fervor back then wasn't
really driven by a desire for a _ubiquitous_ anything; it was driven
specifically by people thinking about browsers, and what is required to
program web-apps in browsers.

What people have wished for, since... oh, 2001 or so, is the ability to write
web-app frontends without needing to grok and deal with the awful runtime
semantics of Javascript—the way you do when you write Javascript, yes, but
also the way you do when you write in a language that directly transpiles _to_
Javascript, like TypeScript or ClojureScript.

Languages like TypeScript may _add_ semantics _on top of_ the JS runtime's
semantics, but they can't get away from the fact that the JS runtime is the
"abstract machine" they program, any more than e.g. Clojure can get away from
the fact that the JVM is the abstract machine it programs. That's why none of
these languages were ever seen as a "saving grace" from the "problem of
Javascript", the way WASM is.

WASM has its own abstract machine (which runs efficiently in browsers), which
finally frees people from the tyranny of the Javascript-runtime-as-abstract-
machine.

It's great that it's also now replacing the Javascript-runtime-abstract-
machine in other contexts (e.g. Node-like server-side usage, plain-V8-like
embedded usage) but that was never really "the thing" that anyone cared about.

\---

Mind you, the NaCl fervor _was_ for a ubiquitous VM—but the NaCl fervor wasn't
nearly as large, and isn't really what's propelling WASM to prominence right
now. Even then, it wasn't about "an easy garbage collected language that is
ubiquitous", no. The goal of it was to be able to take code that you already
have—native code, written to run _fast_ , like a AAA game—and put it in a
browser-strength sandbox, such that it can be zero-installed just by visiting
a URL, with full performance. You know, like ActiveX was supposed to be. But
better.

NaCl didn't really get us there, because it happened right as the
architectural split between x86 and ARM really started heating up, and NaCl's
solution to that split—PNaCl, a.k.a. sandboxed LLVM IR—was both too late and
not really efficient-enough at the time to fully supplant the "Native" NaCl in
NaCl messaging. (LLVM IR works well-enough _now_ for Apple to rely on it for
being a "unified intermediate" of both x86 and ARM target object code, but
that shift only began with ~8 additional years of LLVM development after the
version of LLVM that PNaCl's IR came from.)

WASM _seems_ to get us there. But do we care any more? Everyone already has
other solutions to this problem. ChromeOS can run Android apps; Ubuntu Snappy
packages can expose GUIs to Wayland; Windows has a Linux ABI to run Docker
containers. Ubiquity is a lot easier now than it was back then, for any
particular use-case you might want.

On the embedded-scripting side of things, everyone has seemingly settled on
embedding LuaJIT or V8. Do people even need embedded scripts to be fast, in a
way that "WASM as compilation target" would help with? Maybe for the more
esoteric use-cases like CouchDB's "design documents" or the Ethereum VM
([https://medium.com/coinmonks/ewasm-web-assembly-for-
ethereum...](https://medium.com/coinmonks/ewasm-web-assembly-for-
ethereum-54719ece2042.)) But I doubt WASM will hit ubiquity here. Why would
OpenResty switch? Why would Redis? Etc. You're not writing-and-compiling
_native code_ for any of these in the first place, so adding WASM here would
only break existing workflows.

~~~
int_19h
> What people have wished for, since... oh, 2001 or so, is the ability to
> write web-app frontends without needing to grok and deal with the awful
> runtime semantics of Javascript

It was so even before 2001. Consider why the <script> element as the "type"
attribute to begin with (and why it had the "language" attribute originally,
before "type"). As I recall, W3C specs from that era gave examples such as
Tcl! On Windows, you could use anything that implemented Active Scripting APIs
- e.g. Perl. JS just happened to be the one that everybody had, because it was
the first, and so it became the common denominator, to the detriment of the
industry.

------
youareawesome
This project has been known to copy code from other projects without
respecting licenses. The founder of ethereum pointed this out a few weeks ago.

[https://twitter.com/gavofyork/status/1094597005333151745](https://twitter.com/gavofyork/status/1094597005333151745)
[https://twitter.com/Sunfishcode/status/1075486397824327681](https://twitter.com/Sunfishcode/status/1075486397824327681)

The extent to which the people in this project took "inspiration" from wasmjit
has been questioned as well
[https://github.com/wasmerio/wasmer/commit/a81500e047fdd321b3...](https://github.com/wasmerio/wasmer/commit/a81500e047fdd321b3dd3f9fabb87fecbd2d7792#diff-9c2f6a65948817d0ab677942d577d2d0)

~~~
justinclift
Looks like they made a mistake, apologised, and have added attribution since?

~~~
youareawesome
When they were called out privately, no mistake was admitted and no action was
taken. The attribution was only added after they were called out publicly.

~~~
ozzmotik
a problem fixed under less ideal situations is still a fixed problem
regardless.

~~~
youareawesome
Do you think they would they have fixed the problem if they weren't called out
publicly?

~~~
ozzmotik
i don't think it matters because they __did__ fix the problem. maybe that
would have been a problem in the past before the problem became acknowledged,
but the thing is, that isn't the case anymore and so to me it really doesn't
matter. but even if it did matter, i still probably wouldn't care. sometimes
people need convincing to do a thing and when it comes to presenting a
consistent and positive image to others, i think it's quite a generally good
thing if someone is responsive to the criticism of others and actually acts on
it. maybe they should have fixed it before of their own accord. but maybe
before they didn't see the issue that others saw. people aren't perfect any
they make mistakes. constantly.

~~~
youareawesome
Do you think it's possible that this wasn't a mistake and instead they acted
with malicious intentions and only fixed the problem to minimize the negative
PR fallout? If not, why not?

~~~
ozzmotik
i sure think it's possible but my decision is binded by Hanlon's razor in this
case. don't attribute to malicious intent that which is attributable to
stupidity/neglect/etc. so I mean it's possible they had malicious intent, but
i mean, really, what did they stand to gain by having it? to me it just seems
more likely that they just didn't notice.

~~~
youareawesome
Do you think potentially malicious behavior should be overlooked or made
known?

~~~
ozzmotik
i think it's for the best if such is done, yes, but then the question becomes
potentially malicious by whose standard? for instance, if we were to operate
off of what your perspective appears to be, then you (appear to) have the
preconceived notion that the actions were indeed malicious and if anything it
would seem you're seeking to gratify your inherent confirmation bias as a
human rather than attempting to discern the actual nature of things. of
course, i don't want you to think im saying you're doing any of this with
absolute certainty as im not sure we can know anything with such clarity, but
more just that in these situations it pays to have a third party that is
ultimately detached from either outcome to determine which interpretation is
the most valid one. also words

~~~
youareawesome
I agree that attention should be drawn to potentially malicious behavior.

I don't know that the actions were indeed malicious but there is evidence to
suggest that they may have been and I'm doing my small part to make the
greater community aware. This will enable the community to make wiser
judgments in the future, if the need arises.

------
kostaw
For those thinking that this is just Java and Flash all over again: Here's the
relevant blog post from Steve Klabnik explaining why this is _very_ different:

[https://words.steveklabnik.com/is-webassembly-the-return-
of-...](https://words.steveklabnik.com/is-webassembly-the-return-of-java-
applets-flash)

~~~
userbinator
_There’s another reason Wasm succeeded: it’s tiny._

I'll agree with him that Java is very much _not_ tiny, but I disagree about
Flash. The last time I remember setting it up, the browser plugin was a single
binary of a few MB (and I'm sure that could be made smaller.) SWF files are
also a great example of a well-designed space-optimised vector graphics format
--- remember that it was designed close to 20 years ago for the computers of
the time.

Edit: care to explain, downvoters?

~~~
vorpalhex
Flash _runtime_ was several hundreds MBs. Sure the actual applets were a few
mb of mostly animations and resources, but the runtime was another thing.

~~~
aepiepaey
The runtime is ~15MB, far from hundreds of MBs.

~~~
stcredzero
Back in the early 2000's, IIRC, Squeak Smalltalkers succeeded in getting a
Smalltalk runtime down to 385 kB. Haters still complained about it being "too
fat." There was an R&D project which got one Smalltalk image for a Unix-style
command line utility to 45 kB. Back in those days, the standard class library
for a VisualWorks Smalltalk image was about 12MB on disk.

In contrast, Perl had a runtime of something like 768 kB. Yet, VisualWorks
could load its runtime faster, if you tweaked things, like shutting off the
boot-up chime and notifier dialog.

~~~
derefr
> Yet, VisualWorks could load its runtime faster, if you tweaked things

For the same reason that Emacs loads quickly: the "image" is (an abstracted,
runtime-dependent equivalent to) a memory dump. Perl has to parse Perl code
when it starts up; Smalltalk just "is" Smalltalk when it starts up. Like
booting up a DBMS where the DB already has data in it.

Honestly, I'm kind of surprised more modern languages/runtimes don't take this
approach. The Smalltalk approach would work exactly as well for e.g. Ruby.

~~~
simcop2387
It leads to a lot of issues with the end design of everything. You either have
to reconstruct the heap and all the pointers involved, or it has to be loaded
at a known address. With things like ASLR, and a bunch of other security
features this ends up difficult or impossible to do directly anymore. Along
with that, it also means that the runtimes aren't cross-compatible at load
time so weird differences might leak out (little or big endianess, etc.). It
leads to a lot of headaches because of changing systems underneath it.

------
plq
This is one of the logical next steps towards mass WASM-adoption. Another was
Cloudflare's Isolates [1].

There needs to be official OS support from vendors (MacOS, Windows and Linux
distros) in order to avoid the stinking pile of non-shared shared library mess
that is electron.

[1]: [https://blog.cloudflare.com/cloud-computing-without-
containe...](https://blog.cloudflare.com/cloud-computing-without-containers/)

~~~
jacobush
So, we are officially campaigning for Javascript as the default language for
everything now? :-(

~~~
degurechaff
WASM is not javascript

~~~
AnIdiotOnTheNet
Funny, I hear often that "WASM is just javascript" whenever I compare it to
Flash and Java, as a defense for why it is different this time and totally
won't have any of the problems of those other runtimes.

~~~
afiori
Because wasm runs on the same javascript and not as a separate plugin. It will
be a major feature of the browser and be automatically updated with it. (also
it allows for feature discovery)

It has no relation to ecmascript, but you could say that it is integrated in
(but independent from) javascript.

People say that it is not javascript because you can use ALL of the wasm
toolchain without any trace of javascript.

------
bluejekyll
Ok, strawman using Rust (pick your favorite WASM capable language): I write in
Rust, that is alreasdy a decently portable language. Most likely WASM will be
on many of the platforms the LLVM allows Rust to target. Most Rust libs are
cross platform capable (Linux, macOS, Windows, etc).

Now, when I target WASM I get one obvious thing, compile once deliver
everywhere, with some overhead hit. Versus produce binaries for everything and
distribute.

Is gaining the universal binary (with WASM runtime) enough? The reason I’m
excited about the Web target for WASM is that I gain the entire web platform
from my favorite language.

I’m 50% excited and also baffled by this. Now, as an embeddable language
runtime in other software, that’s interesting...

~~~
steveklabnik
Maybe, maybe not, in this specific scenario.

But it's not the only scenario. Imagine, for a moment, that you're not
distributing your own binaries; you're in the business of running them,
possibly from untrusted sources. And that's just one other scenario.

~~~
bluejekyll
So the Cloudflare perspective. Yes, it’s interesting.

~~~
steveklabnik
Or the “script my application with wasm” perspective, or the “smart contracts
for blockchain” perspective, yeah. Think “docker”, in some ways.

------
yami
Amazing! It's like we could write once and run everywaaaait a moment...

~~~
sacado2
But now you can choose your own programming language. The JVM is very Java
centric, for obvious reasons.

~~~
shellac
Obviously its purpose was to support Java, but a number of languages - most
prominently Scala, Kotlin, Clojure, Groovy and Ruby - run on the JVM. With
perhaps the exception of Kotlin, these are not especially Java-like.

There is an interesting degree of independence. A lot of Java semantics is not
baked into the JVM, and in the case of invokedynamic there was for a time a
significant JVM feature that java didn't use.

The JVM is a pretty decent target for languages with garbage collection,
objects (of some form), and methods / functions. Those facilities are useful
for most languages these days, and provide a large degree of interoperability.
I don't have to really thing about ruby calling java and back again, no
calling conventions or issues with garbage.

It will be interesting to see whether WASM will support those kinds of
features.

~~~
jsight
Names matter, though. For as long as the JVM has been called the "JVM" it has
been associated with the Java language.

Using the Java language on other VMs confuses people in exactly the same way
that using the Java Virtual Machine for other languages confuses people.

The outcome might have been different had they called it something like HLVM
instead of JVM.

~~~
Volt
Taking this further, wouldn't this imply that WebAssembly is only for the Web?

------
spease
Very impressive. Is this compatible with any WASM-compliant language, or just
the ones listed? EG AssemblyScript:

[https://github.com/AssemblyScript/assemblyscript](https://github.com/AssemblyScript/assemblyscript)

I'm looking forward to seeing some benchmarks comparing native binaries with
the same program run via wasmer.

~~~
mkl
It says it runs compiled .wasm binaries, which should mean any language. I
think the listed languages are those targeted for interoperability.

~~~
syrusakbary
That's right.

Wasmer executes any wasm binary, including AssemblyScript generated ones :)

------
skybrian
The hard part will be coming up with portable API's that can do the things
that native apps can do.

Consider that browser standards include an enormous amount of functionality
and new web API's are getting added all the time, and yet, many people claim
that web apps can't compete with native apps on phones or desktop. Also, even
if you just pick one of these, there have been many attempts to come up with a
portable way to write apps for both iOS and Android, and it's getting better
(see Flutter for example), but it's still a lot of work for the implementers.

Docker got around this by standardizing on Linux (including the filesystem),
but the client side is much harder.

So I suspect that for a "universal" file format based on WebAssembly to get
anywhere, it will have to succeed in some niche not served well by web
browsers, Docker, or Unity.

WebAssembly itself is useful in the way a fast interpreter for a scripting
language is useful - as an embedded component of some larger runtime. Its
potential customers are teams that would otherwise need a scripting language
and choose WebAssembly instead.

~~~
flohofwoe
One realistic use case that comes to mind for WebAssembly modules outside the
browser is extension plugins for tools like Maya, 3DSMax or Photoshop. For
such cases it's usually ok to provide a restricted set of APIs, but you gain
binary compatibility across platforms and performance that's much better than
(for instance) Python or Lua scripting.

------
aaaaaaaaaaab
Can’t wait to have popups on my desktop telling me to update my WASM runtime
to the latest version!

~~~
marmaduke
And each app shipping its own copy

~~~
kozak
Electron apps already do.

~~~
marmaduke
Indeed my comment was a variant on the electron meme to this effect

------
mkl
Embedding in other applications seems useful - imagine using it as a general
plugin system. It's a bit strange that security and sandboxing aren't
mentioned; that seems like WASM's primary value proposition here.

~~~
pavlov
Those plugins still need an API in some language to interface with the host. A
natural choice would be JavaScript: it's the world's most popular programming
language, relatively easy to embed, and runtimes are available in every
operating system.

At that point, you don't need WASM separately — just execute JavaScript and
allow plugin writers to embed WASM modules for high performance, just like
browsers do.

~~~
mkl
Well, if you were doing that, I don't think you'd need wasmer. V8 alone would
be enough. Wasmer seems like an attempt to get away from Javascript and
interface more directly with WASM.

------
jokoon
Any real, simple c++ toolchain compiling directly to .WASM?

Emscripten is not really user friendly.

Time is passing, WASM is here but I can't see decent toolchains available to
work with it.

~~~
flohofwoe
Depends on how you define "user friendly". IMHO emscripten does what a gcc-
compatible C/C++ toolchain is supposed to do:

> emcc hello.c -o hello.html

...which gives you a complete WebAssembly application runnable in the browser.

With VSCode as IDE it's possible to build a fairly nice edit-compile-test
workflow with Intellisense and error squiggles.

BUT:

What's really missing is proper debugging support (can mostly be worked around
by debugging a platform-native executable compiled from the same source, but
working source-level debugging for WASM blobs would be nice).

------
tambourine_man
Is anyone working on something like a POSIX layer on top of it? And maybe,
someday, a GUI? We have universal binaries now, but what APIs will we call?

------
richardwhiuk
What problem is this possibly solving? Why wouldn't you just compile your
Rust/Go to a native binary?

~~~
thefounder
A portable binary like wasm makes deployment easier and potentially makes it
more secure/easier to sandbox.

~~~
richardwhiuk
Makes deployment harder surely? Now you need to both ship the wasm runner and
the compiled code of the executable?

~~~
thefounder
The host is supposed to support wasm and most hosts will do.

~~~
mr_toad
With about 50% of corporate desktops still using Windows 7 with IE11 as the
default browser - it’s going to take a while before wasm is truely ubiquitous.

~~~
maxgraey
That's not true: [https://bit.ly/2GMbAN3](https://bit.ly/2GMbAN3)

------
kgraves
Fantastic! This makes me extremely excited about WASM! (Bonus points for Rust)

------
willvarfar
What's the strategy with dealing with 32-bit vs 64-bit machines?

Historic attempts at using LLVM IR as a universal binary have stumbled on that
issue, and typically have ended up deciding to support the lowest-common-
denominator machines i.e. 32-bit, meaning that it hasn't been viable to use
them for server-style software.

~~~
maxmcd
Wasm is split between wasm32 and wasm64 they are separate
[https://github.com/WebAssembly/design/blob/master/FutureFeat...](https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#linear-
memory-bigger-than-4-gib)

So yes, we're at the lowest common denominator for addressing memory. You
would need to explicitly build for wasm64 in the future.

Within wasmer wasm is compiled into a different IR through cranelift. That
generally compiles for 64 bit systems but can compile to 32:
[https://github.com/CraneStation/wasmtime/pull/44](https://github.com/CraneStation/wasmtime/pull/44)

Not sure if this entirely answers your question. Seems like there are still a
handful for decisions wasmer would need to make in terms of what exactly is
supported.

------
klunger
If you are having trouble wrapping your head around WASM (it is a bit funny --
almost but not quite analogous to several more familiar paradigms), I highly
recommend this series of posts: [https://hacks.mozilla.org/category/code-
cartoons/a-cartoon-i...](https://hacks.mozilla.org/category/code-
cartoons/a-cartoon-intro-to-webassembly/)

------
pjmlp
Ah, Pascal UCSD!

------
stcredzero
We should bring back a platform like TAOS.

The TAOS operating system (1991) had a virtual Instruction Set Architecture
(ISA). Except for a small kernel, the entire OS was compiled to the virtual
ISA, then assembled into actual machine code Just In Time as fast as the
executable was being read off disk.

This resulted in an operating system that could run with decent speeds (80-90%
of native) on seemingly any hardware, which could be ported to a new platform
in just 3 days.

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

~~~
runeks
How is this different from compiling Linux from C to LLVM to native code?

And why would I ever want to generate native code for an OS at runtime?

~~~
stcredzero
_And why would I ever want to generate native code for an OS at runtime?_

Why? To get write once, run everywhere. If you can do the generation at the
speed the data comes off the disk, you're paying nothing for the feature.

If you do things right, the abstract memory model can even be bit-identical.
Even though there are differences in the underlying hardware, like endianess,
all of the virtual ISAs can still implement the same virtual memory model.
Smalltalk also does this, and it absolutely works across 100's of combinations
of ISA and OS.

------
dmitrygr

      > curl https://get.wasmer.io -sSfL | sh
    

Why do people still do this? What happens when owner of the domain forgets to
renew it and someone else buys it, and puts up a copy of this site, with the
binary replaced? Or if the owner sells it to someone malicious who does that?
Or someone messes with your DNS server to serve that?

Please please please never do this.

Oh, and _SERIOUSLY_ question the ability of anyone who suggests doing this to
at all reason in a secure fashion.

------
jayd16
This is neat but it has me thinking. Is there a similar project that allows
linking wasm libraries into your LLVM language of choice? Seems like that
could allow for shared libraries across languages. The lib would take some
perf hit but your core project perf could be unaffected.

------
unnouinceput
So ActiveX / Java applets, then Flash and now this. Yeah just another fad. It
will pass, and next generation of developers will think something else to make
the "holy grail" that is cross-platform everywhere with native speed. And so
on and so forth.

------
kevin_b_er
[http://troubles.md/posts/wasm-is-not-a-stack-
machine/](http://troubles.md/posts/wasm-is-not-a-stack-machine/) wasm is
already tainted by the legacy of javascript. It was intended as a replacement
for asm.js and carries the burden of being too intended to be with javascript
and as a way to get "faster javascript" due to how poor javascript is at
executing efficiently.

The result is what I'd consider a poor mans java bytecode. The legacy of java
was bloat connected to the runtime and its massive standard library coupled
with nasty Sun then Oracle burden. And Oracle again being Oracle with what
feels like more more lawyers than engineers to threaten.

So we tossed out a standard library and made a poor man's java virtual machine
model.

This is java again, it just has massive hype because its better than
javascript at actually running efficiently. But it can still be worse than any
given other virtual machines out there.

------
decafbad
I'm guessing that's the point everyone should see. WASM is going to be the new
bytecode that works everywhere. If that's not the reason of even Golang
started to support Webassembly, I would love to hear your your conjecture.

------
hypfer
Its literally Java all over again.

Don't. Just. Don't.

~~~
rkangel
Why not? A single cross-platform compilation target seems like a great idea.

Java got caught up with some proprietary stuff thanks to Oracle, but there's a
useful goal there. In the same way that the web is a useful target for cross-
platform UI applications.

~~~
pjmlp
As if under Sun it was all flowers and such.

------
seanwilson
Why is this post generating so many low effort joke comments? Is the project
idea really that bad or are people missing the point?

It's sad to see people wailing on a project that (I'm assuming) people have
put a lot of time into without trying to understand what it is and what it
isn't.

~~~
kowdermeister
I think because it's very easy to see it as something familiar. People are
always skeptical about new stuff plus that familiar thing was shit so this
must be shit too.

So no critical thinking leads to lame jokes and "OMG NO JAVA" style comments.

~~~
arendtio
Well, the concept is arguably very close to what Java was marketed for. So I
think it is quite natural to respond with some kind of Java association.

Nevertheless, I think this is a very interesting project.

~~~
afiori
It is close in the wording but very different in almost every other sense.
wasm pushes for many indipendent implementation, it is meant to be very
minimal and importantly it is made to be embeddable. In a sense it is closer
to lua than Java.

~~~
runako
At the risk of jumping into this, Java was intended to be small (small enough
to run on processors that were below PC-class in the 1990s) and embeddable.

[https://www.javaworld.com/article/2073700/mobile-
java/mobile...](https://www.javaworld.com/article/2073700/mobile-java/mobile-
java-java-everywhere-is-for-world-domination.html)

The idea of Java running on devices goes back AFAICR to the very beginning of
the language. I remember the "Java everywhere" slogan and initiatives to put
Java into every device. Java Card was a version of Java designed to run on
smart cards. If memory serves, these were all design goals of the Java
platform in the early 90s.

(Remarkably, this was all well before Linux really took off, before the
Internet was ubiquitous, and when the most sophisticated electronics most
households owned was a VHS player.)

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

~~~
afiori
There is indeed a risk that Wasm will end up bloated and fail at its main
purpose.

Supporters hope that the web process will prevent excessive features. Actually
the dual presence JS/wams will reduce the pressure on JS to be a strong
compilation target.

I agree that (almost) no single aspect of wasm is new, but it has a lot of
good points.

------
titanix2
> Build Once, Run Anywhere.

Build once, run where the runtime in available.

~~~
ubercow13
Kind of like Java

~~~
thefounder
Java is slow(to start) and memory hungry. That's why it failed so badly.
Compare that with JavaScript/Electron.

~~~
krapp
>Compare that with JavaScript/Electron.

Electron is heavier and even more memory hungry.

~~~
StavrosK
I don't know what the GP was thinking. Hopefully exactly that.

------
vkaku
Except the Web part, it looks good. The portable object that nobody agreed
upon now happens to be a eloquent JS representation _Sigh_

~~~
ZenPsycho
that isn’t what wasm is.

~~~
vkaku
I remember running good old text WebAssembly about 7 years ago, which is
admittedly cool - I was even waiting for Chrome to support it before I gave up
on that. I remember how people had to ship a gzip-ed Unreal engine on the web
for the first version;

My quip is how the C++ community miserably failed to ship a portable object
that could have been used for module based compilation / linking without the
AST generation overhead.

Unless wasm really becomes the package/intermediate standard for code, I
wouldn't really regard it as useful yet. It would be another Java for me.

