I recently did the exact same job as the author of this post.
Migrating 15K LoC from JS to TS.
The author of Vue.JS also migrated Vue completely to Typescript.
At first I had major apprehension because of how much Microsoft generally enforces things on developers.
It's well know that if you start using C# , your entire stack will generally be MS based...(SQL Server, Azure etc... )
But after I did the migration , I was blown away by how confident and how much flexibility I had when i was writing my code.
Even if I have been writing code with Java / C# for nearly a decade , nothing has come close to Typescript in terms of productivity,flexibility and confidence.
Having used Javascript since before Node.JS , I think the whole idea of having to "transpile" my code to something or to respect some "rules" define by a company with a reputation that wasn't really "all in open source" .
But after using Typescript on multiples projects , you just can't go back , it's incredible how well it's scale without enforcing anything on the developers.
Hopefully , one day bootcamps will include Typescript in their trainings to demonstrate how typings can solve maintainability issues...
"Even if I have been writing code with Java / C# for nearly a decade , nothing has come close to Typescript in terms of productivity,flexibility and confidence."
Same here.
Isn't this truly amazing?
Take a jangly language like JS, and add some typing for the compiler, which forces you to write cleaner code in addition to all the compiler advantages ... combined with some really cool features and bang a magical, pragmatic language.
Aside for some script things for which Python is still a blessing, I'd chose TS for everything else, at least to start.
It just has the right mix of flexibility and expressivity etc..
Though TS is an MS project, I suggest it really is quite different, it's 'open from the start' kind of thing, you can have a loot at TSC internals. The team seems to be fairly dynamic and responsive.
Typscript is my #1 favorite 'invention' of the last few years, I think it will be around for a while, and I hope to see many more JS API's 'properly documented' with the help of TS.
> Aside for some script things for which Python is still a blessing, I'd chose TS for everything else, at least to start.
I really wish Python had a decent type system; hopefully the Mypy project takes a leaf from TypeScript's book.
Also, I've found that Go does for Python much of what TypeScript does for JavaScript. Of course, Go's APIs are different than Python's and its type system is less expressive than TypeScript so it's not a perfect analog, but Go also brings speed, parallelism, sane concurrency (Python's async is a hot mess by comparison), sane deployment, and great editor integrations, which are things I sorely miss when writing Python.
Mypy is already quite powerful and understands a lot of the language. With latest versions of the language, what is handled by "transpiling" to JS, can be done "natively", ie. there is no need for an intermediate step to strip out the additional syntax for declaring types as it's now built in.
Mypy and TC and Flow and many other similar projects seem to stem from the academic work on gradual typing from nearly 20 years ago. What we're seeing now is "practical application" of that research, and while different projects have different budgets, it won't be surprising if they all converge in terms of features at some point. I'm not an expert, by any means, but we've already seen this happening many times with languages and software platforms. At least this time the point of convergence is based on comp-sci research and not on the marketing one.
My grievance is mostly that Mypy is much less polished than TS and Flow (you can argue that it's a lack of investment and that's probably true, but it doesn't do me any good as a Python developer). Notably, Mypy's syntax is very much shoehorned in. How do I define a TypeVar for a particular method in a class? If I define a TypeVar () in the class scope, does every reference to T take on the same type? I can't honestly tell by looking if it's safe to use for each generic method in a class or if the type system will try to unify them to the same type. Also, does Mypy support recursive types yet? Can I meaningfully define a JSON type without hacks (e.g., `Dict[str, Any]`)? Also, can I stub out generated types yet? IIRC, the official position for SQLAlchemy was something like "eh, it's out of scope for the project". Pretty sure there was a lot of problems with defining different kinds of callables (maybe those with args and kwargs?) not to mention a bunch of ergonomic problems because they don't want to extend the parser much (it appears they take the view that it's better to have terrible syntax that is "valid Python" without much modification to the Python parser--to be clear, this isn't referring to angle brackets vs square brackets, but things like using variable declaration syntax in an outer scope to declare a type variable for a generic context).
Each method is independent unless the class is a Generic[T].
You can define a recursive type by quoting the nested reference.
You can define a JSON type with recursive types.
You can create stubs. Some are in typeshed.[1]
Mypy recently added protocols to simplify defining callable types.
Python has always been slow to add new syntax. I think that's a good thing overall.