Think about dialects for js like typescript, flow.

[acrazing]

Both typescript and flow write code as static language, and then compile source to dynamic language, and execute it in browser.

Why not compile it to binary code? If so, the performance will be improved greatly!

We can update ecma 262 to es2015/es2016, and invent typescript, flow, and so on. Why not update browser to run binary code?

[kitsonk]

That is just about contrary to every TypeScript design goal. That is some other project, not TypeScript.

[RyanCavanaugh]

See also why we don't do asm.js compilation (#375).

If someone wants to go write that themselves, they're free to, but it would be an enormous undertaking that is far outside what our team can do.

[acrazing]

@jslegers May be you can try kotlin, it will be compiled to java code in the future.

[jslegers]

Personally, I don't see much of a benefit of using TypeScript or Flow instead of JavaScript. Especially now that the ES6 standard also added class-based object-oriented programming to the language, all you'd really get from adopting TypeScript or Flow today would be the addition of static typing... and interfaces. Besides making your code look more like eg. Java code, I really don't see the benefit at all... except when using static typing to optimize the JavaScript code it produces... which is where asm.js comes in.

In environments where high performance is essential (eg. 3D rendering in the browser for browser games or GIS web apps), the current approach is to write the core code (that does the heavy lifting) in C/C++ (compiled to asm.js) and everything else in JavaScript. That means you need a really good understanding of both JavaScript (which I do) and C/C++ (which I don't) to be able to write proper code or maintain existing code for such apps, both inside and outside of the the core code.

How great would it be to be able to use one - TypeScript - codebase for such projects and compile to asm where possible and to regular JavaScript where not possible? Or to put it differently : how great would it be for a JavaScript programmer to be able to program in highly readable superset of JavaScript and have it compiled - where possible - to a highly optimized subset of JavaScript?

It seems like a win-win for everyone, really, especially if you leave it optional whether or not to compile to asm.js for developers who don't work in high performance environments and prefer readability to performance.

IMO, compilation of (a subset of) TypeScript to asm.js would be major improvement over TypeScript as it exists today. For me, it would totally be a game changer and make the difference between supporting and not supporting the adoptation of TypeScript - or Flow for that matter - at the company I work for...

[kitsonk]

@jslegers you are clearly looking for something other than TypeScript.

[jslegers]

@kitsonk :

I guess the tool I'm looking for hasn't been invented yet 😛

Anyway, I really don't get why ANYONE would want to use TypeScript if the static typing comes without the performance benefits I would expect to get from static typing (and that I would get if I write my code in C/C++ and compile it to asm.js instead). If seems to me to be a totally unnecessary abstraction layer that has literally zero benefits in comparison to ordinary JavaScript. But maybe that's just me...

[jslegers]

While I understand that TypeScript is not intented to be compiled to asm.js, C/C++ or WebAssembly (and I expect that), the ability to export a language like Flow or TypeScript to typed AST in some way or another would be a good first start. With the TypeScript core devs not interested in this feature, it would at least open up the possibility for other teams to implement TypeScript to WebAssembly, TypeScript to C/C++ or TypeScript to asm.js conversion wherever possible.

[acrazing]

@jslegers I think it should be a good solution: the v8 engine compiles JavaScript code to dynamic assembly code, and then execute it, why not we compile it to assembly before send it to browser?

[jslegers]

Either way, if the TypeScript devs aren't interested in compiling to asm.js, C/C++, WebAssembly or whatever else someone may want to convert their TypeScript to, allowing the export of the typed AST seems like a minimal effort that would allow other developers with enough time and/or budget on their hands to do the hard work of implementing such a conversion.

The short term benefit would obviously be small, but the large term benefit would be quite significant, as it would basically provide a pluggable interface that allows - subsets of - TypeScript to be converted to any language that is sufficiently compatible. And I'm sure there are many clever folks out there who can come up with far more use cases than the ones I've mentioned...

[kitsonk]

TypeScript to be converted to any language that is sufficiently compatible. And I'm sure there are many clever folks out there who can come up with far more use cases than the ones I've mentioned...

I think even the TypeScript team that TypeScript wouldn't be the language to start it with. Its objectives are to make JavaScript as sane as possible. There are some really challenging things with the way JavaScript is constructed that make both Flow and TypeScript do horrible type abuses. Both are designed to make JavaScript more maintainable and better to manage.

Lots of people misunderstand the objectives of asm.js and WebAssembly. None of those technologies are really designed to be a replacement for JavaScript in the browser. There are there essentially as an escape hatch when the browser vendors haven't had the time to incorporate low level APIs into their browsers. There are huge amounts of optimisations that ChakraCore, V8, SpiderMonkey and Nitro perform, all in slightly different ways, someone trying to take JavaScript/TypeScript to what is still an intermediary syntax of assembly, before bypassing these engines is on a fools errand, but if it is an errand one wants to embark on, this is clearly not the forum for discussing it.

[jslegers]

There are some really challenging things with the way JavaScript is constructed that make both Flow and TypeScript do horrible type abuses. Both are designed to make JavaScript more maintainable and better to manage.

Recently, I joined the R&D department of a company to work on a product that has two codebases :

• A C/C++ OpenGL 3D engine, ported to asm.js
• A JavaScript codebase built on top of that engine

That means two codebases, written in two different languages, for one product. For projects like these, it would make sense to move to a language like TypeScript, and convert that code to asm.js where possible. It would allow JS developers to add to the existing C/C++ engine without having to learn C/C++ and it would allow C/C++ developers to use static typing in their JavaScript - which Java programmers and C/C++ programmers understandably tend to prefer to the dynamic typing used in "normal" JavaScript. You would get the best of both worlds, alleviate frustrations on both side and be able to move towards a more unified codebase.

Lots of people misunderstand the objectives of asm.js and WebAssembly. None of those technologies are really designed to be a replacement for JavaScript in the browser.

They are not designed to replace ALL of your JavaScript code, no. However, they are designed to supplement your ordinary slow JavaScript with specialized high performance JavaScript. They are designed as a way to efficiently process expensive operations in your browser in a language already supported by every browser.

someone trying to take JavaScript/TypeScript to what is still an intermediary syntax of assembly, before bypassing these engines is on a fools errand

I don't see what would make conversion of a subset of TypeScript to asm.js that different from eg. converting from TypeScript to JavaScript, EcmaScript2015 to EcmaScript5 (which Babel does), SCSS to CSS (what Sass does) or other conversions that convert / preprocess / transpile one language to a subset of that language. As long as the implementation of the first is something that can be expressed in the second (eg. you can't use Babel to transpile Proxies, because there's no way to represent Proxies in EcmaScript5), such a conversion is feasible.

if it is an errand one wants to embark on, this is clearly not the forum for discussing it.

Fair enough...

[jslegers]

Those also interested in converting staticly typed variations of JavaScript to asm.js, WebAssembly or C might want to take a look at ThinScript, TurboScript or AssemblyScript.

ThinScript compiles to JavaScript, WebAssembly, and C. TurboScript compiles only to JavaScript and WebAssembly. AssemblyScript compiles to WebAssembly only.

Each of these languages have been inspired by TypeScript, and the latter is a subset of TypeScript.

I'd like to thank @RReverser for pointing me in the direction of these languages.