I'm not sure this is the highest priority, but it would be a lovely thing to have. Is the JS interpreter sufficiently close to standard that this would work at present?

Good point!
If the Interpreter is close enough, and If in general the wish is there to officially "support" TS, then I think this could be handled as not any official task (and therefore any specific priority), but instead get entirely crowdsourced.
Even the typings could be incrementally updated until at some point finished.

I personally would enjoy contributing to this endeavor

I think @T0TProduction may have already seen this, but there is already one Typescript app called BangleRun: https://github.com/espruino/BangleApps/tree/master/apps/banglerun

On the whole Espruino seems fine with the minified code that comes out of Typescript, and adding apps in the way BangleRun did seems like a definite possibility (with the TypeScript source but minified JS stored to get uploaded, and build instructions in a README).

However my concern is really with maintainability. BangleRun is a great example - it was written in thoughtful way, but the original maintainer stopped contributing after a while, and then when there are issues it falls down to the community. And that meant me, because nobody else dared poke around in it.

Actually debugging/fixing stuff like this is a nightmare. So you get a stack trace in JS? You've then got to search through the minified JS and try and find the matching bit, and then try and guess where in the Typescript it was. And then when you find it, you've got this maze of totally undocumented spaghetti code to wade through.

It feels like when you're writing apps that you submit you shouldn't just be thinking about 'how can I make this easy for myself', but 'how can I make this easy for others to contribute'. I feel like with BangleRun the idea was 'I'll use TypeScript to make this easy for everyone, it's self-documenting because it has types' - but in this case, the reality was exactly the opposite... What should have been a simple <200 line app with comments turned into an 8 file, undocumented, unmaintained project written in a different language to every other app.

I'm not saying you shouldn't use TypeScript - but just be aware that you may lose interest at some point, and then someone else will have to maintain the code.

Interesting, I hadn't seen it until now!

Concerning maintainability, that's exactly why I suggested building an "official" typing as well as project/build configuration
So the only thing specific to a single TS app will be its own code, nothing around it.
The rest should be shared across all TS apps and therefore maintainability doesn't rely on individuals.
This shared config could be well documented, e.g. directly with a readme next to it.

But knowing that in theory it works (as we have a working example), maybe just starting with it and trying to create a shareable MVP (with just a small part of the bangle modules being typed) configuration would be a good next step!

If I were to start something, would you want it to be part of this repository? There could be a ~/typescript folder in the root, which includes a package that exports the config and the types
It could then be imported/used by any app within the repo, without needing a second repo or any package publishing to npm

Yes, a typescript folder seems like a good possibility to keep as much common code as possible.

The official typing of Bangle seems to be Javascript.

I know I sound like a dinosaur but for a platform as this really like to be able and use the core of the language and not (all) the metalanguages and frameworks on top of javascript. Especially for the point Gordon brought up; it's a trend for a while, something even cooler pops up and everyone moves untill the next big thing. I know Typescript is around for a while, but as long as you'd have the option to just use native Javascript and not create a dependency and transpiling hell, I think you are more accessible ad s platform and (maybe even more important) less dependent on 'third-party' infrastructure.

I agree - the point is not to remove JS support, but add TS support. (which just compiles to JS in the end anyways.)

When talking about "typing all modules bangle.js exposes" this means adding type.d.ts files that describe the JS. This does not mean changing the code to TS.
The only code written in TS would be apps, and of course, those can still be written in JS just as before.

On a different note, I started working on the first configuration and realized that I was wrong about the following:
TS does and can not minify or mangle code during compilation (microsoft/TypeScript#8). This needs to be done after the code has been compiled to JS.
So in my opinion, we should not do any minification when compiling from TS to JS, and leave it up to the app loader (exactly as with current JS apps) to minify when loading to the watch. This means debugging etc. will be pretty much the same as with current JS apps.

So in my opinion, we should not do any minification when compiling from TS to JS, and leave it up to the app loader (exactly as with current JS apps) to minify when loading to the watch. This means debugging etc. will be pretty much the same as with current JS apps.

This would be a good plan, yes.

But I do think there is still the question: Why do you actually want to do this?

• What apps are you planning on making that require TypeScript and couldn't be done just as easily in JavaScript?
• Will using TypeScript and having the extra compile step make the app more maintainable than if you just wrote JS? I think likely not.
• Have you looked at any potential performance implications, for instance of the Polyfills that may get added?

I think I've given a pretty compelling example of something that was a nightmare - I'd just like to know what the actual real benefits this is going to bring before we do something that's going to cause even more of a maintenance headache.

First, concerning your questions:

• I do not plan on anything that requires using TS. In general, nothing should require switching to TS.
• Maintainability is not the goal behind adding Typescript support. I personally don't think it would suffer either, but I understand that is up for debate
• I have not looked at performance implications, though In my experience if anything changed, Typescript performed better because of more optimization during build steps. Since we don't do any optimization here, I would assume no difference whatsoever.
  Concerning polyfills, as far as I understand Typescript does not add any (Proposal: Auto-polyfilling microsoft/TypeScript#3101). If polyfills are added, that is a step after and while potentially common in combination with TS, is not linked to it.

Why do you actually want to do this?

The main reason I personally love Typescript is typing (duh).
It makes developing a lot easier and quicker because the IDE (and build) lets you know when you are using any given module etc. in a wrong way. Also, a lot better autocompletion.
Another great thing about typing is the safety. Using Typescript, runtime errors are no longer a thing.

I think these features are a great way to support not only myself, but anyone who wants to (start to) contribute. IMO, this makes the platform more accessible, and more stable at the same time.

I finished the very first draft of project and type definitions and used the widget I recently added as test-app. (rewritten to TS)
Please do take a look at the draft PR and let me know what you think!

Will do - I'm just a bit busy right now!

Let's bring Svelte then. It compiles down to plain JS like TS, easier to debug, but can offer possibilities TS can't. Comparison just by value

Yeah, afaik Svelte is made for building webapps - which bangle apps are not. They cannot display any HTML or CSS.
(Except in the app loader settings. But not on the actual watch)

yeah, that was silly of me :(

TypeScript seems will stay with us for a long time. There are people who want to write code only in statically typed languages ​​with interfaces. If such people will write interesting apps for Bangle.js well it would be nice.
The question with apps support is open, perhaps if the developer abandoned the application and it is difficult to maintain, then indicate in the description: the application is not supported at the moment? Perhaps there is a need to make a separate tab in the app loader for such abandoned apps that will be awaiting support?

It would be great to see such an implementation: we connect the extension to the VS Code, write the dev version of the TypeScript there, and the result can be simply run in the Bangle.js emulator. I mean without copy paste in WEB IDE. And as a result will be compilation of the production version with correct JS.

If you're interested in how the TS implementation currently looks, check out the linked PR!
In general I think adding support to the web IDE will be a lot more difficult.
TS needs build tools, and those aren't made to run in browsers. Definitely possible, but also definitely not as straight forward as using TS locally.

Concerning TS not going away:
I think we can all agree that the seventh most used language (https://insights.stackoverflow.com/survey/2021#most-popular-technologies-language) will not just disappear. TS is here to stay, and that's a fact.

Ok, just merged the PR for this.

Just a note here - any new PR for a TypeScript Bangle.js app that doesn't use what's in #1052 isn't going to be merged