Choose HTML5. Choose Node. Choose your fucking social networking sites. Choose open APIs and a per-year subscription model. Choose microformats, micropayments, and SOA. Choose targeted mobile advertising. Choose user-contributed content. Choose your widgets in a range of matching Bootstrap colors. Choose a CDN, or two, or three. Choose the long-tail and wondering who the fuck you are on a Sunday morning. Choose surfing on that walled-garden device, a machine you paid for but do not own, watching mind-numbing, spirit-crushing videos, stuffing fucking junk food into your mouth. Choose rotting away at the end of it all, pissing your last in a miserable home, nothing more than an embarrassment to the selfish, fucked up followers you spawned to replace yourself. Choose your future. Choose WebAssembly.
(Not my idea, I just updated it for the times. Please don't mod down for foul language kthx, it's a homage to the original.)
That’s a big downside and something I don’t like. But if we get actual universal bytecode out of it, it will have been worth it. Every platform out there, with the same bytecode and with a myriad of OSS languages out there able to target everything under the sun. It would take us out of the dark ages of having everything in C cause lowest common denominator...
Honestly the whole thing is like a bizarro Java world. Everything is significantly worse than the comparative technologies, some of which are 20+ years old. package.json is worse than pom.xml, build.ts is a bizarro build.gradle, and the vm itself doesn't even begin to compare. There's some kind of market failure going on when browser providers are devoting millions of dollars to poorly reinvent the wheel. On Android we'll be seeing 3 VMs running on top of each other. It's insanity. Frankly it does not inspire confidence in the future of browsers as a platform.
The VM may or may not compare, from some abstract standpoint, but:
1. the startup time and upfront memory usage of V8 and other JS VMs is incomparably lower (better) than that of HotSpot; and
2. Java in the browser was relegated to gray opaque squares, while JS / Wasm has control of the entire viewport and all browsers APIs.
Those two points alone make it a clear winner. Not to mention the horrible security track of Java, probably due to the complexity of its implementation.
Even back in the day, the correct answer was Sun's HotJava, running applets within a native Java runtime, which was killed in the crib to appease NetScape.
You've heard the cliche about how sufficiently complicated 'C' programs recreate LISP, only poorly?
20 years recreating WORM applets. 20 years recreating grid computing and software agents (now pimped as 'serverless').
Imagine the world today if Sun had had some saavy championing their own tech.
#2 Canvas. The inevitable omega point will be tunneling X-Windows thru the HTTP, HTML, CSS, JavaScript (WASM) obfuscation & error injection gauntlet.
> On Android we'll be seeing 3 VMs running on top of each other. It's insanity.
Why does it follow that development of abstractions will lead to people stacking endless VMs on top of each other? Javascript runs on Android today in a native VM, not a java-based one. Why would that change in the future?
Java would have really rocked the client side web world if Sun had figured out the interface between DOM and Java applets instead of pushing their GUI implementation.
This is why Stallman says we need to push to have a link out to the un-minified (or in this case source code that led to the WASM) so that people can go and read the source.
We already have this, there's nothing stopping you from using source maps in production. They're automatically loaded by browsers and can contain the full source code.
I've never seen a Lisp machine, but when I use Chrome's developer tools, which can display complex, interactive objects right in the text console, that's what I think about.
not only that, the fact that you have programmatic access to low level semantics up to presentation into a "single" window and language. Very dynamic and multilayered
Nice video but (unrelated to the IDE) in order to use a printf from js it was necessary to:
provide a js emulated syscall to c file
that calls another c function that calls back to js again
Yeah, it’s super weird when most people are expecting this to compile into JavaScript running in a browser. Nevertheless, to be fair, this isn’t a C, C++, or Rust to JavaScript compiler-compiler it’s a C, C++, or Rust compiler that targets WebAssembly. I realize this might read as overly pedantic but it explains why it makes sense to the implement the C interface. It’s also a reasonable optimization pass for a mature compiler when it knows that you’re targeting WebAssembly running in a browser.
The WebAssembly Studio may track its usage through telemetry. We use this information to improve user experience. This information is not made publicly available.
env: {
__syscall0: function __syscall0(n) { return syscall(instance, n, []); },
__syscall1: function __syscall1(n, a) { return syscall(instance, n, [a]); },
__syscall2: function __syscall2(n, a, b) { return syscall(instance, n, [a, b]); },
__syscall3: function __syscall3(n, a, b, c) { return syscall(instance, n, [a, b, c]); },
__syscall4: function __syscall4(n, a, b, c, d) { return syscall(instance, n, [a, b, c, d]); },
__syscall5: function __syscall5(n, a, b, c, d, e) { return syscall(instance, n, [a, b, c, d, e]); },
__syscall6: function __syscall6(n, a, b, c, d, e, f) { return syscall(instance, n, [a, b, c, d, e, f]); },
