Design: Webasm can replace Javascript in browser?

I am not familiar enough with c#, but actually, I think wasm can not take over javascript completely.

First, if you have tried, you would found that javascript is much quicker than wasm in some lower-level operations, such as "+,-,*,/" and some other math related operations because of the slight overhead when calling from JavaScript into WebAssembly and back. #1120

Second, for web developers, they had already familiar with javascript and its grammar, it's unnecessary and hard for them to build web apps with another non-web developing language.

At last, with the help of "Binary AST", the performance of current web applications will be raised to a new level without any revisions on those applications.

PS:
No matter C# or Java, if you want to make this programming language much more friendly to developers, the efficiency of this language will be limited because of some "easily-using" features like "weakly type" and any other features, vise versa.

@Becavalier May be yes if you are trying to call a wasm function from JS context overhead exists, but the runtime don't communicate to Javascript until and unless it is exclusively required to.. like DOM query/Manipulation, CSS inline, Canvas paints _etc.._ All the execution happening inside the wasm context is pretty faster. Delay comes into picture when the JS bridge is introduced, like in the case of #1120 you are trying to print the performance timestamp in Javascript context for a function thats executed in wasm context which is an additional delay.

Popular frameworks like Angular2/4 which is a complete revamp adopting Typescript, Android in Kotlin or iOS in Swift, when there is a big name behind some of the frameworks or language whole world try to adopt the change.

So the point is, there is a possibility of JS being sidelined or even removed from the picture by abstracting the API bridges and porting runtimes on browser. Webassembly has opened the door for compilers of other languages to compete with Javascript on browser.

We initially used to adopt technologies that made our JS code more efficient to run on VM's like V8 and others, but now you can write and compile to an assembly code that can leap frog the JS code.

Now you can expect compilers for web replacing transpilers like TypeScript, CoffeeScript etc..

Javascript developers, keep your fingers crossed. Can expect some big move in forth coming years.

P.S : I love Javascript and C-Lang

Webassembly has opened the door for compilers of other languages to compete with Javascript on browser.

Yes indeed, that is one of the purposes of WebAssembly.

Here is a quote from the WebAssembly FAQ:

While WebAssembly will, over time, allow many languages to be compiled to the Web, JavaScript has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web. Furthermore, it is expected that JavaScript and WebAssembly will be used together in a number of configurations:

• Whole, compiled C++ apps that leverage JavaScript to glue things together.

Keep in mind that other languages have compiled to JavaScript for years, and they will continue to do so with or without WebAssembly.

You can already compile C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, etc. to JavaScript.

You can compile .NET bytecode to JavaScript, you can compile OCaml bytecode to JavaScript, and GWT has been around for 11 years and has been used in big projects.

These projects have been around for many years. It's not really a new thing.

JavaScript already competes with other languages. WebAssembly just makes other languages more efficient, that's all.

We initially used to adopt technologies that made our JS code more efficient to run on VM's like V8 and others, but now you can write and compile to an assembly code that can leap frog the JS code.

Yes, because JavaScript VMs can never achieve native performance, because of the overhead of JIT engines (and the inherently dynamic nature of JavaScript), so if you want more performance you need tight low-level control of the code execution. WebAssembly gives you that control.

So the point is, there is a possibility of JS being sidelined or even removed from the picture by abstracting the API bridges and porting runtimes on browser.

No, people will continue to use JavaScript.

For many years on the desktop there have been many languages to choose from: Python, Perl, Ruby, PHP, Haskell, JavaScript (Node.js), OCaml, C++, Java, etc.

People use many languages, including JavaScript. JavaScript isn't going anywhere.

Even in a (very unlikely) hypothetical world where JavaScript isn't a first-class language, people can still compile JavaScript to WebAssembly.

Now you can expect compilers for web replacing transpilers like TypeScript, CoffeeScript etc..

That's unlikely, there are still good reasons for people to use TypeScript and JavaScript.

Of course there will be alternatives to TypeScript, and some people will use those alternatives, but TypeScript is unlikely to go away.

I say that because there have already been good alternatives to TypeScript for years (such as Haxe) but they never replaced TypeScript.

On 4 September 2017 at 03:42, Pauan notifications@github.com wrote:
>

JavaScript already competes with other languages. WebAssembly just makes
other languages more efficient, that's all.

The latter is not quite correct. Another goal of Wasm is to enable features
that are not supported by JavaScript, and potentially never will be. For
example, concurrency, tail calls, or resumable exceptions are all on the
road map.

@rossberg-chromium Indeed you are correct, I had forgotten that detail. Thanks for clarifying.

@Pauan Thanks for the details. Although some of your point are valid and makes sense, i dont agree with all.

C# on client side looks promising and a killer example to avoid Javascript completely at development stage. ie.. I can use C# to write a fully functional webapp without me writing any Javascript code. This kinda attitude based frameworks have a probable chance of muting Javascript legacy at-least to an extent.

You can already compile C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, etc. to JavaScript.

Yes the Javascript was in picture. But now with WASM/Webasm my motive of compiling to Javascript is changed. One can directly compile to wasm and write an API mask layer or bridges in Javascript whenever required, so the developer base don't need to know Javascript to develop a webapp with Webapp i mean pure Webapp not ASP.net, JSP kinda frameworks.

Keep in mind that other languages have compiled to JavaScript for years, and they will continue to do so with or without WebAssembly.

You can already compile C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, etc. to JavaScript.

While many languages can compile to JavaScript already, would compiling to Webasm avoid the signficant load and runtime performance penalties for doing so? And the performance issues if you compiled a languages full C VM to Webasm to do it that way?

If using other languages results in unavoidable performance issues, or lots of places that violate that languages spec (for performance reasons), its a partial replacement for JavaScript at best and generally Ive seen them used more for porting legacy code than new code to "replace JavaScript" (excepting CoffeeScript, TypeScript, etc. that are designed to compile to JS nicely).

Are these problems that can be solved? e.g. with a new Ruby -> Webasm compiler, and get comparable performance to current browser JavaScript?

To use JavaScript and Ruby (with Opal) as an example (as somthing I tried and basically abandoned previously):

In JavaScript with a + operator, it allows numbers to be converted to a string, e.g.

5 + " example" === "5 example"

Ruby has much stronger typing, and that is not allowed:

5 + " example"
#TypeError: String can't be coerced into Integer

So Opal has to make its own plus, and fairly complex methods for many core types

function $rb_plus(lhs, rhs) {
  return (typeof(lhs) === 'number' && typeof(rhs) === 'number') ? lhs + rhs : lhs['$+'](rhs);
}
String.prototype['$+'] = function (r){var t=this,n=arguments.length;return 1!==n&&e.ac(n,1,this,"+"),r=ke.get("Opal").$coerce_to(r,ke.get("String"),"to_str"),t+r.$to_s()}

Likewise for many basic operations.

# Ruby: if a || b
if ((($a = ((($b = a) !== false && $b !== nil && $b != null) ? $b : b)) !== nil && $a != null && (!$a.$$is_boolean || $a == true))) {

Maybe in theory a JIT could optimise that fully, but don't think they are close (didnt micro benchmark, but for an entire prototype app/page I did the Ruby version was significantly slower) and conversions like that seem to just be making the optimisers life harder?

And even then, some things are wrong or not supported (allthough Webasm has native integers, so thats a start hopefully if compiling to Webasm rather than JS):

1 / 2 == 0.5 # Should be 0, Ruby has integer division

str = "Hello"
str << " World" # Opal: String#<< not supported. Mutable String methods are not supported in Opal.
puts str # "Hello World"

@nirus

I can use C# to write a fully functional webapp without me writing any Javascript code.

Yes, and I agree that's very cool (I am working on a language which I plan to compile to WebAssembly), but my point is that you can already do that, even without WebAssembly.

One can directly compile to wasm and write an API mask layer or bridges in Javascript whenever required, so the developer base don't need to know Javascript to develop a webapp with Webapp i mean pure Webapp not ASP.net, JSP kinda frameworks.

Indeed, and that's already been possible for many years now. You don't need to wait for WebAssembly, you can start now: asm.js has existed for several years.

@wnewbery

While many languages can compile to JavaScript already, would compiling to Webasm avoid the signficant load and runtime performance penalties for doing so? And the performance issues if you compiled a languages full C VM to Webasm to do it that way?

It might help the parse times, but it's unlikely to help the runtime performance.

Let me clear up something: asm.js has existed for several years. It allows you to compile a program to JavaScript, and that program will run at almost-native speeds. In other words, you can run a program at the same speed that it runs on the desktop.

So it has already been possible to take a language, compile its VM, runtime, and garbage collector to asm.js, and you can then run whatever language you want in the browser, at almost the same speed as on the desktop. This has already been possible for quite a while now.

However, compiling the VM, runtime, and garbage collector means that the file size will be quite large (many megabytes).

And it's difficult to communicate with JS APIs (like the DOM).

But some people have done it anyways, and created things like PyPy.js which compiles the PyPy interpreter into asm.js.

It runs faster than CPython (yes, really! The PyPy interpreter which has been compiled to JavaScript and is running in a browser runs faster than native CPython on the desktop!)

But the file size is quite bad (5 megabytes gzipped, 15 megabytes raw).

So you could compile Ruby's VM + garbage collector + runtime to asm.js, and it would be very fast, but it would have those problems. So instead people create things like Opal.

WebAssembly is the next evolution of asm.js. At the moment, anything that you can do with WebAssembly, you can do with asm.js as well.

So yes it is possible to compile your language + VM + runtime + garbage collector to WebAssembly, and it will run at almost native speed.

But of course it has the same downsides as asm.js: very large file size, and it's hard to communicate with JS APIs.

There are seven differences between WebAssembly and asm.js:

1. WebAssembly is a tiny bit (5%) faster than asm.js in general.

2. WebAssembly is significantly (~400%) faster than asm.js if you are using 64-bit integers.

3. WebAssembly can be parsed much faster. This does not improve the runtime speed of your program, but it does mean that the initial load time is faster with WebAssembly.

4. WebAssembly file size is smaller than asm.js file size (about 10-20% smaller).

5. WebAssembly might in the future gain awesome features which asm.js doesn't have (threads, concurrency, zero-cost exceptions, etc.).

6. WebAssembly might in the future gain access to JavaScript's garbage collector (which means you won't need to compile your language's garbage collector to WebAssembly anymore, which means smaller file sizes).

7. WebAssembly will in the future gain the ability to easily use JS APIs (like the DOM).

But even in the future it will still be necessary to compile your language's VM + runtime into WebAssembly, so file size will still be an issue.

If compiling your language's VM + runtime + garbage collector into asm.js is not acceptable to you, it probably still won't be acceptable even with WebAssembly.

And if compiling your language's VM + runtime + garbage collector is acceptable to you, you can already do that right now with asm.js (and then easily transition to WebAssembly later).

Are these problems that can be solved? e.g. with a new Ruby -> Webasm compiler, and get comparable performance to current browser JavaScript?

WebAssembly's purpose is to run programs at native speeds. In other words, running them at the same speed that they run on the desktop.

So if you compile Ruby to WebAssembly, it will run at the same speed that Ruby runs on the desktop.

Ruby is a pretty slow language. Slow languages and slow programs will still be slow, even when compiled with WebAssembly.

1 / 2 == 0.5 # Should be 0, Ruby has integer division

That's a bug in Opal which can be fixed by simply changing the definition of the $rb_divide function.

str << " World" # Opal: String#<< not supported. Mutable String methods are not supported in Opal.

That can be fixed by having Opal compile strings into JavaScript arrays (which are mutable).

@Pauan

WebAssembly might in the future gain awesome features which asm.js doesn't have (threads, concurrency, zero-cost exceptions, etc.).

Thread is a very important feature for many languages, libraries, frameworks.Without thread, many apps created by c++, c#, java which rely on multithread cannot just transform to webapp since it may cause weird behavior(Not to mention another good thing like SIMD support _in the future(?)_). In short, I think asm.js is not good enough, either performance nor port ability, it if is that good, there should be more libraries "ported" to asm.js long time ago.

as everyone has said javascript won't just go away because it's so popular and for legacy support, most browser's will still support running javascript natively but I think in the future anyone making new websites with javascript will compile it to wasm for all those performance gains

@unmellow, to debunk that myth again: there would be no magic performance gains from compiling JS to Wasm, quite the contrary. If you want better performance than JS engines are able to deliver then you have to pick a better language.

yeah sorry I forgot I meant it would parse faster
edit: something that might happen though is browser not updating their javascript engines to support
newer versions of javascript sense people could compile to wasm without any losses in performance

I'm not really comfortable with kicking up an year-old ticket, but, for the sake of discussion and just a little rant.

I can see many people are skeptical with the idea of replacing Javascript with WASM, but one thing is that WASM isn't really just about performance. What people mostly forget about is that Javascript isn't the language they want (or wanted). I mean, at least, the barebone Javascript is not what people want. More and more people are going with transpilers, which are basically compilers for 3rd party languages. This is merely that people gave up relying on standards and diverted to userland(?) solutions.

But transpilation is, by its nature, much more difficult than compilation. The mathematical problem of mapping one language to another isn't always limited to local scope. Some contextual information has to be carried over to the other side, and correctly doing so is a difficult problem. That's why non-Javascript-like transpilers are not widely adopted (or why they should not be relied on).

Also, there's a problem with duplicated efforts. Transpilers are compilers, and bundlers are linkers. We all have had those tools for ages. Modules, tree shaking, code splitting, dynamic/lazy loading, asset management, etc. Nothing is genuinely new, but people need new tools to have these features just for web, which isn't friendly to non-web solutions.

It's not like WASM will change everything in one day. Javascript has a well built ecosystem right now, while other languages don't. I'll take time before Javascript really goes somewhere, but it'll clearly happen in a long run.

Javascript is heading in, what I consider to be, an awful direction so I welcome a WASM replacement. I think while there have been significant improvements, a lot of the community and direction has been mislead over the past several years. I'd more than welcome a proper language to.. not necessarily to take its place, but to be a direct competitor so I didn't have to write this new obnoxious flavor of JS and its "frameworks" that have shown up.

@spencerudnick Never written assembly for performance gains you can't get from C?