Why WebAssembly Is Faster Than Asm.js
hacks.mozilla.org
hacks.mozilla.org
The real questions are: what are you really doing that actually couldn't be done with Craigslist-level technology? Does your application need to look and feel the way it does because you want show off what you are capable of, or because your customers would actually like you less if you did less?
What people keep missing is that the Web isn't a platform, it's an idea: It's the idea that the lowest common denominator, or whatever crappy text-based document format is supported in every single device ever made, is actually good enough for almost everything. And you can add fanciness, and you can add features, but the weight of the web pulls all content towards that lowest common denominator.
This drives iOS developers crazy, because they want to be special snowflakes who make animations that run at 100hz and might make Dieter Rams notice them in the lunchroom. Platform after platform keeps challenging the web, and the web keeps chugging along. Because the web is not a tool, it's the idea that we should communicate with as many people as we can, and to do that we should use the simplest technology that will do the job.
The future has changed! https://www.destroyallsoftware.com/talks/the-birth-and-death...
Plus, the concurrent model of Go doesn't really shine if you run it in a single threaded configuration (which is most likely to be the case in wasm).
I might be missing something but to me it sounds like pure hype to put go and wasm together.
Even with GOMAXPROCS=1 (1 CPU running Go code), it's very liberating to be able to write blocking Go code and not worry about callbacks or async/await and let Go's runtime deal with it all while you write concurrent code.
I'm not, it's just that the most appealing feature of Go is it's ability to use parallelism for concurrency with a decent overhead, which makes it straightforward to scale vertically.
> Even with GOMAXPROCS=1 (1 CPU running Go code), it's very liberating to be able to write blocking Go code and not worry about callbacks or async/await and let Go's runtime deal with it all while you write concurrent code.
IMO, Async/await is a much cooler pattern than Goroutine + channels do do concurrent stuff on one thread. I find it way easier to use, and less error prone. The drawback is that you need a different paradigm when you want to take advantage of parallelism.
Of course it's a matter of personal preferences, but the prevalence of async/await in different programming languages indicates that at least I'm not the only one thinking this way :).
Running other languages(than JS) in the browser is interesting for sure.
a) binary portability - compile and ship WASM link/run on any machine with WASM VM - eg. package up to NPM and run trough any V8 target
b) extra sandboxing layer for security (it's designed for browsers where you are supposed to run non-trusted code)
c) portable APIs (assuming WASM targets expose the same underlying platform like node or w/e)
d) WASM is single threaded right now but from what I've seen it's a top priority for next release to spec out shared memory threads
a) and c) means it's portable on everything a JS VM runs on, which is not that much more than what Go runs on.
b) is legit, but that really sounds like an overkill.
No. It also has non-JS accessible language features, and the article lists several of them.
Sort of, but not exactly. See section 2 of the linked article.
The silver lining, is that many things usually get better the second time around. Let's see what WASM hold - it's pretty limited in its current form.
FTFY.
The second time around is usually so troubled by politics that there's an entire Wikipedia page about the topic of the second-version syndrome.
And WebASM is in every way inferior to Java still.
If the sandbox didn't have so many holes in it Java applets were arguably better for webapps than the unholy mess we've cobbled together over the last ten years to replace them.
It's sad to me that Java fell out of the browser and was replaced with a slow non standardized single threaded shit language for almost ten years just because Java didn't have DOM access.
JavaScript is just nearing Java feature parity and still not anywhere close for performance.
And I'll tell you what Java didn't have. A unfathomable clusterfuck of module systems, transpilers, shit build tools and IDE support, crazy syntax gotchas, unholy and inconsistent exception handling systems. God dammit what have we done.
Shakes cane at neighborhood kids
If Java were our only option I assure you we'd have come up with all kinds of crazy alternative systems of doing things.
Plus, targeting the JVM for weird transpiled language was what all of the cool kids did before doing it in JS became cool. This isn't unique to JS. It's probably unique to any language with that much adoption.
Pretty much. If Sun had made a decent plugin instead of expecting every browser to roll their own VM, and if AWT had been a lot less buggy, it could have worked.
A unfathomable clusterfuck of module systems, transpilers, shit build tools and IDE support, crazy syntax gotchas, unholy and inconsistent exception handling systems.
Amen. It's ridiculous how many millions of engineer-hours have been spent trying to turn JS into a usable environment.
It's not just JS: https://en.wikipedia.org/wiki/List_of_JVM_languages
Java ran pretty damn good for what it pulled off back then. It would have been orders of magnitude easier to make Java into what we have today than it was to bastardize HTML and JS to be usable.
Java these days uses native UI which looks nicer and is much faster than in-browser rending. Graceful degredation is only needed because some browsers are such crap. This was never a big problem in Java and still isn't. If a JVM supports JDK 8 you can expect it to run java 8 apps reliably
Java seems like a resource hog because it will use spare ram when you've got it, but most apps run fine on around 15mb of ram. Less if you use AOT compilation. Modern webapps use around 50-100.
> had weird clunky UIs that were out of place in the host OS and the browser
Just like web apps, the may be prettier, but they look just as out of plus with custom widgets everywhere and complete disregard for the desktop theme. Hell, for some reason chrome added that shitty task bar color attribute that allows a web page to alter the desktop (well mobile top) theme.
So, Java wasn't ahead of its time, and it was much much worse than Flash (which, despite numerous efforts to kill it, is still alive, unlike Java Applets which have essentially been dead for years).
Too be fair though, it's a hard comparison, applets were generally apps while flash was fancy graphics.
My memory from the mid/late nineties is that Microsoft wanted to balkanise Java with J++ (or was it J# ?) and got into a big argument with Sun, and because of this and the fact they eventually came to own the browser market there was no way they'd embed a JVM in the browser.
Java is slow on the first run (even if you admit it is just the JVM running your already compiled code). Try running a different java code in every site and you will understand why JS is prefered to it.
Also JS has a foot in functional programming and is much less verbose, it also has evolved to be even leaner. e.g. The current lambda syntax (fat arrows) is a treat
I wanted to point out, however, that Java 8/9 has excellent support for basic functional programming features, with an equally-nice syntax for lambdas, but with a good type system (via Functional interfaces) to boot.
The thing that I get hung up time and again, with ES6/7, is lack of a type system. We write some complex ES6/7 + Immutable JS apps (e.g. in the financial services domain), and haven't managed to extract full value from Flow or TypeScript just yet, due to library constraints etc.
I would like to look into the Java functional approach. Is there any reference you recommend ?
I've always been deeply into it, and using it for years at work, so no good off-hand reference. I'd be picking one as random as any web search that you'd perform, sorry!
I should never have learnt Haskell. It messes with your mind [1] whenever you write in any other programming language, yet you can hardly ever use it in practice. Well, certainly here in South Africa.
[1] Obligatory link: http://www.xent.com/pipermail/fork/Week-of-Mon-20070219/0441...
It is amazing the amount of stuff that JS does if you don't follow the trends blindly and think a bit about your usage and tools.
Webasm still can't manipulate the DOM, so it's still not very useful as a replacement for JS, but it is planned. To really replace JS though, we'd need webasm to support garbage-collected languages for ease of use. Probably, some dynamically typed languages as well.
Well... see https://en.wikipedia.org/wiki/NPAPI#LiveConnect
Now it's true that it involved more hoops, especially for someone who just knew Java but not DOM bits, so implementing a GUI using Swing or whatever was a path of least resistance. But it wasn't the only path.
> Webasm still can't manipulate the DOM
Not directly, but via FFI to JS it can.... Pretty similar to LiveConnect in some ways.
The difficulties for language developers are on two fronts really. #1 is producing WASM in a compiler backend, instead of LLVM IR / Java bytecode / bare machine code. #2 is getting the language small enough to be possible and not wasteful to implement in wasm. You don't have a filesystem, or really anything a regular OS provides, so you have to be able to strip those language / stdlib features away.
Rust is often cited as a go-to because it can already do #2 easily: #![no_std] strips out the os-dependendent standard library and essentially all of the already tiny stack-unwinding 'runtime'. #1 can be done with an LLVM backend, though it's still a bit of a hack and Rust would prefer to skip LLVM and that whole redundant optimisation phase entirely.
Most importantly, CLR and .NET are just too heavyweight for anyone to bother writing any wasm code in. What are the uses for wasm as it stands? There's basically no DOM interaction yet, so just really fast optimised code that has no OS interaction for crypto and other CPU-heavy tasks. You can't write a game targeting wasm, but you could outsource your ray-tracer there. Plain C++ and Rust are good at that. CLR/.NET is pretty quick when JITing x86 but wouldn't be worth the tremendous effort to port to wasm when you already have C++ and Rust, and they'd still be quicker in the end anyway.
Lastly there's the question of how to run a JIT at all within wasm. I don't think there is a way of creating executable memory regions (ie x86) within wasm, because wasm is independent of who's running it. You would have to instead generate executable wasm regions, which would need to be parsed again... all of which sounds fairly impossible too, as far as I know.
But is WASM set in stone already? I would have thought there would be a strong interest in seeing higher level languages made available through the browser. Are there fundamental reasons why WASM would never implement the features required to run a CLR (not necessarily a file system but for instance the threading model you mentioned).
The case for using c#/vb/java in WASM is I think strong.
First this would allow developers to write truly cross platform apps, using a lot less hacks than a solution like Xamarin.
The UI could be HTML but I would think that a CLR would ship with a version of WPF (think silverlight).
In a intranet/corporate environment, it would make the deployment of internal applications trivial.
You could have webapps with the same code base that run on mobile and desktop. The download time is not necessarily relevant. The code would be stored on the machine like any other webapp.
I think there is a reason why c#, python or java are so widely used over c++ outside of performance critical code. It is a lot easier, faster and safer to develop. I don't think c++ is a reasonable alternative to c# or java. As for rust, I don't have an opinion on its merit as I am not familiar enough with it, but its developer base is a small fraction of each of the vb/c#/java developer base.
If you tried to implement a new WASM backend for Roslyn or javac or something, it would be impossible simply because of how much the behaviour of these languages depends on their VM. Stuff like `synchronized` and introspection (esp in CLR managed classes / reflection APIs). You need the VM for that. Projects like Scala Native work because you still have an entire OS to work with on the target platforms.
You would have to implement very low level virtual-machine-like features in WASM to support something like that. And even if you did, the scope of WASM isn't big enough to support all the features of something like Silverlight running in it. I don't think they will ever support a graphics API you could do that in, for example.
At a higher level, trying to run a heavy framework on top of WASM is just silly. You already have a heavy framework, in the DOM and other browser APIs. They are essentially all you could possibly need to do anything useful in a browser. They are the only way to display anything to the user. You can't run an HTTP server inside WASM, but you wouldn't want to. You can't implement a custom interface technology in WASM, because you can't draw anything, but you can do all that with the DOM APIs or WebGL/canvas/etc so why would you want to? All these things you would need to hack together a Silverlight are already available, and your wasm would need to include an implementation of all of them. These are all things you kinda want to dynamically link against... which wasm doesn't support...
The focus for WASM (after it properly nails down the spec on a whole lot of basics) will be memory management and enabling access to GC'd JS objects. Then using JS APIs would follow. We're a long way off both of those, let alone providing VM-like features you could target a managed language at, or enough native-like APIs to allow building something like Silverlight on top of it.
I say we, but it's definitely not me working on this stuff, and it's not half the engineering talent from Microsoft either.
What I would really like to see is GC support in WASM. That would make it possible to AOT-compile managed languages like C#/Java to WASM. You wouldn't need to port the whole VM, "just" translate e.g. *.class-files to WASM which would seem a lot more feasible for the moment. That would sure only allow a subset of C#/Java, but since the web environment is distinct enough and the subset is large enough that would IMHO be acceptable.
The interesting question is whether it's a good universal language runtime, and what kind of languages it's best for.
Today, WASM doesn't support GC, which means it's unlikely to be a good runtime for any language that wants to automatically manage memory and interact with the DOM (which needs to have its own GC).
Why don't we just use an existing bytecode format and skip all the pointless design? LLVM? Android DEX? Java Class or C# IL formats aren't enough? Hell if we use one of those bytecode formats we could reuse the runtime too!
I'm sure there's probably 20+ bytecode formats and I'm rolling my eyes that we need yet another for the web....
None of those platforms' security models are as good as the web's, either, nor are their runtimes able to work well in that context.
This basically means that programming languages usually have to be specially designed for them. There's ironpython, but it's not fully compatible with python for instance.
LLVM IR is designed as a compiler IR and hardly useful for this usecase, as it is unstable, target-specific and has a complicated largely undocumented bitcode format (I don't know any reimplementations). It has been tried with PNaCl and the original SPIR, but both projects abandoned LLVM-IR/ were abandoned.
Because the major browser devs that designed WebAssembly are not smart enough to have thought this
/s
It sucked.
The reality is that WASM has to target the existing JavaScript backends in every popular browser. And now you can't use LLVM, because the backends in question typically only handle reducible control flow, etc. Conversion from LLVM to a form that your JavaScript backend supports is relatively expensive and not something you want to do on every load.
Is that really a problem considering most languages already implement a VM with GC?
That's true for now, but they're [planning][1] on adding support for that in the near future.
[1]: https://github.com/WebAssembly/design/blob/master/GC.md
If you want to get an idea of where GC is on the priorities list, have a look at the [roadmap][2]. There are still other things they have to deal with before they start working on GC support, but it's coming.
The positive side is what took 250ms to run with cold JS (nothing JIT compiled) and 35ms after a few runs takes just 5ms the first time in WASM. This is on Chrome Canary on Windows.
Is there anything I'm missing to speed this up?
Performance will be slightly worse but a smaller wasm binary means less for the browser to deal with on initialization.
Also, parsing is separate from optimization. If the browser also optimizes, that takes a lot more than parsing. However, browsers are starting to add baseline JITs for wasm, interpreters, etc., in which case parsing will be the larger factor.
With the optimization vs. parsing that's a bit opaque and I'd like more control over it. Right now our use case is such that only about 20% of the JS gets used in the first seconds of a users session, so we're paying startup time for code that either will get executed later or not at all.
And yeah, it's common that most code is not used early. Browsers are implementing baseline JITs to help there, so they only fully optimize necessary code. I don't think any browser landed that yet though. Another option here is dynamic code loading, if you know some code is only needed later, you can load it yourself (dlopen, etc., which is supported already).
What problems with those existing technologies could wasm solve better?
Web developers have been reinventing the wheel every 3-6 months and calling it innovation.
Apparently they aren't cool anymore so we need to spend another few thousand man years building another system in their image
They also, as you note in another comment, do not have the appropriate security model for web apps.
.NET 1.x introduced Managed C++.
.NET 2.0 replaced Managed C++ with C++/CLI due to feedback from C++ devs, regarding keywords and how GC types were declared. C++/CLI was submitted to ANSI C++ as standard proposal.
UWP introduced C++/CX, although it does compile to native code and interoperates with .NET Native instead.
Or Flash for that matter, which had a C++ compiler called FlasCC.
C++/CX is closer, but a) also still not the same language and b) doesn't run on the CLR, so isn't an argument for replacing wasm with IL.
WASM is assembly level just sandboxed and portable - direct memory access and basic instructions - it doesn't even have GC right now.
They are only superficially similar.
Providing a lower-level platform; directly exposing open web APIs. The first may not seem like an advantage, but it means more flexibility in the higher level systems (including runtimes like JVM or CLR, if you wanted to) that can be usefully run on top of it.
Maybe if we had a JS framework for reinventing the wheel...
Anyways you should take a look, it's a lot easier to pick up than RollCircle and nobody really uses Wheel.js anymore
npm elipse.js
It's based on circle, but I'm still working out some issues.
The WASM FAQ has an entry about LLVM IR: https://github.com/WebAssembly/design/blob/master/FAQ.md#why...
What is WebAssembly going to be used for that isn't already handled well by Javascript? High-end video games is an important example. Those are almost exclusively written in C++. Lots of indie games are written in C# using Unity, but the Unity runtime library itself is C++.
So why not LLVM? The LLVM isn't actually well-defined, stable, or even platform-independent. That hasn't stopped both Google and Apple trying to use it for this kind of thing (PNaCl and Bitcode respectively). PNaCl failed to catch on, Bitcode is helped by the fact that Apple has complete control over their own platform.
Edit to add: from a game developer's point of view, a good question is why we need both this and the new "SPIR-V" thing in Vulkan...!
The return of Silverlight! (which I welcome by the way)
Also, there's this passage from the CLR docs (a.k.a. Book of the Runtime) that explicitly states its multi-language intentions[1].
[1] https://github.com/dotnet/coreclr/blob/master/Documentation/...
It seems like alternate languages on the CLR have never really caught on, even though in principle it's more flexible than the JVM. The only ones you hear much about are C# and F#. Compare to the JVM where you have Java, Scala, Clojure, Kotlin.
And neither the CLR nor JVM seems to have caught on for low-level, performance-critical code (game engines, scientific programming, deep learning). I guess people feel the garbage collection and bounds checking add too much overhead.
So the new fashionable approach seems to be portable machine code, very close to the way real hardware behaves. If you want bounds checking and garbage collection, do it yourself.
In a different domain from games, there were some very interesting apps I've seen that were very low-level, performance-critical written for the IoT before IoT was a term space in the old Micro-CLR.
I still of the opinion that a lot of the reason people don't use CLR/JVM and other runtimes more for low-level/performance-critical code has a lot less to do with "overhead" of garbage collection/bounds checking (whether it is as bad as critics often perceive it to be is another debate), and as much to do with stubbornness and job protection ("Of course my C and Assembly skills are still needed, because the CLR will never compete with my hand unrolled loops that are nearly impossible to debug and segfault the machine sometimes, which you should pay me to fix.").
MS managed to take their own excellent technology and turn it into a legacy nightmare. Am I targeting C#, the CLR, the CLI, or making a PCL, or what? Which PCL profile(s)? It's way worse than Java in that respect and Java's already pretty bad (not that anyone uses J2ME much any more).
This article is promoting how fast WebAssembly is to parse (and no doubt it is faster than JS), and yet LEB128 is a slower-to-parse representation than "prefix varint" with the same cost in bits [1][2]. It seems the designers didn't actually care what was faster. [3]
[1] https://news.ycombinator.com/item?id=11263378 [2] https://github.com/stoklund/varint [3] https://github.com/WebAssembly/design/issues/601
Interesting. Any idea what's meant by "layer 1" here?
A lot of web people don't realize magnitude of impact WASM will have on the web.
The other thing preventing the use of JVM or .NET is that porting the runtimes over isn't easy. i.e. You can already run this bytecode in a browser but it isn't widely used. (http://jsil.org/, https://github.com/decatur/j2js-compiler, https://github.com/plasma-umass/doppio, https://github.com/mozilla/pluotsorbet etc)
I already write backends in Go, the hope of writing frontend code in Go is really exciting. All the JS people are going to say, "with node JS is already there", but this misses that I (and a vast number of other developers) hate JS with a burning fiery passion.
Every developer I know hates JavaScript. I think the only ones that like it are honestly people that haven't used much else. Literally everything about the language including tooling and module systems around it is a garbage fire.
I tried to use Node and it gives stupid shitty error messages all the time and blows up if anything hangs for 200ms because it only supports a single thread. It's honestly pretty crap compared to more mature runtimes in C#, Java, Go, Python etc...
I think what's happened is that a bunch of front end HTML guys that only use JS have been introduced to fire water and they're going nuts about it
GopherJS apparently struggles with binary size too [2] (though that's not WebAssembly).
[1] https://blog.golang.org/go1.7-binary-size [2] https://github.com/gopherjs/gopherjs/issues/136
1. without concurrency
2. if GC end up being provided by the execution environment
3. without the need to support networking and file-system (assuming this has to go through JS)
And guess what? I've been doing a ton of web dev over the past 5 or so years and I love it. I use React/Webpack/Node/ES201x/Typescript/etc. It's great.
When you're in a bubble, you like things for the beast you know, and hate things for the beast you don't know. There are a ton of devs out there that do not hate JS, and it sure as hell isn't out of inexperience.
>You're in a bubble.
Come on, I made a qualified statement, I didn't even say most devs.
> I've used QBASIC, C, C++, various .NET languages, Java, Python, list goes on and on. I've led desktop app, firmware drivers, kernel driver, security architecture projects, list goes on and on.
I have a fairly similar history, ASM, QBASIC, C/C++, Java, Go, .NET (C#/VB), Haskell, Scheme, Prolog etc. I have also worked on systems software and applications.
I've worked at consulting firms, fortune 500s and startups and I have to say if you haven't run into my sentiment before commonly, I would assert that it is you who are in the bubble (sorry). I don't think you have to agree with my opinion, but to reject it as being common is absurd.
I don't hate JS out of lack of familiarity, in fact I have spent a lot of time porting node apps to Go and discovering all their terrifying callback spaghetti, concurrency bottle necks and inconsistent typing during single variable lifetime.
It's meant to provide plug-able, high-performance functions for heavy computational tasks - crypto, game rendering, heavy in-browser data analysis, etc etc.
I double JVM in WASM makes sense at all - though somebody will probably do it in anyway. WASM is not meant to be good at Garbage Collection, etc. It's not a design goal at all.
Well yeah.. it's an assembly language, the sort you inline in your C (or some other) programs to squeeze critical code paths.
Doing your virtualdom or form validation in assembly probably wasn't a core design goal, no matter all the scripters that get so easily hyped about wasm. But consider usecases such as real-time interactively adjustable filters on currently-playing page-embedded media objects, 3d editors that let the user run (non-shader) algos on the current model such as geometry simplification.. all kinds of use-cases come to mind where wasm can really drive richer, faster, more powerful browserbased apps than were possible without it.
It wasn't part of the MVP, but it most definitely is a design goal for future iterations. See: https://github.com/WebAssembly/design/blob/master/GC.md
If you're going to target the web and need a GC, why not use hand-written Javascript? (or any variant like Typescript/Purescript if you want additional compile-time checks like type-safety/immutability).
If your users only have to download the language runtime once, the idea of using a runtime for a popular language on your site doesn't seem like such a bad idea. Popular runtimes could even be pre-cached and shipped with the browser.
(1) http://www.eblong.com/zarf/glulx/ (2) https://github.com/thiloplanz/glulx-wasm/
WebAss is a technical solution to an economic problem: lackluster SW sales and adblocking
WASM, if it allows to run high level languages like c#/vb/python/java, will enable a huge developer base to start writing truly cross platform, productive apps with a single code base. So it would be a solution to a fundamental technical problem: the fragmentation and incompatibility of proprietary platforms.
As a side, it would have another benefit (which would make it even less palatable to Apple but should motivate Microsoft to develop a CLR for WASM): as the apps would be cross platform, it would lower the barrier to entry for alternative mobile platforms. If the same app compiled to WASM runs on every platform, a Windows mobile OS (or any other challenger) would immediately have access to the same apps that are available for iOS or Android.
I'm not against portable bytecodes (though I find it pointless, and proven to have failed in the past); it's the mating to the Web that I'm concerned with, and the infinite potential for tracking and other privacy invasion.
To bring portability in a meaningful way, Apple and Google have to agree on a common API for touch, phoning, GPS, USB, power management, proximity, NFC, UI. Not going to happen.
So why bring yet another avenue for tracking and malware to browsers? To top it, lets base it on C and SIMD primitives. Lets ditch HTML and draw to a canvas all the time, accesibility, hyperlinking, etc. be damned. Because we don't like JavaScript.
It's an open source project that compiles Java to all OS's including iOS, Windows (UWP), Android (obviously) as well as JavaScript (with threads etc.)
If you embrace only the good / modern parts of ES6/ES7, you can really write elegant, modern, functional-style code. Not sure there is much left to complain about, other than the lack of built-in type system, which many others (but certainly not me) argue is a good thing.
WASM just means these apps will be faster, with closer-to-native performance.
Java has a strange way of handling object lifetimes that complcates things, but it's not the norm.
Considering Rubinius uses LLVM that's not quite true, and further, just because people haven't succeeded in taking it all the way it doesn't mean you can't. Maybe it's just hard.
For example, if you're willing to sacrifice a few features that make compilation difficult you actually can compile Ruby: RubyMotion (http://www.rubymotion.com/tour/how-it-works/) does it.
The biggest problem is something like eval, but if you're willing to live without dynamic features like that you don't have a lot of impediments to compiling to LLVM.
Unfortunately, writing Rust is an order of magnitude more difficult thatn writing ECMAScript, so hopefully it doesn't create a negative response from hordes of ES developers that want to check out this WASM thing.
But it's so much more suited than C/C++ (the other obvious candidates). In a nutshell, WASM is not really intended for higher-level languages with garbage collectors, etc. For that kind of work, I'd stick with ECMAScript.
The browser could reduce its' surface area to just network, html/css layout, compositing, and wasm. Js just becomes a special case with an automatically loaded wasm plugin.
That will make asm.js look a lot slower and should get it closer to C/C++ where it's still lagging.
I don't think downloading the app everytime is a big deal on an intranet/local wifi. Also with things like the core CLR, the assemblies should be smaller.
Now web browsers turned to Java WebStart again.
It's a very dumb thing. Browsers will waste a lot of battery. Lot's of DRM and binary blobs.
ASM.js was at least based on Javascript. Now Javascript already got "class" syntax thanks to Microsoft, now they hit the Web with another nail. An inside job, we may see another propriotary closed web with pay-to-view and ISP whitelisting certain services like is already reality in third world countries in Africa (and sponsored by Microsoft and Facebook).
It's just a personal nit and beside the point of the (rather short) article, but I've long felt it sad that the more correct 'indices' is so rare and the correct-but-inelegant 'indexes' is so very common.
This issue was closed 12 hours ago: https://github.com/WebAssembly/design/issues/219
I know it's cliche and been written about ad nauseum, but this really does feel like the trojan horse threat to MS, Apple and Android.
It baffles me when people are asking for "a mechanism (aka hidden behind-the-scenes magic) for objects and GC" in an assembly language =)
(I imagine the threat here is that the more things can be deployed as web apps, the less they depend on any particular desktop OS.)
AFAIK even conservative root-scanning is not possible right now. Please correct me if I am wrong: With the current bytecodes it is only possible to access the heap but not the stack. To make things worse, object references could also be in registers.
1) You can't integrate it with the Javascript GC for interacting with the DOM and other JS-side objects
2) Now you have to distribute the GC with every app that uses it