Maybe TypeScript will turn out to have more staying power, but my current guess is that something will happen that makes another technology -- probably WebAssembly -- very popular in the next few years and that will kill off a lot of the hype around TypeScript. Then that will itself mostly get killed off by some other technology about 3~5 years after it hits peak popularity, and so on...
I could be completely wrong though, of course! Predicting the future is hard. This is just my guess based on handwavey recollection of the last decade and a half of web trends.
It has a powerful type inference system that puts C# to shame in places, and in some places I prefer TS to C#.
I don't feel like Typescript is 'hyped'. It is popular because it's damn good. As a programming language alone it could be seen as not too special, but when you see what it's trying to do, get JS developers to use types and not run a mile, then it does a brilliant job.
Hmm, the biggest problem with JS is types? Are you sure? I rarely had issues with types in JS. With JS I just used my trusty dynamic type checker at specific places in the codebase, and testing coverage of course even more importantly.
But with TS, the codebases I see on a daily base are mostly a terrible mess of wrong ideas, wrong libraries, wrong constructs, wrong design principles, tooling hell, etc, etc.. Which is IMHO the real issue with JS/TS. For some reason TS proponents seem to live in a world where 'TS solves everything'.
For me TS is just writing 20% more code and regularly needing to use the 'any' keyword to avoid spending hours on getting a basic line of code working. Everything I write non-professionally is not TS, I cannot think of 1 single reason to give myself that burden.
The best thing TS has given me is even more jobs. With Agile front-end developers spend at least 1 day a week in the meeting room, now with TS they spend 20% of their time left to hassling with types. It's hilarious. Especially all those managers that have no clue what's going on, why front-end development gets slower and slower.
They are things as different as that you can actually have type problems only in a really typed system (as a static type system). Javascript has a very weak type system, and that's the problem. I think you do not understand that static typing serves to solve other problems in the code, not to solve type problems ... it would be like saying that an hypothetical language needs functions to solve function problems ... and then you say that you never had problems with functions in that hypothetical language (ex: assembler, with very primitives "functions", where you have to save data in register before jumping to code in another memory address).
But so many TypeScript fans act as if having types is the be-all and end-all.
And, unless I’m mistaken and something has changed recently, I often wonder how many of the TypeScript proponents don’t realize that they’re mostly only getting compile time type checking since the compiler strips away the types after TypeScript gets compiled down to Javascript.
Don’t get me wrong; TypeScript is great. But I don’t see it as the savior that others make it out to be.
Surely the biggest benefit from static typing is for static-analysis tooling. (e.g. strong compile-time checks).
Typescript has chosen to interop nicely with JS, and they took the tradeoff that if you are passed an object (e.g. from an Ajax request) and you assert that it's a Duck, TS will assume that is correct during static typing. Of course this might be wrong at runtime, you may get returned {'foo':1} instead of {'foo':'bar'} and your object.foo.length now returns undefined.
Static typing in general (in other languages) does persist into the lifetime of the application. By persist, I mean the guarantees persist, even if the types are thrown away. Haskell for example throws away the types at runtime (you can't reflect on them) but because it's so strict, you can be sure that X: String->String does indeed return a string. This you cannot be 100% sure of in Typescript.
So why is Typescript useful? Well if you write an entire app in TS (which I am doing now) then all the code you write ... which is the new non-battle-tested code ... is now type checked against itself. Also well written libraries using TS will be well type checked against. People doing stuff like casting to <any> etc. could break things for you. But in general you get Pareto's rule applied and because most of your code is type checked (and it only isn't when getting stuff from the server or using a dodgy library that has exported an incorrect .d.ts or something), then you get almost 100% of the benefit.
Basically am I getting errors due to incorrect types at runtime in Haskell? Never. Am I getting them in Typescript? Not yet but it's possible, maybe 0.1% chance?
Bad types at runtime: with a static type system you make the effort to be sure the code does what it says. With plain ol' JS you can get that confidence from tests. -- different trade-offs made each way.
But another benefit to static types is knowing the structure of the data you're dealing with and how to manipulate it, while you're developing/maintaining the code. -- sure: naming, unit tests, documentation etc. can help, but I find not having the static types handy makes things tricky when there's enough indirection/complexity.
As with the stuff about runtime errors, tastes vary, of course.
What I like most about static typing is tooling support for refactoring and how much easier it can be to change a name or significantly change internal apis and jig stuff around with confidence.
"Because JavaScript is the language of the web browser, and because the web browser has become the dominant application delivery system, and because JavaScript isn't too bad, JavaScript has become the World's Most Popular Programming Language. Its popularity is growing. It is now being embedded in other applications and contexts. JavaScript has become important. It is better to be lucky than smart."
TypeScript is a very smart language, but then, so are Dart, CoffeeScript, ClojureScript. I suspect that if code durability is what matters to you, JS (and the ES evolutions thereof) will have the real staying power. Plus, not everyone is sold on the value of static types, but everyone is sold on the value of JavaScript.
I'm hoping that when WASM matures a bit more, and becomes as universally supported in browsers as a javascript runtime, JS just becomes the default language supported by it, not the only one possible. Maybe one day it'll be common to see Typescript run directly in the browser, who knows?
>but everyone is sold on the value of JavaScript.
Not everyone[0].
Edit: Mea culpa. I got my numbers mixed up, or whatever source I thought I remembered just doesn’t exist. 46% in 2018 (state of js) says nothing about 2019, and is not a majority. That 46% is also backed up by a similar survey that npm ran. It’s worth adding though, I think, that js devs benefit from ts type inferencing and IDE support even if they aren’t using it directly
i like that qualification :)
most likely typescript is still a very small minority given how large the javascript world is
https://medium.com/javascript-scene/the-typescript-tax-132ff...
I use TypeScript. It's not all rosy.
I'm being flippant, but Typescript is quite popular, that's it, most people who write JS write JS.
TS is quite popular, but this cannot possibly be representative of the general population of js devs, not even close.
it's more like ES6 >> JSX >> TS >> Flow.
my assessment isn't what things compile to but what they are authored in.
To be clear there are a gazillion Js projects that don't use react.
to use javascript -- or say python -- in an corporate/enterprise environment, you need to analyze your code base. static analysis is what worked well and still does but you need types. ofc having types has other major benefits but this is the big one for me at least.