I confused those features of the native language server, so here's the summary:
- Go-to-Definition: For variables, jump to the declaration. For functions/classes/types, jump to its types or implementation.
- Go-to-Type-Definition: For variables, jump to its type declaration instead of the variable declaration.
- Go-to-Implementation: For interfaces/abstruct classes, jump to (multiple) implementations of the method. For compiled TypeScript file (like them under node_modules), jump to its implementation rather than .d.ts files.
I genuinely don’t understand this sentiment at all. Typescript looks great when you put it next to JavaScript in most cases. And looks like shit when you put it next to any other modern language that emerged from a similar time frame (Kotlin, Dart, Swift etc..)
I really don’t see TypeScript destined for long term success with the rise of Wasm on the web. It is only where it is currently because it has operated at a huge advantage of being the only viable solution to a problem that every web developer has needed.
I say this as someone who writes a lot of typescript professionally and a lot of Dart for everything else I possibly can. The difference between the two is huge on almost every factor I can think of where Dart wins by a considerable margin. I’m thankful that Typescript existed at a time when it did but I don’t think it’s in anyway actually a good or sensible language (because it’s so closely to JavaScript) and I can’t wait to not have to use it in the future because better options exist and are becoming viable for more use cases.
Have you engaged with the advanced features? TS is the only mainstream language that lets you express pretty much everything in the typesystem, to the point where I frequently have to hold myself back.
Having used Swift and Kotlin in the past, their typesystems don’t come close to the flexibility with which you can wrangle data in TS. Many concepts that I would consider fundamental are either not present or require complicated syntax eg.: product types A & B, sum types A | B, { …spreading }.
And where Swift needs custom syntax such as `guard let` and `case let` to narrow types, Typescript is able to analyze normal control flow.
For practical reasons, there are a ton of ugly workarounds, but I’d rather live with those than go back to the rigid “Java++” languages.
The problem is the type system is not strong, where structural typing can cause a lot of issues, such as adding a property to an object for example and the typechecker will not care. This does not happen in more strongly, non-structural typed languages.
Yeah that's one of the practical workarounds I mentioned. It mostly comes up while spreading (which is why spreads should usually go first) and when persisting (which is why your ORM should have a runtime schema).
But it's a double edged sword:
- You can brand types with additional information. For example, React Query does this to keep track of which type is stored under which cache-key. This is where most strongly typed languages just give up.
- You can progressively extend/narrow types without having to worry about inheritance. Invariants can be statically checked by encoding them in a type: eg IssuedInvoice = Invoice & { … }. A function that needs only a subset of a domain-object can specify this rather than requiring the email-address to verify a phone number.
- You can even emulate nominal types using keyed unions.
The first two alone have saved me from more errors than structural typing introduced.
Well: Static types exist at runtime, VM can optimize using type information (Inline caching, Devirtualization, predictable, fixed object layout), AOT compiled, Dart’s type system is sound, language-supported Isolates (wow feature), hot reload at runtime (wow feature) since Dart can patch classes and functions in memory.
I'm excited for this, but I'm not looking forward to yet another round of refactoring for all of the linters, formatters, bundlers, etc. I still haven't fully migrated every project I maintain to eslint 9.
I don't know, hopefully not much! Just reading the article about IDEs using one version of typescript and builds using another, along with some incompatibilities. It raises concerns there will be some hiccups with various dev tools.
Does IDEA count? It's the same server underneath. I've been using it since support for it became available, maybe four months ago, and it's been pretty OK. Much faster, but there are some occasional crashes at least with incremental type checking enabled. The speed difference more than makes up for it.
"Native typescript execution" can mean two different things:
1. Chrome/v8 takes TS code, compiles it down to JS internally, erases types, and then runs it like normal. This isn't going to be too hard to do, but also isn't going to be very meaningful. Compiling is a one-step process in any case, and plenty of tooling exists to make it seamless.
2. Chrome/v8 actually understands TS types at runtime, and throws exceptions for mismatches. This isn't going to be possible without a major rewrite of the v8 engine and the ECMAScript spec itself.
And a big challenge for both of these is that TypeScript is iterating at too fast a pace for something like Chrome to keep up. It's best to just leave versioning and compilation for the developer to manage and give end users a consistent JavaScript experience.
I think there's also option 3, v8 understands types and uses them for optimization, but handles wrong types gracefully.
I don't think any type of understanding TS would require changing ECMAScript spec. Would a TypeScript-understanding parser not be able to handle normal ECMAScript correctly? It could switch between two modes based on the file type.
For option 1 the speed of TS development is not an issue, as Chrome would only need to include some up-to-date compiler, and the TS files could specify their TS version. But doing TS compilation in the browser would only be a small nice thing for devs, for website users it would be a downgrade, as the page load would be slower because of the compiling and the larger file sizes (JS files can already be very big these days).
It's unclear whether you could build a JIT that meaningfully benefits from typescript types.
1. Hidden classes can't be created from TS interfaces because they don't represent the full data of the underlying object
2. You don't really ever want to compile code the first time you see it, because that takes a lot of memory and extra CPU cycles. By the time code has run enough to be worth compiling, you probably have enough profile data to optimize better than you could with data from the types anyway.
3. Many of the juiciest optimizations come from types that aren't representable in TS, like integers.
4. Including all the types for all your code and deps (literally all the .d.ts) is huge, and the size increase alone might nullify any performance benefit.
If you want proper run time type safety you’re going to need a language designed for that which Typescript never was. I write a bunch of Dart which I compile to Wasm and get proper run time type safety in the browser and it works great.
1. Would still be meaningful, since it would pretty much mean we could completely ignore untyped JS code aside from legacy support, the same way we can currently pretend untyped python doesn't exist
Different projects use different versions of typescript with different configurations, and almost no one wants the client to throw type errors where the untyped code would have actually worked. I.e. the are drawbacks but no advantages.
This is ongoing standardisation work to allow it to _ignore_ typescript and just run the JavaScript which will be nice but not a huge win.
Exactly so all the Browser should do is erase the types. Doing that after you have spent extra time downloading and parsing them is not a useful enough feature to lumber the language with having to get all Browser's to ship each new change.
There's effort towards "erasable syntax" but in practice not many really want to run anything more than basic TS in the browser, simply because you lose things like 'import _ from "lodash", which requires further setup (import maps) or is impractical in larger projects.
The real reason however is that TS is just a language, not part of any standard, and browsers are not just going to support random languages headed by corporations (Microsoft) and that are not community projects.
> you lose things like 'import _ from "lodash", which requires further setup (import maps) or is impractical in larger projects.
I think importmaps are reasonably practical even for larger projects today. I know Firefox supporting multiple importmaps in the same HTML is still a wishlist item for some to avoid more scenarios that need an importmap compile step in very large projects, but importmaps are relatively easy to automate (it's just JSON wrapped in a script tag; merging them can be just a matter of a couple Object.assign calls or object spread notation; the multiple importmaps standard that Firefox is behind on is just that, a basic Object.assign merge).
> The real reason however is that TS is just a language, not part of any standard
Right, which is why the TC-39 (committee that owns JS) proposal for "erasable syntax" for "type annotations" isn't Typescript-specific and isn't a pure superset of Typescript syntax. The node implementation of erasable syntax doesn't use the Typescript compiler and doesn't support the full Typescript syntax and is relatively close to the TC-39 proposal.
> not just going to support random languages headed by corporations (Microsoft) and that are not community projects.
Nitpicking somewhat, but Typescript has been open source since it was publicly launched and a fair enough chunk over the years of contributors aren't/haven't been Microsoft employees. It's fairly reasonable to say it is a community project. I appreciate the point that it is still seen as a specific-vendor solution and the point of separating the JS language standard proposal from being "just do what Microsoft decides is right for Typescript" (as TC-39 is trying to do), but to be fair to Typescript, it is a also bit wilder and more open than that "just a Microsoft solution" at this point (and arguably also for most of its history).
The "types as comments" proposal has a stated goal to not codify any semantics to the annotations.
This is not only due to implementation complexity, but also to keep TS to be able to change. Or even to build an entire different JS superset. With that proposal, even flow could be natively executed.
It is an approach that has already seen some success in Python. Languages often have constructs that are reserved for future use or that "parse but don't validate". JS has a lot of reserved keywords (thanks to ES4 and ES5, especially) that "don't mean anything" today but could in the future and still parse even though they'll give a runtime error. Beyond that, almost every language has a syntax for comments. Comments don't mean anything to the parser/compiler either, but they mean a lot to the people writing the source files and they still need syntax to write them.
If you allow arbitrary meaningless data in today, you can never add meaning in the future. That's why the reserved words cannot be used. They need to be safe to add meaning to down the line!
I'm not enough of an expert in PL theory and compilers to say for sure, but I suspect that because Typescript's syntax and semantics are all designed with total type erasure in mind, there's no advantage you could get to executing it natively versus compiling to JavaScript and taking advantage of all the optimizations JS engines already have.
I confused those features of the native language server, so here's the summary:
Love it. What a fantastic show case for Go.
Typescript is my favourite language. Glad it's being continuously developed.
I genuinely don’t understand this sentiment at all. Typescript looks great when you put it next to JavaScript in most cases. And looks like shit when you put it next to any other modern language that emerged from a similar time frame (Kotlin, Dart, Swift etc..)
I really don’t see TypeScript destined for long term success with the rise of Wasm on the web. It is only where it is currently because it has operated at a huge advantage of being the only viable solution to a problem that every web developer has needed.
I say this as someone who writes a lot of typescript professionally and a lot of Dart for everything else I possibly can. The difference between the two is huge on almost every factor I can think of where Dart wins by a considerable margin. I’m thankful that Typescript existed at a time when it did but I don’t think it’s in anyway actually a good or sensible language (because it’s so closely to JavaScript) and I can’t wait to not have to use it in the future because better options exist and are becoming viable for more use cases.
Have you engaged with the advanced features? TS is the only mainstream language that lets you express pretty much everything in the typesystem, to the point where I frequently have to hold myself back.
Having used Swift and Kotlin in the past, their typesystems don’t come close to the flexibility with which you can wrangle data in TS. Many concepts that I would consider fundamental are either not present or require complicated syntax eg.: product types A & B, sum types A | B, { …spreading }.
And where Swift needs custom syntax such as `guard let` and `case let` to narrow types, Typescript is able to analyze normal control flow.
For practical reasons, there are a ton of ugly workarounds, but I’d rather live with those than go back to the rigid “Java++” languages.
The problem is the type system is not strong, where structural typing can cause a lot of issues, such as adding a property to an object for example and the typechecker will not care. This does not happen in more strongly, non-structural typed languages.
Yeah that's one of the practical workarounds I mentioned. It mostly comes up while spreading (which is why spreads should usually go first) and when persisting (which is why your ORM should have a runtime schema).
But it's a double edged sword:
- You can brand types with additional information. For example, React Query does this to keep track of which type is stored under which cache-key. This is where most strongly typed languages just give up.
- You can progressively extend/narrow types without having to worry about inheritance. Invariants can be statically checked by encoding them in a type: eg IssuedInvoice = Invoice & { … }. A function that needs only a subset of a domain-object can specify this rather than requiring the email-address to verify a phone number.
- You can even emulate nominal types using keyed unions.
The first two alone have saved me from more errors than structural typing introduced.
Why is Dart better in your experience?
Well: Static types exist at runtime, VM can optimize using type information (Inline caching, Devirtualization, predictable, fixed object layout), AOT compiled, Dart’s type system is sound, language-supported Isolates (wow feature), hot reload at runtime (wow feature) since Dart can patch classes and functions in memory.
I'm excited for this, but I'm not looking forward to yet another round of refactoring for all of the linters, formatters, bundlers, etc. I still haven't fully migrated every project I maintain to eslint 9.
I'm unfamiliar with all the changes coming soon. What would you need to refactor?
I don't know, hopefully not much! Just reading the article about IDEs using one version of typescript and builds using another, along with some incompatibilities. It raises concerns there will be some hiccups with various dev tools.
Migrated to what? Rust, or Go? Or Rust and Go?
is anyone using the preview releases in neovim yet?
Does IDEA count? It's the same server underneath. I've been using it since support for it became available, maybe four months ago, and it's been pretty OK. Much faster, but there are some occasional crashes at least with incremental type checking enabled. The speed difference more than makes up for it.
stupid question: why doesnt google chrome support native typescript execution on their chromium engine?
"Native typescript execution" can mean two different things:
1. Chrome/v8 takes TS code, compiles it down to JS internally, erases types, and then runs it like normal. This isn't going to be too hard to do, but also isn't going to be very meaningful. Compiling is a one-step process in any case, and plenty of tooling exists to make it seamless.
2. Chrome/v8 actually understands TS types at runtime, and throws exceptions for mismatches. This isn't going to be possible without a major rewrite of the v8 engine and the ECMAScript spec itself.
And a big challenge for both of these is that TypeScript is iterating at too fast a pace for something like Chrome to keep up. It's best to just leave versioning and compilation for the developer to manage and give end users a consistent JavaScript experience.
I think there's also option 3, v8 understands types and uses them for optimization, but handles wrong types gracefully.
I don't think any type of understanding TS would require changing ECMAScript spec. Would a TypeScript-understanding parser not be able to handle normal ECMAScript correctly? It could switch between two modes based on the file type.
For option 1 the speed of TS development is not an issue, as Chrome would only need to include some up-to-date compiler, and the TS files could specify their TS version. But doing TS compilation in the browser would only be a small nice thing for devs, for website users it would be a downgrade, as the page load would be slower because of the compiling and the larger file sizes (JS files can already be very big these days).
It's unclear whether you could build a JIT that meaningfully benefits from typescript types.
1. Hidden classes can't be created from TS interfaces because they don't represent the full data of the underlying object
2. You don't really ever want to compile code the first time you see it, because that takes a lot of memory and extra CPU cycles. By the time code has run enough to be worth compiling, you probably have enough profile data to optimize better than you could with data from the types anyway.
3. Many of the juiciest optimizations come from types that aren't representable in TS, like integers.
4. Including all the types for all your code and deps (literally all the .d.ts) is huge, and the size increase alone might nullify any performance benefit.
If you want proper run time type safety you’re going to need a language designed for that which Typescript never was. I write a bunch of Dart which I compile to Wasm and get proper run time type safety in the browser and it works great.
1. Would still be meaningful, since it would pretty much mean we could completely ignore untyped JS code aside from legacy support, the same way we can currently pretend untyped python doesn't exist
Different projects use different versions of typescript with different configurations, and almost no one wants the client to throw type errors where the untyped code would have actually worked. I.e. the are drawbacks but no advantages. This is ongoing standardisation work to allow it to _ignore_ typescript and just run the JavaScript which will be nice but not a huge win.
> no one wants the client to throw type errors where the untyped code would have actually worked
That’s not how TypeScript works. You execute it after erasing the types.
Exactly so all the Browser should do is erase the types. Doing that after you have spent extra time downloading and parsing them is not a useful enough feature to lumber the language with having to get all Browser's to ship each new change.
Unless you use enums, of course.
Or constructor property initializers.
Is a typescript feature.It's not a stupid question, but here is the TC39 proposal to add type declarations to JS: https://github.com/tc39/proposal-type-annotations
Because TypeScript is a (legacy) mess.
There's effort towards "erasable syntax" but in practice not many really want to run anything more than basic TS in the browser, simply because you lose things like 'import _ from "lodash", which requires further setup (import maps) or is impractical in larger projects.
The real reason however is that TS is just a language, not part of any standard, and browsers are not just going to support random languages headed by corporations (Microsoft) and that are not community projects.
> you lose things like 'import _ from "lodash", which requires further setup (import maps) or is impractical in larger projects.
I think importmaps are reasonably practical even for larger projects today. I know Firefox supporting multiple importmaps in the same HTML is still a wishlist item for some to avoid more scenarios that need an importmap compile step in very large projects, but importmaps are relatively easy to automate (it's just JSON wrapped in a script tag; merging them can be just a matter of a couple Object.assign calls or object spread notation; the multiple importmaps standard that Firefox is behind on is just that, a basic Object.assign merge).
> The real reason however is that TS is just a language, not part of any standard
Right, which is why the TC-39 (committee that owns JS) proposal for "erasable syntax" for "type annotations" isn't Typescript-specific and isn't a pure superset of Typescript syntax. The node implementation of erasable syntax doesn't use the Typescript compiler and doesn't support the full Typescript syntax and is relatively close to the TC-39 proposal.
> not just going to support random languages headed by corporations (Microsoft) and that are not community projects.
Nitpicking somewhat, but Typescript has been open source since it was publicly launched and a fair enough chunk over the years of contributors aren't/haven't been Microsoft employees. It's fairly reasonable to say it is a community project. I appreciate the point that it is still seen as a specific-vendor solution and the point of separating the JS language standard proposal from being "just do what Microsoft decides is right for Typescript" (as TC-39 is trying to do), but to be fair to Typescript, it is a also bit wilder and more open than that "just a Microsoft solution" at this point (and arguably also for most of its history).
The "types as comments" proposal has a stated goal to not codify any semantics to the annotations.
This is not only due to implementation complexity, but also to keep TS to be able to change. Or even to build an entire different JS superset. With that proposal, even flow could be natively executed.
That proposal is a practical joke. You haven't got a language at all if the words don't mean anything.
It is an approach that has already seen some success in Python. Languages often have constructs that are reserved for future use or that "parse but don't validate". JS has a lot of reserved keywords (thanks to ES4 and ES5, especially) that "don't mean anything" today but could in the future and still parse even though they'll give a runtime error. Beyond that, almost every language has a syntax for comments. Comments don't mean anything to the parser/compiler either, but they mean a lot to the people writing the source files and they still need syntax to write them.
If you allow arbitrary meaningless data in today, you can never add meaning in the future. That's why the reserved words cannot be used. They need to be safe to add meaning to down the line!
I'm not enough of an expert in PL theory and compilers to say for sure, but I suspect that because Typescript's syntax and semantics are all designed with total type erasure in mind, there's no advantage you could get to executing it natively versus compiling to JavaScript and taking advantage of all the optimizations JS engines already have.