7

Since Typescript is just a superset of javascript (every javascript program is also a typescript program), I've got this idea - why doesn't v8 support typescript? or anything statically typed compatible with JS? This way it could do some real big performance hacks and suit a much wider range of programmers who require static typing... For me it sounds like a very good idea. Why hasn't anyone done this yet? (so the Q is: are there some visible downsides of this solution? I don't see anything but I'm sure there may be something...)

5
  • 2
    For the record, V8 is open source. If this would be useful to you, then off you go. Let people know when you're done. – riwalk Mar 6 '15 at 19:35
  • I believe some major TypeScript features (like classes) have been proposed for the ECMAScript 6 standard, so it's possible the answer to your question is "soon it will." But I'm not entirely sure about that so leaving this as a comment. – Ixrec Mar 6 '15 at 19:35
  • Typescript code is compiled to JavaScript code... which is then run by the client side JavaScript engine. – GrandmasterB Mar 6 '15 at 19:38
  • 3
    @GrandmasterB: yeah I know. My point was - why to compile typescript to javascript and lose all the valuable information about types and then just replace it with some stupid if statements, if you could use all that information directly in v8 compiler and gain some performance... – Tomy Mar 6 '15 at 22:54
  • Check AssemblyScript: assemblyscript.org – Amin Jan 22 at 13:31
17

For starters, v8 predates (public knowledge of) TypeScript by several years, TypeScript isn't from Google, TypeScript is far from an industry standard, and Google has its own language trying to fill a similar niche (Dart). And then there's the problem that nobody deploys TypeScript to websites, it's designed to be compiled to JavaScript and that's what everyone does. But let's assume none of this matters.

I don't believe that there are any performance gains to be had. Precisely because it is interoperable with JavaScript, TypeScript's type system provides virtually no hard guarantees. Sure, it allows workable autocomplete in most circumstances, but it does not guarantee that the types are all 100% correct. With type assertions (<Type> something), you can smuggle type errors past the type checker, and it's not even a runtime error. TypeScript code can and does call into JavaScript code, which might break any guarantees in arbitrary ways. So V8 can't rely on anything the TypeScript types assert.

JIT compilers can already figure out all information they need for optimization with runtime instrumentation. TypeScript can't statically eliminate the need for those checks, so it provides no extra value.

Maybe the types could give the baseline compiler an initial guess for speculative optimizations (which would be overridden by runtime profiling data in later stages), but:

  1. That there is a benefit at all is complete speculation at this stage.
  2. Type checking and inference takes time, and time is precious for baseline execution. Browsers want to start executing scripts as soon as possible.
  3. It would have to be worth the extra complexity and implementation effort.
  4. see the first paragraph.
2
  • 3
    The benefits of static typing for performance are vastly overestimated. OpenJDK/HotSpot is essentially a slightly modified Smalltalk VM that doesn't even use the static type information of the JVM bytecode language for any interesting optimizations. Stuff like Escape Detection, Speculative Inlining, Adaptive Optimizations, De-Optimization etc. are independent of the typing discipline, and stuff like Polymorphic Inline Caching need to know the dynamic runtime type instead of the static type anyway. V8 was created by the same people who created HotSpot and started out from the same codebase. – Jörg W Mittag Mar 7 '15 at 4:47
  • 2
    The V8 team is/was researching it: developers.google.com/v8/experiments#introduction – kwcto May 6 '16 at 3:06

Not the answer you're looking for? Browse other questions tagged or ask your own question.