TypeScript to haxe converter : a first step for TS => native Android/iOS

[Ezelia]

TypeScript is an awesome programming language but it only compiles to JS.

haxe is cross-platforms and good language too but lacks some syntax/features I like in TypeScript ....(I started using haxe/NME some days ago)

 

I want to be able to compile my typescript code to native Android/iOS/other platforms but it's presently not possible so here is a part of the solution :

 

ts2haxe is a script I made to help me automatically convert TypeScript code to Haxe code, it will not convert APIs only syntax conversion is supported for now.

 

next step will be to write a common rendering API, based on PIXI.js in TypeScript side and NME in haxe side so all code can be converted and compiled with minimum manual fixes.

 

 

here is the source code https://github.com/Ezelia/ts2haxe

 

feel free to share/report issues/contribute

 

 

[rich]

I always thought haXe converted to JS easily?

[PixelPicoSean]

Is PIXI's api similar to flash? I used to use haxeflixel for some small projects but never used NME directly.

 

Haxe is now fully supported by sublime text, how I wish there's a fast lightweight typescript editor for OSX.

[PixelPicoSean]

I always thought haXe converted to JS easily?

Haxe can be directly compiled to js and includes its own library. Now I do not want to turn back to use haxe any more since it forces everything static typed, while typescript gives me power of embeding pure js code.

[Ezelia]

I always thought haXe converted to JS easily?

 

I gave it a test and the html5 performance was horrible compared to pixi, but it does a good job for native Android or flash (didn't tested for iOS).

I want to be able to create html5 games with pixi rendered (or a custom rendered) while being able to convert the code easily to native mobile app (not html5 wrapping).

 

 

EDIT :

I also don't want to write code with haxe I prefer TypeScript

[YellowAfterlife]

Now I do not want to turn back to use haxe any more since it forces everything static typed, while typescript gives me power of embeding pure js code.

Just to note, you can use Haxe' Dynamic for when type is not clearly determined, or __js__ magic if you are that desperate to write some JS-specific code.

[jeremyfa]

Hi Ezelia,

 

Just letting you know that I have been working on a similar tool recently: https://github.com/jeremyfa/node-ts2hx

 

I thought you might be interested in it!

[Ezelia]

Hi Jeremy !
sure your project seems very interesting.

 

my implementation was more a "hack" than a real transpiler, as I didn't had time to write a real transpiler.

the goal was to make a proof of concept for compilling TypeScript code with Pixi.js API to native iOS/Android from VisualStudio

here is a demo video :

 

 

it'll be awesome if we can build true native iOS/Android packages with a click

from what I can see, your implementation of ts2hx is quite advanced, there is possibility to make interesing things !
I'll try to integrate it to VS, and maybe build an extension around it when I have some time.

really interesting project.





 

[jeremyfa]

I actually saved some time by using the AST computed from the official typescript compiler (well, I had to tweak a bit in it and make it available as a node module: ts2json). Then, ts2hx is mostly walking through the AST to output Haxe code.

 

From you video, I can see that your setup is similar to what I am doing on Webstorm (on Mac). I can run Flash or iOS in one click as I have integrated custom scripts that run ts2hx and then let openfl do the rest of the work. Maybe my approach about a common API is a bit different as I am not trying to port pixi.js to haxe. Instead, I am writing a bunch of core classes: Sprite, Layer, Sound etc... that are using pixi.js/soundJS in HTML5 and openFL API in haxe. Then I can keep the rest of the project completely cross platform.

 

A Visual Studio integration sounds nice !

[Ezelia]

I didn't ported Pixi.js too

what I did are some wrapper classes that convert Pixi.js objects to OpenFL objects, I think our approach is the same.

OpenFL do a very good job on native platforms so there's no need to recreate the wheel, but it still have some performance issues in HTML5 compared to Pixi.

 

the complex part in this approach is to wrap all Pixi.js API, and implement the lacking features, as Pixi have added some cool features which does not exist in OpenFL.

 

I'll take a closed look to your source code when I have some time, especially in the glue (Pixi-to-OpenFL) part, and maybe contribute with some code

 

 

Edit : just saw that the source code only contain the ts2hx part, I suppose the Pixi to OpenFL wrapper is attached to your game project.

a good idea IMO would be to create a separate repository for a Pixi/OpenFL wrapper

[totor]

openfl html5 backend is supposed to be pixijs according to http://www.openfl.org/blog/2014/03/18/flash-and-html5/

[Ezelia]

This is an old anoucement, Pixi support was deprecated (see https://github.com/openfl/openfl-pixi )

 

OpenFL have its own HTML5 implementation, and I think that WebGL support is still limitted. the Canvas2D is good but not as performant as Pixi.js

[jeremyfa]

From what I understood, your approach is still a little different than mine in the way that you still try to be able to have a "PIXI.Sprite" or a "PIXI.DisplayObjectContainer" etc... backed with openFL, while I am more into creating my own custom Sprite class that will use under the hood, but not exposed pixi.js in the typescript implementation and openFL in haxe implementation.

 

That means I would have two different implementations of my custom "Sprite" class (which is not "PIXI.Sprite"). One to run my typescript project as a regular HTML5 app, and one when using haxe. This also means that I don't have to implement with openFL the features of PIXI.Sprite that I don't use, because I am having my custom Sprite class (which is still very similar to a PIXI.Sprite class but doesn't have to do everything that PIXI.Sprite does).

 

In the same way, if I make sounds in HTML5 with SoundJS, I would not try to create a SoundJS wrapper class in haxe that uses openFL. Instead, I would create my custom "Sound" class that has 2 implementations : one written in typescript that uses SoundJS, and one in haxe that uses openfl.media.Sound. This gives me again complete control about what (and how) I want to implement. The downside of this method is that I cannot have a portable typescript project that would directly use pixi.js API or SoundJS API. I would have to use only my custom classes "Sprite" and "Sound".

 

For now, I don't have any mature "glue-class" code to share as I am still experimenting theses methods in one of my projects, but it is possible that I release some generic and reusable classes in a separate project if it goes well.

 

I also don't plan to use the openFL's HTML5 target because the typescript project is already able to output very clean HTML5 and giving me complete control on the libraries I use. My focus is more on using openFL to run smoothly on iOS and Android devices .

[jeremyfa]

Some updates on this topic. While I continued to improve little by little ts2hx, I created another library to convert haxe files to Typescript definition files.

I use it for example to access the flixel framework (http://haxeflixel.com) directly from Typescript, with autocompletion.

 

The source code is on GitHub: https://github.com/jeremyfa/node-hx2dts

 

If some people are interested, I can make a sample Typescript project using flixel or openfl.

[totor]

@jeremyfa, you write typescript then you transpile to haxe and haxeflixel? why not use directly haxe?

how do you then convert to html5, haxeflixel support for html5 was not very good? I would really appreciate if you explain more your workflow or post an example using flixel.

[jeremyfa]

There are several reasons I would still use typescript:

 

- Haxe is a very good language, but lacks of a solid IDE. I am not using Windows (and don't wish to). So possible options to develop with Haxe are Sublime Text or Intellij IDEA. Both plugins are having issues when we push them too much. FlashDevelop is on Windows thus is not an option for me. In contrast, Typescript is supported very well on IntelliJ IDEA and WebStorm, making the coding experience much better than with the Haxe plugin. This means that even if I don't support HTML5 (and only want to code for native mobile for example), I still have a reason to use Typescript.

 

- You are right, flixel HTML5 export is not so good. That said, Typescript makes it easy to use third-party javascript libraries (with definition files) so it is not extremely difficult to port a (transpiled) typescript game written for flixel to, let's say, a phaser game, if needed. A better option would be to have a set of core classes that have alternative implementations for Web (a Sprite class using flixel's sprite, another Sprite class using Phaser.Sprite). This would allow to have complete control on web while being able to target native platform and share most of the game's code. Meanwhile it is possible that flixel's HTML5 target will improve in the future.

 

As far as I am concerned, the first reason is enough for me to use Typescript, even if I don't target HTML5. I always had some annoying issues with my editor when writting Haxe code directly (incorrect indentation, autocompletion that stops working...). However when using Typescript, I had a more pleasant experience. The tools are somehow less buggy in practice. Things work fine and I don't waste time anymore. In that situation, I prefer to write native game with Typescript than with Haxe. Maybe I will change my mind in few years if haxe comes with a great IDE or Plugin that doesn't have such issues. Let's see.

[totor]

damn it! i secretly hope you had found a magic way to make haxeflixel work with html5.

I didn't get you are not targeting html5, makes sense now. Thanks for explaining your workflow. FYI it seems they found a way to make Flashdevelop work on linux and osx.

[jeremyfa]

You're welcome

 

Yes, I tried to use FlashDevelop on Mac with CrossOver, but even if it works, it is far from optimal and not integrated at all with the OS and the other tools I use on Mac...