Add a Typescript example

[willeastcott]

Add a sample Typescript project that demonstrates how to use the playcanvas.d.ts file and structure scripts.

[blairmacintyre]

I am mostly finished creating a Typescript version of the Editor's WebXR starter kit, would be happy to contribute it back. Let me know if that's of interest. I'm sure I'm not doing everything "the best way", since it's also my "learn how to do this" project.

[willeastcott]

Thanks for the offer on that @blairmacintyre. I think any examples and test coverage for the engine Typescript bindings would be beneficial. But maybe we should strategize a bit on this first. I guess there are a few options.

We could move the examples to Typescript wholesale. But then, that might alienate JS devs. That said, compiling TS generates JS of course, so we could have TS and JS side by side, and devs inspect whichever they prefer. I personally don't have a huge amount of experience with TS->JS output so I'm not sure if it would make good example code.

To begin with, it'd probably be good to just create a very basic 'hello world' TS example and check that in. Something equivalent to this say.

[blairmacintyre]

I think more pervasive support for Typescript would be amazing, in both the editor and the engine.

I started my students off this semester with Babylon and Typescript, and then have them do a Playcanvas assignment using the Editor: number 1 complaint is "OMG, Javascript sucks" ... when you get used to strong typing finding things for you, esp when you are learning a system, it's super annoying to go back. Integrating Typescript into the script editor, so you can use it, would be great.

Of course, there are other issues that will come up: any dynamic will be problematic. So, adding a script to a Script Component will throw tons of errors if you have strict typing set and try to access it via the dynamically created property.

Now, that said, you can do what some systems do and provide both: just using the JS output would be less than ideal, so you'd really want to write both. When we did our Argon system, we embedded both in our example pages (e.g., see https://docs.argonjs.io/tutorial/part1/). You'd need to do the API docs and all the

Honestly, for doing large projects with complex libraries, using Typescript is a huge win, especially if you're using Visual Studio Code, since you get deep Intelisense that lets you find many many errors while editing, whole project refactoring becomes a snap, etc.

[blairmacintyre]

Regarding the example, one issue is: you can't have it all in one file. You need to have a .ts file separately, and then have it generate a .js.

Here's the assignment I gave my students, which has the working "XR Starter Kit" as their starting point. https://github.com/3dui-class-f20/a1c-template

(a1a was "make this simple app in Babylon", a1b was to do the same thing in the Playcanvas Editor, a1c is to move that to the Engine. Learning objective is to see the difference in an Object-based system from an Entity Component architecture, and then see how the Editor is not really magic, it maps pretty directly to code).

[Maksims]

Some of IMHOs:

Whole TypeScript topic - is very very subjective. And to understand its feasibility, it has to be looked at from very big picture. Some of large questions has to be answered:

1. What background developer is coming from: strong type environments (classic gamedev), or web, front-end, creative, newbie, etc.
2. Popularity and future of the TypeScript (there has been many JS pre-processors, TS is backed by Microsoft a lot, will TS be growing without MS behind them?).
3. Learning curve: should developer be better learning JS or TS, especially depending on their background and future branching out. Learning JS is way
4. Integration, accessibility and portability: TS requires pre-processing, it is not directly executed by browsers / systems. This leads to needs of pre-processing. Integrations in Editor can lead to reduced UX. Enforcing more sophisticated build processes for projects using the Engine - is definitely a bad thing as well. Developers should have choice.
5. Legacy of JS: it has tons of info online, solved common questions, tasks and challenges in JS. This is not true for TS. Putting plain JS into TS - we end up with mixed salad.

Things has to be considered for many existing users as well, and forcing them to learn new stuff, or even worse: splitting developer pool into separate groups - is a very bad thing for community.

[blairmacintyre]

Hi @Maksims ... I definitely don't want to get into a TS vs JS debate. "Been down that road many times." I think the popularity of TS is pretty self-evident at this point (it's massive and used by some fairly massive projects outside of MSFT -- that was true half a dozen years ago when I started using it). I personally prefer it, and since I work a lot with novices (students) I insist on using strongly typed languages because it saves them time and headaches (when I give an assignment that supposed to take 8-10 hours, I don't want them blowing an hour here or there on some silly typo that TS would have caught). But, that's preference, and context.

I would not advocate for a all-or-nothing approach switching to TS -- I think supporting both is great, and if only one can be supported, then I think JS is fine because, as you say, it's more universal.

That said, I was reacting to @willeastcott's comments, and would love to see the Editor support TS "as an option" ... just like Unity dumped Javascript for C# (but still supports JS, I think). There are plenty of examples of running the TS compiler in the browser, so having the Editor support TS and convert to JS in the background is pretty trivial. However, again, decisions like that are up to you and involved tradeoff.

As for samples in the Engine, again I was reacting to Will. I think it's sufficient to have a complete and up-to-date set of bindings, and a few samples. I suggested the conversion of the XR starter kit because that's something that people can see easily in the Editor and compare to. I'd suggest doing an equivalent to each of the possible project starter kits. And, then, I'd pick a few other key things and do samples. For example, something with physics (so that people see how to set up and load WASM).

I'd also like to see a robust example of how to use the Asset loading/management system. My impression is that the basic loader works for basic assets, but you need to use the "loadFromURL" for models? I ended up using "loadFromURL" for all my assets, but perhaps could convert that back to using it only for the model.

[Maksims]

I'd also like to see a robust example of how to use the Asset loading/management system. My impression is that the basic loader works for basic assets, but you need to use the "loadFromURL" for models? I ended up using "loadFromURL" for all my assets, but perhaps could convert that back to using it only for the model.

You can create pc.Asset object, provide it with necessary type, file and data info, and add it to assets registry. Then it should load either by calling assets.load(asset), or if it is used as an asset on any components and being rendered. Without need to call loadFromURL.

[blairmacintyre]

You can create pc.Asset object, provide it with necessary type, file and data info, and add it to assets registry. Then it should load either by calling assets.load(asset), or if it is used as an asset on any components and being rendered. Without need to call loadFromURL.

I could get that working for everything EXCEPT models (for the rest of the stuff, that worked fine, in an obvious way). It didn't seem to handle the recursive loading of the various assets, and I couldn't see how to make that work. Even the docs encourage loadFromURL in that case.

[willeastcott]

Closing since we now have this: https://github.com/playcanvas/playcanvas-editor-ts-template