Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Typescript support #998

Closed
maybeanerd opened this issue Dec 4, 2021 · 20 comments
Closed

Typescript support #998

maybeanerd opened this issue Dec 4, 2021 · 20 comments

Comments

@maybeanerd
Copy link
Contributor

maybeanerd commented Dec 4, 2021 •
edited
Loading

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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

@jeroenpeters1986
Copy link
Contributor

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
Copy link
Contributor Author

maybeanerd commented Dec 7, 2021 •
edited
Loading

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
Copy link
Contributor Author

maybeanerd commented Dec 7, 2021 •
edited
Loading

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
Copy link
Member

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
Copy link
Contributor Author

maybeanerd commented Dec 8, 2021 •
edited
Loading

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 maybeanerd mentioned this issue Dec 10, 2021
Merged
5 tasks
@maybeanerd
Copy link
Contributor Author

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
Copy link
Member

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

@RomanistHere
Copy link
Contributor

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
Copy link
Contributor

stephenPspackman commented Dec 17, 2021 via email

@maybeanerd
Copy link
Contributor Author

maybeanerd commented Dec 17, 2021 •
edited
Loading

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)

@RomanistHere
Copy link
Contributor

yeah, that was silly of me :(

@zloid
Copy link

zloid commented Dec 21, 2021

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.

@maybeanerd
Copy link
Contributor Author

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.

@stephenPspackman
Copy link
Contributor

stephenPspackman commented Dec 21, 2021 via email

@gfwilliams
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@gfwilliams @jeroenpeters1986 @maybeanerd @zloid @RomanistHere @stephenPspackman