PIXI.js & Typescript Getting Started

[Jonny Shaw]

Hey all, just wondering if anyone could spare their knowledge on getting started with PIXI.js with Typescript

I've made a couple of simple games now using PIXI.js and love it!  Though really find javascript a pain to use as the games get bigger with all code being in 1 js file.

What I want to start doing is making a library around PIXI.js for common things I will need (e.g. controls, grid layouts, etc) and build it up from there.  Something so simple with UnityC# and even FlashAS3 that I always took for granted!

I understand Typescript maybe the best way to do this, though am a little confused about the difference between all the options (Browserify, Babel, ES6, Typescript etc) what they all actually do what if any of those I will need, and what is the best way forward!

Many thanks for any advice!
 

[ivan.popelyshev]

I love typescript , and I'm even making full-TS conversion of pixi  

I dont like dependencies, so I use global namespaces in typescript, that means no Browserify. That way it stays compatible with some awesome languages like Scala and Kotlin. Using "import/export" for small modules is heresy, and authors of Spine (https://github.com/EsotericSoftware/spine-runtimes/tree/3.6/spine-ts) agree with me on it.

You can get typings here: https://github.com/pixijs/pixi-typescript

Typings for plugins can be found at the same place as a plugins themselves, because most of them are written in TS.

[mattstyles]

Typescript isn't for splitting your code into separate files, its a type checker to try to add types to JS.

ESNext (es6 became es2016, which is now es2017 and es2018, its awkward! es2015 was probably the first one used) is a specification for new syntax and language features. Module spec was defined as part of es2016 but has only very recently been implemented in some browsers, although still might not work as you expect. Other new syntax that is now in browsers and commonly used are stuff like arrow functions, classes, template strings, let, const etc etc

Babel is a transpiler, which converts your code into something else, most commonly it gives you access to new language features and converts that code into something that browsers of today (and yesterday) can understand.

Typescript is also a transpiler as the source code you write can not be understood by any browser so it converts it into something that browsers can understand, along the way it also type checks as best it can from your static code.

Browserify, webpack, rollup etc are module bundlers, which sounds like they are the things you want.

All of these projects have great documentation and lots of getting started help, plus they're all mature projects so there's loads of info out there.

I'd suggest starting with a module bundler. This gets you in to the realm of creating a build pipeline (dont worry, its easier than maybe it sounds, and lots of help out there).

Once you get a bundle going, i.e. turn multiple files in to one (yes, you could just concatenate buts sounds like you want to deep dive this so go straight to module bundling), you might want to look at adding a transpilation step, use Babel to start with.

Once you've got babel transpiling your code and a module bundler (I'd recommend browserify to start as its easiest), you might want to think about tacking on Typescript if types are your thing (also check out Flow, which is an alternative type checker).

Type checking is a bit hard in JS, but don't fall in to the trap that suddenly your code will be safer, it won't be, although it will be better documented.

Good luck!

Ivan beat me to the bullet but has reminded me to clarify: if your goal is to split your project up into different files then you don't need any of these tools, they certainly add a fairly hefty level of complexity, if you're not onboard with the advantages then don't use them.

 

[mattstyles]

4 minutes ago, ivan.popelyshev said:

Using "import/export" for small modules is heresy,

He he, I disagree with Ivan here and go full bore on the small module philosophy, but its cool we can have conflicting views and still produce awesome JS stuff, that sort of thing is a huge part of JS's many successes. 

[ivan.popelyshev]

10 minutes ago, mattstyles said:

Ivan beat me to the bullet but has reminded me to clarify: if your goal is to split your project up into different files then you don't need any of these tools, they certainly add a fairly hefty level of complexity, if you're not onboard with the advantages then don't use them.

 

Agree.

Just take VSCode or WebStorm and it'll give as much advantages.

[Jonny Shaw]

23 minutes ago, mattstyles said:

Typescript isn't for splitting your code into separate files, its a type checker to try to add types to JS.

ESNext (es6 became es2016, which is now es2017 and es2018, its awkward! es2015 was probably the first one used) is a specification for new syntax and language features. Module spec was defined as part of es2016 but has only very recently been implemented in some browsers, although still might not work as you expect. Other new syntax that is now in browsers and commonly used are stuff like arrow functions, classes, template strings, let, const etc etc

Babel is a transpiler, which converts your code into something else, most commonly it gives you access to new language features and converts that code into something that browsers of today (and yesterday) can understand.

Typescript is also a transpiler as the source code you write can not be understood by any browser so it converts it into something that browsers can understand, along the way it also type checks as best it can from your static code.

Browserify, webpack, rollup etc are module bundlers, which sounds like they are the things you want.

All of these projects have great documentation and lots of getting started help, plus they're all mature projects so there's loads of info out there.

I'd suggest starting with a module bundler. This gets you in to the realm of creating a build pipeline (dont worry, its easier than maybe it sounds, and lots of help out there).

Once you get a bundle going, i.e. turn multiple files in to one (yes, you could just concatenate buts sounds like you want to deep dive this so go straight to module bundling), you might want to look at adding a transpilation step, use Babel to start with.

Once you've got babel transpiling your code and a module bundler (I'd recommend browserify to start as its easiest), you might want to think about tacking on Typescript if types are your thing (also check out Flow, which is an alternative type checker).

Type checking is a bit hard in JS, but don't fall in to the trap that suddenly your code will be safer, it won't be, although it will be better documented.

Good luck!

Ivan beat me to the bullet but has reminded me to clarify: if your goal is to split your project up into different files then you don't need any of these tools, they certainly add a fairly hefty level of complexity, if you're not onboard with the advantages then don't use them.

 

absolutely brilliant!  Thanks for taking the time to type that all up, yep modules is the main thing I'm missing at the moment! 

Probably another stupid question here...

Compatibility maybe a problem though, the games I'm currently putting together for a client do need to run on devices (probably up to 4 years old), and Ive already come across a couple of problems with using es6 features (const was one if I remember)
so if modules are only going to run on es6 capable browsers, do any of these tools offer an option to rebundle/recompile into a single js file if that was the only solution? 


I'm using VSCode alongside a localhost works perfectly for checking on mobile + desktop, but not sure how to set that up with modules, I tried a couple of tests from es6 code I found but it came back with errors on import

So would something like browserify also enable to extend classes I presume?  One of the first things I want to try it out with is a basic UI Kit, so intially starting with layout grids, tables, controls etc.

So a type checker - on a simple level guessing that's more of a way to cast types to variables?  Something I do again miss, but not vital atm

 

[mattstyles]

19 hours ago, sHAYM4N said:

so if modules are only going to run on es6 capable browsers, do any of these tools offer an option to rebundle/recompile into a single js file if that was the only solution? 

This is exactly what Babel is designed for. Babel does a few passes through your code, it traces it back to an abstract syntax tree (AST), makes changes, then reconstructs the AST (older approaches, such as early Traceur, used a regex-replace style but AST is super duper powerful for lots of things). In the case of `const`, it looks through your code and replaces instances of `const` with `var`, so your source code contains `const` but your output contains `var` so older browsers can parse and execute the JS. In this case the only reason to use a const becomes for future-proofing (i.e. when you turn the compiler off because all your targets can consume your source), but for other syntax features (such as destructuring, arrows, generators etc) you get lots of code readibility advantages which lets you write code cleaner and therefore makes simple coding errors harder to make and easier to spot, hence, having your source in this 'newer' format is often good for you as a developer/s.

19 hours ago, sHAYM4N said:

I'm using VSCode alongside a localhost works perfectly for checking on mobile + desktop, but not sure how to set that up with modules, I tried a couple of tests from es6 code I found but it came back with errors on import

You'd have to check with VSCode if it can handle constructing some sort of pipeline that does the relevant building, you probably want to check for Babel plugins for VSCode.

19 hours ago, sHAYM4N said:

So would something like browserify also enable to extend classes I presume?

Nope, browserify only constructs a bundle from a load of files, tracing through requires/exports (commonJS syntax). Babel (et al) would be responsible for the newer syntax stuff like classes. In the case of `import/export`, this is ESNext module spec, so the process would go: Babel transpile to commonJS (require/export), Browserify create the bundle. The transpilation and bundling steps are separate and the tools remain separate, the issue that muddies this is that you usually specify a transpiler when you do the bundling (i.e. browserify -t babelify, more long-winded for webpack) but the steps remain unique (where this gets even trickier is that in order to do some code conversions Babel etc add some extra utility functions, generally you don't want these per-file, you just want them once per bundle, hence the two tools—any combo of the ones discussed—do infact work a little bit together).

19 hours ago, sHAYM4N said:

So a type checker - on a simple level guessing that's more of a way to cast types to variables?

Nope, its only concern is creating a specification for what a variable should be and trying to ensure that the variable is of a specific type when it gets used. For languages designed like this (C, Rust, many many many) they can do this check at compile time and know that it is correct (Rust has such a strong and prohibitive type system, and some other stuff, that if you get something to compile its almost guaranteed to be crash-free, interestingly, Elm claims the same and that compiles to JS), however, for lovely old dynamic JS this is not true, all Typescript/Flow et al do is state that your program might be correct, given that you know that already a cynic would say why bother? But, whilst adding types is verbose it does help clarify what is happening in your program and can help to catch and eliminate some bugs (proper unit testing should always be preferred over type checking, but no reason you can't do both), i.e.

function writeLn (str: string): void {
  console.log(str)
}

// somewhere else in your program...

writeLn(1000) // Type ERROR!

(note, this is Flow, TS syntax might differ)

Hopefully that is pretty clear, we've defined a function `writeLn` that accepts a single variable, which we've said should be a `string`, we've also declared that the function returns `void` (JS doesn't have void but its common in typed languages, for JS it just means it returns `undefined`).

The type checker remembers this specification of the function (in other languages you might specify the function somewhere else from its implementation, in JS we do it both together) and when it sees an invocation later on in the program it knows to check the specification, in this case it knows (well, guesses via inference) that 1000 is an integer and throws you up a warning. Of course, if you stripped the types from the code, it would run just fine, but, not everyone thinks JS should be so permissive, if you're in this camp then maybe type checking is your thing!

To fix it you'd turn 1000 into '1000' implicitly or you could do a type cast such as (1000 + ''), JS is pretty limited in this regard as its dynamic and not typed.

[yahiko]

@sHAYM4N

I've created a TypeScript + Pixi boilet plate : https://github.com/yahiko00/PixiProject

It uses browserify and uglify.

Feel free to use it. Hope this helps.

[ivan.popelyshev]

@yahiko Not related to this thread, just want to notify you: https://github.com/pixijs/pixi-projection/blob/master/src/proj2d/sprites/Sprite2dRenderer.ts , my new lib has template for MultiTexture renderer. I'm working on very hard stuff with custom projections. Related to https://github.com/pixijs/pixi.js/issues/4178

Also as far as I know Yahiko wasn't Uzumaki. I'm confused by your login for a month already.