I disagree. Perhaps I am in the minority on this, I don't know. I care about types and don't care about intellisence. I write lots of atomic algorithms that are super-independent, independent of each other but also compensating for the changes by each other, and make heavy use of scope. It is very important to my code that things execute efficiently and accurately.
TypeScript's strict types will see the error if the those are not the same data type. A TypeScript aware editor will yell at me before I compile the code. Perhaps what I really wanted is:
props.removes[cc][0] !== props.last.margin
In JavaScript I would have to execute the code. If the code doesn't throw an error then I would have to examine the output to see if the resulting data structure matches what I expect. If not I have to run tests and track down the error. Then once the error is found and resolved I have to write unit tests for this scenario.
You can use an auto-generated intermediate format when running the tests, that check each member object, give test coverage, etc. Eg. a tool that parses the code and inserts a bunch of checks above each member access. So you start with plain JavaScript, and you ship plain JavaScript.
JavaScript will always convert a value to a type. It's dynamic, but very strongly typed. JavaScript engines do not care about type annotations, only TypeScript does. You might have annotated something as a number, but the JavaScript engine might chose to convert it to a string ... I think type annotations is a unnecessary chore, and that types should be inferred.
Type annotations does not replace proper documentation. And with properly named parameters the annotations are not needed.
It's also a convention among JavaScript programmers that each function should not only check the parameters, but also convert them, so you can leave out optional arguments, pass a notated object {foo: "bar"}, or pass a string and have the function convert it to an array so you can write foo(bar) instead of foo([bar]) when calling the function. Or convert an object if it's not of the correct instance.
This is more fun then annotating types and having a compiler shout out weird errors at you.
TypeScript is already good at inferring the types, so you can get suggestions on unannotated code, but I think TypeScript should get even better at inferring by getting closer to what a JS engine do and closer to the JS spec (eg. get rid of the type annotations)
I'm not sure I agree with the quantity "most", but clearly the Typescript team also cares about the people that don't need/want types, but do care about smart intellisense and detecting basic errors. A large part of this roadmap directly deals with that directly, because Typescript is powering more and more JS experiences in editors. The most direct section on this in the roadmap is the one titled: "JavaScript: TypeScript beyond TypeScript". But also a good majority of the "Developer productivity tools and integration" directly or indirectly involves both JS without types and TS with types.
If you use Atom or VSCode or any of the other growing number of editors that use Typescript to power their JavaScript/ECMAScript experiences, this Roadmap should help reassure you that the team still has you in mind and wants you to be happy.
(One of the interesting parts here is the reveal that Typescript is moving to use ESLint everywhere instead of TSLint. It's an interesting investment into the lint experience across the board for both JS and TS.)
I dream about typescript becoming statically compiled language. Or hybrid language similar to dart and flutter, which in dev mode is interpreted for fast reload times and in production it gets compiled to native code.
17 comments
[ 3.5 ms ] story [ 46.0 ms ] threadconst sum = (number, number) => number+number
Where type annotations becomes unnecessary verbose.
It's also a convention among JavaScript programmers that each function should not only check the parameters, but also convert them, so you can leave out optional arguments, pass a notated object {foo: "bar"}, or pass a string and have the function convert it to an array so you can write foo(bar) instead of foo([bar]) when calling the function. Or convert an object if it's not of the correct instance. This is more fun then annotating types and having a compiler shout out weird errors at you.
If you use Atom or VSCode or any of the other growing number of editors that use Typescript to power their JavaScript/ECMAScript experiences, this Roadmap should help reassure you that the team still has you in mind and wants you to be happy.
(One of the interesting parts here is the reveal that Typescript is moving to use ESLint everywhere instead of TSLint. It's an interesting investment into the lint experience across the board for both JS and TS.)