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.
> 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.
Agreed. And when you compare how TS was designed to how other languages were designed, it makes a lot of sense why TS ended up being such a great language.
Unlike virtually every other language in existence, TS was not designed from the ground up. It was designed with a very specific goal in mind: to adhere to the standards that JS developers had already converged on. So when a JS developer said if (foo), TS was built to realize that was an implicit type check against null. When a JS developer said if (obj.type === “bar”), TS read that as a way to ensure obj was in fact a bar.
It’s unlikely that a language developer working from scratch would have come up with these odd idioms, let alone prioritized their inclusion into a new language. But in the case of TS, all these idioms came from millions of lines of working code.
I think that’s why TS feels so enjoyable and easy to work with nowadays, whereas even the best of other languages feel a little clunky at times. It was developed prioritizing making real actual code idioms people wanted to do work.
The exception I'd add is that JavaScript's standard library is still very weak. I find myself leaning on Lodash for functionality that would be built into any other language.
Part of me would love for TS to build one out and add shims as part of the transpilation process, but it would go miles out of the scope of what TS is trying to do. And I love that (compared to Babel) TS has no plugins and relatively few options.
> 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.
> Take a jangly language like JS, and add some typing for the compiler
It so turns out that there is a great sweet spot in between the straight jacket typing of classic Java/C# and the loose "do way ever you like" approach in Python/JS.
I don't want use another language that doesn't have optional typing and structural typing. It combines the best of both ends of the spectrum.
I've heard it said that Javascript and C are both good languages to compile to -- the language itself is very "fast" in basic operations (V8 is hyper-optimized, C is relatively close to the metal), but an ugly language with lots of gotchas and warts that make it hard for a human to use effectively, but which don't pose a problem for a well-designed compiler.
I'm starting to think Microsoft's strategy with things like VS Code, Monaco editor, and Typescript is "blow the developer away with how amazingly productive they are so that they will want to use more of our products". Because it's just so high quality yet also gratis/libre (MIT license), that I can't see what else they could be trying to do.
Honestly I also think its a recruiting tool for Microsoft. Developers watch the meaningful and useful open source contributions made by Microsoft, and some of the highbrow disinterest in Microsoft due to choices made in the past will fade.
Never forget "Embrace, extend, extinguish". Microsoft has a history of adopting open standards, adding value to them to gain market share, then leveraging that to destroy their competition.
Microsoft might seem to be an "open source champion" now, but remember that it is a publicly traded corporation with a fiduciary responsibility to maximize profits for its shareholders and a history of anti-competitive, anti-consumer practices.
Right now they are being warm and fuzzy to regain the developer mind-share they have lost over the past couple decades to open-source software. If they get a large percentage of developers using their tools and services (looking at you GitHub) I would not trust that they will continue to be so warm and fuzzy.
Granted, they weren't releasing much open source then, but it was all free to use, and the quality was far above open source alternatives (e.g. think the Visual Studio debugger vs. GDB wrappers).
I think they just naturally figured out that there's zero advantage to keeping developer tools closed source.
MS has long been about "Developers! Developers! Developers!" But these days they're about more than just Windows developers shipping native closed source applications.
It's probably multi-faceted. Part of me thinks it's just something they use internally extensively and that branching out to the public means they can easily hire talent to work on their own projects. It's also probably an effort to stay relevant and make amends with web developers, who have long held them in low regard.
And yeah, Azure is a booming business for them. VSCode has a bunch of first-party extensions that reduce friction for working on their platform.
Microsoft does the same thing over and over - "embrace" a technology, "extend" it by adding some extra stuff to it that happens to work best on Windows then "extinguish" the tech once people are locked in.
Also see: Internet Explorer or Kerberos or Office document interoperability or AIM (messenger) or half a dozen other things.
It appears the tide is changing and what was once hated upon by many in the JS and front-end community, has now become cool and a tonne of projects are migrating. Another project migrating to TypeScript is the Aurelia Javascript Framework for its next version coming out later in 2019.
It's funny because I remember when Angular 2 was announced and that it would be written completely in TypeScript, they copped a lot of backlash for it, but it appears to have been a good move.
I exclusively have been writing in TypeScript for about 3 years now and it's crazy how good it actually is, especially for distributed teams in different time zones. The code is self-documenting and the number of silly mistakes being committed into our codebase has dramatically been reduced, combined with solid unit tests, we haven't really had a code level bug in what feels like months, browser bugs on the other hand...
My favourite thing about TS besides the types and interfaces is the compiler. I no longer have to use transpilers like Babel anymore because TypeScript handles compiling to many different module formats and targets. Back when I used Babel, it felt like pulling teeth because of the different plugins and packages you had to install and configure to use.
I find it really hard to use anything other than TypeScript now, it is simply too good.
I'd argue that porting from JS to TS is a very different beast than porting from Flow to TS.
I've ported code from JS to Flow and could say the benefits are similar to those of porting from JS to TS.
The most relevant part in this article IMHO is the conclusion:
> things like a strong community and availability of type definitions are more important because weak type inference can be solved by "handholding" the type checker a bit more.
I think it's important to highlight that this may be true of his project but not necessarily yours or mine.
Flow's type inference provides a much deeper level of confidence than TS with far less effort, for example, typing only the public interface of a module is often enough to surface type mismatch errors several functions deep within the module. In TS, you'd have to type every function signature to get the same level of confidence.
What worries me about flow is reflected in the comment from the facebook engineer linked from the article: it seems the flow team is focusing heavily on facebook-scale performance at the expense of most every other aspect of the project. A while back, the existential operator was quietly deprecated in the name of perf, and lately some updates have been of questionable soundness, e.g.
> In TS, you'd have to type every function signature to get the same level of confidence.
I don't disagree, but isn't this the point? That by typing every function you can reliably have confidence in parameter types and return value types, and if your program is able to throw a type error on build, then it should and alert the developer that they're not logically correct in their implementation.
> 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.
TypeScript is, by far, my favorite type system. I love structural typing. I love conditional types (ReturnType<T>). I love things like `keyof T`. I love how good it's inference system is. I love how I can still use it in a JS file and still get type checking with JSDoc.
I tried out Dart over the holidays and it felt like a major step backwards. Seriously, hats off to the developers.
> 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
I can completely relate. To me the greatest thing is the tooling around it. Using tide[0] on even plain js codebase is just amazing.
I really wish ruby had a TypeRuby compiler (to regular ruby). I know about crystal, but I still want regular Ruby, just with a type checker at compile time, not runtime.
Yup, it's ridiculous cargo cultism from mediocre C# programmers. There's nothing about C# that forces you into MS's ecosystem.
In 2014, well before Microsoft's dotnetcore oss adventure, I ran the dev team at a startup. Our entire backend was C#. Our devs used the OS of their preference, and so we had Mac, Windows and Linux. Xamarin Studio is (was?) a remarkably decent IDE for something so niche.
We hosted it in Docker (bad call, it was way too new then) on Mono (great call, it Just Worked), on Linux. Data in Postgres. All of this was as easy as doing the same with eg JS or Java (and arguably easier than eg Ruby because C# has a proper cross platform dependency story).
There's nothing about C# that forces you to use SQL Server or Azure. Absolutely nothing.
That's awesome! Did you convert from Flow or just plain JS? I think the experience is much different when converting from Flow vs converting from JS. When coming from pure JavaScript, you do indeed become much more confident and flexible around the code. When you come from Flow, the differences are much more subtle as I described in the article.
IMHO the largest difference is the amount of time you save hunting down stupid issues. e.g. no more spending 3 hours fixing a typo.
Also, code is much more manageable, and refactoring is tons easier.
With enough Babel plugins, you can get ESNext functionality that does whatever you want (some of those early stage proposals are really cool! They might go away tomorrow, but hey, so cool!), so Typescript's old advantage of offering more language features is kinda nullified.
In the end, I started writing the later part of my current project in Typescript, and I much more enjoy working on that part of the code than the earlier parts.
TS takes one day to get going, which is one of the best things about it.
Stick to the 'basics' of TS, which are super general programming syntax structures and idioms - there's really nothing new you'll come across (maybe unions?) - so it's easy.
Then you can try some of the trickier things but frankly we don't use them that much.
You'll be up and running pretty quickly because you can mix your 'new' TS modules with old-school JS code no problem.
And then go from there.
I like TS because it's not some big new fancy paradigm shift: it's just typing, some other pragmatic things, and it works pretty well, very quickly.
It's the only tech I will actively evangelize as being 'the thing you need if you use JS' type thing.
> It's well know that if you start using C# , your entire stack will generally be MS based...(SQL Server, Azure etc... )
Why the fuck...?
I love using Linux+PostgreSQL with F#, and deploying to AWS.
> 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.
Disagree. After doing JS & Java & C# & Perl & F# & TS (& a bit of others such as C, C++, Python), I think TS is just a giant patch to a language that is broken by design. And a patch is just a patch. Just fucking migrate to a decent language already! (e.g. F# or Rust)
From my point of view, they have just great integration together, but but nothing really forces you to use them.
Original post sounded like you are being forced into it.
They wrote: "The TypeScript compiler could theoretically perform bundle optimizations based on types and you are missing on that by having a separate emitter and type checker."
Actually, this isn't true, and it's a fundamental property of TypeScript. It's actually the secret to being a TypeScript wizard, and the more you internalize it, the more questions about TypeScript you can answer in advance. I go through some others here: http://neugierig.org/software/blog/2016/04/typescript-types....
It's an important property in part for exactly the reasons this author worries about it -- it preserves the property always safe to type check and emit separately.
It's so fundamental to TS that their bug tracker, when reporting a bug, has a checkbox about whether your request violates this property, and if so they will discard your bug.
It's really the most important feature/aspect of TypeScript -- the fact that it's just a type-checking veneer on top of JavaScript.
It's not its own language like Dart or the myriad of languages (Reason, PureScript, etc.) that transpiled to JavaScript. It's not just that its types are erased at runtime, as you point out; there are many nuances caused by the fact that it's a superset of JS.
While I think TypeScript is the best we have right now, I'm also a bit sad that we need to endure this kind of compromise. Maybe once Wasm because widely supported we can finally cast away the JS legacy and begin anew.
Even though I'm a huge TypeScript fan, I'm grateful for the existence of Flow.
Their focus on soundness has shown the TypeScript team that they should give a lot more priority to getting the typesystem in a better shape over the years. If Flow didn't exist, I doubt we'd be seeing many of the features in TypeScript's --strict mode.
Plus, they were the first to develop some features like intersection types, or even some of the advanced type transformations. Shame it was (at least historically) a bit difficult to find them in the docs.
I'm hoping Flow can push TS to close up the remaining soundness gaps, and fix up some of their features (sealed vs open types is much better than the strange object literal checks in TS)
It's amazing to me watching Typescript and Flow and the choices they make.
From an actual typing standpoint, I MUCH prefer Flow. The soundness guarantees were traditionally much nicer, and the inference it does made some things MUCH simpler (I was able to create a typedef for the react-redux connect function that made it so you could use an entirely un-typed `mapStateToProps` function, and it would infer the types from the reducers as the prop types automatically. It was amazing reducing the amount of code/types needed for each component, and it still gave us intellisense-style hover tips in our editors for what the actual types of each prop were.).
But at the same time, the tooling in the Flow world has always been MUCH worse. I found countless bugs on my own just with what I felt was pretty normal usage, there were many workarounds and issues on windows that were needed, flow-typed is an embarrassment compared to the @types org that typescript uses now, and there are so many weird options and settings that you can use in a `.flowconfig` file that are completely undocumented, deprecated but not documented somewhere, or are facebook-internal or meant to be used with metro (the react-native bundler) only or something.
I love flow, and I still greatly prefer the model they use over that of Typescripts in many ways, but at the end of the day Typescript is winning the tooling fight, and that tooling is bringing many people over. "Imperfect" types that work consistently are better than "perfect" types that are flakey or difficult to use because of the tooling.
I actually think TS team is much closer to the community than Flow's. Just look at the number of open and closed Issues on GitHub.
To me, Flow feels like something they needed in Facebook and they happened to open source. Their main focus is still FB's internal use and the direction is set by it.
TypeScript, on the other hand, does not feel like this at all. They truly put the community first, or so I - and many others - feel like.
Are there any people that have switched to TypeScript that still think dynamically typed languages have advantages over statically typed ones? Even for small projects with only me working on them, I find static typing saves me a ton of time and dynamic features are very rarely required or useful. The vast majority of bugs in my TypeScript programs collect around the places they interface with untyped JavaScript code.
I bounce back and forth between TypeScript and Clojure. I've been keeping a close eye on Clojure's upcoming spec as it seems to be a nice opt-in, run-time type-checking solution. I like the flexibility and quickness with which dynamic languages let me iterate, but I want the safety. I want at least some of the benefits of both.
So yes, they (dynamically typed languages) have some advantages. Sometimes when I'm iterating quickly, especially on new projects, I don't want to fight with the compiler. BUT, I vastly prefer TypeScript to JavaScript because JS has a lot of foot-guns. I think when we get the existential operator, it will have less foot-guns, but I will probably never again write a new project for work in JS from scratch.
The ability to spec out the shape of an object, and then in the different contexts in which you need some of that data, specify what you need, is an awesome solution to optionality (Watch the talk!). I absolutely love how much thought RH has put into the design of Clojure, and I think the final release of spec will be a close to perfect balance of dynamism and opt-in safety.
Of course, TS is a superset of JS, so adopting it little by little sorta gets me that balance I want.
> The ability to spec out the shape of an object, and then in the different contexts in which you need some of that data, specify what you need, is an awesome solution to optionality
You realise you can do the same thing in TS with its structural type system?
Regarding Typescript specifically, I'm a bit torn.
I used to be excited about it but after a while of using it I see it more like a tool to migrate existing JS code or to interface with existing libraries written in JS, and not like an ideal tool to write code from scratch.
The reason is, the type system is actually incredibly complicated (to accommodate to all sorts of silly and messy things you can actually do in JavaScript).
I'd prefer using a more principled language for brand new projects. Which language is that? I'm not sure yet, but dynamic vs typed doesn't seem as important to me. I think ClojureScript is a better language than TS. Kotlin/JS also looks good, for a less "alien" language that is still better typed than JS/TS. But I don't have experience working on medium/big projects with these yet.
OTOH, for browser apps, the main plus for TypeScript is that if you pick a subset, ala C++, you get an OK language that never gets too far away from what you actually get when you convert the app to JS, so easier to debug and sometimes reason about.
> The reason is, the type system is actually incredibly complicated (to accommodate to all sorts of silly and messy things you can actually do in JavaScript).
Can you give some examples?
I have a feeling if you need that, you are writing some complicated magic code, but I might be wrong.
Does TypeScript let you build a program interactively as a living thing? Example of what dynamic languages for the browser (ClojureScript) have been doing for 5 years now: https://www.youtube.com/watch?v=KZjFVdU8VLI Given that frontend work is so often an endless series of tweaks I don't know how people stand doing anything big for a long duration the classic way of edit -> compile (refresh) -> rebuild runtime state to look at what changed/play around/test -> repeat.
Typescript can be indeed run directly inside the browser, though that's often not recommended, and none of the currently recommended "Hot Module Reloading" tools that I know of take that approach.
Most of the HMR tools out there support Typescript in some way directly or indirectly (Typescript plugins for webpack, etc).
`tsc --watch` is quite handy and useful in those situations where an HMR tool doesn't support Typescript or you aren't using an HMR tool at all. (For instance, on one project recently I've been just using npm package `lite-server` which implements "BrowserSync" automatic reload and `tsc --watch`, because I currently don't need a full bundler like webpack, though I expect that to change soon.)
Over the past year I converted 50k loc language beautifier to Typescript. The Typescript compile time is about 5 seconds give or take half a second, which is about 99% of my total build time.
I have a tool I developed that is a combination of a web server and web sockets that automatically rebuild and refresh the browser when a code file is saved.
the problem with most static typed languages is that the type systems are just not very flexible. Typescript union types are 10x more useful than Haskell's `Either` type, and you can build extremely complex type signatures that let you build clean APIs just from that.
Static typing is nice when the tools given actually let you build nice APIs
Good thing about TS is that it's currently an evolving language and if you have problems with the typing system, there's a good chance it will be improved instead of other languages where it might not pick the improvement up quickly which makes you feel like the language is at a dead end.
I use Flow at work, and have plenty of experience with both statically-typed and dynamically-typed languages. I think it's a simple tradeoff- more certainty for more toil.
It can be a real chore convincing Flow that working code works, and this can force you to use less-readable idioms to make the typechecker happy. It also lards up your code with extra dollar signs, angle brackets, and other crud, making it less readable.
These can be acceptable costs depending on your project, particularly the size of it (in lines of code, components, number of engineers, however you care to count).
function f(leaves: Array<Leaf>, aggregators: Array<Aggregator>): Array<MemsqlNode> {
// The next line errors because you cannot concat aggregators to leaves.
return leaves.concat(aggregators);
}
That's just wrong, of course you can't concat aggregators and leaves! and Typescript is OK to not accept it. If you want that to be ok, you could do something like
> We converted a codebase that was adapted to Flow to TypeScript. This means that we obviously only found things that Flow can express but TypeScript can't. If the port had been the other way around, I'm sure we would have found things that TypeScript can infer/express better than Flow.
So he's aware of the conundrum, and, I hope, his readers too.
Concat doesn't mutate the original array, so there is no reason the output has to have the same value as the original array. Typescript has chosen to implement it this way, but it's not a limitation of the underlying JS method. Saying it's wrong because it's how Typescript has typed the function is circular reasoning.
Consider the same functionality exposed as a function, it would seem be fine to type this as:
function concat(a: Array<A>, b: Array<B>): Array<A | B> { }
Author here. I understand this example may be a little controversial. However, from my point of view, if I annotate my function as returning an `Array<MemsqlNode>` and `leaves.concat(aggregators)` can be cast to `Array<MemsqlNode>`, then I don't see why I shouldn't be able to return this in this function without verbose syntax or "tricks".
it's not a trick. Yes, it can be casted, but you should be explicit about it. AFAIK, the signature for the concat function is dependent on the array you're using it, so in this case, it's Array<Leaves>. Even though concat returns a new array, it is expecting the arguments to be of similar type. That's a "safe" behavior and something I would expect. Auto-casting to the return type (in this case) is something that I would not expect to happen, as it could be the source of errors.
Doing [].concat(Array<A>, Array<B>) is fine, because you did not specify the type of the array for the literal [], it's not a trick, in that case the type should be Array<any>, but it's casted to Array<MemsqlNode>.
No, because JS concat is an in place operation, Typescript models it as Array<T>.concat() (intentionally leaves it "narrow") rather than Array<T>.concat<U extends T>(). In this case it is the input type that potentially would need to change so that the left hand side was Array<Leaf | Aggregator>.
Or as others point out, array spread does widen unlike concat (because it isn't an in-place operation).
What about the speed of type-checking? Flow is near-instant by keeping everything live from the last check whereas TypeScript has always been much slower.
Other than that aspect (which is very important!) I do think TypeScript is likely a better choice if you use any third party libraries that already have definitions available.
I work exclusively in VS Code with TypeScript. It is very fast after it first parses the project which isn't instant, but I often use the AWS SDK and some other packages with very large type surfaces. I'm not sure how fine grain it gets with caching, but it feels like it at most only ever needs to re-evaluate the file you are editing and this is practically unnoticeable to me.
> unfortunately when you share a TypeScript playground link, those settings are not saved in the URL. For this reason, you have to manually set them when you open any TypeScript playground link from this article.
There is a much better typescript playground[0] that supports all options in the permalink, for example see this link[1] that has `removeComments` enabled.
I have been using Ramda’s R.partial() function a bit, as well as some in-house stuff (e.g. - to generate 0-arity event handlers), but this would be a very helpful feature, particularly once IDE recognition becomes widespread.
Background: suite of related projects started in early 2015, ES5 on IE11 kind of limitations... (recently started using a transpiler for syntactic sugar)
Readit News
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...
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.
Agreed. And when you compare how TS was designed to how other languages were designed, it makes a lot of sense why TS ended up being such a great language.
Unlike virtually every other language in existence, TS was not designed from the ground up. It was designed with a very specific goal in mind: to adhere to the standards that JS developers had already converged on. So when a JS developer said if (foo), TS was built to realize that was an implicit type check against null. When a JS developer said if (obj.type === “bar”), TS read that as a way to ensure obj was in fact a bar.
It’s unlikely that a language developer working from scratch would have come up with these odd idioms, let alone prioritized their inclusion into a new language. But in the case of TS, all these idioms came from millions of lines of working code.
I think that’s why TS feels so enjoyable and easy to work with nowadays, whereas even the best of other languages feel a little clunky at times. It was developed prioritizing making real actual code idioms people wanted to do work.
Part of me would love for TS to build one out and add shims as part of the transpilation process, but it would go miles out of the scope of what TS is trying to do. And I love that (compared to Babel) TS has no plugins and relatively few options.
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.
It so turns out that there is a great sweet spot in between the straight jacket typing of classic Java/C# and the loose "do way ever you like" approach in Python/JS.
I don't want use another language that doesn't have optional typing and structural typing. It combines the best of both ends of the spectrum.
Have you tried using type hints (https://www.python.org/dev/peps/pep-0484/) with mypy?
I'd be willing to say it's actually the "heart" of the new MS. Eliminating the incentive to selling OS licenses is doing marvels for them.
Microsoft might seem to be an "open source champion" now, but remember that it is a publicly traded corporation with a fiduciary responsibility to maximize profits for its shareholders and a history of anti-competitive, anti-consumer practices.
Right now they are being warm and fuzzy to regain the developer mind-share they have lost over the past couple decades to open-source software. If they get a large percentage of developers using their tools and services (looking at you GitHub) I would not trust that they will continue to be so warm and fuzzy.
https://www.youtube.com/watch?v=Vhh_GeBPOhs
Granted, they weren't releasing much open source then, but it was all free to use, and the quality was far above open source alternatives (e.g. think the Visual Studio debugger vs. GDB wrappers).
I think they just naturally figured out that there's zero advantage to keeping developer tools closed source.
And yeah, Azure is a booming business for them. VSCode has a bunch of first-party extensions that reduce friction for working on their platform.
Trying to work with other databases after using SQL Studio is incredibly frustrating
https://en.wikipedia.org/wiki/Visual_J%2B%2B
Microsoft does the same thing over and over - "embrace" a technology, "extend" it by adding some extra stuff to it that happens to work best on Windows then "extinguish" the tech once people are locked in.
Also see: Internet Explorer or Kerberos or Office document interoperability or AIM (messenger) or half a dozen other things.
It's funny because I remember when Angular 2 was announced and that it would be written completely in TypeScript, they copped a lot of backlash for it, but it appears to have been a good move.
I exclusively have been writing in TypeScript for about 3 years now and it's crazy how good it actually is, especially for distributed teams in different time zones. The code is self-documenting and the number of silly mistakes being committed into our codebase has dramatically been reduced, combined with solid unit tests, we haven't really had a code level bug in what feels like months, browser bugs on the other hand...
My favourite thing about TS besides the types and interfaces is the compiler. I no longer have to use transpilers like Babel anymore because TypeScript handles compiling to many different module formats and targets. Back when I used Babel, it felt like pulling teeth because of the different plugins and packages you had to install and configure to use.
I find it really hard to use anything other than TypeScript now, it is simply too good.
I've ported code from JS to Flow and could say the benefits are similar to those of porting from JS to TS.
The most relevant part in this article IMHO is the conclusion:
> things like a strong community and availability of type definitions are more important because weak type inference can be solved by "handholding" the type checker a bit more.
I think it's important to highlight that this may be true of his project but not necessarily yours or mine.
Flow's type inference provides a much deeper level of confidence than TS with far less effort, for example, typing only the public interface of a module is often enough to surface type mismatch errors several functions deep within the module. In TS, you'd have to type every function signature to get the same level of confidence.
What worries me about flow is reflected in the comment from the facebook engineer linked from the article: it seems the flow team is focusing heavily on facebook-scale performance at the expense of most every other aspect of the project. A while back, the existential operator was quietly deprecated in the name of perf, and lately some updates have been of questionable soundness, e.g.
https://flow.org/try/#0GYVwdgxgLglg9mABAdxFAFAQwFyIPIBGAVgKb... (compared to http://www.typescriptlang.org/play/#src=function%20wut(a%3A%... )
I don't disagree, but isn't this the point? That by typing every function you can reliably have confidence in parameter types and return value types, and if your program is able to throw a type error on build, then it should and alert the developer that they're not logically correct in their implementation.
TypeScript is, by far, my favorite type system. I love structural typing. I love conditional types (ReturnType<T>). I love things like `keyof T`. I love how good it's inference system is. I love how I can still use it in a JS file and still get type checking with JSDoc.
I tried out Dart over the holidays and it felt like a major step backwards. Seriously, hats off to the developers.
I can completely relate. To me the greatest thing is the tooling around it. Using tide[0] on even plain js codebase is just amazing.
I really wish ruby had a TypeRuby compiler (to regular ruby). I know about crystal, but I still want regular Ruby, just with a type checker at compile time, not runtime.
[0]: https://github.com/ananthakumaran/tide
That’s only because of Microsoft fanboys nowadays, .NET core is a pleasure to use on Linux and AWS with a variety of databases etc
In 2014, well before Microsoft's dotnetcore oss adventure, I ran the dev team at a startup. Our entire backend was C#. Our devs used the OS of their preference, and so we had Mac, Windows and Linux. Xamarin Studio is (was?) a remarkably decent IDE for something so niche.
We hosted it in Docker (bad call, it was way too new then) on Mono (great call, it Just Worked), on Linux. Data in Postgres. All of this was as easy as doing the same with eg JS or Java (and arguably easier than eg Ruby because C# has a proper cross platform dependency story).
There's nothing about C# that forces you to use SQL Server or Azure. Absolutely nothing.
This is very not true. For the past 2 years or so of using C# I never used MSSQL, Azure or even Windows.
It may be "well know" but it's entirely untrue.
No transpiration needed for node modules. No source maps, it’s same old plain JS that’s nicely checked by typescript.
It was such a big jump, after 8 months of it now. I am so much more productive than I was before. It's just not funny.
If I did the same as you. Going from JS to TS, what kind of experience (from there on in) should I be looking at?
Also, code is much more manageable, and refactoring is tons easier.
With enough Babel plugins, you can get ESNext functionality that does whatever you want (some of those early stage proposals are really cool! They might go away tomorrow, but hey, so cool!), so Typescript's old advantage of offering more language features is kinda nullified.
In the end, I started writing the later part of my current project in Typescript, and I much more enjoy working on that part of the code than the earlier parts.
Stick to the 'basics' of TS, which are super general programming syntax structures and idioms - there's really nothing new you'll come across (maybe unions?) - so it's easy.
Then you can try some of the trickier things but frankly we don't use them that much.
You'll be up and running pretty quickly because you can mix your 'new' TS modules with old-school JS code no problem.
And then go from there.
I like TS because it's not some big new fancy paradigm shift: it's just typing, some other pragmatic things, and it works pretty well, very quickly.
It's the only tech I will actively evangelize as being 'the thing you need if you use JS' type thing.
Deleted Comment
Why the fuck...?
I love using Linux+PostgreSQL with F#, and deploying to AWS.
> 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.
Disagree. After doing JS & Java & C# & Perl & F# & TS (& a bit of others such as C, C++, Python), I think TS is just a giant patch to a language that is broken by design. And a patch is just a patch. Just fucking migrate to a decent language already! (e.g. F# or Rust)
Dead Comment
Actually, this isn't true, and it's a fundamental property of TypeScript. It's actually the secret to being a TypeScript wizard, and the more you internalize it, the more questions about TypeScript you can answer in advance. I go through some others here: http://neugierig.org/software/blog/2016/04/typescript-types....
It's an important property in part for exactly the reasons this author worries about it -- it preserves the property always safe to type check and emit separately.
It's so fundamental to TS that their bug tracker, when reporting a bug, has a checkbox about whether your request violates this property, and if so they will discard your bug.
It's not its own language like Dart or the myriad of languages (Reason, PureScript, etc.) that transpiled to JavaScript. It's not just that its types are erased at runtime, as you point out; there are many nuances caused by the fact that it's a superset of JS.
While I think TypeScript is the best we have right now, I'm also a bit sad that we need to endure this kind of compromise. Maybe once Wasm because widely supported we can finally cast away the JS legacy and begin anew.
EDIT: This is incorrect ^, I misread your comment at first.
Thank you for bringing this up, this makes me feel even better about using Babel to emit code.
I vaguely recall there was some issue with the Babel emit of enums, but I can't remember it well enough to even remember whether it was fixed or not.
Their focus on soundness has shown the TypeScript team that they should give a lot more priority to getting the typesystem in a better shape over the years. If Flow didn't exist, I doubt we'd be seeing many of the features in TypeScript's --strict mode.
Plus, they were the first to develop some features like intersection types, or even some of the advanced type transformations. Shame it was (at least historically) a bit difficult to find them in the docs.
I'm hoping Flow can push TS to close up the remaining soundness gaps, and fix up some of their features (sealed vs open types is much better than the strange object literal checks in TS)
I really would hate for Facebook to kill off flow because Typescript is popular.
Microsoft, as great as they are at OSS, they still have to answer to a chain of Managers who are distant from the actual users of their software.
From an actual typing standpoint, I MUCH prefer Flow. The soundness guarantees were traditionally much nicer, and the inference it does made some things MUCH simpler (I was able to create a typedef for the react-redux connect function that made it so you could use an entirely un-typed `mapStateToProps` function, and it would infer the types from the reducers as the prop types automatically. It was amazing reducing the amount of code/types needed for each component, and it still gave us intellisense-style hover tips in our editors for what the actual types of each prop were.).
But at the same time, the tooling in the Flow world has always been MUCH worse. I found countless bugs on my own just with what I felt was pretty normal usage, there were many workarounds and issues on windows that were needed, flow-typed is an embarrassment compared to the @types org that typescript uses now, and there are so many weird options and settings that you can use in a `.flowconfig` file that are completely undocumented, deprecated but not documented somewhere, or are facebook-internal or meant to be used with metro (the react-native bundler) only or something.
I love flow, and I still greatly prefer the model they use over that of Typescripts in many ways, but at the end of the day Typescript is winning the tooling fight, and that tooling is bringing many people over. "Imperfect" types that work consistently are better than "perfect" types that are flakey or difficult to use because of the tooling.
To me, Flow feels like something they needed in Facebook and they happened to open source. Their main focus is still FB's internal use and the direction is set by it.
TypeScript, on the other hand, does not feel like this at all. They truly put the community first, or so I - and many others - feel like.
Just a few years ago, that would have been a laugh. Don’t get me wrong, I love the world we’re living in :)
So yes, they (dynamically typed languages) have some advantages. Sometimes when I'm iterating quickly, especially on new projects, I don't want to fight with the compiler. BUT, I vastly prefer TypeScript to JavaScript because JS has a lot of foot-guns. I think when we get the existential operator, it will have less foot-guns, but I will probably never again write a new project for work in JS from scratch.
I really love the ideas Rich Hickey put forth in his most recent Clojure conj talk: https://www.youtube.com/watch?v=YR5WdGrpoug
The ability to spec out the shape of an object, and then in the different contexts in which you need some of that data, specify what you need, is an awesome solution to optionality (Watch the talk!). I absolutely love how much thought RH has put into the design of Clojure, and I think the final release of spec will be a close to perfect balance of dynamism and opt-in safety.
Of course, TS is a superset of JS, so adopting it little by little sorta gets me that balance I want.
The only time you're ever fighting the compiler in a modern statically typed languages with type inference is when you've made a mistake.
You realise you can do the same thing in TS with its structural type system?
I used to be excited about it but after a while of using it I see it more like a tool to migrate existing JS code or to interface with existing libraries written in JS, and not like an ideal tool to write code from scratch.
The reason is, the type system is actually incredibly complicated (to accommodate to all sorts of silly and messy things you can actually do in JavaScript).
I'd prefer using a more principled language for brand new projects. Which language is that? I'm not sure yet, but dynamic vs typed doesn't seem as important to me. I think ClojureScript is a better language than TS. Kotlin/JS also looks good, for a less "alien" language that is still better typed than JS/TS. But I don't have experience working on medium/big projects with these yet.
OTOH, for browser apps, the main plus for TypeScript is that if you pick a subset, ala C++, you get an OK language that never gets too far away from what you actually get when you convert the app to JS, so easier to debug and sometimes reason about.
So there you have it... I'm torn :-)
Can you give some examples?
I have a feeling if you need that, you are writing some complicated magic code, but I might be wrong.
Most of the HMR tools out there support Typescript in some way directly or indirectly (Typescript plugins for webpack, etc).
`tsc --watch` is quite handy and useful in those situations where an HMR tool doesn't support Typescript or you aren't using an HMR tool at all. (For instance, on one project recently I've been just using npm package `lite-server` which implements "BrowserSync" automatic reload and `tsc --watch`, because I currently don't need a full bundler like webpack, though I expect that to change soon.)
I have a tool I developed that is a combination of a web server and web sockets that automatically rebuild and refresh the browser when a code file is saved.
Static typing is nice when the tools given actually let you build nice APIs
Some people can’t seem to function without static (global?) types though, and this works for them.
It can be a real chore convincing Flow that working code works, and this can force you to use less-readable idioms to make the typechecker happy. It also lards up your code with extra dollar signs, angle brackets, and other crud, making it less readable.
These can be acceptable costs depending on your project, particularly the size of it (in lines of code, components, number of engineers, however you care to count).
> We converted a codebase that was adapted to Flow to TypeScript. This means that we obviously only found things that Flow can express but TypeScript can't. If the port had been the other way around, I'm sure we would have found things that TypeScript can infer/express better than Flow.
So he's aware of the conundrum, and, I hope, his readers too.
Consider the same functionality exposed as a function, it would seem be fine to type this as:
Doing [].concat(Array<A>, Array<B>) is fine, because you did not specify the type of the array for the literal [], it's not a trick, in that case the type should be Array<any>, but it's casted to Array<MemsqlNode>.
Or as others point out, array spread does widen unlike concat (because it isn't an in-place operation).
Other than that aspect (which is very important!) I do think TypeScript is likely a better choice if you use any third party libraries that already have definitions available.
There is a much better typescript playground[0] that supports all options in the permalink, for example see this link[1] that has `removeComments` enabled.
[0]: https://typescript-play.js.org
[1]: https://typescript-play.js.org/?removeComments=true#code/PTA...
https://agentcooper.github.io/typescript-play/
[0]: https://github.com/agentcooper/typescript-play/pull/24
Actually, I’ve moved away from OOP in general in my JavaScript, only as a last resort. (Not going to put in long comment from tablet screen...)
That said, there is a Stage 1 TC39 proposal for partial application. https://github.com/tc39/proposal-partial-application
I have been using Ramda’s R.partial() function a bit, as well as some in-house stuff (e.g. - to generate 0-arity event handlers), but this would be a very helpful feature, particularly once IDE recognition becomes widespread.
Background: suite of related projects started in early 2015, ES5 on IE11 kind of limitations... (recently started using a transpiler for syntactic sugar)