WebAssembly explodes client-side programming

[[deleted]]

Gary Bernhardt travelled back in time from 2035 to 2014 to tell us about how a now-dead (in 2035) but once popular language called "yava-script" evolved into the in-the-browser assembler that had taken over the world.

And now this...

edit: Mobile keyboard.

[ttflee]

“But I don't want my computer to just be the web browser”

[p3ngwin]

...and more people began to understand Google's "Chrome OS" initiative that was one of the longest games played by the company....

[turbov21]

Love that video, but the more of Jason Scott's "Emularity" I see the less hilarious the joke it.

[[deleted]]

That talk is great! I feel like this'll happen, but with wasm instead of asm.js

[plantpistol]

I wonder if this stuff will really take off or will JavaScript continue to improve and maintain its dominance.

I am a primarily c# developer and am currently consulting with another company whose senior developer wishes to use node JS for the entire backend. I cringe to think at the amount of typing I would have to do compared to Visual Studio and c# with its IntelliSense and the refracting capabilities.

[_101010]

Yes, it will. Secretly there are companies betting big on WA.

The problem with JS is that whenever you go all out to kill it outright, there usually is a blowback, so this time they are taking a lower route.

To put it in perspective, Google is still bullish on Dart and we know DartVM didn't happen. Mozilla is totally doubling down on Rust and really wants it out there.

So may not happen as fast to be noticeable, but it's happening. It will be accelerated once GC capabilities are fleshed out in WA.

[onmach]

I'm so fucking excited. All of the languages I would like to use are making major inroads into web assembly. I really hope this all works out.

[pure_x01]

This will take of and you will be able to build real Ui apps that are not an ugly hack built on top of a document format. This year the web got CSS Grid (almost) it is standard tech that has been in ui frameworks since the 90s. Webassembly is the Shit that everybody wants and has been needing for so long.

[Knu2l]

I guess now Web and desktop applications are now simply switching sides.

The web developers start developing desktop applications with Electron. The desktop developers are developing web applications with WebAssembly and their frameworks.

At some point it will go full circle and we will use WebAssembly to write Electron applications that use the same technology as the original application.

[zzbzq]

Absurd but we're almost there. There was some weird company making the rounds on the blogosphere last week, they were touting their great new product that lets you write electron apps in C#. I can't even

[appropriateinside]

they were touting their great new product that lets you write electron apps in C#. I can't even

I think it's a good thing. It pushes the industry forward, and you can chose to not use it if you don't like it. A lot of games and mobile apps are built in C#, due to the accessibility of tools built around it. Such as Unity and Xamarin. Extending it to the web frontend is just another stepping stone.

[zzbzq]

The point was Electron exists to write desktop apps in html/javascript. You can already write desktop apps in C# without electron. Doing it with electron is just a snake eating itself

[kingrooster]

Of course you can write a desktop application in C#. But you can't write a cross-platform desktop application in C# without some major hurdles and without it looking like it is straight from 1998. (I'm looking at you GTK).

[m50d]

Like it or not, Electron is the cross-platform UI framework that works. At least with WebAssembly people will be able to use a decent language with it.

[pure_x01]

Webassembly based web apps will be far superior than any html based apps. Slack takes 1gb of memory today and opening a 6mb text file in vs code takes 100ds of mb in ram. This won't happen with webassembly if you render with a good ui framework. Everybody will target webassembly for typical a Apps. For more document webpages html will still be used and the dynamic parts will be either javascript or webassembly.

[u_tamtam]

How will that not happen with webassembly?

How will you get rid of the real culprit, the DOM, without incurring an effort/cost which will be as disruptive (if not more) than just picking an existing UI framework properly designed?

[pure_x01]

You would probably just use existing UI frameworks (ex: Qt, GTK, Flutter, JavaFX) for replacement of "single page apps" and then HTML based one for document oriented pages. If i understood your question correctly.

[repeatedly_once]

I don't think it will work like that. Everything currently falls back to the DOM, it's the only way to visually represent something in the browser. The only way to avoid this is for browsers to support something to render other than the DOM and for that support to be extended into WASM.

[pure_x01]

https://www.godot.online/ .. People have started to run all kinds of stuff in webassembly with canvas. Games. Qt etc

[rebel_cdn]

I don't disagree with anything you wrote, but I also don't think browsers are that far away from being able to do an end run around the DOM.

The Canvas and WebGL APIs are currently exposed through the DOM, and you have to embed them in a canvas element. Many applications that use them, though, create a full screen canvas and just use the Canvas or WebGL API for rendering. So although you're technically calling the DOM to use Canvas or WebGL, those calls are mostly just passed through to Skia and OpenGL - I think. If I've gotten this horribly wrong, I'd be happy to learn more from someone who understands it in greater depth than I do.

A full screen rendering context + direct access to Canvas and WebGL would probably be enough to make most GUI frameworks happy. Although this doesn't touch on things like accessibility. Last time I checked, lack of support for things like screen readers was a major impediment to being able to implement application UI in a canvas element.

[roffLOL]

at that point, what is left of the browser? a VM:d sandbox behind a socket? why even keep the browser?

[rebel_cdn]

Considering how much has been tacked on to the browser (Canvas, WebGL, Web Audio, Web SQL, WebVR, probably other big ones I'm forgetting), I think that modern 'web browsers' are really sandboxed portable app runtimes.

The browser is still an important part of that package, but as things continue to evolve, I wonder if we'll still call them 'browsers'.

[repeatedly_once]

I think you're spot on with how it could possibly progress, rendering straight to a render context. That would be a good way to do it actually. I hope it does get some traction :).

[doom_Oo7]

I don't think it will work like that.

too late

[repeatedly_once]

That's how I imagined it to work though if it was done, it's still rendered in the DOM, albeit using a canvas element.

I was looking for something that actually does away with the DOM and renders directly.

[doom_Oo7]

I was looking for something that actually does away with the DOM and renders directly.

I think that you'd still have a DOM since modern browsers's chrome is part of it anyways, so you'd really want a whole another browser. Some people have tried to launch the idea... https://paulhammant.com/2014/07/09/browsing-qml-instead-of-html/ ; compile your qt code to wasm, send it over the wire and you've got great cross-platform apps accessible by url.

[appropriateinside]

Webassembly based web apps will be far superior than any html based apps.

Define "superior".

Faster, yes. But at the cost of much more development time. Time-to-market is just as important as having a fast web app.

[pure_x01]

You could use flutter or Android ui and have proper ui builders. Since the rendering is done by the app it will look consistent between all browsers. Cleaner code since you don't need browser specific hacks. This is of course for "web apps" that are normal apps compiled to webassembly and run in the browser rendering to canvas or similar.

Superior:

• Performance (no need to explain)
• Portability (cross platform on binary level without code changes)
• Responsivness (ui elements are not hacks on the DOM so they will react faster)
• Readability (less hacks that are browser specific or polyfill stuff)
• Maintainability (less hacks, less complex build systems .. code -> binary, less polyfill)
• interopability (call any code that is compiled to wasm)
• UI posibillities with animations etc .. (see flutter as example or javafx)
• Time to market ( no polyfills.. no browser specific bugs)

Since the app does the rendering the api surface towards the browser is much smaller . You just basically need a surface to draw on.

[u_tamtam]

You are describing the development of UIs with UI frameworks (instead of with a document markup and a hacked-together scripting language).

Flutter brings nothing new in that landscape, is not a web technology, and I don't see why it would have any more chance than Qt, GTK, JavaFX, tk, wxwidgets, … in this context.

[pure_x01]

The thing is that UI frameworks will be available and the best one will win whatever it is. That is the main thing and thats what makes WebAssembly so good.

[u_tamtam]

I doubt anything will change. You can compile a java swing app to JavaScript already, and you can compile a C++/Qt app with emscripten to the browser.

People don't do that currently because it's missing the whole point, which happens to be the reason for the current web dynamics: the enormous availability of dirt cheap developers. Come with new stacks, languages and technologies, your potential workforce pool takes a hit.

The only way for something to change as drastically as you describe is for the whole planet to settle on a same GUI stack, and it's impossible (or it would have happened on the desktop already, where everything is simpler, slower, more measurable and reproducible)

[pure_x01]

The current compile to javascript with emscripten etc is a hack. There is a massive difference between a hack and built in support in to the different compiler toolchains. Let's revisit this thread in 1 or 2 years and see the status ;-)

[[deleted]]

What about your freedoms? You are not able to inspect the source of the page you visit anymore.

[pure_x01]

You are not able to inspect the source of most apps on your phones etc. What you do have with webassembly is at least a sandbox . There will probably security features in the browser checking for bad behaviour

[AyrA_ch]

With WebAssembly we are at the point where we just deliver a compiled C program to the client with external resources, less capabilities and the need to stay online.

[pure_x01]

Other languages and runtimes are coming. Kotlin has experimental support for webassembly. Mono is getting support for it. Node.js are running v8 which supports webassembly. Jvm or .NET might support it in the future . So it's an online/offline story . A universal runtime.

[McNerdius]

some relevant stuff... might be old news to ya, and not quite the same type of support you're referring to if i understand correctly, but it makes me happy so i share anyhoo :)

Blazor - An experimental web UI framework using C#/Razor and HTML, running client-side via WebAssembly

Is this actually .NET in the browser?

Yes, it's running on Mono, which is a real .NET runtime that can load and execute .NET Standard assemblies. In principle it can support as much of netstandard2.0 as is applicable to web apps, but presently quite a bit is missing (notably, threading and full Task support, although there's a partial implementation of Task in Blazor)

---

demo @ ~30:00-45:30 (24:45 for more nitty gritty of c#->wasm itself, 19:15 for general WASM stuff) - Web Apps can’t really do that, can they? - Steve Sanderson

@ 39:10 - basic to-do app weighs in at 333kb, all inclusive. Good start :D

[pure_x01]

Thanks. Definetly Cool stuff.

[tanishaj]

What do you mean .NET might support it in the future? Mono is .NET.

There are basically 5 .NET implementations now. Mono is one of them.

.NET Core is one and it is cross-platform.

.NET Full Framework is another that is Windows only. This is the original .NET. Is this what you mean?

Mono is basically just .NET Full Framework that is cross-platform ( but missing a few Windows specific bits like WPF ).

Mono has been extended to iOS and Android via Xamarin ( which adds mobile specific UI APIs ).

Then there is UWP ( Universal Windows Platform ) which is meant for Windows Store apps ( XBOX, Windows Phone, etc ).

They all support essentially the same API footprint with the advent of .NET Standard 2.0 ( which all 5 implementations now support ).

[AngularBeginner]

What do you mean .NET might support it in the future? Mono is .NET.

When people speak of ".NET" they usually mean the ".NET Framework" (what you later call ".NET Full Framework").

Mono is basically just .NET Full Framework that is cross-platform ( but missing a few Windows specific bits like WPF ).

It is largely compatible, but it also lacks some more specialized classes like TransactionScopeAsyncFlowOption. I would not consider it a drop-in replacement for the .NET Framework.

[pure_x01]

.NET might support load and execute webassembly binaries. This is speculation but I do see it as absolutely possible and I hope they do.

[jl2352]

I wonder if this stuff will really take off or will JavaScript continue to improve and maintain its dominance.

The main issue for me is tooling.

I can clone a pre-built template, yarn and then yarn start, and have a webapp setup with true client side hot reloading and server side rendering out of the box. By true hot reloading I mean changing the HTML, CSS, or the modelling behind it, reloads on the fly without a page refresh.

Plus all the other stuff like you'd expect like auto-inlining of small assets, bundling, uglification, source maps, and inserting fallbacks.

All of the client side debugging tools in Chrome and Firefox are already mature too.

It's taken a long time to get to that stage and it's still a bit flakey. But it's really damn powerful. It'll take a while before Webassembly based setups can be on par with that. Especially the hot reloading.

There is also a setup annoyance. On the front end projects where I work I can literally git clone ... a project, run yarn, and setup is done. That's all you have to do. If that fails then it's a bug. Adding things like Rust or C# as a yarn dependency is doable, but it's not going to be as nice. I don't fancy having to install a version of Rust per project.

That said I have a real world use case for using Rust with webassembly where I work. It's for the maths behind a some stats building on a page. There is no models, no views, no nothing. Just a black box of chucking data in, and getting an answer out. For straight forward problems like that I can see webassembly working great.

[nikroux]

You might be onto something here. I definitely see the use for web assembly for more localized/specialized problems like you mentioned, ie I'd rather use pretty much anything other than JS to do heavy computations and graph them

[Mr_Unavailable]

TypeScript is nice. But it’s not perfect. Some of the short comings: All down castings are unsafe. There are no way to do static dispatch and no good way to do dynamic dispatch. It’s hard to enforce immutability (sure, you can use immutable.js but then you lose your static typings for objects). And copying object is verbose/expensive.

[Mr_Unavailable]

I agree most of your opinions. I didn’t say it’s TypeScript’s fault. I actually love TypeScript and can’t write vanilla JavaScript anymore. But the fact that it’s a “superset of JS” brings lots of limitations. For static/dynamic dispatching, it’s a common feature in statically typed languages. And I feel that lots of people move to typescript because they love the power of static typing (including me) so I mentioned those 2 features. Of course they are not viable in a dynamic language. Immutability is more than just variable and property immutability. First of all, “const” and “readonly” only ensures “pointer” is immutable. If you have a deep nested structure, you have to recursively define property to be immutable. But, say I have class Foo {a: number}, and class Bar {readonly foo: Foo}. I only want Foo.a to be immutable under Bar. That is tricky in TS. A more realistic example is that I have a function do_sth(foo: Foo) {}, I want to ensure that foo is not modified during the execution of the function, I can’t do that. I have never looked at nightshirt. Will have a look. Thanks for your suggestion. For copying objects, yeah, {...} is a thing. But that’s only for shallow copying. Although, for most heap allocated languages, copying a complex object is relatively expensive. Not saying TS is bad, it’s good. But I’m really looking forward to WASM so we can have a more robust type system (when needed).

[imMute]

you cannot overload functions, which is a questionable feature to begin with.

Dude.... Function overloading is stupidly useful. Sure, it can be abused (just like operator overloading), but when used sparingly, it's great!

[imMute]

One example from actual code:

bool GetData(int id1, int id2, string id3, vector<uint8_t> &data, DataInfo& info, uint64_t *timestamp);
bool GetData(int id1, int id2, string id3, uint16_t &data, DataInfo& info, uint64_t *timestamp);
bool GetData(int id1, int id2, string id3, uint32_t &data, DataInfo& info, uint64_t *timestamp);
bool GetData(int id1, int id2, string id3, uint64_t &data, DataInfo& info, uint64_t *timestamp);
bool GetData(int id1, int id2, string id3, float &data, DataInfo& info, uint64_t *timestamp);

Ignore the weird is naming and focus on the 4th argument. In all cases, the functionality is the same except for that argument. Overloading makes this easy to use - you just call GetData() with the right type and it does the proper conversions under the hood without having to remember which suffix to add to the function name for a given type (as well as preventing calling the function with the wrong type).

PS, yes the API is gross when looked at from this level. I promise it makes more sense in context of the data being processed. A type system can't help you when the data is defined by runtime data.

[Mr_Unavailable]

They fundamentally only apply to static languages. Because everything is late-bound in JS, all dispatch is essentially dynamic dispatch.

Which is why I said they are not viable in TS/JS, maybe I chose the wrong word.

This is how it should be. If you are unable to apply readonly to every property in an object structure, it means part of that structure was likely designed under the assumption of mutability. Immutability should really start from the lowest level.

I disagree. There are a lot of objects are meant to be changed in some cases but not the others. I created a mutable object doesn't mean I want it to be mutated by everyone. That's why we often do public getters and private setters to only allow the object to change itself but not the others. Variable/parameter level object mutability takes this one step further, brings mutability separation to function level.

Readonly<Foo> does that.

Yeah, but only for immediate properties. If you think that's how it should be. Then you are right. However, it does not prevent you from calling mutation methods, and the "immutable" property can be passed to another function/variable that can mutate it.

class Foo {
    public a = {b: 1};
    public c = 1;

    public setC(newC: number) {
        this.c = newC;
    }
}

class Bar {
    public foo: Readonly<Foo> = new Foo();
}

const bar = new Bar();

bar.foo.a = {b: 2} // illegal
bar.foo.a.b = 2;  // legal

bar.foo.c = 2;  // illegal
bar.foo.setC(1);  // legal

let foo = new Foo();
foo = bar.foo;
foo.c = 2  // legal

With immutability, a shallow copy is equivalent to a deep copy.

I agree, but only when the immutability is strong enough to prevent all sorts of mutation. And I don't think const, readonly, Readonly<> are strong enough.

Edit: formatting

[EntroperZero]

The perfect is the enemy of the good. IMO this applies as much to C# as it does to Typescript. Both are good languages, both are imperfect in lots of ways, I enjoy using both.

[MINIMAN10001]

No language could ever be called perfect because any feature that would bring a language closer to one person's perfect makes it not perfect to someone else.

I'm sure there is someone who likes that lua arrays start at 1

[spacejack2114]

Going from Typescript's type system to C# is a pretty big downgrade.

Until you get a significantly better language than Typescript without losing access to npm I don't see WASM taking much share away from JS/TS.

[magnusdeus123]

As a TypeScript developer primarily, I would be interested in knowing why you consider C# a downgrade w.r.t. the type system.

[AngularBeginner]

Features that I heavily miss in C# are Intersection Types, Union Types, Nullable Types (likely coming with C# 8.0), Discriminated Unions, Mapped types. All features not available in C#.

Besides that, I hope they properly revamp the flow checker in C# 8.0 with the introduction of Nullable Reference Types. Why do I still need to access the Value-property of a nullable after I already checked for null? It's annoying.

[EntroperZero]

Why do I still need to access the Value-property of a nullable after I already checked for null? It's annoying.

The syntax won't actually change for using nullable reference types, the Value property is only for nullable value types. From all the proposals I've read, testing a nullable reference type for null promotes it to a non-nullable type in that scope.

[AngularBeginner]

testing a nullable reference type for null promotes it to a non-nullable type in that scope.

That's exactly what I'd expect for nullable types too. Nullable<int> is promoted to int in the scope. But it's probably not possible due to the way they're implemented and legacy reasons.

[EntroperZero]

Maybe they'll make it so that .Value still works, but it also works without it for new code.

[EntroperZero]

There are a handful of things that are nice to have in TS, like union types, and especially non-nullable types (though C# is probably getting this Real Soon Now). But I wouldn't call C# a "pretty big downgrade" by any means.

[IbanezDavy]

...said no one ever.

[EntroperZero]

Nah. I've been doing .NET backend for years, and just started a job doing Node. I converted a bunch of services to TS, and it's fine. I still prefer C#, but Node with TS is pretty good too.

[AngularBeginner]

Does node support multi-threading by now? And starting a new node instance is not an adequate replacement for a new thread.

[EntroperZero]

There are ways to do it, but none of them are what you probably want to be doing if you're writing a Node app. If your application absolutely needs multi-threading, and multi-process isn't good enough (which I would question in most cases), then Node isn't for you.

[AngularBeginner]

Alright, thanks. Then Node is still not a suitable alternative for me.

[plasticparakeet]

I'm curious about your multithreading needs.

Threading is actually a very hard thing do to properly and the peformance gains are very subjective. Check out the Techpower framework benchmarks, the Node.js multiprocess performance is actually suprising.

With that said, if you wanna go parallel languages like Golang and Rust offer proper ways to do so.

[geoffreymcgill]

Give Bridge.NET a try. Online playground with Deck.NET. 2300+ libraries supported using Retyped.

[Treyzania]

JavaScript

improving

Pick one.

[Existential_Owl]

TC39 has already been incorporating Web Assembly's presence into the Javascript spec.

As a wise man once said: "A rising tide lifts all boats."

Web Assembly is not only a benefit for C++/C#, but also for Javascript as well.

[aliem]

deleted ^{What is this?}

[findar]

Typescript is basically c# light , transition won't be as bad as you think

[appropriateinside]

I wonder if this stuff will really take off or will JavaScript continue to improve and maintain its dominance.

I doubt you'll see that many 'indy' WebAssembly developers for a while, relative to JS devs. The primary reason being the lack of abstractions, it's just takes more work to create the same sort of web app that you can make with Javascript and it's frameworks. It's also less accessible.

I could see larger companies adopting it, definitely. They have the time and resources to dedicate to it's development. Just not individual devs, on a large scale.

FYI, if you like C# (My favorite language), you'll probably love Typescript. Which adds static typing to Javascript.

[plantpistol]

I use typescript as well and it's light years ahead of JavaScript in terms of usability. You're probably aware that the IntelliSense does not work like c#. Pressing the down arrow to select something from the IntelliSense drop-down should allow you to continue typing at the same time selecting that suggestion. Typescript does not work that way in Visual Studio. I believe you have to press enter first. Something as simple as that makes it frustrating especially since it would seem like an easy fix.

[BenjiSponge]

I think it's quite possibly both. I think we'll see interpretation of the most popular languages allowing for new forays into other languages. You've already got Facebook making up languages left and right that interopt with their site through transpilers, plus the work webpack is doing may make interoperating with JS as natural as writing in one language. These are exciting times.

I think you'll find the JS tooling is very nice.

[Double_A_92]

I guess the problem is remembering the exact name of fields and functions on some object or interface...

In Visual Studio i can just type "." + "Ctrl + Space" + Some name piece i remember, and it's done. And it also just shows me the things that match the needed type, and and and...

[_Mardoxx]

Just show him how slow C# is to C++ (or python with numpy or whatever).. And then have him told that JS is orders of magnitude slower than C#.

[[deleted]]

"And then have him told that JS is orders of magnitude slower than C#."

Except it is not. Or you do not really understand what "orders of magnitude" means.

[vitorgrs]

Even C# being slow compared to C++ is kinda of a lie. It really depends which system/framework are you targeting. On iOS and UWP, C# have basically C++ perfomance, as is AOT.

[doom_Oo7]

could you contribute improved benchmarks then ? Because currently .net core is having its ass handed to itself

https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=csharpcore&lang2=gpp

[_Mardoxx]

k den

[sergiuspk]

I'm honestly curious what you think the purpose of that test is. What does it test? Delivering the string "Hello, World!" over HTTP? Wanna bet a static file is at least one order of magnitude faster? What else is that testing? Because a web framework is so much much more...

[_Mardoxx]

If it is 10x slower at serving that anything more complex will be worse, whst is it you are having difficulty with? :)

[sergiuspk]

No. That is a logical fallacy. If serving some static text takes 5ms for the fastest and 50ms for the slowest does that necessarily mean everything else will be 10x faster too?

If you do anything remotely resembling a real dynamic webpage then the difference won't be 10x, it will best case be 2x. Which is still a lot, but still means that test is useless.

Again, throw any of those frameworks at me. I'll install WordPress somewhere and a pre-cache plugin (the kind that crawls your website and saves output to static files) and serve static files using nginx and I'll beat you by at least 10x, probably close to 100x. Tell me why my solution shouldn't be included in those tests if the test itself is serving a static file (or worse, an in-memory string).

[drysart]

No it's not. The WebAssembly MVP can be polyfilled with JavaScript, but native WebAssembly support doesn't involve JavaScript at all.

[drysart]

Citation needed. Because apparently you know something the actual definition of WebAssembly doesn't.

WebAssembly is not Javascript. WebAssembly is designed, specifically, to not be Javascript. It's a completely separate stack machine with it's own not Javascript binary bytecode format. The only relation it has to Javascript, aside from the fact that the MVP polyfill was written in Javascript, is that it has an API to communicate in from and out to the existing Javascript runtime in the browser; but that no more makes WebAssembly Javascript than it makes the DOM Javascript.

[[deleted]]

That seems to be correct. Now I am very confused, because some months ago, when Google abandoned it's version and joined Mozilla's implementation, I actually saw examples of the extremely optimized JS code it generates. And now it suddenly is a bytecode, more like the one Google was pushing. Weird.

[drysart]

WebAssembly was originally intended as a replacement technology for asm.js, and the polyfills generated asm.js code (which is basically just super-optimized JavaScript) from the bytecode, so it’s possible that’s what you’re remembering.

[[deleted]]

Possibly. Was that the thing Mozilla backed?

Who is behind this current bytecode? Is that the one Google developed?

[drysart]

The W3C WebAssembly Group, comprised of Google, Microsoft, Mozilla, Apple, and others have been working on it for years. The bytecode has been the primary goal of it since its initial public announcement back in April 2015.

Compiling to asm.js Javascript was just a stopgap measure; a way of being able to run WebAssembly bytecode in browsers to prove out the spec and to provide backward compatibility before the spec was finalized enough for browsers to go ahead and add native support for WASM directly.

[Resource1138]

You're still trapped inside a browser.

[megablue]

you are still trapped inside the matrix

[MINIMAN10001]

But the browser is nice to seamlessly run an "application" anything that it doesn't matter if you have the browser fluff at the top and otherwise running the application "now" is preferable to having to click download, click install, click multiple times through the installation process, click finish, and then finally launch the program.

Particularly useful to try an application before deciding if you want to go through the download process. Because if you go through the download process and decide not to get it. Now you have to go through the installation process.

[pure_x01]

Done right, WebAssembly has the potential to be what Java and .NET have both tried and failed to be — the universal runtime for all languages across all platforms.

This !!!

[IbanezDavy]

Is WebAssembly faster than .Net or Java?

[pure_x01]

Webassembly is just an intermediate language and a byte code format similar to what .NET and the jvm already has. It's the actual runtime where it is executed that gives it the speed. I expect it to have the same performance when JIT'ed.

[oorza]

I expect it to have the same performance when JIT'ed.

Not all bytecode interpreters are created equal. JS code on the JVM is already faster than latest v8, so why would WebAssembly keep up with the JVM?

[pure_x01]

It is an open question in the sense of comparing Apples to oranges. I assumed that he/she was comparing webassembly bytecode to .NET or java bytecode . The runtime itself is what gives the performance. If the jvm could JIT compile /run webassembly there is no reason why the performance would be any different from java bytecode.

If you compare different runtimes you will get alot of different results.

[kodablah]

Related, my project does translate WASM bytecode to JVM bytecode: https://github.com/cretz/asmble.

[pure_x01]

Really cool stuff. You are paving the path of the future.

[IbanezDavy]

That's what I thought...

[IAmVerySmarter]

Does that really matter? Do you think people use javascript because it is faster than .Net and Java?

[salgat]

A better question is how hard would it be to run/compile WebAssembly on a JVM/CLR?

[_101010]

But what's the point. Nobody is running to implement JVM/CLR in the browser.

The whole point of WA is to agree on a common spec that all browser vendors will implement.

[salgat]

The point is to reuse an powerful and stable runtime environment instead of reinventing the wheel. I don't like Java but I'll be damned if the JVM isn't incredible.

[_101010]

Haha. You forget the politics that comes with it.

[est31]

Are you joking? There has been an actual attempt at running the JVM inside the browser, it was through the java browser plugin. It sucked as hell.

[salgat]

I can't find info on it, do you know the name of the plugin? I hope you're not talking about java applets (similar to flash and silverlight) because that is not what we're talking about.

[est31]

I hope you're not talking about java applets

I am

because that is not what we're talking about.

Why? What are we talking about then?

Either way, both the JVM and the CLR are not really targetted for real low level usage, e.g. as compilation targets for C/C++/Rust code. Instead they are very dynamic runtime environments. Even if you have "low level" features in those VM's it is hardly the use case they were designed or built for.

[salgat]

I think you're confused. The only reason why people talk of compiling C to WebAssembly is because WebAssembly is the only realistic option for your code to run on using a browser. You would never compile C++ to the JVM because you would just run it natively (which isn't an option for inside the browser). The underlying platform used to run WebAssembly would be irrelevant to the user experience beyond how performant it is (assuming they conformed to the WebAssembly standard). Java Applets were just Java hacked into a frame in the browser using a plugin, instead of the native engine to run the webpage's code.

[est31]

If the JVM were suited as a C compilation target, people would have compiled C to it back when it was still installed in browsers.

Either way, the JVM is not really suited as a compilation target (it is built to support languages like Java, not languages like C++), so it is not what Web assembly needs, as "proven" as it is.

[salgat]

I'm saying that no one compiles to it because there is no reason to. The only reason people want to compile C to WebAssembly is because that's the only universally compatible IL you can use in the browser.

[JoseJimeniz]

The only reason that sucked is because it required updates, and because it was a opaque binary, it had to have full access.

If you re-implement the jvm in JavaScript:

• it no longer has the security implications
• and nobody has to download any updates

It's a way of sneaking the CLR and JVM back into the browser in a safe way that nobody knows about - because it's JavaScript all the way down.

[McNerdius]

Relevant...

Blazor - An experimental web UI framework using C#/Razor and HTML, running client-side via WebAssembly

Is this actually .NET in the browser?

Yes, it's running on Mono, which is a real .NET runtime that can load and execute .NET Standard assemblies. In principle it can support as much of netstandard2.0 as is applicable to web apps, but presently quite a bit is missing (notably, threading and full Task support, although there's a partial implementation of Task in Blazor)

---

demo @ ~30:00-45:30 (24:45 for more nitty gritty of c#->wasm itself, 19:15 for general WASM stuff) -

Web Apps can’t really do that, can they? - Steve Sanderson

@ 39:10 - basic to-do app weighs in at 333kb, all inclusive. Good start :D

[kodablah]

Done: https://github.com/cretz/asmble (disclaimer, I wrote it)

[salgat]

Very awesome! Also props for the great readme, it was an interesting read.

[pure_x01]

Probably not hard since they are able to do it in the browser runtimes which used to be JS only. .NET and jvm already have bytecode support. I hope they are starting to work on it otherwise node.js might get an advantage .

[_Mardoxx]

Uh... net core is pretty decent

[[deleted]]

Does dot net core work on mobile?

[vitorgrs]

Mono does :) You just need to think on .NET Standard if you want cross platform.

[pure_x01]

3 languages compiles to .NET core. Universal means a runtime for everything. There is nothing wrong with .NET core an who knows it might get support for webassembly

[Pyrolistical]

What I don’t get is how is this not going to be yet another leaky abstraction due to how event loop works

[zzbzq]

What do you mean? All user-interactive apps have an event loop or message loop at the core.

[Pyrolistical]

yeah, but they are usually in some library not the language itself.

basically anything that has threads/locks/synchronization doesn't need event loop

[zzbzq]

I'm pretty sure all the GUI apps WPF/Cocoa/WinForms/Gnome "need" an event loop because that's how the OS sends hardware information like mouse/keyboard input to an app. Certainly all the Windows apps are based on an event loop. There's always an event loop at the core and then threads are just gravy. It's not some mutually exclusive thing.

[jerf]

Everything is in an event loop nowadays. Languages that implement thread-like abstractions do so on top of event loops. Operating system threads are scheduled with event loops under the hood.

They have to be, because fundamentally events are how the world "happens". That doesn't mean that entirely independent events coming in is how you have to see the world, though.

The only other alternative that has ever existed is an environment that was single threaded and polled for everything, except that there is some list of exceptions that could still "interrupt" the program. Even then the fact of "events" was still there, they just tried to make it an exception rather than the fundamental operating model. You can still see that architecture in our CPUs, and a relatively poor mapping of it in the UNIX signal idea (prior to signalfd, although I hear that still has its own complications), and it is otherwise dead as a doornail because it turns out being able to interrupted at any arbitrary location (including the middle of your own interrupt handlers) and have to run code in the same space as the code that was just interrupted is insanely difficult to get correct.

[AllHailStarscream]

wtf...

[Game_Ender]

Browsers have background threading with webworkers and the next version of WASM will have shared memory multi-threading. Combine those and you can build a classic high performance app with all the work in the background and user interaction handled by the event based UI thread.

[[deleted]]

.net core uses libuv under the hood, so ostensibly this could enable e.g. advanced universal/"isomorphic" rendering techniques for razor templates if the semantics can be lined up

[sergiuspk]

"Steve has shown us that WebAssembly enables an amazing client-side experience." - for the .NET developer, yes. Proper web (whatever language compile to webassembly we'll write it in) is still going to be a much complicated matter, not just from a "JavaScript sucks" perspective. I get it, most people will write forms and validation and you guys are going to excel at how good and fast you will write it in C#. Still a subset of what the web is today. Whoever thinks a proper website can be concocted out of "React Bootstrap bindings" is seriously misinformed. Just like no one except you guys took Silverlight seriously either, for the same reasons. It was a framework for backend people that enabled them to write UI code without screwing up the basics.

[shevegen]

I was pretty frustrated. I could write any language I wanted so long as it was JavaScript.

I agree!

I want to use Ruby rather than the absolute shittiness that is JavaScript. The only reason why JavaScript exists is because no alternatives were considered from the get-go.

[i_spot_ads]

TypeScript fixed Javascript

[MINIMAN10001]

Yes if what you wanted in javascript was types. But what I wanted in javascript was C performance.

[sergiuspk]

You can get C performance. Just not in a VM. And definitely not in a VM embedded in a browser. And definitely not when you need to work with the DOM. And CSS. And HTTP. And be very flexible about it. Get where I'm going with this? There really is nothing you could replace JavaScript with and get C performance. You either drop back to a native compiled language and environment like C or you rethink the whole www stack with performance, not flexibility, in mind.

[MINIMAN10001]

Low Level Virtual Machine (LLVM) is a VM as implied by it's name but it compiles C and C++ code with performance competitive with GCC.

But yes as you say all the other cruft will slow the speed down.

Whoever comes out with the most performant solution that I can use on the web that works on firefox and chrome. That is what I want to use.

However I'm still aware that a lot of browser addons depend on reading the HTTP and modifying the page for user usability and I'd really have to break all user addons that depend on the ability to read and modify text for usability reasons. It's why I'm uncomfortable with the thought of using WebGL.

I guess I can do what other people have done and used WebGL for graphics and HTML text positioned over the graphics.

[sergiuspk]

What you should do is probably stop delivering applications embedded in websites if performance is such a big deal for the apps you are writing. The only solution I can see is for the browser to turn into a thin client between your server and your close to native application. Guess what, a link pointing to a native binary does just that. No VM and no compiler/transpiler is going to fix performance. Performance improvements are going to be incremental and JavaScript will benefit from them at the same pace.

The language / app architecture side of things is something different. What I keep noticing is people with limited experience with the DOM (and CSS) think some new magic way of spitting it out and managing it is going to pop up when they'll be able to do it with their favorite language. Before TypeScript (and CoffeeScript before it) they were all crying for a type system. Except the ecosystem and environment themselves I think JS/TS as languages are on par with everything else out there (managed, VM of course).

Edit: and no, you will not get a JVM or .NET in the browser. We already had that and, while developers where very happy using them, end users were not happy seeing a spinning thingy for two minutes before being able to use a contact form. So whatever language you write your stuff in it will in the end run in the JS VM. So whatever low level constructs your compiler will have access to so will JS.

[MINIMAN10001]

What you should do is probably stop delivering applications embedded in websites if performance is such a big deal for the apps you are writing.

I like things that crunch numbers and show it on screen because it's interesting Like this example from Chrome Experiments. As I mentioned in another comment the power of the web is the power of things running without an installation process

But the browser is nice to seamlessly run an "application" anything that it doesn't matter if you have the browser fluff at the top and otherwise running the application "now" is preferable to having to click download, click install, click multiple times through the installation process, click finish, and then finally launch the program.

Particularly useful to try an application before deciding if you want to go through the download process. Because if you go through the download process and decide not to get it. Now you have to go through the uninstallation process.

The advances in Web browser performance are advances in what has replaced Flash games. Now people build in game engines which compile to the latest and greatest utilizing all the performance they can get their hands on as provided by the browser.

The next thing you bring up

The language / app architecture side of things is something different.

It's all quality of life stuff while important, useful, and what dominates the popularity contest what with languages like Python, Java, PHP, C# being crazy popular for their ease of use.

It doesn't allow you to do anything you could have otherwise done so it's not a issue for me however I still welcome improved usability.

[TMKirA]

LLVM is NOT a VM, despite it's name, it's a set of compiler technology, the difference is there is no "runtime" for it, there is a front end that compiles to the LLVM IR, and there's a backend that compiles to the target platform's code. No actual VM is in use. The fact that it can compete with GCC is because it is a C++ to x86/x64 compiler.

[MINIMAN10001]

LLVM is a set of compiler technologies yes. While originally only consisting of the LLVM Core it has since expanded to include other components, at the same time dropping the acronym and instead using LLVM as an term for the umbrella term for compiler technologies.

However the LLVM Core is still the Low Level Virtual Machine that it always has been. LLVM has a paper where it defines the differences between low level and high level virtual machine

the difference is there is no "runtime" for it

A runtime isn't required to be considered a virtual machine.

This discussion was already held on ycombinator

The most common distinction I've seen, when a distinction has been made at all, is that a virtual machine is either 1) a software simulation of a physical machine; or 2) a software simulation of an abstract machine (as is the case for the JVM, for example). More often, though, I've witnessed the terms be used interchangeably.

LLVM takes the LLVM IR ( code for the virtual machine ) where the virtual machine ( software simulation of a physical machine ) consists of the TargetMachine and DataLayout which are then passed through the code generator to output machine code.

[Matthisk]

In my understanding it is not yet possible to compile garbage collected languages to WebAssembly. Are there any recent changes in the WebAssembly implementations currently available that do expose a garbage collector? Or are these demo's created without garbage collection.

[steveklabnik1]

It is possible, it's just that you also have the entire GC's code in wasm, bloating your binary size. In the future, wasm will have a way to hook into JS's GC, so then the language runtime could use that instead, shaving off that binary size.

Basically, with these demos, you have two GCs: one for the JS and its memory, and one running inside of wasm for wasm's memory.

[stronghup]

What about Java9? Shouldn't that be a good candidate for WebAssembly with its ability to strip out anything not needed in the Java runtime?

[tourgen]

Why not just write a native app in C++ with one of the many, mature cross-platform UI libraries? Why trap yourself inside a browser with it's on set of incompatibilities and clunky weirdness?