New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Will there be a JS -> WASM compiler? #219

Closed
bguiz opened this Issue Jun 23, 2015 · 82 comments

Comments

Projects
None yet
@bguiz

bguiz commented Jun 23, 2015

After scrutinizing the design docs, I was able to find a mention of a polyfill that would transpile WASM -> JS. I was also able to find mention of a C++ -> WASM compiler.

However, I was unable to find any mention of a JS -> WASM compiler.

The majority web developers are fluent in Javascript, and thus a JS -> WASM compiler would be ideal. Web developers will want to continue writing their websites using Javascript, instead of writing them using C++. Thus I am not sure what to make of the MVP, nor the post-MVP sections making no mention of a JS -> WASM compiler. What is happening here?

@creationix

This comment has been minimized.

creationix commented Jun 23, 2015

Browsers will still have native JavaScript VM along-side wasm. There is no reason to compile JS to wasm because you would have to also include a whole javascript vm. The resulting code would be huge and slower than the JS VM natively provided.

There is a task post MVP for adding things like adding access to the GC from wasm code so that scripting languages can be implemented for wasm.

@jfbastien

This comment has been minimized.

Member

jfbastien commented Jun 23, 2015

JS → wasm will only really make sense once wasm supports GC, and most likely JIT compilation too, which is still quite a while away. This would basically be equivalent to implementing the JS engine in wasm! I mentioned this recently and @BrendanEich accused me of having been taken over by horse_js.

To be clear, wasm's goal isn't to replace JavaScript, it's to supplement it. It's therefore not really a goal at the moment to support JS → wasm, but the features we want to implement will make it possible. I'm not sure it'll be that useful from a developer's perspective, though. You may get some size reduction, but that's about it. From a browser's perspective it may be interesting to have the JS engine implemented in wasm from a pure security perspective.

@creationix

This comment has been minimized.

creationix commented Jun 23, 2015

@jfbastien I beat you by 2 seconds ;)

But your answer is better. I'm excited for GC and JIT in wasm. I love creating my own languages and running them on the web.

@bguiz

This comment has been minimized.

bguiz commented Jun 23, 2015

And how about supporting variants such as asm.js or TypeScript/ES7? These
flavours of Javascript promise some level of type guarantees.

I'd imagine the need for JIT would be less so, but GC still very much
needed for these languages. Would having a {typed flavour JS} -> WASM make
this any more feasible?

W: http://bguiz.com

On 24 June 2015 at 09:44, Tim Caswell notifications@github.com wrote:

@jfbastien https://github.com/jfbastien you beat me by 2 seconds :P


Reply to this email directly or view it on GitHub
#219 (comment).

@titzer

This comment has been minimized.

Contributor

titzer commented Jun 24, 2015

Yes, an asm.js -> wasm translator is a high priority, and Luke already did
work on a compressor that might serve as a good starting point.

On Wed, Jun 24, 2015 at 1:59 AM, Brendan Graetz notifications@github.com
wrote:

And how about supporting variants such as asm.js or TypeScript/ES7? These
flavours of Javascript promise some level of type guarantees.

I'd imagine the need for JIT would be less so, but GC still very much
needed for these languages. Would having a {typed flavour JS} -> WASM make
this any more feasible?

W: http://bguiz.com

On 24 June 2015 at 09:44, Tim Caswell notifications@github.com wrote:

@jfbastien https://github.com/jfbastien you beat me by 2 seconds :P


Reply to this email directly or view it on GitHub
<#219 (comment)
.


Reply to this email directly or view it on GitHub
#219 (comment).

@MikeHolman

This comment has been minimized.

Member

MikeHolman commented Jun 24, 2015

We have spoken with the TypeScript team about this possibility and they have shown interest, but it seems like progress there is currently gated on adding typed objects into JS.

@BrendanEich

This comment has been minimized.

BrendanEich commented Jun 24, 2015

@bguiz: JS engine is the wasm engine, and it will continue to support the evolving JS standard language. No worries there (I wasn't sure whether you thought that might go away. Not in any future that I can foresee). OTOH as others note, wasm needs time to evolve GC, JIT support, and other dynamic language features, to be a first-class target for JS. Even when it does evolve these things, I have doubts that JS/wasm engines will drop their JS syntax and built-ins in favor of downloaded JS-in-wasm VMs. We shall see!

/be

@sunfishcode

This comment has been minimized.

Member

sunfishcode commented Jun 25, 2015

An asm.js-to-WebAssembly translator will also be something we're planning to add to Emscripten.

As for regular JS, I think others have answered the question above.

@alexino2

This comment has been minimized.

alexino2 commented Sep 16, 2015

The whole point of JS is easy to code and can do amazing things : dhteumeuleu or codepen.io/ge1doot, but you can see the source and it's easy to hack.

"wasm" is only a way to sell more game and others apps for google, apple an co. The only "evolution" is that there'll be able to control you better with "no install", directly from the big brother server... I'm just surprised they are not afraid of eating each other yet...

@gregtour

This comment has been minimized.

gregtour commented Mar 15, 2016

It's possible with code analysis or code annotations to compile ECMAScript to WebAssembly. This doesn't sound like a priority for the WebAssembly team but it does sound like a great idea for an independent effort.

@evanw

This comment has been minimized.

evanw commented Mar 27, 2016

I just started experimenting with a toy programming language that might be relevant: https://github.com/evanw/thinscript. It uses TypeScript-style syntax and compiles to WebAssembly. I figured I should mention it because it might be an interesting case study. Also I was pleasantly surprised by how easy WebAssembly was to generate. Nice work everyone!

@sunfishcode

This comment has been minimized.

Member

sunfishcode commented Mar 27, 2016

I would caution people about using very thin wrappers on top of wasm though, in general. As one example, thumbing through the thinscript code, I see there's a while statement which is lowered to loop { if (!condition) break; }, which will be less efficient than if (condition) loop { ...; br_if condition } on several wasm engines.

To me, the thing that makes wasm more than just a reheated JS is the possibility of a different philosophy: because wasm is a compiler target, compilers can perform optimizations before shipping the code to clients, so we can keep client-side VMs simpler and faster. However, if thin wrappers around wasm become popular, there's a risk that client-side implementations will eventually have to grow bulkier and more complex in order to do the optimizations that aren't being done.

@evanw

This comment has been minimized.

evanw commented Mar 27, 2016

Yes I agree. One of the things I like most about WebAssembly is its simplicity. I'm planning on adding compiler optimizations and doing benchmarks once the language is more complete. I expect inlining to be one of the bigger wins, for example, and I wouldn't expect WebAssembly to do that for me. I'm also planning on experimenting with a machine code target and I will be using the same optimizations for both targets.

@sunfishcode

This comment has been minimized.

Member

sunfishcode commented Mar 27, 2016

Sounds very cool! I'll be interested to see where it leads.

@affixalex

This comment has been minimized.

affixalex commented Aug 14, 2016

I'm imagining JS->WASM being more appealing for servers than clients. As a very high-level overview of the architecture that I have in mind...

JavaScript -> WebAssembly -> Tracing Interpreter -> LLVM IR -> Machine Code

In this conception, a clear mapping from WASM to LLVM IR for garbage collection would be very desirable. Promotion from IEEE doubles to integers could be done as an LLVM pass. The notion of separate JITs for warm and hot code could be implemented in terms of LLVM pass managers.

Just some thoughts, please feel free to delete this if it's spurious!

@AlicanC

This comment has been minimized.

AlicanC commented Oct 13, 2016

Cross environment compatibility is a serious problem in JS ecosystem. Babel tries solves this problem by transpiling down to some more adopted version of ES and I guess we can all say that it is pretty successful.

There is still an issue here though. For example, if you are transpiling your ES 2016 code down to ES5 for compatibility and your code happens to run on an environment with (partial or complete) ES 2016 support, you will be missing out the benefits of having ES 2016 support in your environment.

If everyone is transpiling their code down to ES5, then what is the benefit of having ES 2016 support in an environment in the first place?

A new project called "babel-preset-env" tries to fight this issue by targeting environments by their versions. The idea behind it is that (1) you ask it to target specific versions or "latest X versions" of browsers, (2) it determines the lowest common denominator of features and (3) enables only necessary transpilations. This helps, but sadly can't solve the issue.

We still have the risk of a major vendor not behaving and causing the same issues Microsoft was causing with Internet Explorer for years. The whole ecosystem is in hands of a few vendors, who decide what to implement and when to implement. This is not free nor open.

The only solution is a new compile target for JavaScript which is performant and needs a lot less maintenance (hopefully none) than a JS engine. When environments (browsers, Node.js, etc.) starts supporting such a target, implementing new ES features should become the responsibility of compilers and not engine vendors.

@Simran-B

This comment has been minimized.

Simran-B commented Oct 20, 2016

JS -> WASM would be interesting to protect intellectual property by code obfuscation when it comes to on-premise installations of let's say Electron apps on customer servers. It's hard to believe but true, there are many small institutions in Germany with very little or no internet connection, which requires on-premise installations, but giving your entire code in plaintext to them can be scary for software companies.

@ghost

This comment has been minimized.

ghost commented Oct 20, 2016

@Simran-B Wasm has as a design principle to support a familiar text format. Notably it has a structured control flow design for quick analysis, and is optimized for single use definitions used in stack order so optimized for readable expressions. Thus it is not a 'code obfuscation' target, but developers can emit their own 'code obfuscation' on top of this but should understand that this is expected to have a cost in terms of decreased encoding efficiency and decreased performance.

@Richard87

This comment has been minimized.

Richard87 commented Nov 13, 2016

Hi all, I just resently discovered WebAssembly, but thinking about the JS -> wasm compiler, I imagined something like Angular2's Ahead-of-Time compilation, jsut way more optimized (I'm thinking machinecode instead of javascript)... Will this ever be possible? Is it worth it?

EDIT
I'm also thinking, is will there ever be a possibility for the browser to send a flag to the client that it supports wasm, and then we can serve up a precompiled app instead of a javascript file?

Richard

@distransient

This comment has been minimized.

Contributor

distransient commented Nov 14, 2016

@Richard87 you could think of webassembly as a platform independent instruction set with its own specialized encoding and calling conventions. There's nothing saying you can't describe a subset of javascript that'd be very easy to transpile to work in webassembly's world of those things, but enforcing that would probably be difficult. The featureset and implementation surface area are forever growing in javascript, and adapting existing libraries and frameworks to work in that subset would likely be difficult, especially given the current lack of garbage collection in webassembly, and you'd essentially lose the benefits of existing javascript code.

With the addition of garbage collection primitives in webassembly, the subset of javascript that would be feasible to transpile without writing a big ol' virtual machine would widen, but it still in my opinion wouldn't be optimal compared to just transpiling from a more suitable language, since your overheads in javascript would only be marginally smaller, the important overheads in web applications (the network!) would widen, and the benefits you'd want to reap from using javascript in the first place would still be out of reach, besides getting to say that it uses something that resembles "javascript" (this is actually a similar boat that Unity is in with UnityScript, except they adapted it somewhat to integrate better with their subsystems and calling conventions in general, besides other whims).

@metacritical

This comment has been minimized.

metacritical commented Jan 28, 2017

I think it is extremely important for some of us who are looking at Browser and Webgl to be faster for gaming. I intent to bring a commercial quality game in webgl but the current tech produces so much garbage that frames skip.
Browser gaming using JS game engines has almost failed and Unity took off. I think C++ => Wasm is an undue advantage for these big Unity like framework makers who could cross compile their code to WASM.
But what about people who write JS by hand using Three JS or Babylon.. Not having a JS/Asm.js => Wasm toolchain would mean large application in Js would be dead and people would use C++ and code generation backends to produce Wasm. More specifically in games and such.
Not having a JS => Wasm backend in unfair to JS Developers. Also EMCC allocates a Big heap when it runs and speeds are evident due to that, but Js Developers who write good js Code still couldnt achieve so much performance due to the complexity of writing such code. There should be some mechanism to reuse most stuff and ability to call gc earlier or at will. Frame skipping when the GC runs causes Webgl to skip frames is a big problem and needs to be resolved. There should be some mechanism to hand tune JS code better than Code generators. like hand written Assembly still produces much smaller and highly aligned code. That should be possible in web-assembly.

@RyanLamansky

This comment has been minimized.

RyanLamansky commented Jan 28, 2017

@metacritical C++ can compile to WASM because many people put a lot of work into the process. The same could happen for JavaScript, but as far as I know, no one is attempting this currently. There is little reason to do so: performance will be unchanged.

Your engine's problem is garbage collection. This problem doesn't go away if you build a garbage collection algorithm that uses linear memory and WASM code... eventually you have to stop the program to see which objects are still alive and delete the ones that are not. The solution is to not create garbage objects, preventing the need for the GC to ever run. You don't need WASM to achieve this, you need to rework your engine.

@metacritical

This comment has been minimized.

metacritical commented Jan 28, 2017

Ultra pristine Javascript that reuse Arrays and produce low garbage are extremely hard to write. Also i think Plain Js cannot be compiled to WASM. Asm.js or Typescript would be easier to compile to WASM due to availability of type annotations or types in them respectively.

@RyanLamansky

This comment has been minimized.

RyanLamansky commented Jan 28, 2017

@metacritical Difficult, but not impossible. Even in the C++ engines, much of the code is around object lifetime management. Although unconventional, there's no reason you can't do the same in JavaScript.

Plain JS could be compiled to WASM but the compiler would have to add a lot of helper code to enable JavaScript's higher-level features like garbage collection, reflection, properties, and so on. Basically, all the stuff you get for free with the browser's built-in JS engine. TypeScript doesn't help much.

By comparison, ASM.JS would be easy to convert to WASM. The strict subset of JS features allowed by ASM.JS is also 100% covered by WASM. If there were a large volume of code written in ASM.JS, this would be a worthwhile effort, but as far as I know all the major ASM.JS files are produced from C++ source code, which can already directly target WASM.

@kripken

This comment has been minimized.

Member

kripken commented Jan 28, 2017

By comparison, ASM.JS would be easy to convert to WASM.

Correct, and actually the main way we compile C++ to wasm today is to compile it to asm.js first, then compile that asm.js to wasm using Binaryen's asm2wasm.

@metacritical

This comment has been minimized.

metacritical commented Jan 29, 2017

@kripken Looking at the asm.js specs it seems easy to write handwritten asm.js, which means all is not lost for js programmers, we can still get WASM binaries using the above.

@aruns07

This comment has been minimized.

aruns07 commented Jan 31, 2017

Wouldn't evolution of JS i.e. strictly typed language, could make it a good candidate for JS -> WASM?
I think TC39 has proposal for typed object. May be more other features could make it possible.

@RyanLamansky

This comment has been minimized.

RyanLamansky commented Jan 31, 2017

@aruns07 The fewer JavaScript features you allow people to use, the easier it would be to compile to WASM, and the more likely people will be unwilling to live with your restrictions due to incompatibility with their favorite libraries.

@metacritical

This comment has been minimized.

metacritical commented Feb 1, 2017

@Kardax @aruns07 People love the convenience of a Dynamic Language. We need strong types occasionally not all the time.

@agnivade

This comment has been minimized.

agnivade commented Apr 28, 2017

Maybe I am not getting something, but one of the ideas of WebAssembly is to directly load the AST to avoid the parse time of js, right ?

So, if we have a tool that compiles js to this ast format and passes that to the browser, won't it benefit from avoiding the time to parse ?

@rossberg

This comment has been minimized.

Member

rossberg commented Apr 28, 2017

@agnivade, it's an AST for a completely different, much more low-level language.

If you were to compile JS to Wasm offline, then yes, you wouldn't need to parse on the client side (just decode). At the same time, because JS is so complicated, code size would drastically increase, probably by a factor of 5 or more, which is a much higher cost. (And that isn't even take into account that you probably would also need to include an entire implementation of a JS VM runtime system in Wasm, which easily is megabytes of code.)

Moreover, without a representation of the sources you cannot implement most of the dynamic optimisations that are crucial for getting JS anywhere near fast. These optimisations rely on recompiling the original source code and specialising it based on profiling information. An already compiled Wasm AST doesn't enable that, you'd need an AST of the original source program.

@agnivade

This comment has been minimized.

agnivade commented Apr 28, 2017

@rossberg-chromium - Thanks a lot. That clears up a lot ! One doubt though -

And that isn't even take into account that you probably would also need to include an entire implementation of a JS VM runtime system in Wasm, which easily is megabytes of code

Why would you need the VM runtime system ? Isn't the browser itself the VM runtime ? I just want the code to be in the AST format so that the browser can readily start executing it. I get that the net size will increase because the language itself is complex, and we cannot implement dynamic optimisations. But why do we need to bundle the VM runtime itself, when we have the browser for that ?

@rossberg

This comment has been minimized.

Member

rossberg commented Apr 28, 2017

@agnivade, without dynamic optimisations JavaScript will be slow, and I mean really slow, like 100x slower, maybe worse.

By "runtime" I don't mean browser stuff like the DOM, but the bare JS language support, i.e., things like garbage collector, object representations, primitives and base libraries, etc. That is pretty huge for JavaScript, and you'd need a reimplementation of all of it inside Wasm.

And of course, you'd also need an interface layer to the DOM.

@agnivade

This comment has been minimized.

agnivade commented Apr 28, 2017

Ok I think I understand things a bit better now. I thought that the

garbage collector, object representations, primitives and base libraries, etc.

can be used from the browser itself. And I can just let the browser load the AST and do its usual job. But now I realize that everything needs to be packaged inside WASM itself.

@distransient

This comment has been minimized.

Contributor

distransient commented May 3, 2017

A universal-ish scripting language bytecode would be interesting though! A compile target designed around efficiently transporting and executing programs written in dynamically typed, garbage collected languages, with all the bizarre edge cases of the popular ones (javascript, ruby, python, lua) covered in (some cases) special opcodes and structures etc

@rossberg

This comment has been minimized.

Member

rossberg commented May 4, 2017

@distransient, so you want the combinatorial insanity of all the scripting languages? I'm optimistic that it would be possible for humanity to gather the engineering resources to specify and implement that efficiently by 2050. :)

@nidin

This comment has been minimized.

Contributor

nidin commented May 4, 2017

Those who interested in compiling TypeScript to WebAssembly using LLVM. check out this reach project. https://github.com/MichaReiser/speedy.js
Looks like this discussion is never ending...

@distransient

This comment has been minimized.

Contributor

distransient commented May 4, 2017

@rossberg-chromium I said it would be "interesting", not easy or pretty 😉

@carlsmith

This comment has been minimized.

carlsmith commented May 25, 2017

A universal-ish scripting language bytecode would be interesting...

While WASM is incrementally evolving to eventually support stuff like Python, we could have first-class support for developing scripting languages for the Web much sooner than WASM can provide it, if we approached the problem from the opposite end at the same time.

It should be relatively simple for JavaScript engines to expose their ability to execute JavaScript ASTs, and the ASTs they accepted could be standardised (even if they're immediately converted to a non-standard, intermediate format internally).

We could simply combine an AST format (like estree) and a serialisation format (like JSON) to create a new file format with a new extension. If browsers supported the format in script tags and so on, then languages like TypeScript and CoffeeScript would just compile to parse trees, and the browser would take it from there. Transpiled languages wouldn't need to do code generation, and source maps would no longer be needed either, as the lexical information would be based on the actual source.

Once the basic support was established, the standard could incrementally evolve to meet WASM in the middle, by basically just adding new node types. There are simple things to start with, like explicit add and concat nodes, or maybe adding new data types, like DEC64.

As WASM builds up to supporting scripting languages, by adding things like GC, AST execution would move downwards, extending JavaScript semantics to include features from other high level languages, so a broader set of scripting languages could compile to a kind of abstract JavaScript.

@rossberg

This comment has been minimized.

Member

rossberg commented May 29, 2017

@carlsmith

This comment has been minimized.

carlsmith commented May 29, 2017

Relative to WASM, it's simple.

@ivanherczeg

This comment has been minimized.

ivanherczeg commented Jul 11, 2017

@bguiz For example:

  • You cannot translate JS natively into ASM, because it has different architecture.
  • You cannot manipulate DOM from ASM, because you don't have access to it's resources at CPU ground level.

Google V8 engine already compiles the JavaScript directly to native machine code, by compiling the whole runtime task, before executing it.

So it would be totally unnecessary to have a alternative WASM pipeline from client side.

In the other hand, WASM was presented with a Mandelbrot demo, then it features Unity "Tanks" demo in the first place, but i doubt very much that drawing pixels with ASM->CPU (even with SSE double precision) could ever be faster than WebGL->GPU, because as this community says the GPU is not in the scope. So what?

@SephReed

This comment has been minimized.

SephReed commented Aug 5, 2017

@ivanherczeg Woah! Where does this community say GPU is not in spec?

@ivanherczeg

This comment has been minimized.

ivanherczeg commented Aug 5, 2017

@SephReed

We already have tensions due to bikeshed differences between arm and x86. I think that adding another set of hardware targets would create more tension: more operations would either have to be slow due to emulation costs to get uniform semantics on all targets, or more operations would have to have undefined behavior to allow everyone to run fast. I think that makes it unprofitable to consider the GPU at this time (or ever).

-Fil

#273 (comment)

@nirus

This comment has been minimized.

nirus commented Aug 17, 2017

C# runtime was ported to wasm and was fully functional prototype replacing JS completely. So this means in future you can expect runtimes emerging out to replace JS on browsers and write client side web apps in Java, C# or even C++ with a statement's saying "Code will run faster near native", "Compiled code are faster than VM" or anything without the aid of JavaScript.

Please watch this video of what i am trying to say.

WebASM was introduced to supplement JS not to take over completely , replacing the First class language.

Near future you can expect webpages delivered from server compiled natively

@Steakeye

This comment has been minimized.

Steakeye commented Dec 15, 2017

@BossLevel

This comment has been minimized.

BossLevel commented Dec 16, 2017

@Steakeye Very nice :) I shall have a play - many thanks for highlighting :)

@2beers

This comment has been minimized.

2beers commented Jan 17, 2018

you can compile JS to WebAssembly using NectarJS . Demo: http://nectar-lang.com/ choose from the dropdown WebAssembly

@kripken

This comment has been minimized.

Member

kripken commented Jan 17, 2018

Interesting, the NectarJS demo uses emscripten, you can see that in the asm.js output. It appears it statically compiles JS into something - likely C or LLVM IR - and then runs that through emscripten.

The wasm output also uses emscripten (can be seen from inspecting the binary), but it seems to use an old version as it emits 0xd wasm binaries, which don't run in modern VMs. It also just sends you the wasm, not the JS, so it's not runnable anyhow. In any case, it's very possible it's just doing the same as for asm.js, just running emscripten with the flag for wasm output flipped on.

The demo has a 300 byte limit on the input, so it's hard to feed it a real-world program to get a feel for how powerful their analysis is, which is the real question with a static approach like this. In general, academic research on this topic suggests skepticism.

@Simran-B

This comment has been minimized.

Simran-B commented Jan 17, 2018

Their compiled demos for Windows simply crash for me 🤕

@alexp-sssup

This comment has been minimized.

alexp-sssup commented Jan 18, 2018

I agree with @kripken skepticism here. I believe arbitrary JS cannot be reasonably converted to WebAssembly. Any tool that claims to achieve this is probably working on some tractable subset of the JS language, or giving up execution performance.

JS is an extremely dynamic language. Unpredictable run-time operations can significantly and globally change the semantics of code. This means that an Ahead-Of-Time (or offline) compiler can only assume the worse and generate very inefficient generic code that can handle all the possible cases. For an example take the following JS code:

var a = {prop1: 1};
func(a);

could be converted (in pseudo-wasm) to this

i32.const 42
call $CreateJSValFromStrTable ;; Returns prop1
i32.const 1
call $CreateJSValFromInt
call $CreateJSObj1 ;; Consume a JS string and a JS value to make an object
call $_func

Now, this is a far call from what we can reasonably consider "compile" and it is more similar to unrolling an interpreter. It is of course also possible to run a JS interpreter compiled to Wasm, but that would hardly be a performance win.

JS engines such as V8 and Spidermonkey can run JS code as fast as they do by compiling it Just-In-Time. By doing JIT compilation they can observe what is the real intended semantics for a given piece of JS and generate fast code for that specific case, while of course being careful to detect any change in the environment that could invalidate the current assumptions.

@Simran-B

This comment has been minimized.

Simran-B commented Jan 18, 2018

Agreed. I wouldn't mind to use a JavaScript subset however. Or maybe a typed variant, which would probably reduce the dynamism and allow for more efficient code to be generated.

Are there any news on the "strong mode" front BTW?

@rossberg

This comment has been minimized.

Member

rossberg commented Jan 18, 2018

@Simran-B, we have long abandoned strong mode, for the reasons summarised here. The takeaway is that it is pretty much impossible to tighten JavaScript semantics without losing interop with existing code.

For the same reason I also don't have much hope for the idea of designing a "statically compilable" dialect of JavaScript or TypeScript -- it would be a different language that can't run existing code, so not much point.

@kripken

This comment has been minimized.

Member

kripken commented Jan 18, 2018

@Simran-B : "I wouldn't mind to use a JavaScript subset however. Or maybe a typed variant"

There is some very interesting work in that space, like AssemblyScript which is a strict subset of TypeScript that compiles to WebAssembly, https://github.com/AssemblyScript/assemblyscript

@rossberg : "I also don't have much hope for the idea of designing a "statically compilable" dialect of JavaScript or TypeScript -- it would be a different language that can't run existing code, so not much point."

I think the big potential with things like AssemblyScript is not about running existing code (I agree with you there, that won't be feasible in general), but that having a friendly and familiar language is a huge deal.

Right now if you are a TypeScript developer and you want to write WebAssembly then you need to use C++ or Rust. Both are good languages but also have downsides. For someone with that background, something like AssemblyScript could be the fastest path to productivity.

@SephReed

This comment has been minimized.

SephReed commented Jan 21, 2018

If AssemblyScript can compile to both JavaScript and Assembly, that would be pretty ideal. Looking forward to these updates.

Also, in the future, unless someone does it first, I'll probably try writing a TypeScript -> Assembly Script converter that goes through the files, asks the questions it needs to ask, and then makes the conversion. Hopefully it works out!

@Pauan

This comment has been minimized.

Pauan commented Jan 22, 2018

@SephReed Yes it can compile to JavaScript, because there is a WebAssembly -> asm.js compiler, which should work with all WebAssembly code.

See also the "Can WebAssembly be polyfilled?" section of the FAQ.

If you instead meant "is it possible for AssemblyScript to compile to idiomatic JavaScript code?", then I have to ask, why would you want to do that when WebAssembly / asm.js are so much faster than idiomatic JavaScript code?

Though I suppose you should be able to run the AssemblyScript code through the TypeScript compiler. However you will need to keep certain things in mind.

See also this section of the AssemblyScript documentation.

@qm3ster

This comment has been minimized.

qm3ster commented Mar 1, 2018

Gentlemen, please consider WALT, the JavaScript-like WebAssembly language.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment