JavaScript Might Get Type Annotations: ECMAScript Proposal

preview_player
Показать описание
In this video I talk about the recent ECMAScript proposal to introduce type annotations in JavaScript.

Contact:

#JavaScript #ECMAScript
Рекомендации по теме
Комментарии
Автор

Static types / type checking is certainly the right direction .. however, I think most people who's used languages with good type systems would agree that sound type system and type inference would be much preferred.. and that can't happen while keeping the whole javascript (too many untypable APIs). I'd like things to move towards taking a well-typed subset of javascript and building from there.. ATM ReScript is one of the best options if you want something like that..

digitalspecter
Автор

While I do agree with the premise that Javascript is just hard to deal with and that inventing a whole new superset of a language named typescript with a compiler to fix it is overblown. However, I do not think that adding some pseudo syntax to the language to help the IDE to figure out what's going on is the best way to go about it.

Firstly, as a PHP developer who has worked with legacy applications which only have types commented on the function I can tell you: Type comments are just lies waiting to happen. The problem is: If the types aren't checked in any place then it's really easy to change the function and forget to change the return type. This sounds like a small problem, it's just one function. No, the problem starts when you use that function. Because then the code building on that function will also have wrong types. On the other hand the developer might also feel some false confidence and not check if the types are actually correct and just blindly trusting what the IDE is telling them.

Secondly, as soon as I hear: "The code is there but it doesn't get executed" alarm bells go off. Again in dynamic languages where you don't have a compilation of code to check if the code is "correct". And code that isn't executed (like in tests for example) is not proven to work. For type information this means: type info that isn't checked anywhere isn't correct. (I know it's a pessimistic approach, but in general true). And if you have a program to check your types at time of writing the code, then you still effectively have a compile time, only that you don't spend time producing new code but rather checking the existing code.

Thirdly, in the presentation where this proposal was shown there was an argument which I was baffled by. They said that for new developers, it would be confusing because most of the code we write today is typescript and when newbies try out typescript in the Javascript console it wouldn't work. Well, the same argument you can make for C++ and C. Just cause they are related doesn't mean that they support the same things and I would argue that with this new syntax it would be harder to distinguish typescript and Javascript.

All in all if you want to have type HINTS (because you still need some process to check them) in your code just use jsdoc-comments. Because essentially that's all this new syntax is a way to hide the doc comments as something that looks like "real" executed code.

mamazu