March 12, 2016, 11:36:17 am

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.

miniSphere 5.1.3 - Cell compiler - SSj debugger - thread | on GitHubFor the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

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.

miniSphere 5.1.3 - Cell compiler - SSj debugger - thread | on GitHubFor the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

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.

miniSphere 5.1.3 - Cell compiler - SSj debugger - thread | on GitHubFor the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

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.

If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

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.

miniSphere 5.1.3 - Cell compiler - SSj debugger - thread | on GitHubFor the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

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 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.

miniSphere 5.1.3 - Cell compiler - SSj debugger - thread | on GitHubFor the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan