WASM has it's uses, for games and such. But on the web, the more weird stuff you do, the more friction you tend to introduce to your users. You can boot a JavaScript app, but the startup time will push people away. You can take months to replicate iOS animations, but the lack of bookmarkability will hamper your virality. Now you can compile C++ and run it in the browser, but you can't use any of the existing web frameworks, and browser support is hit or miss.
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.
I'm not sure I see any interest in that tbh: what's the point of porting a memory-safe (with GC and runtime) on a VM especially dedicated to remove the costly memory safety part of JavaScript.
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 :).
async/await is possibly simpler to implement. At least: in go effectively every method is async (at least the api doesn't show what is and is not), and that means you can't afford the inefficiencies that typical async/await implementations have because you'd be paying them all over the place.
javascript shows no sign of dying since that talk, more people are doing desktop software (Electron) and more people using js to make native apps (React Native). Node.js is also popular on the server. Babel also took off which lessen the need for compile-to-js languages and makes the future of javascript into more javascript. Javascript is more ubiquitous than ever, wasm is best suited for hardware intensive applications and library authors, this is overkill for normal client side javascript
Those techs you mentioned are successful largely because they use Javascript as a runtime. Supposing those runtimes also eventually support WASM (with a good story of linking binaries), I see no reason why other languages won't begin to be used. Perhaps not for a few years though.
What seems most important about WebAssembly is that it is essentially a universal language runtime. It's not that what it brings to the web is unimportant, just that it seems like we're also getting a way to do truly cross-platform language deployment as a bonus. Am I wrong about this?
Every Turing complete language is a universe language runtime.
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).
Yes, because it means shipping the language's own VM down with your application. It also means that VM's GC has to interact with the browser's own GC for DOM nodes if you want to be able to touch the DOM.
What about Haskell, which compiles everything - including the garbage collector - into a static binary? Or is it not possible to have GC-thread running with WebAssembly?
I can't remember if threading support is in yet, but it should be possible. The downside is that it will be a rather hefty binary the user has to download.
GC was not part of [the MVP][1], and the MVP itself was only finished around 2 weeks ago, so of course not. They haven't even had an opportunity to work on it yet. Like I said, "long-term goals".
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.
So wasm is a bytecode format like Java or C#'s IL except it basically has no runtime?
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....
Java (including dex) and IL bytecodes are too high level. They assume that everything is laid out in garbage collected classes.
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.
This has been brought up several times in this thread, but none of those bytecodes is sufficient. LLVM is not platform-agnostic, JVM/IL are sub-optimal for languages like C++.
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.
As others have already pointed out, this has been tried before. Turns out that some people are opposed to shipping LLVM with the browser, or any other large existing codebase.
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.
WebAssembly is not a universal language runtime. Currently it really only handles C style Ahead-Of-Time compiled languages. e.g. if you wanted to implement a JS JIT or really any other kind of JIT on top of WebAssembly you're going to have a really bad time.
I don't think it has GC at the moment. It might be alright if the GC doesn't show up for a few years; languages like Rust can demonstrate bare-metal, stutter-free performance on the Web.
You'd have to compile the CLR itself into wasm first, which I'm guessing wouldn't necessarily run that well. Language runtimes often provide stuff like os-independent threading or green threads, which have to be implemented all over again for wasm's threading model (I'm not sure it even exists yet). Some CLR features would be redundant, like the security model or the profiling API... and then you'd need to compile your C#/VB/F# down to managed CLR code without using the .NET Framework at all, since so much of .NET depends on having stuff wasm can't provide (not even .NET Core has few enough features to run on wasm). Either you make '.NET Core Core Web Edition Preview 3' and make library developers explicitly target this new framework subset so you can use it, or you just give up and recognise that without most of .NET it's not that worthwhile having C# in the browser.
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.
WASM isn't set in stone, in fact it is constantly evolving. But I doubt it will ever really let you do JIT compilation. WASM itself can be JIT compiled if you want to implement it that way, but executing memory just doesn't seem feasible given that the security model simply has to forbid executing machine code directly. I don't think the JIT>WASM>JIT again is the best way to go about things.
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.
JIT-Support is listed as a possible future feature for WASM: http://webassembly.org/docs/future-features/. Why shouldn't a WASM program not be able to generate WASM bytecode at runtime? The runtime-generated bytecode can be verified and then compiled by the WASM compiler, just like it is done for AOT-generated WASM bytecode. That said, I am not sure if WASM should support jitting. But if there is demand for it, then it will probably get done.
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.
I kinda see the future in that talk as that as a worthwhile goal. If we could get all the security and interoperability advantages of the web but with native-level performance, support for multiple languages, and backwards-compatibility with legacy software that'd be huge.
Is it just me or do Java applets seem like they were way the hell ahead of their time?
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.
I remember Java applets, and reading this thread it's hard to square the revisionist nostalgia with those experiences. The Java applets I remember absolutely sucked as a user. They took forever to load, had weird clunky UIs that were out of place in the host OS and the browser, constantly broke due to compatibility issues, and had no concept of graceful degradation. There's a reason Java applets lie in the dustbin of history - good riddance to them, it's where they belong!
The rose tinting of HTML should also be taken into account. Java was maybe 10x slower in those days, but more importantly internet was 100x slower and computers 500x slower.
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.
Yes they were slow and clunky, but they ran on computers with 100Mhz processors and 8/16MB of RAM. I doubt you could load a chrome tab on that.
> 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.
Yes, but the competition at the time was HTML (slowly getting interactive with time, and mostly ugly, but fast and dependable), and Flash -- and Flash was way faster, way more compact, and way more prevalent than Java.
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).
I don't think flash was much better at anything interactive, or at least animated. On the same hardware as above I remember "frog in a blender" could render well south of 1FPS, on a 486/686 (outdated but still in common use) it was more like 0.1FPS.
Too be fair though, it's a hard comparison, applets were generally apps while flash was fancy graphics.
Java could have worked fine in the browser. All feature phones (which are/were almost universally less powerful than a desktop PC) were able to run Java ME applications just fine.
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.
do Java applets seem like they were way the hell ahead of their time?
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.
:) if you'll notice maybe half of those are other languages adapted to the JVM to make them more usable, which should say something is redeeming about the JVM at least.
Java applets never had, and never were planned to, have access to the DOM.
Without access to the DOM, they had to implement their own GUI from scratch. The Java UI experience has always suffered from it's platform-agnostic look that never fits in (and is just ugly).
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.
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.
Compile time in Java is way bigger than in JS. What do I need to do in order to compile a simple hello world in java ? In JS i only need the browser and a text editor if i'm fancy.
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
As a Java engineer, I'm enjoying ES6/7 development much more these days.
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.
Indeed, coming from a Haskell background I also have some problems with Flow. I spend more time struggling with it than with reaping the benefits it brings. Perhaps this will change in a near future.
I would like to look into the Java functional approach. Is there any reference you recommend ?
Java's type system and FP features are really weak compared to Haskell's :-) But it compares favourably with ES6's, until you start using ImmutableJS, and ES6 currying. Then Java lags far behind...
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.
Running babel is consistently slower than running MSBuild or javac in any of my projects. Not to mention all the other linting, uglifying, minifying, bundling and copying bullshit the gulp script is doing.
The same could be said about Netbeans or other specific optional parts of Java development. JS devs that target anything after the iphone 5S (2013, almost 4 years ago, before 64bit processors even arrived in android land) don't need to use babel, and arguably http2 takes most of the benefits from minifying and bundling.
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.
The performance of JS these days, for such a dynamic language, is actually very impressive.
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.
I was a very early adopter of java in the browser and we compared shockwave (Macromedia/Adobe Director) with java and despite java being so allegedly ahead of its time, shockwave was far better in all respects (speed, functionality, size, spinup time, user experience). And shockwave was awful (it was rendered irrelevant by Flash, which rose on its coat tails (SWF stands for "shockwave flash", although the two had nothing in common).
Using Emscripten (with embind) 1.37.3 it takes slightly over 1 second to initialize a 2.7mb wasm file. The JS version shows slightly under 300ms for parse time, obviously not the same as the full WASM pass, but it does significantly delay initial page load.
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.
Cool. And if you see slowness on more than one browser, please file a bug, it could be something in the toolchain we need to fix (if it's fast in one browser but slow in another, the slow one probably just needs to improve).
It's 733ms in Firefox, measured from the time doNativeWasm is called until the wasm-instantiate run dependency is removed. Not sure what time should be expected. It's certainly not an order of magnitude faster.
That's not quite measuring the same thing, as it includes the download of the wasm (which will then depend on the webserver, e.g., the simple python one people use for debugging is super-convenient but not that fast). You can force sync compilation (BINARYEN_ASYNC_COMPILATION=0) to make measuring that easier, or measure it in the shell.
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.
Not in this case, I'm preloading the wasm binary blob and then assigning it to the Module object.
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.
Oh ok, yeah, if you preload the binary, it's a good measurement (of parsing + optimization).
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).
Java and the CLR are pretty similar (legal issues aside). Both are great, but neither is ideal as a general-purpose VM for arbitrary programming languages. Neither is a good target for C and C++. (The CLR has "managed C++" but I don't think that's widely used.)
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...!
I thought the exact purpose of the CLR was to be a general-purpose VM for arbitrary programming languages. I mean, it's even in the name: Common Language Runtime.
Also, there's this passage from the CLR docs (a.k.a. Book of the Runtime) that explicitly states its multi-language intentions[1].
Huh, the meaning of the name hadn't even occurred to me! I guess I just think of it as the Common Microsoft Language Runtime. :)
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.
I've seen the CLR used in low-level, performance-critical code. Performant game engines in XNA were better than a lot of critics gave them credit for. (Schizoid, a game nearly no one purchased, for one immediate example of a very performant game built in the CLR that didn't get enough credit.) The failures in XNA were more market segmentation failures (XBLIG versus XBLA, alone; though Schizoid and a few others passed through into XBLA) than engineering. With the UWP the market segmentation failures are disappearing, which is good for sales, but also means that successes in the CLR are less visible too: at a glance you can't tell if a UWP app is a CLR app or not. (Plus, .NET Native further blurs the lines.)
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.").
I think a big part of the problem with .NET is just that it's a big confusing mess of confusingly-named components.
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).
Your comment doesn't seem particularly on topic, but a lot of the confusion you speak of seems to be your own. C# is a language, the CLR is the standard for a runtime (and typically the name of the classic .NET desktop runtime if not otherwise specified), CLI are command line interfaces, PCLs are now extinct and going the way of the dodo (replaced by the much more useful .NET Standards, of which .NET Standard 2.0 is probably the only one most people care about right now). Yes, there are plenty of acronyms to keep up with, but I'm not sure I would agree that .NET is any worse than Java (or really any other multi-language, multi-platform stack that has to support both the future and a good collection of backwards compatibility).
But I presume that webassembly will allow a program to ship with its own managed environment. So you can have a .net program running within a CLR within webassembly.
The return of Silverlight! (which I welcome by the way)
Java bytecode doesn't make a good compilation target for compiled languages; wasm specifically aims to provide a good target for such languages. LLVM IR by itself doesn't provide appropriate sandboxing for the web; wasm has security and sandboxing as a fundamental part of its design. The CLR shares many of the same problems Java has, and would also fail to provide a vendor-neutral, unencumbered solution.
You seriously don't see the difference between WASM and CLR/JVM ? JVM/CLR are high level and need to know about things like types/object model - this lets them do GC more efficiently and fancy stuff like reflection, etc. at
WASM is assembly level just sandboxed and portable - direct memory access and basic instructions - it doesn't even have GC right now.
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.
.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.
I prefer ReWheel. It's like RollCircle but they've reduced everything to a single wheel so it's easier to reason about. Some people still think you shouldn't have a single global wheel but it's definitely where things are headed.
Anyways you should take a look, it's a lot easier to pick up than RollCircle and nobody really uses Wheel.js anymore
I tried to install but I'm getting an error message: "undefined" is "undefined" on line 27361 in elipse.min.js . I'll send you the stacktrace because it's bigger than the message limit here. I see that you're transpiling typescript into ES2015 then down to ES5 in Babel, cool. Could I get a source map for the original file?
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]
> Implementors have discussed and concluded that while alternative encodings might offer improved size, the intention to support layer 1 (allowing outer wrapping format specific compression), and the degree to which LEBs are well known, outweighs this advantage for MVP.
Interesting. Any idea what's meant by "layer 1" here?
Without a GC WASM is very hard to use for regular web development tasks. When GC infrastructure lands lots of mind-blowing stuff will happen. Things like JVM and .NET running in WASM.
A lot of web people don't realize magnitude of impact WASM will have on the web.
> Without a GC WASM is very hard to use for regular web development tasks
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.
To get good performance on running JVM or .NET WASM will probably need more than just GC support. JVM/.NET JITs rely on inline-caches that aren't currently expressible in WASM. There are ideas about ways to make this work, but it will be a while.
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.
Yes! Go has a really small runtime I think a lot of us can't wait till Go is usable in browser.
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
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)
The go runtime for WASM could potentially be much smaller than the size of the standard server side runtime.
I forgot to note, if lots of page use this runtime and its loaded as a separate cacheable asset with a long TTL, the chances of it being cache are pretty great. Go didn't get popular for FE and I was writing a webapp FE in it I might stick it local storage too...
You're in a bubble. 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.
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.
EDIT: I just realized you were replying to the over zealous fellow that replied to me and not me. Sorry. Time for coffee.
>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.
I have used many languages, including Python, and I like JavaScript. It depend of lot of what you want to do with the language. If all the programmers you know are doing the same sort of tasks, such as server side scripts (the goal of Go), they have no reason to like JS.
> Without a GC WASM is very hard to use for regular web development tasks.
I don't get it.
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).
I wonder if this could be solved with a better caching system for dependencies shared between multiple sites. Maybe some kind of content-addressable cache?
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.
I think you're missing the core use-case of WASM. It's not for general app development, which will stay with JS.
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.
A colleague, Thilo Planz, is working on an Interactive Fiction VM based on the Glulx specification (1) called glulx-wasm (2). If completed, this will be integrated with fyrevm-web, a web platform for glulx+channel IO stories.
Do we know if we are likely to see support for WebAssembly for all platforms? It looks like a way to bypass the app store. I am surprised apple or google (on android) would be happy to do so.
Web apps have been a pretty good way to bypass the app store for quite a while now, and Apple/Google don't seem to have a problem with that. Heck, Google is even taking steps to integrate web apps more deeply into Android so that they're almost indistinguishable from native apps: https://blog.chromium.org/2017/02/integrating-progressive-we...
WASM just means these apps will be faster, with closer-to-native performance.
Exactly. Apple won't support WebAss, and I'm WITH them on this one. Why does a browser have to run native apps with a laughable/non-existant, designed-by-comitee API? That's what the operating system is for IMO.
WebAss is a technical solution to an economic problem: lackluster SW sales and adblocking
I don't agree with you. The only language that allows truly cross platform development right now is javascript. It's a language I do not like and I believe I am not the only one. In fact the popularity of extensions like typescript is an evidence of the challenges of using what was meant to be a simple scripting language as a full blown programming language.
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.
WASM is not positioning itself as a high-level application development platform. It's specifically meant to co-exist with ECMAScript (which is the app "glue"). It's meant to out-source computationally-intensive functions to, nothing more.
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.
The end user won't benefit from the portability aspect, though. He/she has to load the damn app anew on every device and every session.
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.
What languages do you all recommend for compiling to Wasm? I know Rust is an option and something like Nim would probably work well. What is the future of Wasm?
WASM is going to make Rust [1] shine like nothing before. I love that all the Mozilla articles keep mentioning it together with C/C++.
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.
There's been a reasonable amount of success for JS programmers moving to Rust; npm is now using it for backend services, for example. There is a big semantic gap, but many don't find that insurmountable.
Honestly I'd only use C and C++ with this. It's not going to be a good target for anything that currently requires a VM (most garbage collected languages)
Unless I'm missing something, I think most languages will be fine. I'd think pretty much every language will need to cross-compile their runtime library to WASM, which would include their garbage collection. C/C++ will obviously be easiest to map onto WASM, but I'm guessing other languages won't be too far behind. LLVM already has a WASM target.
Different langauges demand different features in the implementation of a garbage collector. A garbage collector that every language implementation could use would basically be a set of functions that languages could use to implement their garbage collectors, but at that point the library would be tiny and the per-langauge implementation of garbage control would be huge.
I'm not sure that the garbage collector in Ruby, Python, Node.js or Perl is going to be radically different. They all have their own implementations for historical reasons, not because they have such wildly different concerns.
Java has a strange way of handling object lifetimes that complcates things, but it's not the norm.
Well you can't even compile Ruby, Python, Node, or Perl to WASM, since you can't compile dynamic scripting languages to LLVM. You could, for example, interpret Python by compiling the CPython interpreter to WASM (though that would mean an absurd bundle size), but this doesn't solve your problem since the python garbage collector is in the CPython source and you can't just remove it nor can you use a different langauges garbage collection because every language represents objects differently.
> you can't compile dynamic scripting languages to LLVM...
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.
What if the javascript interpreter / jitter was built in WASM and the jit target was WASM?
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.
I predicted this before, but somebody will do a cloud with webassembly. With all the extensions, this becomes quite an interesting middle ground between VMs and containers.
By the time wasm supports GC languages like python or ruby, javascript may get a lot better. Will people still want to write client side apps in python?, even if it means that it will run slower and also you have to download the language runtime on a webpage load.
JS is not to everyone's taste. And certainly not to mine. In the line of business world, there would be a huge value added being able to use the browser as a distribution mechanism for what are effectively desktop apps, developped in a high level but statically typed language like VB, C# or Java.
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.
Thanks for pointing out the obvious. That's not what I asked, I asked whether can you compile javascript to WebAssembly, without having to parse javascript source files on the fly and expose source code to the javascript engine, but instead provide just the WebAssembly output directly.
Who else thinks that Asm.js was okay, but WebAssembly is evil and might destroy the current web landscape. It's like a trojan horse. Guess which companies are involved.
Microsoft will finally be able to compile their C++ based Office.
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).
Why would that make ad and tracking blockers impossible? Those blockers usually operate by blocking resource loads, and a browser-in-browser runtime can't sidestep that, because any network access still has to go through the browser and therefore can be blocked.
Fair point. But a browser-in-browser can hide so many things from you. It can easily piggyback tracking data on regular content requests, use proxies, block basic page navigation; the possibilities are endless.
It's just that I find the WebAss propaganda dishonest and the discussion here naive. I personally have no problem discussing the economies of publishing, and I'm also not against ads. Tracking, OTOH, needs to go away.
I don't see any propaganda, I see a very interesting, beneficial and good technology. What's naive about that? No one says it has no downsides; but some people don't consider it a downside. And again - if you don't like being tracked, there's nothing easier than not visiting these sites, because that's simply the price of visiting the page. Obfuscated JavaScript code is about as hard to read as equivalent WebAssembly code, maybe even harder, so you still have exactly the same options to find out you're being tracked.
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.
It makes complete sense to ask for GC support. Even if it's never used to implement GC-d languages targeting WebAssembly, it's still important for integration with the Javascript GC.
(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.)
How would you implement determining the root set? So how would you detect which local variables reference an object? The Gc needs to keep these objects alive.
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.
WebAssembly is mostly about being a faster-to-parse version of asm.js. asm.js is an easier-to-optimize subset of Javascript. If it were easy to transform any arbitrary Javascript into asm.js, then browser makers would just apply that transformation themselves (or more likely, write the optimizations so they don't target only a subset).
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.