Typescript support

[maybeanerd]

Im a fan of the simple way this repository hosts app as well as the existence of the web IDE and emulators for ease of use.

One thing I was wondering though:
Is there any Typescript support? Obviously all distributed apps need to be JS, but in theory typing the entire BangleJS environment and creating a default export/transpile script that exports files to the correct format and structure could be a huge help to creating new apps.

The main two questions I would have are:

• Was this already considered? If so, what was the reason against it? (Or is there already something in the works that I missed?)
• Would PRs to this repo be allowed to be minified Typescript exports? Obviously the JS can be rather unrecognizable after being transpiled.
  This can be deactivated, but saves memory etc. so why should we remove that benefit of TS.
  A solution to this could be to also add the TS files to the PR, maybe in an extra folder which is used to verify the code logic in PRs, but just ignored by the app loader later on.

A probably overkill solution for the second question could also be to allow TS PRs, and then after approval a GitHub Action transpiles the TS without any human interaction - making sure the potentially unreadable code is actually created with the reviewed TS code.

Edit : there is an open pull request:
#1052

[stephenPspackman]

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?

[maybeanerd]

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

[gfwilliams]

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.

[maybeanerd]

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

[gfwilliams]

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

[jeroenpeters1986]

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.

[maybeanerd]

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.

[maybeanerd]

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.

[gfwilliams]

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.

[maybeanerd]

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.

[maybeanerd]

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!

[gfwilliams]

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

[RomanistHere]

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

[stephenPspackman]

I don't think Svelte does what you think it does? Typescript is an annotation layer on top of Javascript, which is itself a general purpose programming language, while—unless I'm utterly confused—Svelte is more like an attempt to fix dynamic HTML.

…

On Fri, 17 Dec 2021 at 09:37, Romanist ***@***.***> wrote: 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 — Reply to this email directly, view it on GitHub <#998 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWGZ2FVFA42W3H37DAUUHWDURNYNTANCNFSM5JLORQVQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>