Would you be interested on porting to typescript, webpack?

[cyberhck]

Hello everyone, I know it's a huge taking,
but would you be interested in slow migration towards typescript and start using webpack or rollup instead of gulp/javascript?

I'm sure you know TypeScript is a superset of JavaScript, and converting to that I feel like it'd make contribution so much more easier, and it could catch bugs in the same time as well.

Let me know if you're interested, I could give a weekend and give starting process a try.

[Persei08]

What are the benefit of typescript over JS ?

[KingOrdinaryCitizen]

"JavaScript is a scripting language which helps you create interactive web pages whereas Typescript is a superset of JavaScript. Typescript code needs to be compiled while JavaScript code doesn't need to compile. Typescript supports a feature of prototyping while JavaScript doesn't support this feature"
https://www.guru99.com/typescript-vs-javascript.html

TLDR: It's an preprocessor (really bad explanation but gives you an general idea) for JavaScript, it allows for more robust code by allowing IDE's and other tools to easier spot errors.

However, since it's practically a full rewrite of the entire codebase, I think it'll cause more errors than it will solve...

[cyberhck]

who said it's practically a full rewrite? that's not true, you can always go one file by one file, module by module,

I've been using TS for more than 4 years now and never been happier, by using typescript, one of the most important thing will be elimination of type based errors, how many times have I done user.owner instead of user.ownerId (or similar),

another benefit as mentioned above is when you use this with a editor worth it's salt like VSCode, (however I really recommend webstorm), it helps you write code faster with intellisense, spotting type errors right when you type, etc.

Another thing with typescript is you almost never refer to someone's documentation, you have it right when you type, always.

The way I was proposing would be going step by step, for example, we could start by porting devices directory to typescript, and you can import those typescript directly on javascript and build it.

The initial work will be a little bit to set things up, because I have no experience with this source code and how the build works,

however, once I'm able to transform files into typescript, it'd be just a matter of renaming them gradually to .ts and adding type definitions over time and slowly move to more and more strict convention.

[frankrobert]

@Persei08 @KingOrdinaryCitizen I believe the point that @cyberhck is trying to make is that Typescript not only provides the ability to, but also encourages incremental migrations.

• Here are a few strategies they propose based on migrating existing build systems such as Grunt, Gulp, Webpack, etc.

• Here's the classic Typescript in 5 Minutes for JavaScript Programmers from the official website.

I think the point is that you gain the ability to write modern javascript with few-to-no additional tools (such as Babel for transpilation) while also having the confidence instilled from the type safety. By merely changing a file extension from .js to .ts the Typescript compiler will often begin immediately highlighting oddities and inconsistencies in your code that would have otherwise been very difficult to identify.

Another major advantage is the intellisense & editor integrations. These allow for a phenomenal developer experience helping you avoid errors before you even get to the point of running/writing tests or committing.

All this said, here's what I would propose if the PT team were on board and would like to integrate TS:

• I would strongly advocate against doing a rewrite of the build toolchain to Webpack as part of this initiative. Before thinking about rewriting the entire build toolchain which can have adverse affects, it would be much safer to look into how we can piecemeal some Typescript code in the existing build.

• We should put together a POC that includes a single .ts file as this would be sufficient before considering touching the rest of the build tools.

• https://www.typescriptlang.org/docs/handbook/gulp.html here's the "official" gulp integration for Typescript as part of their documentation. Who knows, there may be other/better tools out there. will need to do some research on that as I'm personally more familiar with the Webpack space compared to Gulp's.

Just my thoughts as an outsider

[pcenta]

I'd support that move but I think it would be smart to have someone experienced overseeing this move towards TypeScript (at least from quality perspective). From my experience it would ease future development and also encourage new developers.

And yes, since TypeScript supports accepting .js files there's no need for complete rewrite just now.

[KingOrdinaryCitizen]

I might come on as a really conservative guy, which only sees the problems (however might be useful to have someone disagree), but here I go again anyway.

I'm for advancements in this project and making it easier to contribute. But I don't like that the fact that a full rewrite is going to happen is being ignored. File by file conversion to TypeScript might work, but it might make it really really confusing in the near future. At the end of the day, everything is then supposed to be in TypeScript anyway.

So contributing will be a lot harder, let's say I have to make changes in file X and file Y, file X has already been converted to TypeScript but file Y hasn't yet. Do I first have to convert file Y, before making my changes/contributions? TLDR: I'm not really for the 'we'll be converting file by file'...

Then again, TypeScript is just physically different as opposed to JavaScript as was written in an article by Jonas Bandi (https://medium.jonasbandi.net/here-is-why-you-might-not-want-to-use-typescript-50ab0d225bdd) suggests that we'll be making the developer pool smaller, since less developers know TypeScript opposed to the majorly popular JavaScript. I know I'd still want to contribute by learning TypeScript, but just pointing out that not everyone might want to learn a new JavaScript.

Also, Jason Bandi brings up the point of TypeScript being the superset and that it's not always straight forward. "TypeScript claims to be a superset of JavaScript. That claim alone is questionable, since typical JavaScript code produces errors in TypeScript."

Note that Jason Bandi still thinks TypeScript is "The best language choice for complex web applications. I choose it for any non-trivial project." (http://blog.jonasbandi.net/2016/10/myth-of-superset.html).

Also note, that I'm not fully against converting to TypeScript, not at all. I'm just pointing the cons out, which seem to be forgotten in all of the many pros you've already given.

[frankrobert]

@KingOrdinaryCitizen I honestly feel that the article you read is fear-mongering Typescript and painting it in the wrong light. I'll do my best to address all or most of the points you (and to some degree that author) raised.

• File-by-file piece-meal migration can also start on a much smaller scale using JSDoc type annotations. This way there's 0 change to the codebase and it would actually encourage better documentation as an added perk.

• We can configure TS to be more flexible, and much more approachable for new contributors.

• Even if a file is has a .ts extension contributors shouldn't concern themselves with the extension name. It's somewhat similar to how c++ uses either .cc or .cpp. The develop shouldn't really care, and so long as the compiler is properly configured it won't either. This should be the same attitude we take with Typescript.

For example, both of these are exactly the same functions in both Javascript and Typescript. We can omit types based on how we configure the compiler.

// JS
const myFunction = () => 'hello world';

// TS
const myFunction = () => 'hello world';

As another alternative, it might be worth looking into babel to transpile modern code to more legacy formats, if needed (is this even needed considering Nwjs is being used?). Babel also supports compiling Typescript code but has some caveats and issues with certain aspects. This might be an easier way to migrate legacy code styles such as the IIFE prototype-based classes that can be rewritten as ES6+ classes.

As I'd mentioned in my last comment I would strongly advocate for a small POC before anyone makes any decisions.

[cyberhck]

btw, this could have been caught during build time, (at least we could throw better error message if really errored)

[cyberhck]

also I don't understand why you keep saying everything is going to be rewritten, please don't say false statements like that, it's not a rewrite, it's basically changing extensions and adding type annotations where we can,

say you have css files and want to convert to scss, just changing extension is enough, and you can slowly start adding variables, nested rules etc, it's not a rewrite, and converting to typescript is less of changes than converting to scss.

[KingOrdinaryCitizen]

But that's not true, I get now that it might not be a full rewrite, but there will be a substantial rewrite.
That's the whole point of changing to TypeScript isn't it? If everything remained the same, why would we ever change to TypeScript.

[frankrobert]

@cyberhck there's no need to be aggressive. @KingOrdinaryCitizen is absolutely correct about the work involved in this initiative. I've spent a few hours already attempting to include TS with as small of footprint/impact on the code-base as possible but the reality is that you have to rewrite the build toolchain to include typescript. In all fairness, I'm not extremely knowledgeable of Gulp and so I'm sure there may be better approaches than what I attempted but I would encourage you to try a small POC to experience the complexities first hand.

This can be done in a non-invasive way once established but the initial integration will require rewriting parts of the build which will require being extremely careful so as to not break anything.

[cyberhck]

hey @frankrobert I'm not being aggressive, @KingOrdinaryCitizen I'm sorry if I sounded so, I just wanted to point out the fact that it's not a rewrite,

but again what do you consider a rewrite, say this migration takes you more than a year because it's not something to do overnight, by then everything would have changed, but that's just normal even if we don't port, we'd be changing files, updating features etc,

Also related to the build, yes, gulp is something I don't know much about either, that's the reason I also was proposing webpack. And yes, I'm not saying let's accept this issue and move forward either, this is a discussion, and what I wanted to try step by step:

• see if we can use typescript without using webpack
• if we can, then migration should be very simple, just add a readme, whatever file you're working on, try and convert to .ts extension and add types where possible, and slowly it'll get converted
• if we can't see if we can migrate to webpack, but don't introduce typescript yet, release a version built with webpack and see if it still works the same
• finally convert to typescript but gradually, go for internal scripts, which don't actually depend on other non typed files, slowly convert everything else.

I don't mean I expect everyone to make this priority either, just continue adding features as you normally would, someone more experienced with gulp can try the gulp path, I could give webpack a try, once it's established we can migrate to typescript together.

[tkSimon]

I'd rather move to es6, use proper es6 classes, use async/await and get rid of all the Q imports and then()'s than move towards TS. 🤷‍♂️
But seems I'm in the minority 😅

[ThaBrad]

In 2022 to not use typescript is kinda stupid (coming from a Senior Frontend Dev working at a FAANG company) 😉.
If you adapt build script a tiny bit, you can just rename all .js to .ts (doesn't matter even for building) and deactivate certain lint rules (for now), or do it file by file and try to autocorrect with ESLint or by by hand.
There's literally nothing speaking against it, besides a little extra work which would pay back in community contributions. Heck, give the plan a GO and I'll contribute even 😅 !