stretchly icon indicating copy to clipboard operation
stretchly copied to clipboard

[Feature request]: Move code to TypeScript

Open senpl opened this issue 4 years ago • 5 comments

Version

  • [X] I'm using version 1.7.0

Existing requests

  • [X] I've checked Existing requests

What operating system are you using?

Linux

Operating System Version

Arch

Problem description

The bigger codebase, the more benefits of move to Typescript. JS is nice, but moving to TS sooner then later will make all future contributions easier.

Possible solution

Moving code base to latest typescript should in most cases just work. Alternatively only new code could be tranfsormed, still it is best if all projects file moves to TS for all advanteges.

Alternative solutions

Code could stay in JS, but this with time will just make more and more errors that could be prevented with Typescript.

Additional information

This looks like big change at first, but if done right could be gain for many.

Code of Conduct

  • [X] I agree to follow this project's Code of Conduct

senpl avatar May 17 '21 10:05 senpl

My few points (probably not valid at all :) )

  • I don't speak TS (but would have to maintain the code)
  • In past, there were issues with code that needs to be translated/transpiled not working in production (bundled version) (so less tooling, the more happy I am)
  • I am not typed kind of dev :)
  • with Electron I can use many new JS features without babel etc
  • in my experience, once I start using some of those tools, every upgrade means upgrade of tooling and usually lot of pain (ie webpacker) which demotivates me.

So what would have to happen to enable TS? What are alternative typed JS thingies?

hovancik avatar May 18 '21 15:05 hovancik

I don't speak TS (but would have to maintain the code)

All code could be not changed (most TS rules could be turn off when not used). TS could also be combine with JS so it's also not holding anyone back.

with Electron I can use many new JS features without babel etc

Electron uses TS so when they change their types in newer version it could be more safely be updated. Other big libraries as well.

So what would have to happen to enable TS?

Just adding ts.config with rules that you want in your project. And building rules that combine JS and TS to not rewrite existing code.

Yes it's another tool, yes it could provide some pains. Still node creator thinks it's a way to go. It's like JS but less error prone. Sure it's your decision. In my opinion it's better to fight 5 minute with TS then searching bug for 2 days that TS could prevent.

senpl avatar May 19 '21 05:05 senpl

Looked a bit at what's also in this space:

  • https://www.purescript.org/
  • https://flow.org/en/
  • https://rescript-lang.org/
  • or not typed https://coffeescript.org/ but like Ruby so I like it

hovancik avatar Jun 03 '21 06:06 hovancik

Just FYI, I've had some brief experience with Flow, and discovered that Typescript is simply several times more popular than any of these alternatives, and thus better maintained. Flow had lapses where stuff wasn't supplied because no one just got around to it (it was some feature that would be used in typedefs for a lib, can't remember for sure).

You can see it just by the numbers of stars on Github:

  • Coffeescript: 15.9k stars
  • ReScript: 568
  • Flow: 21.3k
  • PureScript: 7.2k
  • Typescript: 72k

When you need typedefs for a lib, TS is way more likely to have them, since it's basically the de-facto standard now and authors themselves sometimes ship typedefs without using TS in the project.

I'm likewise skeptical about bringing in TS—imo types matter mostly when the team gets larger, which is unlikely when the app doesn't really gain new features. Some code reorganization could be more useful ;) But if you ever decide to have types, TS is probably the least problematic way for that.

decadent avatar Jul 11 '21 16:07 decadent

I agree that TypeScript is a great addition to any JS codebase, and think that it is much better than the other alternatives. However I don't see a reason for this feature reqeust considering that @hovancik is the only maintainer and he has clear reasons to why he prefers JS.

Asking for a codebase to be migrated to another language just because you feel like it is better is not a valid reason imo. A better way to approach this would be to port sections of the codebase yourself (on a fork) and then you could show the benefits to the repo's maintainer.

mikaelmello avatar Jul 23 '21 16:07 mikaelmello

As I don't think I will move to TypeScript, will be closing this issue. Sorry.

hovancik avatar Dec 22 '22 12:12 hovancik