minisphere 3.0 includes basic, provisional support for TypeScript.  In order to maintain full compatibility with Sphere 1.x semantics, the ts.transpile() method is used to convert .ts scripts into JavaScript before evaluating them.  This allows all of TypeScript's syntax features to be used such as lambdas x => x * 812 and classes, however it loses features that require the full TypeScript program model such as compile-time type checking and module support.

Since TypeScript is a proper superset of JavaScript, it strikes me that, for Sphere 2.0, we could standardize on TypeScript instead of plain JavaScript.  minisphere 4.0 would be a good place to start experimenting with this.

If this were implemented, legacy constructs such as RequireScript()--which for compatibility reasons can never be made SphereFS compliant--could be deprecated in favor of TS's much cleaner imports system.  This would bring us closer to the original vision of Pegasus without the hackiness of extensions like CommonJS.

Wouldn't implementing ES6 JS instead cover most of the use cases TypeScript was created to achieve? Ignoring differences in underlying implementation for a second, I would be ok as long as the ES5 JS we currently (mostly?) support remains intact.

One thing TypeScript has even over ES6 is compiler-enforced strong typing.  Of course, being a strict superset, it's optional--so you can still have duck typing if you want.  But having strong typing might be useful when developing a large-scale game.

Besides the fact that it doesn't seem like Duktape is going to get proper ES6 support any time soon, implementing TypeScript now would be much quicker.  I don't intend to port minisphere to SpiderMonkey or V8, so this seems the most feasible option right now.

Besides the fact that it doesn't seem like Duktape is going to get proper ES6 support any time soon, implementing TypeScript now would be much quicker.  I don't intend to port minisphere to SpiderMonkey or V8, so this seems the most feasible option right now.

Would this mean that implementing TypeScript may result in having two script engines? I'm fine with this, I just want to make sure we're on the same page.

TypeScript is like CoffeeScript, it gets transpiled into JS using a compiler script, so it would still ultimately be Duktape (in the case of minisphere) running the code.  But here's the beauty of it: It's a proper superset, and all valid JavaScript code is valid TypeScript code.  Theoretically the engine could just run everything through the TS transpiler and still be backwards compatible.  So there's very little extra cost to maintain such a system.

That's why I'm so willing to experiment with this.  Fragmentation is the last thing Sphere needs, we've seen where that's gotten us before.  But something like this, that can be phased in smoothly (minisphere 3.0 could be considered Phase 1), might be worth pursuing.

And it gives the engine a better angle than just saying JavaScript, because there has been several JS-based game engines since Sphere and nearly all of them are better than it. And these engines are accepting typescript too (naturally). So this is really nice to have to remain toe-to-toe.

I have an idea.

Why build in TypeScript, if we can just make use of the transpilers already out there? I mostly use a grunt workspace setup that transpiles every time I change a TS file. It compiles it to ES5. That would solve everything?

Only thing we need it a set of typings for Pegasus. As Pegasus is just specs anyway, we could make it TS-ish to add nice typings for the implementor.

Mostly because Sphere's biggest strength, like Node.js, is that there's no need for a build step.  If the engine can run TS code "directly" (by running the transpiler internally) that avoids the need for fancy IDEs and development can be done entirely from the command line.

But then, as you noted, the use of TS is: none. If you just natively support ES6 you get the same result, but without naming the files .ts and having the hassle of transpiling. TS = ES6 + type safety and you say ts.transpile() does not support type safety.

I am all in favor of ES6.

I am too, but Duktape doesn't support it and likely won't for some time (the Duktape developer needs to rewrite the compiler from the ground up to support it).  And switching out Duktape for a different JS engine is probably prohibitively difficult at this point without some major refactoring.

In that case, how about a live transpile from ES6 to ES5? It seems Duktape has _some_ ES6 functionality..