I read through (most of) this article earlier. I didn't realize just how much TypeScript added other than just "types". Some things I've actually longed for, like top-level await. Other things I...
I read through (most of) this article earlier. I didn't realize just how much TypeScript added other than just "types". Some things I've actually longed for, like top-level await. Other things I suspect I'd never use.
I guess it really does make more sense to think of TypeScript as its own language, rather than an addon to ECMAScript.
Top-level await is coming to ECMAScript. It's at Stage 3 now and has some preliminary support in Chrome. I don't think it makes sense to think of TS as its own language. It doesn't have its own...
Top-level await is coming to ECMAScript. It's at Stage 3 now and has some preliminary support in Chrome.
I don't think it makes sense to think of TS as its own language. It doesn't have its own runtime, for one. Other than types, the features it adds are essentially syntactic sugar and in-development ES proposals.
I know about Deno and am super fucking excited about it, but it's still (for now, at least) just running TS through a TS compiler into Javascript before executing it. It's still ends up as JS at...
I know about Deno and am super fucking excited about it, but it's still (for now, at least) just running TS through a TS compiler into Javascript before executing it. It's still ends up as JS at runtime.
That doesn't really matter. C# and F# are both dot net, yet you'd be hard pressed to call them the same. Java, Scala, clojure, and kotlin are all jvm, and yet no one calls them the same language...
I don't think it makes sense to think of TS as its own language. It doesn't have its own runtime, for one.
That doesn't really matter. C# and F# are both dot net, yet you'd be hard pressed to call them the same. Java, Scala, clojure, and kotlin are all jvm, and yet no one calls them the same language either.
In particular, Kotlin and Java have a similar relationship to TS and JS
On its own, maybe not, but I didn't say they're the "same language." TS just isn't it's "own" language separate from ES. I don't want to get into a semantics argument. Kotlin isn't transpiled into...
On its own, maybe not, but I didn't say they're the "same language." TS just isn't it's "own" language separate from ES. I don't want to get into a semantics argument.
Kotlin isn't transpiled into plain Java so I disagree that their relationship is similar to TS and JS. Kotlin and Java are compiled into the same intermediate representation, but in TS's case, JS is the intermediate representation. Kotlin requires a bundled runtime library. Typescript has tslib, but AFAIK it's sole purpose is supporting older ES targets.
I mean the whole thing about whether "TS is its own language" is a semantics argument. Personally, I would consider TS in the same realm as, say, ReasonML, and do consider both different...
I mean the whole thing about whether "TS is its own language" is a semantics argument. Personally, I would consider TS in the same realm as, say, ReasonML, and do consider both different languages. TS has certainly less changes than Reason, but it still is syntactically different than JS, like strict enforcement on ==.
Yeah, but the degree to which Typescript is separated from ECMAScript is what we're discussing, not what the words "its own language" mean. Maybe you know something I don't, but as far as I'm...
Yeah, but the degree to which Typescript is separated from ECMAScript is what we're discussing, not what the words "its own language" mean.
Maybe you know something I don't, but as far as I'm aware, the only syntactical differences TS has from JS (that aren't work-in-progress ES proposals) are the type annotations, which have zero effect on how the code works at runtime. I'm not sure what you're referring to about "strict enforcement on ==". TS warns if there's type discrepancies, but it doesn't change what the JS equality operators do. Maybe you're thinking of Coffeescript, which converts all ==s to ===s?
I know nothing about ReasonML, but I'll throw Dart in the conversation (pun not intended, I swear). It supports JS as a compilation target, but it's not a superset. Its syntax is fundamentally different, has no relevance to ES beyond implementation details that only the language designers need to be worried about, and requires a runtime to work. It also supports compilation targets other than Javascript. It is definitively "its own language." If all knowledge of Javascript was wiped from human memory, Dart could stand on its own. Typescript couldn't.
Let me ask this... do you consider ES2016 to be a different language than ES4? It is syntactically different.
I don't know if this is an active ES proposal, but TypeScript enums do not have an obvious translation into JavaScript. At least, it's not something I would come up with quickly. In...
I don't know if this is an active ES proposal, but TypeScript enums do not have an obvious translation into JavaScript. At least, it's not something I would come up with quickly.
In ReScript/BuckleScript/Reason, for the most part, primitive operations map very directly to JavaScript. By far the fanciest part of the compiler is variant types and pattern matching, where the compiler keeps track of the discriminant as part of the type of a value where possible, falling back to a JS object where necessary. In fact, None is encoded as JS undefined!
This is a little more complicated by the fact that the ReScript family is an evolution of OCaml syntax in the style of JavaScript. I like reading and writing OCaml, but RS has fixed some real syntactic problems, and in the process made the language read much more like JS. RS easily stands alone as a language, but it also literally wouldn't exist without the direct influence of JS.
Enums aren't an ES feature, true, but this is how they're compiled: enum Direction { Up, Down, Left, Right } var Direction; (function (Direction) { Direction[Direction["Up"] = 0] = "Up";...
Enums aren't an ES feature, true, but this is how they're compiled:
That's just a terse way of creating an object with entries so that enum members can be accessed by the key or the value. Nothing special about them.
Another similar TS feature that isn't an ES feature is namespaces, but like enums, TS is just creating objects and assigning things to it inside of a closure.
Right. If you ignore the typechecking part, nearly all of what Typescript compilation does to produce the output is just strip out all the type annotations from the code. function foo(x: number):...
Right. If you ignore the typechecking part, nearly all of what Typescript compilation does to produce the output is just strip out all the type annotations from the code. function foo(x: number): string { ... } becomes function foo(x) { ... }, etc. Typescript doesn't provide any heavy lifting to support features at runtime that don't exist in regular Javascript (except maybe in a few cases for backwards compatibility with older JS versions).
It looks like TypeScript and therefore VS Code is following a similar path to full-fledged IDE's like IntelliJ IDEA for Java. As projects get bigger, they get slower and then the tools need...
It looks like TypeScript and therefore VS Code is following a similar path to full-fledged IDE's like IntelliJ IDEA for Java. As projects get bigger, they get slower and then the tools need performance hacks, such as a partial editing mode at startup.
It's the cycle of life I guess. A new language comes along and all the tools need to be rewritten. The new tools need to do all the same things as the old tools did because the problems haven't gone away. But hopefully things are better after the rewrite, so there is some progress.
I think it's easy to misread what you said, so just to be clear: The partial editing mode wasn't added because VS Code got bigger and slower, it got added because VS Code's Typescript-related IDE...
I think it's easy to misread what you said, so just to be clear: The partial editing mode wasn't added because VS Code got bigger and slower, it got added because VS Code's Typescript-related IDE features were always slow to become usable on large projects that were opened inside of VS Code.
Yes, that's true. But I suspect it's also the case that as language ecosystems mature, average project size goes up, because projects tend to be older, people have written more code, and they've...
Yes, that's true. But I suspect it's also the case that as language ecosystems mature, average project size goes up, because projects tend to be older, people have written more code, and they've started using more dependencies. Tool vendors have to worry more about handling bigger projects.
If you're starting fresh then there's less to worry about. Other people have pushed the limits more than you.
I read through (most of) this article earlier. I didn't realize just how much TypeScript added other than just "types". Some things I've actually longed for, like top-level
await. Other things I suspect I'd never use.I guess it really does make more sense to think of TypeScript as its own language, rather than an addon to ECMAScript.
Top-level await is coming to ECMAScript. It's at Stage 3 now and has some preliminary support in Chrome.
I don't think it makes sense to think of TS as its own language. It doesn't have its own runtime, for one. Other than types, the features it adds are essentially syntactic sugar and in-development ES proposals.
May I introduce you to deno, the next generation JS/TS runtime?
I know about Deno and am super fucking excited about it, but it's still (for now, at least) just running TS through a TS compiler into Javascript before executing it. It's still ends up as JS at runtime.
That doesn't really matter. C# and F# are both dot net, yet you'd be hard pressed to call them the same. Java, Scala, clojure, and kotlin are all jvm, and yet no one calls them the same language either.
In particular, Kotlin and Java have a similar relationship to TS and JS
On its own, maybe not, but I didn't say they're the "same language." TS just isn't it's "own" language separate from ES. I don't want to get into a semantics argument.
Kotlin isn't transpiled into plain Java so I disagree that their relationship is similar to TS and JS. Kotlin and Java are compiled into the same intermediate representation, but in TS's case, JS is the intermediate representation. Kotlin requires a bundled runtime library. Typescript has
tslib, but AFAIK it's sole purpose is supporting older ES targets.I mean the whole thing about whether "TS is its own language" is a semantics argument. Personally, I would consider TS in the same realm as, say, ReasonML, and do consider both different languages. TS has certainly less changes than Reason, but it still is syntactically different than JS, like strict enforcement on ==.
Yeah, but the degree to which Typescript is separated from ECMAScript is what we're discussing, not what the words "its own language" mean.
Maybe you know something I don't, but as far as I'm aware, the only syntactical differences TS has from JS (that aren't work-in-progress ES proposals) are the type annotations, which have zero effect on how the code works at runtime. I'm not sure what you're referring to about "strict enforcement on ==". TS warns if there's type discrepancies, but it doesn't change what the JS equality operators do. Maybe you're thinking of Coffeescript, which converts all
==s to===s?I know nothing about ReasonML, but I'll throw Dart in the conversation (pun not intended, I swear). It supports JS as a compilation target, but it's not a superset. Its syntax is fundamentally different, has no relevance to ES beyond implementation details that only the language designers need to be worried about, and requires a runtime to work. It also supports compilation targets other than Javascript. It is definitively "its own language." If all knowledge of Javascript was wiped from human memory, Dart could stand on its own. Typescript couldn't.
Let me ask this... do you consider ES2016 to be a different language than ES4? It is syntactically different.
I don't know if this is an active ES proposal, but TypeScript enums do not have an obvious translation into JavaScript. At least, it's not something I would come up with quickly.
In ReScript/BuckleScript/Reason, for the most part, primitive operations map very directly to JavaScript. By far the fanciest part of the compiler is variant types and pattern matching, where the compiler keeps track of the discriminant as part of the type of a value where possible, falling back to a JS object where necessary. In fact,
Noneis encoded as JSundefined!This is a little more complicated by the fact that the ReScript family is an evolution of OCaml syntax in the style of JavaScript. I like reading and writing OCaml, but RS has fixed some real syntactic problems, and in the process made the language read much more like JS. RS easily stands alone as a language, but it also literally wouldn't exist without the direct influence of JS.
Enums aren't an ES feature, true, but this is how they're compiled:
That's just a terse way of creating an object with entries so that enum members can be accessed by the key or the value. Nothing special about them.
Another similar TS feature that isn't an ES feature is namespaces, but like enums, TS is just creating objects and assigning things to it inside of a closure.
Right. If you ignore the typechecking part, nearly all of what Typescript compilation does to produce the output is just strip out all the type annotations from the code.
function foo(x: number): string { ... }becomesfunction foo(x) { ... }, etc. Typescript doesn't provide any heavy lifting to support features at runtime that don't exist in regular Javascript (except maybe in a few cases for backwards compatibility with older JS versions).It looks like TypeScript and therefore VS Code is following a similar path to full-fledged IDE's like IntelliJ IDEA for Java. As projects get bigger, they get slower and then the tools need performance hacks, such as a partial editing mode at startup.
It's the cycle of life I guess. A new language comes along and all the tools need to be rewritten. The new tools need to do all the same things as the old tools did because the problems haven't gone away. But hopefully things are better after the rewrite, so there is some progress.
I think it's easy to misread what you said, so just to be clear: The partial editing mode wasn't added because VS Code got bigger and slower, it got added because VS Code's Typescript-related IDE features were always slow to become usable on large projects that were opened inside of VS Code.
Yes, that's true. But I suspect it's also the case that as language ecosystems mature, average project size goes up, because projects tend to be older, people have written more code, and they've started using more dependencies. Tool vendors have to worry more about handling bigger projects.
If you're starting fresh then there's less to worry about. Other people have pushed the limits more than you.