My excitement for WASM has nothing to do with speed or efficiency of the runtime. It's all about finally having a universal compile target for the web. We're finally going to be able to develop web apps in a proper language of our own choosing, without needing hacks like TypeScript.
Hopefully, this will lead to real dedicated IDE tooling and standardized libraries for the web along the lines of what's available in iOS and Android native development.
That's what I find great too, though for some reasons they put too much emphasis on JS-wasm compatibility and less on language support(i.e DOM or GC are considered "unicorn" features). I'm pretty sure 90% of the web developers won't mix js with wasm once they can compile their preferred language to wasm. You will find either js apps or wasm apps. There may be also a very small percent of js apps with wasm modules(i.e for video decoding)
They are trying to convert current web devs. JS is the language of the browser and essentially the web, so most developers working in webdev primarily work w/ js.
Actually many of us use es6 with a compiler to turn into some dialect of js that runs in browsers. We will hardly notice if our code starts getting compiled to wasm instead..
Eh, there isn't any reason that it couldn't at some point in the future. That won't be happening any time soon, but I'd love to see that day, personally.
Then you're shipping the entire (or at least large pieces of) language runtime to the client since presumably, you'd need to compile that to WASM as well.
Given that runtimes like Lua are comparable in size to a single image, and/or could be cached in web browsers, I don't think that will much of a problem. And the more that WebAssembly adds, the smaller that will get.
Obviously if we're trying to run a full JVM or CLR in WebAssembly, that will cause problems, but C# and F# both have compile-to-js targets that would likely just get faster.
Something that never really worked was cached versions of jquery (and similar) from cdn. One reason is that browsers didn't give them any particular precedence. The other was that jquery was moving quite fast compared to devs using it so as an end user i nearly never benefited from the caching. I wonder if this might work better for language run times. Maybe browsers could be provided with some manifest saying 'this site needs python 3+' or 'this site needs python 3-3.5' so that end users end up with less runtimes cached.
The JS devs don't really need wasm. JS works just fine in browser. I find the use cases mentioned (js app + high performance wasm modules) limited to a very small niche. WASM is supposed to be a target language. Are they trying to convert current web devs to C++/rust devs? It doesn't make any sense to me. If wasm was designed just to help JS to do more then it is doomed to fail.
Sure it does. And the myriad of languages that pop up to support WASM will work infinitely better. ES6 was a huge step forward, but it's still a long way from a real language like C#.
I suspect Javascript development will always be a thing, but that front end development will fracture into multiple different languages and runtimes as full WASM support comes online.
While I can agree that C# has tons of language features that make it more powerful than JavaScript, I take issue with the idea that those features are the defining characteristic of a "real" language. I think there are many reasons to choose C# over JS, but there are also a non-trivial of reasons to make the opposite choice.
I disagree with OP, but two interesting corollaries of TS type semantics are its strong type inference and structural typing:
Const x = [{x: 3, y: "hi"}, {x: 9, y: "bye"}];
Automatically gets you x: "Array of {x : number, y: string }". And if you declare the same type somewhere else, as long as they're "structurally equivalent" (i.e. same x and y types) you can actually use them interchangeably. You can't do that e.g. with c#, where one class will never be exchangeable with an unrelated class , no matter how similar the definitions.
All in all, it's more of an oddity than an actual strength, if you ask me. It's necessary to emulate JS semantics, but I wouldn't consider it an advantage in a new language.
> You can't do that e.g. with c#, where one class will never be exchangeable with an unrelated class , no matter how similar the definitions.
Agreed. Duck typing is a killer feature. I can't say how many time's I've rolled a new class for no reason other than data structuring, which would have been far preferable as something just defined inline.
Mostly, for me, it comes down to union types, intersection types, the ability to disallow implicit nulls (meaning null must be declared as a valid value at the type level, and therefore cannot creep in unexpectedly), string literal types, discriminated unions (most of the good stuff from algebraic data types), and index types.
Typescript is designed to be compiled to JS. WASM is designed for staticly compiled languages. Even if there is GC and DOM access through WASM, Typescript will be better off to run for the natively JIT optimized JS path.
Sure, Anders is great but this not so easy. Basically you would have to re-implement all the features and optimizations of current JS-Engines.
In WASM you are restricted to the given (statically-typed) opcodes, while a JS-JIT has more knowledge about program semantics and can thus apply optimizations more easily.
In addition the JIT can also make use of hand-written assembly if it is needed for best performance.
I think JRuby does a similar thing for Ruby and Java Bytecode. TruffleRuby shows that it is possible to be faster, they do not compile to bytecode and use their own compiler.
Sure, but all else being equal, a statically typed language will always be faster than a dynamically typed one, because you can do way more optimization at compile-time rather than run-time. So you're right in that JS is pretty darn fast, but it probably wouldn't take that much effort to surpass JS performance with a custom TypeScript -> WASM compiler.
Sure, but AFAIK TypeScript is not generally fully statically typed. You could just rename a .js file to .ts and call that TypeScript. Please correct me if I am wrong.
There are some dynamically typed languages like Python or Dart that allow (or are in the process to allow) type annotations. But all these languages I know about claim that type annotations do not help performance.
I guess you could define a fully statically typed subset of TypeScript that allows you to compile it to fast WebAssembly bytecode. But that would probably also mean to change some semantics: see int vs double for numbers in JavaScript.
The only reason type annotations in those languages don't increase performance is that they compile down to JS, which is dynamically typed, so all static type information is lost. But you're right, you would either have to annotate everything with types, or re-implement the JS runtime in WASM in order to gain any benefit from it. The most feasible option would be to target a fully-typed subset of TS, which may or may not be practical.
Your claim was "it probably wouldn't take that much effort to surpass JS performance with a custom TypeScript -> WASM compiler"
I guess you basically have two options:
1) Implement a JS-Engine on top of WASM. Which is a lot of work. But what could you do to get better performance than current JS-Engines? Every optimization you can implement on top of WASM, you can also implement for native JS-Engines. Quite the contrary it is even harder, since you are an abstraction layer higher and can only make use of WASM opcodes.
2) Define a fully-statically typed subset of Dart and compile to WASM. You could sure do that, but don't forget about e.g. the ubiquitous number type in JS/TS. You may have to use double (almost) everywhere if you want to match semantics of JS. How many non-trivial TypeScript programs could such a subset run successfully? I assume not a lot.
I don't see how you could write a TypeScript to WASM compiler without much effort. Care to explain?
I don't understand why the downvotes , JS is one of the most target languages. Elm,GHJS(Haskell),Purescript,Clojurescript and supersets like Typescript which come with their own toolchains.
Hopefully, this will lead to real dedicated IDE tooling and standardized libraries for the web along the lines of what's available in iOS and Android native development.