4 ms·
I'd be more optimistic about official type annotations for JavaScript if said typing was less like the particularly unique syntax of TypeScript and more like th
by ravenstine 5y ago
I'd be more optimistic about official type annotations for JavaScript if said typing was less like the particularly unique syntax of TypeScript and more like that which already exists in C-family languages. For instance, in Typescript, we can do this:
---
const user: User = {
...
};
---
Why couldn't this be more like C rather than this weird conflation with the existing colon token?
---
const User user = {
...
};
---
That might seem not as pleasing to those familiar with Typescript, but it's much closer to other existing syntaxes (meaning less of a learning curve coming from Java or C).
Same with function definitions:
---
function foo (bar: string, baz: boolean): Qux {
...
}
---
Versus:
---
Qux function foo (string bar, bool baz) {
...
}
---
I find the latter much more familiar than Typescript and less confusing. It's also slightly less verbose.
- kderbyma 5y agothen we would have another type system....no just stick with typescript or none at all...
- ravenstine 5y agoWell... yeah, I don't actually advocate for another type system, but more that if we have any type system at all for JavaScript then asking why we're going with one that overloads the colon token when it's already been sufficiently overloaded in the first place. Typescript already is what it is, and I think we should just stick with it, but if we are going to get yet another type annotation system then perhaps it might as well not be as novel as Typescript if there's a benefit.
- danielvaughn 5y agoYes exactly. There must be some good reason why TS chose the syntax they did, because a lot of it feels very old-school-java.
- stasm 5y agoType inference is one good reason. Similar syntax exists in a few modern languages, too: e.g. Rust and Swift. In languages with type inference it can be convenient that type annotations are in the postfix position relative to variable names: let user = new User(); let user: User = new User();
- seniorsassycat 5y ago: type syntax will be more familiar to rust, kotlin, and typescript devs. Why is c relevant? The name is usually more important than the type so I like that typescript puts it first.
- Etheryte 5y agoMy completely subjective guess is that it might be to avoid ambiguity around reserved keywords. For example, the `void` keyword [0]: void function () { return 42; }(); // returns undefined It's not something you would usually use in your code, but many Javascript minimizers make heavy use of it, and Typescript must know how to handle any valid Javascript without ambiguity. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/void https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- S1ngleM4lt 5y agoThat seems to be mostly just a matter of taste, but is definitely off putting when coming from other languages. Interestingly other recent languages like rust, zig, and go follow a similar convention to type script. Go has a brief explanation of why they went with this approach [0] so I’d be curious if other langs have documented their decisions. [0] https://go.dev/doc/faq#declarations_backwards https://go.dev/doc/faq#declarations_backwards
- deleted 5y ago[deleted]
- orif 5y agoActually, I would prefer a C/C++ dialect in TypeScript’s type notation. Parsing time/complexity would reduce drastically, and would allow type inference.
- jestar_jokin 5y agoAs you say, it's just a matter of familiarity. Sounds like you just need exposure to more programming languages/paradigms, as it's a pretty common convention. I believe it comes from the ML family. OCaml[0] springs to mind. As others have mentioned, Rust[1], Kotlin[2], Haxe[3], Nim[4], Swift[5], Elm[6], Dhall[7], and Scala[8] all use this convention. The current syntax seems better for type inference and gradual typing. [0] https://learnxinyminutes.com/docs/ocaml/ https://learnxinyminutes.com/docs/ocaml/ [1] https://learnxinyminutes.com/docs/rust/ https://learnxinyminutes.com/docs/rust/ [2] https://learnxinyminutes.com/docs/kotlin/ https://learnxinyminutes.com/docs/kotlin/ [3] https://learnxinyminutes.com/docs/haxe/ https://learnxinyminutes.com/docs/haxe/ [4] https://learnxinyminutes.com/docs/nim/ https://learnxinyminutes.com/docs/nim/ [5] https://learnxinyminutes.com/docs/swift/ https://learnxinyminutes.com/docs/swift/ [6] https://learnxinyminutes.com/docs/elm/ https://learnxinyminutes.com/docs/elm/ [7] https://learnxinyminutes.com/docs/dhall/ https://learnxinyminutes.com/docs/dhall/ [8] https://learnxinyminutes.com/docs/scala/ https://learnxinyminutes.com/docs/scala/