Some food for thought in this regarding JS vs TS:
I never really embraced TS myself due to the reasons mentioned, instead went the JSDoc route.
AFAIK, Meteor is in the process of refactoring all code into TypeScript.
Not saying it’s a bad move, but… just putting this here.
ping @filipenevola
Same here, but coming from Java, I do think TS is extremely useful for large complex codebases with multiple people working on it, with that said, I’m glad people are pointing the pros/cons of the tech.
Absolutely. I can also see TS as a very possible net-positive for a project the size of Meteor, but thought I’d share since I think this is an interesting trend - reap many of the benefits with minimal cost.
I’m following this movement in the community and tbh I was never a huge fan of Typescript.
I used to work with Java so I understand really well the benefits of types but I also see a lot of benefits in Javascript as it is.
The decision to migrate to Typescript was made before I was working for Meteor and I’m not against if people (community) want to move it forward but I don’t see much benefit on this move.
The decision to migrate to Typescript was made before I was working for Meteor and I’m not against if people (community) want to move it forward but I don’t see much benefit on this move.
Arguing the other side: As someone who occasionally reads through parts of the Meteor source code, I do believe types are helpful for making the code more readable and the authors’ intentions more clear. When contributing (granted, I am not a frequent Meteor contributor), existing type annotations give some assurance that changes won’t introduce obvious regressions. The same benefits can be accomplished without types, but it typically requires some combination of JSDoc + runtime checks + unit tests that can be a little clunkier and harder to maintain than just building in static types to begin with.
All of that said, this benefit is limited in a large codebase where most of the files remain untyped, so it does require some level of buy-in from contributors and maintainers (but hey, everything has to start somewhere).
When I work with back-end meteor methods, pub/sub, I think JSDoc is fine. But when I work with React Components, I usually split them into many small components and then Typescript works beautifully.
With editor which supports Typescript likes Visual Studio Code, I think it’s easier to work with Typescript than Javascript. It took more time to write codes at first but It takes less time to maintain, refactor then.
Using Webstorm it has auto-complete based on propTypes for React, does TypeScript add more value with respect to React?
How about reducers? other functions? custom hooks? state variable types… Using propTypes can just solve a case, and the time you write propTypes, you can write types, they are about the same.
You can write Typescript without a ton of complexity. If you find yourself writing complex types, just take a step back and reevaluate. I’ll never understand the puritanical extremes that many devs seem to fall in to.
Removing Typescript in such cases isn’t going to solve the problem, BTW, it’s just going to hide them. The same design decisions will need to be made in JS, except you won’t have any type safety. What will have been gained?
As for compile times - that just needs to be improved.
I made a lot of investigation (and preparation) previously towards adopting typescript for our projects. I was on the fence for a few months until I read one article (I can no longer find it) which discussed how typescript (just like unit testing) is a tool to “prevent you from failing,” which is different from “succeeding.” That was an eye-opener. Once you understand the difference between the two, deciding if typescript is suitable for your project and with the resources you have becomes easier.
I get it.
But again arguing on the other side, for smaller projects and when you want to get things done quickly, there is a pleasure in the speed of pure JavaScript. I remember when I started coding heavily in JS versus Java, there was this feeling of freedom and flexibility that you get when you just creating variables, calling functions, and getting things done.
There are pros/cons to it, and really depending on the project and the size of the team. It is difficult to argue against what the tech community as a whole perceives as worthy at the peak of hype, there is an inherent risk to that, to appear backward or negative, and many times one can be wrong, but there are so many people hyping TypeScript, so I think it is useful for others to voice the cons, show some constructive skepticism, in order to balance the field and help us see things for what they are.
I will never use typescript at the start of a project or any project without any semblance of success. It is a waste of time while affecting the team’s velocity and thus, hampering innovations. I’d instead use the available resources on innovation and making the project successful.
In terms of adding types, here is my hierarchy of types (both compile-time and runtime) in terms of importance:
I like this hierarchy, I tend to follow the same approach as well, thanks for sharing
I see the biggest benefit for TS when using it with OOP, however this changes the whole way to think about software design for JS applications IMO.
Currently with Meteor I am fast and precise to write JS code mostly procedural and functional. With TS I feel subconsciously forced to go the OOP way way too much.
Also one other thing that annoys me - the code is much less readable to me. Am I the only one who perceives it that way?
I feel the same but I’m biased here as I migrated from Java years ago because I was tired of types and verbosity 
Java also forces OOP which I avoid today with all my strengths. I prefer functional and declarative approaches. One example of declarative approach instead of imperative you can see in my suggestion in this PR.
TypeScript is a huge benefit IMO. In strictly-typed projects, being able to navigate code makes understanding, refactoring, and maintenance much easier, but of course there is an initial cost in learning enough TypeScript for it to be useful.
TypeScript does not force anyone to use OOP. TypeScript only provides types for things you can do in JavaScript, whether that is with functions or with objects (you choose). OOP isn’t always good. Pure-functional isn’t always good either. Both have pros and cons depending on use cases.
I despise OOP, and love typescript. I suspect most of the folks here who can’t stand typescript are trying to do OOP with it. It’s probably OOP they hate, they just don’t know it yet.
I would argue functional with objects is not OOP at all. If you aren’t having endless conversations with your team about “has a” vs “is a” and taxonomies, deep inheritance chains, and patterns like inversion of control, and dependency injection, and the gang of four, ad nauseam, you aren’t doing OOP. You are doing functional programming with objects. 
I will probably never start again a project without types.
For a throw-away script, why not ? but writing code without types now feel like driving with my eyes closed.
I go faster in typescript, because my tools are able to be much more helpful. I think, and please excuse the bluntness, if typescript is slowing you down, you are using it wrong.
Computer languages have 3 environments. The syntax, static environment (what the code literally says) and the dynamic environment (what happens at runtime). The more you can tell by reading the code in the static environment, the easier everything is. JS is a “dynamic language” because it defers a lot of things to the dynamic environment (at runtime) like type marshaling, and property resolution (this). The problem with that is, you have to essentially run the program in your head to make sure all your code is right, and that’s just an error prone and slower (and more exhausting) way to code.
Think about typescript as a tool, rather than gospel. You shouldn’t have to write complex type - really ever. I almost don’t type anything, and instead simply learned to write code in a way that TS can infer almost every type. This makes things like refactoring a breeze.
I will note - I don’t do OOP. OOP is the problem 90% of the time, not typescript. OOP was a generational mistake in computer programming. Do FP (with objects) and free yourself.