Why not TS :'(

[Zeko369]

Why wouldn't we reconsider dropping TS. For this size I think it would that VS Code (and other editos) tooling with TS outweighs any downsides.

[francocorreasosa]

Not something we should decide now. The idea is to build an MVP, check if the idea works, and then if we agree we could easily convert the MVP code to TS and continue from there.

[das3in]

I'd be interested in contributing in a TS world - I'm of the opinion that things like type safety speed up development rather than slow them down (catching bugs earlier, not as many tests needed) so I'm not sure why we wouldn't start with TS.

Also the professional world is moving more and more towards Typescript - this project has the potential to be a good reference point for what a good code base should look like for up and coming Campers

[mattwelke]

One thing to keep in mind is that not everyone is using TS yet. By using JS, the codebase can be more approachable by the open source community, even if people who are used to type safety have to give that up.

[Zeko369]

Maybe flow?

[shovon]

@Zeko369 Flow seems to be stuck at version 0. My guess is that Facebook has given up on it.

Meanwhile, TypeScript is at version 3.6, with all sorts of neat bells and whistles. Version 3.7 is currently in beta, which introduces optional chaining.

[vorpalhex]

TS has a lot of overhead, basically requires VSCode which automatically alienates a ton of devs, and leads to a lot of boilerplate writing instead of feature work. It can be helpful to align on models, but there are also tools such as Joi to enable that. That's before we even get to the version issues and additional build complexity of TS.

[nhsz]

One of the best features of TS IMHO is that typing is optional and progressive. I agree 100% that JS for rapid prototyping is the best option now, we can then just change .js extensions to .ts to start catching bugs.

Meanwhile, in VSCode you can turn on type checking for JS enabling checkJs

[RA9]

Well @Zeko369 using ts now will slow the process down, given the fact that not everyone knows how to use ts.
I will like to suggest that we keep moving with js for now but add something like a style guide that contributors can follow.
Later we could suggest a great resource that teaches ts and add it to the prerequisite resources to use while contributing.

[typeofweb]

I think there's a common misconception that TS slows the process down. It's quite the opposite, actually.

First of all, TypeScript allows prototyping as fast as JS, maybe even faster. There's almost no overhead in terms of code and there's much less mental overhead, which seems to be what slows projects down the most as they grow. Users don't have to know or remember things about the code because the compiler does it for them.

Second of all, TypeScript lets new users contribute to the project much quicker than pure JS. It makes it more approachable. With TypeScript, you can just preview what kind of arguments functions accept and what they return — there's no need for meticulous code reading. One can just quickly look at types and start writing code. There's no need for inspecting what objects actually contain during runtime, which is common in the pure JS world.

Lastly, converting the codebase to TS will be much harder than using it from the beginning. Not because of the code overhead but because models and functions written in pure JS tend to become an entangled mess in terms of types. This is the kind of issue that you spot and fix instantly when using TypeScript. Not so easy with just JS.

I wanted to also address some of the misconceptions in this thread:

TS has a lot of overhead, basically requires VSCode (…)

That's not true :) TypeScript is completely independent of the editor you use. Tons of TypeScript users use WebStorm, NetBeans, Atom, Notepad++, Eclipse, Visual Studio CE, or vim. TypeScript provides a language server that is responsible for all the code suggestions and refactoring, and that's why it's so easy to integrate it with any editor!

It also doesn't increase the build complexity significantly — at worse it's one additional tool. For development, you just replace your JS tools with TS tools (i.e. node with ts-node, node-dev with ts-node-dev and so on…)

(…) there are also tools such as Joi to enable that

Joi is great! I love Joi, it's my favourite validation library. But keep in mind that validation and typechecking are completely different processes, on different levels of abstraction, and for different purpose. With TypeScript, you'd still want to keep on using a validation library (there's even typesafe-joi which makes it smoother!)

@francocorreasosa I was hoping the team could reconsider. I'd be happy to contribute, answer all questions related to TS and help newcomers with learning it 👍

[martindavid]

Agree with @mmiszy. I think people just misunderstanding TS all of this time. In the place I'm working now, people also hesitant to move to Typescript. They already happy with Flow being the safety check for our codebase, but there are lot of things that TS can do better than a static type check library.

And also I'd say, transition from JS to TS is not as painful as other would think, you can still write JS style code in it but if you can write fluent TS, the code will looks better

Notes: @shovon Flow is not stuck at 0, they use https://0ver.org/

[sinharaksh1t]

Agree 100% with @mmiszy. I would also like to pitch in to support contribution, answering questions related to TS and most importantly, helping newcomers especially those who are intimidated by TS. :)
It would be great if the team could reconsider to use TS instead of JS.

[shirakaba]

@francocorreasosa

The idea is to build an MVP, check if the idea works, and then if we agree we could easily convert the MVP code to TS and continue from there.

@jesseokeya

But as the project grows im sure it won't be a problem to migrate to ts slowly.

@RA9

I will like to suggest that we keep moving with js for now

This is like hearing "let's just burn the coal now and revisit the climate change issue later". It is easy to run ahead and whip up a small app in JS. It is also equally easy to end up riddled with subtle run-time errors and paralysed about making changes to various parts of that app because nobody can be sure what the consequences of refactoring it would be.

This is not a one-developer project; it needs to be intuitive to new contributors. It is desperately hard to contribute to a project that is not automatically self-documenting – TypeScript gives you this, freeing contributors from spending half their time jumping around the source just to determine the behaviour of under-documented functions. It furthermore catches potential run-time errors at compile-time and makes code review easier, because if it at least compiles, it can't be far wrong.

I've been here many times, as maintainers underestimate the difficulty of late adoption of TS. As PRs can't be written for two languages at the same time, one thing is inevitable: If a project starts as JS, it's never moving to TS. Please don't sweep TS under the rug, as we'll only be shooting our own feet.

[typeofweb]

@jesseokeya the libraries mentioned in the tech stack thread are all well typed or written in TypeScript. There's no need to write typings for them.

We need to design types and contracts anyway, regardless of whether we'll be using JavaScript or TypeScript. What TypeScript gives you is a way to actually enforce these contracts automatically. Thanks to this, overall mental overhead is much lower.

[rinajhinjhina]

@mmiszy I agree. I don't think TS would really slow down development. And as others have this is a project spanning a lot of developers so TS would really help I feel.

Furthermore if we do establish an MVP, I assume the goal will be to transition the MVP into a product. That will be a lot easier to do if the codebase is in TS.

[jtomaszewski]

Just adding my 2 cents.

1. Developer surveys like the ones of StackOverflow clearly show that people are eager to learn TS, or have already been using it and they still want to use it. So it might actually encourage more people to take part in this project, because it uses tech they like to work in.

   Also, it's easier to create and merge PRs that won't break things, because of type safety, as @mmiszy had already said.

2. There's tens of projects that had recently switched to TS which proves the point it's a good stack. (next.js for example).

   React and Next.js are well typed so there's more cons than pros in not taking TS, IMHO.

For those still not convinced, you might take a look at this article - I wrote it a few months ago in order to convince management of my previous company to let us use TS. (It worked. 💪 )

[das3in]

Not for nothing but at thoughtbot we work with dozens of tech clients from greenfield startups to billion dollar corporations and we're almost exclusively doing TS at this point.

On the whole "speed of development" thing, I think it's silly to assume that TS slows down development. That's like saying writing tests slows down development. It catches bugs, makes features more robust and makes deployments more reliable. Also type signatures make functions more readable (literally describe what's going on instead of guessing) so it makes onboarding new developers that much easier.

[nhsz]

I like TS, but don't think we need it for the MVP, it would add unnecessary friction. Remember this is a FCC community-driven project, so the stack should mirror FCC curriculum's as much as possible IMHO, to ease colaboration. FCC uses JS.

[das3in]

I like TS, but don't think we need it for the MVP, it would add unnecessary friction.

This seems arbitrary. How does adding TS add any friction? Much less unnecessary?

Follow up question: do you believe tests add "unnecessary friction?"

[nhsz]

FCC uses JS by now, no TS. Also Node for the backend and that's why it was chosen and not any other lang. TS adds friction when you start to add external libs/node modules for example and they aren't typed or correctly typed, for example

[typeofweb]

All the modules mentioned in the tech stack thread are either written in TypeScript or have proper typings, so there would be no friction there.

[aloisdg]

@nhsz TS ease collaboration for all non js users not familiar with the mess that js is. At the end, it doesn't really matter. It is quite easy to add later on.

[das3in]

@nhsz It is quite easy to add later on.

Is what everyone always says about tests and why test coverage at a lot of places that transition out of the MVP phase is abysmal. Doing things like writing tests and using a type system drastically reduce friction by creating more readable, reusable and refactorable code. The fact that no one has taken a stance on the "Do tests cause friction" question is telling.

[Wonder2210]

we can work for the first version on .ts files using standar js syntax to fit with tech stack of most of the contributors and when the things become weird , start using type checking on functions arguments .... As this way , we can include along the way TS andat least for the start everyone can contribute

[allella]

Pinging @rohanfaiyazkhan @abidRahim @booleanhunter since TypeScript is making it into the stack and you each mentioned TypeScript in #11 (and possibly above).

We haven't posted the notes from last nights meeting of the most active contributors, but one of the decisions was to start with TypeScript in a minimal way, using mostly JS with .ts files, and gradually bringing others up to speed.

[abidRahim]

@allella That's great news

[martindavid]

This is great news. Looking forward to soon contribute to the project.

[vkWeb]

As @allella mentioned. TypeScript is officially into the stack now.

Thanks to everyone who participated in this discussion and helped our team to go with TypeScript. So I'm closing this issue.

[allella]

The October 20th, 2019 meeting notes, including the TypeScript conversation, are now published as a page in the Wiki.