As we know, JavaScript is primarily a web language. For over a decade Sphere has somehow been able to bend JS to the whims and wills of those developers who choose Sphere as their game engine of choose. Web languages, however, have "advanced" while Sphere remains firmly entrenched in using strictly JS; CSS has Less and SASS to add programmatic capabilities to it, while JavaScript has, among others, CoffeeScript and Dart perform in similar fashions. Both the CSS solutions and the JS solutions aren't interpreted directly by the browser but are instead "transcompiled" (Wikipedia's word) to their original respective languages which CAN be interpreted directly.

All four of the listed language "supersets" have standalone compilers or shim scripts to allow direct embeds into web pages, but of interest to us right now is the JS set. So I pose the question:

If a person wants to write their Sphere-compatible script in a language like CoffeeScript or Dart, should we build in pre-compilation/interpretation/"transcompilation" to JS into Sphere (either the editor, engine, or both) or force those scripts to be converted to JS before inclusion in their projects?

Such functionality also opens the door to discussion of Sphere-compatible engines using non-JavaScript-based languages like Python, Ruby, or Lua for scripting, so I'll open another thread on that. This thread is for discussion of "transcompilation" to JavaScript.

A year and a half later, I find this topic. I think the idea has merit, although I'm not sure it should be built into the engine.  I think something like this is best left to an editor, just as how the OS doesn't compile code for you, you need to use a compiler on it yourself, often through an IDE.

You may note that TurboSphere includes a demo of using a game that uses CoffeeScript.

Is the CS handled by the engine, or is a compiler script included?  Just curious.

I just run the compiler script. The CS code is included as a separate file, though.

Well, looks like we can cross another thing off the list of "stuff to implement to modernize Sphere"

That's actually a pretty good way to implement it, only allowing Coffee loading if you have the CoffeeScript transpiler in the system scripts folder; though it seems you ended up building it into the engine directly right after.

I like the first approach, as this allows extensibility of X-to-JS support ("simply drop the transpiler into the system scripts folder") and allows for the transpiler to be updated independently of the engine.

It's not built in per se, the engine evaluates coffee-script.js on startup automatically (if it exists) and then when you RequireScript a .coffee file it calls CoffeeScript.compile() on the source, passing the output on to Duktape.  If you try to run a .coffee file without the compiler in the system folder, it will throw an error.

Basically the engine serves as a go-between but doesn't actually do anything with CS itself, it defers to the compiler.

As I did not understand minisphere's coffeescript support in this thread, here is a small how-to:

1. Get coffeescript from http://coffeescript.org/ (either github or the tarball link)
2. Find ./extras/coffee-script.js in the source. It is 156Kb (NOT the one in ./lib/)
3. copy this file to minisphere/bin/system/  (thus, NOT in the minisphere/bin/system/scripts/ )
4. open a game.js file, and just EvaluateScript("myfile.coffee")

Wait... did I forget to include coffee-script.js in the distribution?  It should have been there already...

Starting in minisphere 3.0, the engine will support on-demand transpilation of TypeScript in addition to CoffeeScript.  I just added support for it today.

Starting in minisphere 3.0, the engine will support on-demand transpilation of TypeScript in addition to CoffeeScript.  I just added support for it today.

TypeScript is nice, good job!

Yeah, the one downside--this will be mentioned in the release notes too--is that it uses `ts.transpile()` under the hood to convert the TypeScript code to JS, but while this allows all TypeScript syntax to be used like lambda arrows, etc. (great for Link!), you lose arguably TypeScript's best feature, compile-time type checking. (this is by design, apparently).

To get the type checking, I would have had to implement a CompilerHost and use `ts.createProgram()`--but the TS program model is so thoroughly at odds with Sphere's architecture that it wasn't worth it.  Any Sphere game using TypeScript would be forced to commit to TS completely instead of being able to mix and match with JS and CoffeeScript like you can now.