21 ms·

TypeScript 5.0

606 points by dimitropoulos 4y ago

dimitropoulos 4y ago
Without Angular, we may very well not have TypeScript today. The top thing listed in this release (TypeScript doesn't follow semver, btw) is about Decorators. I find the whole story about Angular's role in TypeScript early days to be very fascinating because I don't hear people talk about it anymore (just search "AtScript TypeScript" if you weren't around at the time). It was the Angular team that forced Decorators to be added when it was still stage 0. In exchange, they forfeited continued work on their would-be competitor to TypeScript. Even without the Decorators thing, Angular was intensely popular and it made a big impact how they went "all in" on TypeScript, pushing a lot of early adoption. I know lots of people that first started with TypeScript because of work on an Angular project. I think a lot of people don't seem to know/remember how touch-and-go TypeScript was in the very early days. There were many large projects that were all-in on FlowType, and others still that were pushing for Elm, etc. For example, it took quite a while for you to be able to do JSX _at all_. Today, we just have TypeScript. Well. I do know one company that uses ReasonML (or isn't it called Rescript now?) --- Historical stuff aside, I'm extremely happy we ended up with TypeScript over the others because the team is so incredibly awesome and dedicated. It's rare you see such a large project so well shepherded by such a talented set of individuals. It speaks volumes that the average tenure on that team is so high. We've seen some public apologies from the Flow team on this topic so I don't feel like I'm talking behind anyone's back if I say they ended up truly not being up to the task of being what TypeScript is today.
- deleted 4y ago
  [deleted]
- JamesSwift 4y ago
  One of my most regretted decisions was evaluating Flow vs Typescript and going with Flow. Years later I had the opportunity to use Typescript and it was so nice comparatively. I've enjoyed it ever since. Of course, that was with years of development in its belt so maybe the experience wouldn't have been as nice if I went with it originally.
  - dimitropoulos 4y ago
    Same. I spent the next few years doing major refactors from Flow to TypeScript (the largest that's public was for Insomnia: https://github.com/Kong/insomnia/discussions/3654 https://github.com/Kong/insomnia/discussions/3654).
  - latchkey 4y ago
    I'm curious what criteria you used to pick Flow vs. Typescript.
    - myth_drannon 4y ago
      Flow allowed gradual typing of the project and Typescript forced you to convert everything at once(at least the first versions of TS)
    - dimitropoulos 4y ago
      for a lot of people it was some combination of: - Flow has more adoption (it did, for a while, in the OSS sphere) - Microsoft is evil (remember, this was before everyone was using VS Code and loving it. (Also, tautologically, TypeScript has been one of the biggest things that changed this public perception for the people I hang around)) - Facebook is awesome (oh, how times have changed...) - Flow has total type soundness as a goal (from the beginning, and through to today, TypeScript still lists this as an explicit non-goal) - You literally cannot use React and Flow together (it didn't support JSX for what felt like an eternity and Flow did from the beginning (I think?). - Flow had exact object types (TypeScript _sorta_ has this today, but most people don't know to turn it on because it isn't in the strict-mode family: exactOptionalPropertyTypes) - Flow had more features (and was faster) - DefinitelyTyped didn't exist yet, and it was easier to find types for Flow (but, let's be real, both had nearly nothing compared to today)
      - RyanCavanaugh 4y ago
        Total type soundness is not a goal of Flow. For example, array bounds are not considered. Flow considers this program to have no errors, but TypeScript (with the correct option enabled) will: let m = [1, 2, 3]; console.log(m[4].toFixed()); Also, DefinitelyTyped itself launched before Flow (2012 vs 2015), so the timeline on that point isn't right.
- martypitt 4y ago
  I remember this well. From the outside, it seemed a fantastic example of collaboration between two separate (competing?) teams. It took humility and pragmatism for the Angular team to abandon AtScript and recognise TS as the better long-term bet.
- agency 4y ago
  I have often thought that it must have been tough to be on the Flow team. It was pretty good, and absolutely would have been "good enough" to catch on if it weren't for TypeScript. But ultimately the better language won.
  - epolanski 4y ago
    Flow ultimately served only Facebook purposes and their work and the evolution of the language wasn't on par with TS.
  - dimitropoulos 4y ago
    And it doesn't hurt that the TypeScript team is so great. We've seen some public apologies from the Flow team on this topic so I don't feel like I'm talking behind anyone's back if I say they ended up truly not being up to the task of being what TypeScript is today.
    - maxloh 4y ago
      Any links to their apologies? I don't understand why they apologized.
      - RyanCavanaugh 4y ago
        I presume they're referring to https://medium.com/flow-type/clarity-on-flows-direction-and-open-source-engagement-e721a4eb4d8b https://medium.com/flow-type/clarity-on-flows-direction-and-...
        dimitropoulos 4y ago
        yes exactly. The only other context I'll add is for people shipping Flow that I knew at the time they felt that this announcement felt like it came about two years too late. I had already switched to TypeScript long before because, in part, of the things they're apologizing for in that article which were evident long before being said out loud. I say that with great reverence and respect for the people that worked so hard on Flow, by the way, but that's the situation I experienced.
- epolanski 4y ago
  True, Angular was crucial for adoption of TypeScript 5+ years ago but I think the community would've migrated nonetheless.
  - dimitropoulos 4y ago
    for sure for sure. that's kinda the point though: they already were migrating... to Flow. Lots of big projects are on the list that had to change course later because TypeScript won: - Yarn - Jest - Luxon - Gatsby - Expo - Styled-Components - GitKraken - GraphQL-js and that's just off the top of my head. I'm sure there were many more.
    - davnn 4y ago
      Do you have the impression that Flow once had greater adoption than TypeScript, or that there was a movement from TypeScript to Flow? I think it was always behind in adoption, but of course, some projects used it anyways. From my memory, Flow always felt like the less conservative cousin and it was tempting to use it, but TypeScript always was the safer bet.
      - dimitropoulos 4y ago
        I have to disclose my potential bias here because I am these days very involved in the TypeScript world (with Michigan TypeScript). That said, I would never hide the fact that I was once a die-hard Flow person that.. died hard, haha. (and I'm very glad I did! more on that later) In the very early days (in every circle I was in) Flow was ahead by every measure (known examples, excitement, adoption, features, speed, etc). You could point to real live running apps like GitKraken and Discord (hopefully my memory isn't failing me on those) that where shipping Flow very early. And you could use JSX! At the time there was literally no known project (especially OSS) actually shipping TypeScript. Not from Microsoft and not from anyone else. It was hard to tell if TypeScript was more of "embrace extend extinguish" (obviously with hindsight we can be absolutely certain that it wasn't that (unless we're talking about a decades long "long con" lol)) But there's something I could never have anticipated at the time that's more important to me today than any feature of the language: The TypeScript team have done a breathtakingly amazing job of carrying the project through the years. TypeScript, as an open source project, is an absolute triumph: and I think it has everything to do with the people behind it. At this point TypeScript is "good enough" in every way that really matters. If they consciously stopped developing the language and just focused on performance and bugs I think we should all call that a success. I really believe it's been handled _that_ well. Meanwhile Flow went the other direction and there were bugs (in the 0.30 era, approximately) that had people pulling their hair out that were caused by the impedance mismatch of them making it for Facebook first and the rest of the world last. As far as I can tell, this really never changed (or at least, if it did, then maybe it was "too little too late"). Meanwhile, it seems like TypeScript has been managed with the literal opposite mindset: putting us in a situation where only one major project is left using Flow... React. There are other projects like ESLint that have been... how do I say this in a not bridge-burn-y way... surprisingly reluctant to realize that TypeScript isn't some passing fad. But I'm confident that they're going to have their wakeup call sooner or later. The culture of JavaScript-land is just not loyal enough for gatekeeping a technology like TypeScript. Look at webpack. We all spent nights and weekends for years gaining knowledge on how it works and weeks per year getting familiar with it, then esbuild happened and we threw webpack away overnight like it never even happened. I believe the same fate awaits projects that deny the necessity of writing in TypeScript at this point in history, with the possible singular exception of React.
- skratlo 4y ago
  We have WASM dude. But TS people are in TS bubble for what it's worth.
  - yCombLinks 4y ago
    It's not worth anything. Are you writing raw WASM?
  - swatcoder 4y ago
    WASM and TypeScript don’t really compare or compete. I’m not sure what you’re saying.
  - mc10 4y ago
    Until WASM can touch the DOM you’re still going to need JS (and hence, TS).
    - oaiey 4y ago
      And objects. And so many more things. Wasm is a cpu or low level operating system and not programming language
    - nicoburns 4y ago
      In fairness, rust-in-wasm has pretty complete DOM bindings. You can quite easily write DOM manipulation code in Rust without ever touching JS/TS. Whether that's a good idea is another matter.
      - maxloh 4y ago
        How does that work?
        amaranth 4y ago
        web-sys[1] generates the binding code using the same IDL files that browsers use to generate their JS bindings to the C++ doing the actual work. [1] https://github.com/rustwasm/wasm-bindgen/tree/main/crates/web-sys https://github.com/rustwasm/wasm-bindgen/tree/main/crates/we...
- cies 4y ago
  > and others still that were pushing for Elm Still pushing for it. TS is like make-up on a pig, compared to Elm. > I do know one company that uses ReasonML (or isn't it called Rescript now?) Re* is also a better alternative imho. Better interop with JS/TS is very nice. But in place one could use Elm, I'd say it certainly wins in the "clean" reward.
- spankalee 4y ago
  AtScript was always stillborn, and the Angular team absolutely could not have made a competitor to TypeScript.
  - dimitropoulos 4y ago
    Agreed, but the point I was making here is that Angular itself was very far from stillborn, it pushed early adoption of TypeScript really really hard which did wonders for TypeScript to be taken seriously.
  - zaphirplane 4y ago
    Wonder why they didn’t go with the other google language Dart Too foreign to frontend audiences? It has a lot of fans in flutter
    - jsyolo 4y ago
      There was AngularDart, don't know what happened to it.
      - pax_americana 4y ago
        Publicly it's dead, but it's alive and well and constantly getting updated inside Google.
- no_wizard 4y ago
  >Today, we just have TypeScript. Well. I do know one company that uses ReasonML (or isn't it called Rescript now?) One company outside Meta?
  - dimitropoulos 4y ago
    yes! haha. They love it. I ping them and see if they want to identify themselves.
    - armacham 4y ago
      FB migrated all of its ReScript to Flow and deleted the ReScript.
  - illusionalsgcty 4y ago
    There's definitely a few around that are using ReScript; we've been using ReScript for production services for a bit more than 2 years now at Autobooks. https://rescript-lang.org https://rescript-lang.org has a list too
- throw_m239339 4y ago
  > Without Angular, we may very well not have TypeScript today. Typescript was started at Microsoft by the guy who designed Turbo Pascal and C#, so completely independently from Google's Angular team. Angular had its own "AtScript" and eventually ditched that. Typescript had experimental decorator support well before Angular Team moved from AtScript, because it was a ECMAScript proposal. Angular had zero influence in the design or success of Typescript. Typescript however does support JSX optionally so one can claim that React DID influence Typescript's design decisions.
  - dimitropoulos 4y ago
    Even if that's true (it's definitely not how it was depicted at the time at conferences and from people on the Google side).. the point stands Angular was absolutely huge for it's day and they pushed TypeScript really really hard. It was a truce between two huge companies and it made waves in terms of people trusting Microsoft. I have personally never been one of those mega Microsoft haters but I witnessed shouting matches in the office from people that we're hotly opposed to TypeScript being added to the codebase against others using Angular as a core motivation in many of their counter-arguments. I'm super glad we have TypeScript one way or the other because the team is so dedicated to OSS.
    - throw_m239339 4y ago
      > Even if that's true (it's definitely not how it was depicted at the time at conferences and from people on the Google side).. the point stands Angular was absolutely huge for it's day and they pushed TypeScript really really hard. It was a truce between two huge companies and it made waves in terms of people trusting Microsoft. Angular.js was huge, by the time Angular version whatever because it was always changing, figured out what it wanted to be, most front-end developers already moved to React. What Microsoft product uses Angular? Doesn't Teams uses Angular.js but not Angular? and what does a Google conference has to do with Microsoft? Nothing.
  - styfle 4y ago
    > Typescript had experimental decorator support well before Angular Team moved from AtScript Do you have a source for this. My memory isn't so good but I seem to remember that the Angular team pushed to get this Stage 0 proposal implemented even though the TypeScript team usually waits until Stage 2 or 3 to implement.
- giraffe_lady 4y ago
  god just think how good life would be if we had all switched to elm or reason instead.
  - roebk 4y ago
    there's not a day that goes by that I don't think about this
  - iudqnolq 4y ago
    If only Elm was infinitesimally less pure.
  - rk06 4y ago
    Elm was never an option with how hard it is on "no js" policy
- nikeee 4y ago
  I remember this well, too. Ironically, I think that angular is the framework that benefits least from actually using TypeScript. There is a separate templating language that's only type-checked if you set the right compiler options. JSX is much better suited for that. Being OOP like angular, it often requires opting out of null-safety or init-checks, because something is late-initialized. Having mutable instance state results in less opportunities to be more strict with typing. Its good that the TS team decided to align with the ES standards. Initially (talking like v0.8.0), I had the impression that they're building a "C# for the web", being incompatible with ES. Maybe that's why enums and namespaces were added and initially, the boolean was named bool.
  - WorldMaker 4y ago
    Enums have been proposed for JS for quite a while (there was a sort of enum in "the lost version" ES4 and a TC-39 proposal stuck in Stage 0 for years now [1]). Enums have always had relatively simple JS output that resembles a somewhat common pattern in JS. It was a "standard", just never really a deeply adopted "standard". What's today called "namespaces" in Typescript was originally called "modules" and then "inner modules" (to differentiate from "exterior modules") and is a tiny simplification on a JS pattern that was extremely common at the time of Typescript's inception called at the time "IIFE modules". "namespace" is a very C# name chosen in desperation (when it became clear that "exterior modules" were the present not just the future of the language and "interior modules" was too confusing a term to live), but it's a very old (and used to be extremely common) JS pattern that TS gave a tiny bit of syntax sugar to. It was a "standard" that existed at the time that was (rightfully) killed by AMD/UMD/CommonJS/ESM, but it is hard to fault the Typescript team at the early 0.x days thinking the "Stage Wild" JS pattern would possibly live on for many years to come. (This is also relevant to the patch notes for Typescript 5.0 as 5.0 is the first version [!] to itself be written as [proper/"exterior"] modules rather than namespaces. There are some interesting stories, including in these release notes for why that took so long to transition and what the performance benefits have been post-transition.) Even those things that didn't seem like ES standards have some history as JS "standards". It's not like TS 0.x/1.x didn't support "standards", it is more that the TS team mostly decided to focus more on later stage ES standards (more likely to be accepted by browsers) rather than trying to "prollyfill" Stage 0 and "Stage Wild" standards. [1] https://github.com/rbuckton/proposal-enum https://github.com/rbuckton/proposal-enum
- truth_seeker 4y ago
  Yep. Frameworks play an important role in end user (developers) helps deliver software as quickly as possible. Just like without Rails framework, we may very well not have Ruby today. Also, without WordPress, we may very well not have PHP today.
martypitt 4y ago
Congrats to the Typescript team. The rate of innovation from them is really impressive. Fantastic to finally see Decorators shed their "experimental" label (they've been the stable backbone of Angular for years).
- simlevesque 4y ago
  It's not the same decorators that existed before that were added. They don't have the same features. The new one are based on the upcoming EcmaScript decorators.
  - WorldMaker 4y ago
    Also, Angular relies on parts of the "experimental" decorators that these Stage 3 decorators do not support, so Angular likely will continue to use the "experimental" compiler flag for some time to come, with the added twist that some uses of decorators will now also compile without the flag but will exhibit different behavior and won't run correctly, which may cause all sorts of new headaches for Angular developers.
    - spiralx 4y ago
      I just posted this in our FE channel at work > Note that the ECMAScript decorator spec now supported in TS 5 doesn't support decorating method arguments, unlike the experimental decorators TS has had an that Angular uses e.g. @Inject, @Self, @Optional etc. I'm guessing that this is part of the motivation behind the inject() function, where you can pass flags to it as a second argument to support cases like self or optional - it gives them a path to moving to the new-style decorators in the long-term. AFAIK argument decorators are only used for constructors, and that usage can be replaced by using inject() with flags, so a migration would be possible even today - although I'm sure there would be plenty of as-yet uncovered subtle implementation quirks! The obvious headache TS 5 will introduce is that failing to follow a decorator name with () will now attempt to treat e.g. Inject as a new-style decorator and cause a type error of some kind, which is likely to be confusing. I'm guessing the Angular compiler will have to do something to manage this, even if it's just ensuring there's a useful error message.
swyx 4y ago
> How? There are a few notable improvements we’d like to give more details on in the future. But we won’t make you wait for that blog post. the typescript project continues to set the bar extremely high in terms of changelog and clear communication. love you so much, drosenwasser and co!! > Decorators are an upcoming ECMAScript feature that allow us to customize classes and their members in a reusable way. huh. i thought this was a bit early to do this but i checked (https://github.com/tc39/proposal-decorators https://github.com/tc39/proposal-decorators) and looks like they've moved to stage 3. curious how this is going to change library/api design in the long term.
- deckard1 4y ago
  I don't think decorators being a proposal matters at this point. I know I've been using them for 5+ years now, and libraries such as NestJS already use them extensively. If you like them, you're probably already drowning in them. Me, personally, I could take them or leave them.
  - madeofpalk 4y ago
    NestJS uses the previous, incompatible decorators implementation IIRC.
    - eropple 4y ago
      And, because it does so, you can fall down really deceptive holes due to the lack of typing around things that decorators apply to, like parameters. I don't think that changes with stage 3 decorators, unfortunately. It makes NestJS really error-prone, in my experience, and it's a big reason I stopped making tooling for NestJS projects.
      - WorldMaker 4y ago
        Yeah, it's going to be really "exciting" for Angular users as well in the next few years because Angular is drowning in those old "experimental decorators" which are not wholly compatible with today's Stage 3 decorators and the transition is going to be error prone and tedious. Up until TS 5.x it at least gave you a compile error if you tried to use decorators in code without the "experimental" flag, but now they will compile (except where they don't) even if you have the wrong flags but the behavior is so different between the flags it likely won't run. That's going to cause some interesting havoc.
azangru 4y ago
> But if you’re already familiar with TypeScript, have no fear! 5.0 is not a disruptive release, and everything you know is still applicable. Do you know what caused the typescript team to make it a major release? Has the decorator api changed sufficiently to become a breaking change?
- demurgos 4y ago
  Typescript always goes from version x.9 to (x+1).0. Please also note that TypeScript does not claim to strictly follow semver.
- cacozen 4y ago
  Internal refactors that included moving to ES modules and ended up improving overall performance and size.
  - dcre 4y ago
    It's not a major release.
    - jakebailey 4y ago
      There's a full page of API breaks: https://github.com/microsoft/TypeScript/wiki/API-Breaking-Changes#typescript-50 https://github.com/microsoft/TypeScript/wiki/API-Breaking-Ch... Then, a new error about the deprecations of ancient options to be removed in 5.5: https://github.com/microsoft/TypeScript/issues/51909 https://github.com/microsoft/TypeScript/issues/51909
      - zdragnar 4y ago
        I think "major" was used in the semver sense, which is not how the TS team chooses version numbers.
        jakebailey 4y ago
        Sure, we don't bump according to semver, but it's hard to say that 5.0 _isn't_ a major release given how we used it as a way to get a bunch of breaking changes and cleanups in. It's a very opportune time as people will be forced to manually upgrade and acknowledge that something is changing.
com2kid 4y ago
Question, is there anything decorators can do that higher order functions and higher order classes cannot already accomplish? I typically dislike decorators because they are spooky action at a distance, and whenever I look at code in a language that has decorators, the code almost becomes a DSL of sorts. Not that HoF and HoC don't tend towards the same problems, React used to be famous for how often HoC got used in the ecosystem and the confusion that caused!
- epolanski 4y ago
  The answer is obviously not since decorators still compile to higher order functions.
- recursive 4y ago
  "higher order class" is not a term I've heard before. I'm not sure what that could mean. Decorators are syntactic sugar for higher ordered functions. They fundamentally have the same capability, just with better ergonomics.
  - zdragnar 4y ago
    Functions can return new class definitions- the "class" keyword represents an expression, not a statement. As such, you could write a function that takes in as an argument a class, and return a new class definition that extends the argument you provided... Or any number of other dubious practices.
  - com2kid 4y ago
    Sorry, I meant a function that rips a class open, messes with it, and returns a new class!
- anthlax 4y ago
  Yes - decorators are syntactically nicer :)
- jdlshore 4y ago
  The EcmaScript implementation of decorators is quite nice—it’s just syntactic sugar for a higher-order function call. Much better than the spooky reflection-based approach you see in some other languages.
brundolf 4y ago
It's easy to miss, but I'm most excited for "--moduleResolution bundler" (https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/#moduleresolution-bundler https://devblogs.microsoft.com/typescript/announcing-typescr...) My understanding is it should allow you to finally have TypeScript files that import other TypeScript files and include the file extension. This is important because, for one, it means Deno TypeScript modules and non-Deno TypeScript modules are now compatible (can import each other)! As long as no unavailable system APIs are used, of course This has been a problem in a project I've been working on where a Deno back-end service wants to share some code with a Next.js front-end service. Currently, the shared modules are not able to import anything else, because Deno requires file extensions in import paths and non-Deno TS requires no file extensions in import paths
- jakebailey 4y ago
  "bundler" is definitely not going to be the right resolution mode for using Deno; you may be better served by using ESNext or Node16/NodeNext (the "strictest" mode, really). The "who should use this mode" section here I believe is still accurate: https://github.com/microsoft/TypeScript/pull/51669 https://github.com/microsoft/TypeScript/pull/51669
  - brundolf 4y ago
    From the PR (https://github.com/microsoft/TypeScript/pull/51669 https://github.com/microsoft/TypeScript/pull/51669): > New compiler options > - allowImportingTsExtensions: Allow imports to include TypeScript file extensions. Requires '--moduleResolution bundler' and either '--noEmit' or '--emitDeclarationOnly' to be set. To be clear, I'm not using tsc to build code for Deno. I've got module X which imports module Y, neither of which have any platform-specific dependencies. Right now if module X imports Y with the .ts extension, Deno can import X but tsc can't. If module X imports Y without the .ts extension, tsc can import X but Deno can't. With this compiler option, I should be able to include the .ts extension and allow both to (independently) import the same code
    - jakebailey 4y ago
cies 4y ago
Slowly TS becomes a quirky Java. I for one am not cheering annotations (uhum decorators). I understand their power, but I preemptively lament the all the project that will over use them (yeah looking at you Hibernate).
- suby 4y ago
  I am in agreement with you. I think there is a danger in them over-complicating the language and everyone suffering as a result. I include regular javascript in this too, as Decorators appear to be coming to JS as well. I wasn't sure how to word this thought, but becoming a quirky Java is a good way of putting it.
- nosianu 4y ago
  TypeScript is ECMAscript. You remove the types and you get pure ECMAscript, apart from some very minor - and nowadays unneeded - additions such as enums or namespaces. TS also lets you do what Babel is for, translate the JS to earlier versions of JS. However, that has nothing to do with TypeScript itself, if your target runtimes support all the ECMAscript features you use you don't need to transpile, you only need to remove the type annotations, none of which are code (apart from the leftovers from early days mentioned above). So you would need to complain about ECMAscript. The decorators in this release, for example, are there because it moved to a stage 3 ECMAscript proposal last year, which means TypeScript must implement it now - because TS ECMAscript and not its own language. So they need to support all of at least stage 3 proposals of ECMAscript.
benatkin 4y ago
Does Number.isInteger() still not serve as a Type Guard? https://github.com/microsoft/TypeScript/issues/21199#issuecomment-357995171 https://github.com/microsoft/TypeScript/issues/21199#issueco...
- RyanCavanaugh 4y ago
  In TypeScript, type guards are considered to be exhaustive, so if you have a string | number and check it against a function that says it returns "x is number", then TypeScript will think that in the negative case, it's a string. If isInteger was marked as a type guard, then you could write code like this: function f(s: string | number) { if (!Number.isInteger(s)) { console.log(s.substring(0, 0)); } } which is clearly wrong. There's an open feature request for a new kind of "one-sided" type guards that don't cause narrowing when they return false.
  - benatkin 4y ago
    That seems like an important feature request. I see TypeScript adding fancy stuff without fixing core limitations.
    - explaininjs 4y ago
      You can get around it pretty easily: const intSymbol = Symbol('integer') type integer = number & {[intSymbol]: never} const isInteger = (n: unknown): n is integer => Number.isInteger(n) function f(s: string | number) { if (isInteger(s)) { const allowed = s.toExponential() } else { // s still string | number } } With this you even get to define functions that must accept integers, which is kinda neat.
      - benatkin 4y ago
        That doesn't seem to address my concern. It seems like more of a curiosity. Whatever floats your boat.
endisneigh 4y ago
I have a strange take - I think Typescript types are better most other languages, including Java, C++ and Go. It's strange since TypeScript is adding types to a weakly typed language. If we could push JavaScript performance to be another order of magnitude faster it wouldn't be necessary to use other languages, imho. Of course, pushing it that far without effectively creating a new one would be difficult, to say the least.
- mrits 4y ago
  That is a strange take. It sounds like you think the reason people don't use Typescript is because of performance and not what some would consider a irresponsible ecosystem of abandoned frameworks and a language that provides little actual safety while still being unpleasant to use.
  - quonn 4y ago
    It‘s not strange at all. I think them same. The type system of TypeScript is in practice much more useful than the one of C# or Java. Nothing is abandoned and in any case typically only a small set of libraries is needed which should be carefully picked.
- deleted 4y ago
  [deleted]
- TOGoS 4y ago
  Good take if you ask me. When I want to flesh out an ontology, I find that TypeScript's type syntax more natural than anything else. Generally I find it to do an amazing job of bridging between a very expressive and flexible type system and a language that at runtime knows nothing about your types. Want structural/duck typing? No problem; that's the default. Define new interfaces that old classes happen to implement without having to wrap them. I always wanted that feature! Want nominal types? No problem; just declare a field indicating the type name! interface Square { classRef: "http://example.com/Shapes/Square"; width: number; } interface Circle { classRef: "http://example.com/Shapes/Circle"; diameter: number; } type Shape = Circle|Square; (I like to express things in a way that can be easily translated to RDF, hence my use of URIs for type and attribute names) Since TypeScript types don't runtime checks, you can even do it on atomic types! type USDollars = number & { [Symbol.for("http://ns.nuke24.net/Synx/unit")]: "USD" } type CanadianDollars = number & { [Symbol.for("http://ns.nuke24.net/Synx/unit")]: "CAD" } const someAmount : CanadianDollars = someExpressionReturningUsDollars; // Compile error! Try doing that in Java! I OFTEN WISH I COULD
yanis_t 4y ago
Your regular reminder, that it’s just a regular release, since typescript don’t follow semver. After 4.9 goes 5.0
- clarkdale 4y ago
  From the release notes, it certainly seems minor / backwards compatible. > 5.0 is not a disruptive release, and everything you know is still applicable. While TypeScript 5.0 includes correctness changes and some deprecations for infrequently-used options, we believe most developers will have an upgrade experience similar to previous releases.
  - brundolf 4y ago
    It does have some backwards-incompatibilities, but they're mostly minor/edge-cases
    - lozenge 4y ago
      So did the 4.x releases.
    - WorldMaker 4y ago
      It has one of the largest internal rewrites in TS history (namespaces to ESM switch), so it's somewhat incredible its backwards-incompatibilities list is mostly minor/edge-cases. (Which is to say that Typescript probably couldn't use semver if it wanted to because it has some extreme views on backwards compatibility, but also that this amount of codebase churn is absolutely semver breaking in the strictest semver senses even if it is mostly backwards compatible.)
- kypro 4y ago
  Is there a reason for this? Why even have the decimal if 4.9 -> 5.0 is just as significant as 4.8 -> 4.9. Just make it v49 -> v50 and remove the ambiguity. What am I missing?
  - 4y ago
claytongulick 4y ago
Probably an unpopular opinion, but my favorite thing about typescript is what it's done for the jsdoc community. A bunch of stuff had to be built to support good tooling in vscode for types with JavaScript, and that was leveraged for jsdoc also. I don't use typescript, but I benefit from it in multiple ways, js doc and the occasional .d.ts file have made my life better.
- c-hendricks 4y ago
  If you use things like `import('some-package').SomeType` in JSDoc I don't think it's fair to say you don't use TypeScript. You do, that's only supported in TS.
  - claytongulick 4y ago
    Yep, and I do. That's my point. I don't write typescript, but it has done wonders for the jsdoc ecosystem.
- FractalHQ 4y ago
  I get triggered by JSDoc and I really wish I didn’t. To me it’s clearly just more verbose Typescript with less features. I can’t understand the appeal, and most arguments I’ve heard for it can be summed up to “typescript is spooky and I don’t want to learn it so I’ll use this inferior thing instead”, which for my personality, is as hard for me to accept as it would be to suffocate myself by holding my breath. The only other argument being “no compile step” which is a non-argument in the age of modern bundlers.
quonn 4y ago
The missing feature I want most is type narrowing across chained functions like: arr.filter(a => a.kind === „bar“).map(a => /* a should now be of type Bar just like in a branch */)
- subarctic 4y ago
  Wait, are you saying they added that in this release? That's awesome!
  - dhritzkiv 4y ago
    This is not part of this release.
- acdibble 4y ago
  This is possible with type predicates, example: https://www.typescriptlang.org/play?#code/C4TwDgpgBAYg9nKBeKBvKA7AhgWwgLigHIAzBIgbigDcsAbAVwMwZwCMIAnKAXwoFgAUKEhQAQlm4p02PISJtJlGvSaEAzsE4BLDAHNeAwUIDGcDJqjb18RCgAUtRs1tQAPuMkBKQk6ZX1WARkAD4VZwA6WWgkWOIyOEohIQATCBM6SWgzC2AoSU4sEEJ7Vw8JTi8AbQBdI1NzSxJtOmAuCBTkfM5CkAjm1q57a1svIwB6cahpqAA9AH4hIA https://www.typescriptlang.org/play?#code/C4TwDgpgBAYg9nKBeK... docs: https://www.typescriptlang.org/docs/handbook/2/narrowing.html#using-type-predicates https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...
- silasdavis 4y ago
  It was would be nice for this to be automatic but filter does work like this it you pass a type guard as the predicate: ``` arr.filter((a: A): a is A & { kind: 'bar'} => a.kind === 'bar') ``` If you define: ``` function isKind<K extends A['kind']>(kind: K): (a: A) => a is A & { kind: K } { return (a): a is A & { kind: K } => a.kind === kind; } ``` Then you can write: ``` arr.filter(isKind('bar')) ``` and get a properly narrowed return type array
  - quonn 4y ago
    Nice, thank you
pjmlp 4y ago
I wonder when will be Typescript done, there is only so much that one can do adding a type system to JavaScript, without starting to become C++ like complexity language, which arguably already is.
- nosianu 4y ago
  It's already there. There are less and less new type features, all they do is implement any new ECMAscript proposals that made it to stage 3 at least. If you look at the changes of this and the last few releases, it's mostly internals, tooling and handling and other non-type things. Decorators are in TS 5 now because they made it to stage 3 last year. They have to follow the other current and future ECMAscript proposals and implement them though, so new features to be supported has for quite some time dependent almost entirely on the ECMAscript process. On the pure TypeScript side there was only minor tweaking and small corrections (for example, TS 4.8 brought "Improved Intersection Reduction, Union Compatibility, and Narrowing", clearly not a new feature but improvements to an existing one).
  - pjmlp 4y ago
    Meanwhile tsconfig.json keeps getting bigger, with combinatorial explosion of Haskel like feature sets, regarding how a source file is to be understood. At least we get lots of opportunities for interview questions.
ssalbdivad 4y ago
Massive release! `const` generic parameters in particular have been a god-send for our repo’s static inference (https://github.com/arktypeio/arktype https://github.com/arktypeio/arktype) where previously we were forced to constantly rely on complex narrowing logic based on extends checks. I look forward to the day when we support 5.0 as our minimum version and replace all of them with `const` generics for 1:1-inferred definitions like this: const package = type({ name: "string", "version?": "number" }) Plus we’ll finally be able to remove the crazy hack we had to write to allow ts-morph to make type assertions on our codebase by transforming all of our `.ts` imports to `.js` in a virtual file system, which now that I think of it I’m probably looking forward to deleting even more XD Great work, and looking forward to what comes next!
- dimitropoulos 4y ago
  100%! I have a package that I've been running on nightly just to get this. Felt a bit like the wait for a const generics in Rust (except here, it didn't take long at all)!
syspec 4y ago
Unpopular opinion, but Please stop adding things to typescript
- ofchnofc 4y ago
  Why?
i_am_toaster 4y ago
I’m always surprised by how much others like typescript. Out of all the languages I have to use, typescript is the one that feels the most like pulling teeth. Maybe I just don’t know how bad it truly was to work with a really large JavaScript project without types and that’s why people love it, but without that experience it just feels like all the hassle of types without most of their benefits.
- goda90 4y ago
  It is truly bad to work with large Javascript projects without types. But I'm curious, what benefits of types do you feel you are missing in Typescript?
- wnolens 4y ago
  I feel the same, but when I complain I get blamed. Or someone chimes in with an illegible type/interface definition that solves my issue but is completely out of reach for all but language experts, which in other languages is not an issue.
  - eropple 4y ago
    Can you provide an example of something you'd see in common use that is 1) not provided by an existing library (such that you are consuming a complex type rather than writing it) and is 2) "out of reach for all but language experts"?
- madeofpalk 4y ago
  I'm curious about what languages you're comparing it to. My other experience is with C# and Go, and I find Typescript's type system to be much more expressive and natural to work with.
- ggregoire 4y ago
  Your experience probably differs from people who like TS. Personally I don't feel any hassle from using it and I couldn't even start listing all the benefits it offers. Even for very small personal projects, first thing I do is installing TS. Not saying it's your case, but I noticed that a lot of people who hate TS like to use techniques and patterns that are usually considered bad practices, which often trigger errors in TS. Mutating an object to add a new property, mutating an array to add an element of a different type, processing apples and oranges in the same function without using generics or the correct union type, etc. Code works but TS doesn't like it and forces them to rewrite it properly and it feels like a hassle with no benefits. I also noticed that lot of people who don't like TS think they need to type everything (every variable, every function's return... which is obviously inconvenient) instead of relying on types inference. There is usually very little to type in TS (compared to Java or C# for example). The two main things are the parameters of your named functions and your external data (i.e. the fetch responses). Almost everything else can be inferred. I also observed that some people refuse to use VSCode (or any code editor with a good TS support). So they don't see any of the benefits while coding and think it's totally useless.
Waterluvian 4y ago
Does anyone else find that Enum is just not worth using and you’re better off with union types?
- christophilus 4y ago
  Yeah. I never use them. They don’t offer enough benefits vs unions.
  - tgv 4y ago
    You can export enums as objects to javascript. And it's easier to change string enums than string unions.
    - WorldMaker 4y ago
      The typescript language server does a great job supporting rename refactors for string unions. It doesn't get much easier than that and is no harder than string enums, in my view. (I've done crazy things like use emoji named types in string unions and then used F2 to rename refactor them to a different emoji or name and not needed to worry if it missed any emoji literals.) The only thing missing from both string enums and string unions is something to support [Symbol.iterator]() to iterate through the available options, but at this point I find that easier to write DRY with string union types (especially with typeof/keyof meta-magic) rather than string enums.
- cageface 4y ago
  Yes. Now all I want is something like Rust traits or Swift protocols for unions.
- spiralx 4y ago
  Well as of this release enums are now also union types by default :) https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/#all-enums-are-union-enums https://devblogs.microsoft.com/typescript/announcing-typescr...
prmph 4y ago
I wish MS will fork Typescript into a new language altogether that transpiles to JS or compiles to WASM. In that case, they can remove all JS weirdness from it, simplify it, add a proper standard library, and add other good parts from other (especially functional) languages to it. My wish list for such a language (in addition to what is already in Typescript), in no particular order: - Generic object literals (Why should generic type inference be limited to functions?) - Deep support for an alternative to exceptions using a Failable<TResult, TError> type - Localizable keywords (Why should programming languages be tools of cultural hegemony?) - Dependent types, with no real distinction between values and types (At a certain point, Typescript’s type system begins to look like a separate Turing-complete language within a language. It’s probably time to do away with this dichotomy entirely somehow) - Higher-kinded types (This is a pending issue in TS since 2014) - JSX built-in without the need for any React-like dependency (No need to use it if you don’t like it; in the general sense, it’s just syntactic sugar for composing function invocations) - No return necessary (the last expression in a block is returned). Thus every flow control construct _can_ (but does not have to) be an expression. - No null, undefined, or any of all that, in favor of using a Maybe<T> type - Proper decimal types (it’s shameful for a language to be without it now) - A reasonably extensive standard library (Math, Stats, Collections (pull & push), String, Objects, Date/Time, Async, Functional, DOM, etc.) That would be getting close to the perfect language for me.
- dmix 4y ago
  > Deep support for an alternative to exceptions using a Failable<TResult, TError> type Is there a good library for this currently? I've been looking for one and a Maybe library. The Maybe one I use is pretty small.
  - halfmatthalfcat 4y ago
    fp-ts (and most functional libraries) have a handy Either type just for this: https://gcanti.github.io/fp-ts/modules/Either.ts.html https://gcanti.github.io/fp-ts/modules/Either.ts.html
    - 4y ago
mtone 4y ago
In a monorepo with project references where each symlinked (not paths) package has a src/ and output lib/, I've always had issues with VsCode incorrectly proposing to import from src/ over lib/ from other packages. Never got it to work just right. Does anyone know if the new package.json resolution settings can help resolve these issues?
BLanen 4y ago
New decorators are so good. I absolutely hated how the experimental ones worked and try to avoid using libraries that use it.
chrismsimpson 4y ago
TypeScript is like having a glass of ice cold water in hell.
- orange8 4y ago
  You drink your glass of water, then continue burning forever and ever.
cutler 4y ago
Decorators - the kiss of death for any programming language.
- dimitropoulos 4y ago
  I encourage anyone who disagrees with this to give Nest.js a try (note: not Next.js)
harel 4y ago
What happens to TypeScript when ECMAScript brings it's core elements to the language?
- WorldMaker 4y ago
  Typescript for a while has focused on Stage 3 and Stage 4 proposals, so its "core elements" are almost all already in the language. Unless you mean the type annotations itself? The good news there is that there is a Stage 1 proposal to take the Python/Ruby approach of bringing them into the language: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations Were that to happen, that proposal doesn't apply any type checking semantics for the browsers themselves and you would still want a type checker, such as Typescript, to actually check the types that are annotated. (Just as you want to run Mypy or Sorbet, respectively, in the cases of Python/Ruby.)
  - harel 4y ago
    Yes I meant type annotations. To be honest, given a choice, I opt for JavaScript. I personally don't find the benefit of TS is worth than all the extra work it requires, to make what is a dynamic language, not so dynamic. Why go for Python/JavaScript/Ruby if the first thing one does is to eliminate what makes it Python/JavaScript/Ruby? (Well, in the case of JavaScript, granted there's little choice available).
    - WorldMaker 4y ago
      I think tools like Typescript/Mypy/Sorbet exhibit is that there's a lovely "gradually typed" spectrum between "no type information/purely dynamic typed language" and static typing. "Gradual typing" has a lot of best of both worlds to it: write the raw and fast "no types" notebook code to proof of concept, then gradually add types as you test and productionize the same code. Production code can have lots of additional type checking and type testing that adds to robustness, while development and early code still have the benefits of a type system that can move fast and easily break things. It's nice to be able to move across that spectrum as a project matures. It's no longer a "hard binary" between dynamic typed languages and static typed languages, and you can choose much more interesting positions between 0% static types and 100% static types depending on your risk profile and interest.
iainmerrick 4y ago
Really glad to see we’ll now be able to import .ts files directly! Previously you had to import with a .js extension, or no extension at all. The price for doing so is to turn off code generation, so TSC is only used for type-checking. But that’s the best way to use TSC anyway!
Zuiii 4y ago
Has anyone found a way to get TypeScript to run directly in the browser without a build step since Microsoft removed the js files that did this? Basically, Is this following pattern still possible? <script src="cdn/typescript.js"></script> <script src="mycode.ts"></script> If not, what typed language do people here use for buildless front-end dev? I REALLY want to move away from weak-dynamically-typed PLs.
- alcuadrado 4y ago
  You can use typescript as jsdoc annotations
  - Zuiii 4y ago
    Can you please expand further? If I annotated my js, how would the browser check and enforce my types? Would the checks include js-to-js code? What is the js script that I should include at the top of my <head>?
    - binarycrusader 4y ago
      I’m guessing what’s documented here: https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported... I’ve never written TypeScript myself so just a guess. There’s also this for node.js: https://github.com/TypeStrong/ts-node https://github.com/TypeStrong/ts-node
    - schwartzworld 4y ago
      > how would the browser check and enforce my types? If this is what you're looking for, you aren't going to get it with TypeScript, even if you could parse it in the browser. It might be possible to port or build a TypeScript parser that runs in the browser (it might even be done already) but this would mean sending a LOT of code over the wire for something that was designed as a static analysis tool. You can use runtime validation libraries like https://zod.dev/ https://zod.dev/. JS will eventually include its own type system so that you will be able to write typed code and have it run in the browser. However, even then the types won't be checked at runtime. You'll still have to rely on a tool like `tsc` to type check your code.
throwaway09432 4y ago
Typescript is a good try, but ultimately our favourite JS runtime errors still happen, even with all the strictest ts settings. Syntactically it is quite clumsy, you can see the uninspired mix of C++ and Java in there. The typings now although people are doing lots of cute things with them, don't do some really fundamental things. For example there is currently no sensible way to type a non empty array in Typescript. Also the discriminated union with the identifying string literal in there is not terribly elegant. Personally I wish either Rescript or Purescript gained adoption instead.
- NoInkling 4y ago
  > there is currently no sensible way to type a non empty array in Typescript If we remove the "sensible" requirement: type NonEmptyArray = [any, ...any[]]
  - triyambakam 4y ago
    Or better: type NonEmptyArray = [unknown, ...unknown[]]; const nea: NonEmptyArray = []; // ^^^ Type '[]' is not assignable to type 'NonEmptyArray'. // Source has 0 element(s) but target requires 1.
    - throwaway09432 4y ago
      Can you map over this and preserve the NonEmptyArray type?
      - triyambakam 4y ago
        Do you mean pass in a type? type NonEmptyArray<T> = [T, ...T[]];
        throwaway09432 4y ago
        I mean if I have a NonEmptyArray say xs, and I then xs.map(x=>2*x), will the result of this expression be a NonEmptyArray ?
grtdhfttd 4y ago
awesome
grtdhfttd 4y ago
Really excited for the future of TypeScript! TypeScript ftw
zeroq 4y ago
Now that 5.0 is out let's talk about the roadmap for 6.0. I've heard it finally will be compatible with Java 1.4!

606 points by dimitropoulos 4y ago

Without Angular, we may very well not have TypeScript today. The top thing listed in this release (TypeScript doesn't follow semver, btw) is about Decorators. I find the whole story about Angular's role in TypeScript early days to be very fascinating because I don't hear people talk about it anymore (just search "AtScript TypeScript" if you weren't around at the time). It was the Angular team that forced Decorators to be added when it was still stage 0. In exchange, they forfeited continued work on their would-be competitor to TypeScript. Even without the Decorators thing, Angular was intensely popular and it made a big impact how they went "all in" on TypeScript, pushing a lot of early adoption. I know lots of people that first started with TypeScript because of work on an Angular project. I think a lot of people don't seem to know/remember how touch-and-go TypeScript was in the very early days. There were many large projects that were all-in on FlowType, and others still that were pushing for Elm, etc. For example, it took quite a while for you to be able to do JSX _at all_. Today, we just have TypeScript. Well. I do know one company that uses ReasonML (or isn't it called Rescript now?) --- Historical stuff aside, I'm extremely happy we ended up with TypeScript over the others because the team is so incredibly awesome and dedicated. It's rare you see such a large project so well shepherded by such a talented set of individuals. It speaks volumes that the average tenure on that team is so high. We've seen some public apologies from the Flow team on this topic so I don't feel like I'm talking behind anyone's back if I say they ended up truly not being up to the task of being what TypeScript is today.

deleted 4y ago
[deleted]
JamesSwift 4y ago
One of my most regretted decisions was evaluating Flow vs Typescript and going with Flow. Years later I had the opportunity to use Typescript and it was so nice comparatively. I've enjoyed it ever since. Of course, that was with years of development in its belt so maybe the experience wouldn't have been as nice if I went with it originally.
- dimitropoulos 4y ago
  Same. I spent the next few years doing major refactors from Flow to TypeScript (the largest that's public was for Insomnia: https://github.com/Kong/insomnia/discussions/3654 https://github.com/Kong/insomnia/discussions/3654).
- latchkey 4y ago
  I'm curious what criteria you used to pick Flow vs. Typescript.
  - myth_drannon 4y ago
    Flow allowed gradual typing of the project and Typescript forced you to convert everything at once(at least the first versions of TS)
  - dimitropoulos 4y ago
    for a lot of people it was some combination of: - Flow has more adoption (it did, for a while, in the OSS sphere) - Microsoft is evil (remember, this was before everyone was using VS Code and loving it. (Also, tautologically, TypeScript has been one of the biggest things that changed this public perception for the people I hang around)) - Facebook is awesome (oh, how times have changed...) - Flow has total type soundness as a goal (from the beginning, and through to today, TypeScript still lists this as an explicit non-goal) - You literally cannot use React and Flow together (it didn't support JSX for what felt like an eternity and Flow did from the beginning (I think?). - Flow had exact object types (TypeScript _sorta_ has this today, but most people don't know to turn it on because it isn't in the strict-mode family: exactOptionalPropertyTypes) - Flow had more features (and was faster) - DefinitelyTyped didn't exist yet, and it was easier to find types for Flow (but, let's be real, both had nearly nothing compared to today)
    - RyanCavanaugh 4y ago
      Total type soundness is not a goal of Flow. For example, array bounds are not considered. Flow considers this program to have no errors, but TypeScript (with the correct option enabled) will: let m = [1, 2, 3]; console.log(m[4].toFixed()); Also, DefinitelyTyped itself launched before Flow (2012 vs 2015), so the timeline on that point isn't right.
martypitt 4y ago
I remember this well. From the outside, it seemed a fantastic example of collaboration between two separate (competing?) teams. It took humility and pragmatism for the Angular team to abandon AtScript and recognise TS as the better long-term bet.
agency 4y ago
I have often thought that it must have been tough to be on the Flow team. It was pretty good, and absolutely would have been "good enough" to catch on if it weren't for TypeScript. But ultimately the better language won.
- epolanski 4y ago
  Flow ultimately served only Facebook purposes and their work and the evolution of the language wasn't on par with TS.
- dimitropoulos 4y ago
  And it doesn't hurt that the TypeScript team is so great. We've seen some public apologies from the Flow team on this topic so I don't feel like I'm talking behind anyone's back if I say they ended up truly not being up to the task of being what TypeScript is today.
  - maxloh 4y ago
    Any links to their apologies? I don't understand why they apologized.
    - RyanCavanaugh 4y ago
      I presume they're referring to https://medium.com/flow-type/clarity-on-flows-direction-and-open-source-engagement-e721a4eb4d8b https://medium.com/flow-type/clarity-on-flows-direction-and-...
      - dimitropoulos 4y ago
        yes exactly. The only other context I'll add is for people shipping Flow that I knew at the time they felt that this announcement felt like it came about two years too late. I had already switched to TypeScript long before because, in part, of the things they're apologizing for in that article which were evident long before being said out loud. I say that with great reverence and respect for the people that worked so hard on Flow, by the way, but that's the situation I experienced.
epolanski 4y ago
True, Angular was crucial for adoption of TypeScript 5+ years ago but I think the community would've migrated nonetheless.
- dimitropoulos 4y ago
  for sure for sure. that's kinda the point though: they already were migrating... to Flow. Lots of big projects are on the list that had to change course later because TypeScript won: - Yarn - Jest - Luxon - Gatsby - Expo - Styled-Components - GitKraken - GraphQL-js and that's just off the top of my head. I'm sure there were many more.
  - davnn 4y ago
    Do you have the impression that Flow once had greater adoption than TypeScript, or that there was a movement from TypeScript to Flow? I think it was always behind in adoption, but of course, some projects used it anyways. From my memory, Flow always felt like the less conservative cousin and it was tempting to use it, but TypeScript always was the safer bet.
    - dimitropoulos 4y ago
      I have to disclose my potential bias here because I am these days very involved in the TypeScript world (with Michigan TypeScript). That said, I would never hide the fact that I was once a die-hard Flow person that.. died hard, haha. (and I'm very glad I did! more on that later) In the very early days (in every circle I was in) Flow was ahead by every measure (known examples, excitement, adoption, features, speed, etc). You could point to real live running apps like GitKraken and Discord (hopefully my memory isn't failing me on those) that where shipping Flow very early. And you could use JSX! At the time there was literally no known project (especially OSS) actually shipping TypeScript. Not from Microsoft and not from anyone else. It was hard to tell if TypeScript was more of "embrace extend extinguish" (obviously with hindsight we can be absolutely certain that it wasn't that (unless we're talking about a decades long "long con" lol)) But there's something I could never have anticipated at the time that's more important to me today than any feature of the language: The TypeScript team have done a breathtakingly amazing job of carrying the project through the years. TypeScript, as an open source project, is an absolute triumph: and I think it has everything to do with the people behind it. At this point TypeScript is "good enough" in every way that really matters. If they consciously stopped developing the language and just focused on performance and bugs I think we should all call that a success. I really believe it's been handled _that_ well. Meanwhile Flow went the other direction and there were bugs (in the 0.30 era, approximately) that had people pulling their hair out that were caused by the impedance mismatch of them making it for Facebook first and the rest of the world last. As far as I can tell, this really never changed (or at least, if it did, then maybe it was "too little too late"). Meanwhile, it seems like TypeScript has been managed with the literal opposite mindset: putting us in a situation where only one major project is left using Flow... React. There are other projects like ESLint that have been... how do I say this in a not bridge-burn-y way... surprisingly reluctant to realize that TypeScript isn't some passing fad. But I'm confident that they're going to have their wakeup call sooner or later. The culture of JavaScript-land is just not loyal enough for gatekeeping a technology like TypeScript. Look at webpack. We all spent nights and weekends for years gaining knowledge on how it works and weeks per year getting familiar with it, then esbuild happened and we threw webpack away overnight like it never even happened. I believe the same fate awaits projects that deny the necessity of writing in TypeScript at this point in history, with the possible singular exception of React.
skratlo 4y ago
We have WASM dude. But TS people are in TS bubble for what it's worth.
- yCombLinks 4y ago
  It's not worth anything. Are you writing raw WASM?
- swatcoder 4y ago
  WASM and TypeScript don’t really compare or compete. I’m not sure what you’re saying.
- mc10 4y ago
  Until WASM can touch the DOM you’re still going to need JS (and hence, TS).
  - oaiey 4y ago
    And objects. And so many more things. Wasm is a cpu or low level operating system and not programming language
  - nicoburns 4y ago
    In fairness, rust-in-wasm has pretty complete DOM bindings. You can quite easily write DOM manipulation code in Rust without ever touching JS/TS. Whether that's a good idea is another matter.
    - maxloh 4y ago
      How does that work?
      - amaranth 4y ago
        web-sys[1] generates the binding code using the same IDL files that browsers use to generate their JS bindings to the C++ doing the actual work. [1] https://github.com/rustwasm/wasm-bindgen/tree/main/crates/web-sys https://github.com/rustwasm/wasm-bindgen/tree/main/crates/we...
cies 4y ago
> and others still that were pushing for Elm Still pushing for it. TS is like make-up on a pig, compared to Elm. > I do know one company that uses ReasonML (or isn't it called Rescript now?) Re* is also a better alternative imho. Better interop with JS/TS is very nice. But in place one could use Elm, I'd say it certainly wins in the "clean" reward.
spankalee 4y ago
AtScript was always stillborn, and the Angular team absolutely could not have made a competitor to TypeScript.
- dimitropoulos 4y ago
  Agreed, but the point I was making here is that Angular itself was very far from stillborn, it pushed early adoption of TypeScript really really hard which did wonders for TypeScript to be taken seriously.
- zaphirplane 4y ago
  Wonder why they didn’t go with the other google language Dart Too foreign to frontend audiences? It has a lot of fans in flutter
  - jsyolo 4y ago
    There was AngularDart, don't know what happened to it.
    - pax_americana 4y ago
      Publicly it's dead, but it's alive and well and constantly getting updated inside Google.
no_wizard 4y ago
>Today, we just have TypeScript. Well. I do know one company that uses ReasonML (or isn't it called Rescript now?) One company outside Meta?
- dimitropoulos 4y ago
  yes! haha. They love it. I ping them and see if they want to identify themselves.
  - armacham 4y ago
    FB migrated all of its ReScript to Flow and deleted the ReScript.
- illusionalsgcty 4y ago
  There's definitely a few around that are using ReScript; we've been using ReScript for production services for a bit more than 2 years now at Autobooks. https://rescript-lang.org https://rescript-lang.org has a list too
throw_m239339 4y ago
> Without Angular, we may very well not have TypeScript today. Typescript was started at Microsoft by the guy who designed Turbo Pascal and C#, so completely independently from Google's Angular team. Angular had its own "AtScript" and eventually ditched that. Typescript had experimental decorator support well before Angular Team moved from AtScript, because it was a ECMAScript proposal. Angular had zero influence in the design or success of Typescript. Typescript however does support JSX optionally so one can claim that React DID influence Typescript's design decisions.
- dimitropoulos 4y ago
  Even if that's true (it's definitely not how it was depicted at the time at conferences and from people on the Google side).. the point stands Angular was absolutely huge for it's day and they pushed TypeScript really really hard. It was a truce between two huge companies and it made waves in terms of people trusting Microsoft. I have personally never been one of those mega Microsoft haters but I witnessed shouting matches in the office from people that we're hotly opposed to TypeScript being added to the codebase against others using Angular as a core motivation in many of their counter-arguments. I'm super glad we have TypeScript one way or the other because the team is so dedicated to OSS.
  - throw_m239339 4y ago
    > Even if that's true (it's definitely not how it was depicted at the time at conferences and from people on the Google side).. the point stands Angular was absolutely huge for it's day and they pushed TypeScript really really hard. It was a truce between two huge companies and it made waves in terms of people trusting Microsoft. Angular.js was huge, by the time Angular version whatever because it was always changing, figured out what it wanted to be, most front-end developers already moved to React. What Microsoft product uses Angular? Doesn't Teams uses Angular.js but not Angular? and what does a Google conference has to do with Microsoft? Nothing.
- styfle 4y ago
  > Typescript had experimental decorator support well before Angular Team moved from AtScript Do you have a source for this. My memory isn't so good but I seem to remember that the Angular team pushed to get this Stage 0 proposal implemented even though the TypeScript team usually waits until Stage 2 or 3 to implement.
giraffe_lady 4y ago
god just think how good life would be if we had all switched to elm or reason instead.
- roebk 4y ago
  there's not a day that goes by that I don't think about this
- iudqnolq 4y ago
  If only Elm was infinitesimally less pure.
- rk06 4y ago
  Elm was never an option with how hard it is on "no js" policy
nikeee 4y ago
I remember this well, too. Ironically, I think that angular is the framework that benefits least from actually using TypeScript. There is a separate templating language that's only type-checked if you set the right compiler options. JSX is much better suited for that. Being OOP like angular, it often requires opting out of null-safety or init-checks, because something is late-initialized. Having mutable instance state results in less opportunities to be more strict with typing. Its good that the TS team decided to align with the ES standards. Initially (talking like v0.8.0), I had the impression that they're building a "C# for the web", being incompatible with ES. Maybe that's why enums and namespaces were added and initially, the boolean was named bool.
- WorldMaker 4y ago
  Enums have been proposed for JS for quite a while (there was a sort of enum in "the lost version" ES4 and a TC-39 proposal stuck in Stage 0 for years now [1]). Enums have always had relatively simple JS output that resembles a somewhat common pattern in JS. It was a "standard", just never really a deeply adopted "standard". What's today called "namespaces" in Typescript was originally called "modules" and then "inner modules" (to differentiate from "exterior modules") and is a tiny simplification on a JS pattern that was extremely common at the time of Typescript's inception called at the time "IIFE modules". "namespace" is a very C# name chosen in desperation (when it became clear that "exterior modules" were the present not just the future of the language and "interior modules" was too confusing a term to live), but it's a very old (and used to be extremely common) JS pattern that TS gave a tiny bit of syntax sugar to. It was a "standard" that existed at the time that was (rightfully) killed by AMD/UMD/CommonJS/ESM, but it is hard to fault the Typescript team at the early 0.x days thinking the "Stage Wild" JS pattern would possibly live on for many years to come. (This is also relevant to the patch notes for Typescript 5.0 as 5.0 is the first version [!] to itself be written as [proper/"exterior"] modules rather than namespaces. There are some interesting stories, including in these release notes for why that took so long to transition and what the performance benefits have been post-transition.) Even those things that didn't seem like ES standards have some history as JS "standards". It's not like TS 0.x/1.x didn't support "standards", it is more that the TS team mostly decided to focus more on later stage ES standards (more likely to be accepted by browsers) rather than trying to "prollyfill" Stage 0 and "Stage Wild" standards. [1] https://github.com/rbuckton/proposal-enum https://github.com/rbuckton/proposal-enum
truth_seeker 4y ago
Yep. Frameworks play an important role in end user (developers) helps deliver software as quickly as possible. Just like without Rails framework, we may very well not have Ruby today. Also, without WordPress, we may very well not have PHP today.

martypitt 4y ago

Congrats to the Typescript team. The rate of innovation from them is really impressive. Fantastic to finally see Decorators shed their "experimental" label (they've been the stable backbone of Angular for years).

simlevesque 4y ago
It's not the same decorators that existed before that were added. They don't have the same features. The new one are based on the upcoming EcmaScript decorators.
- WorldMaker 4y ago
  Also, Angular relies on parts of the "experimental" decorators that these Stage 3 decorators do not support, so Angular likely will continue to use the "experimental" compiler flag for some time to come, with the added twist that some uses of decorators will now also compile without the flag but will exhibit different behavior and won't run correctly, which may cause all sorts of new headaches for Angular developers.
  - spiralx 4y ago
    I just posted this in our FE channel at work > Note that the ECMAScript decorator spec now supported in TS 5 doesn't support decorating method arguments, unlike the experimental decorators TS has had an that Angular uses e.g. @Inject, @Self, @Optional etc. I'm guessing that this is part of the motivation behind the inject() function, where you can pass flags to it as a second argument to support cases like self or optional - it gives them a path to moving to the new-style decorators in the long-term. AFAIK argument decorators are only used for constructors, and that usage can be replaced by using inject() with flags, so a migration would be possible even today - although I'm sure there would be plenty of as-yet uncovered subtle implementation quirks! The obvious headache TS 5 will introduce is that failing to follow a decorator name with () will now attempt to treat e.g. Inject as a new-style decorator and cause a type error of some kind, which is likely to be confusing. I'm guessing the Angular compiler will have to do something to manage this, even if it's just ensuring there's a useful error message.

swyx 4y ago

> How? There are a few notable improvements we’d like to give more details on in the future. But we won’t make you wait for that blog post. the typescript project continues to set the bar extremely high in terms of changelog and clear communication. love you so much, drosenwasser and co!! > Decorators are an upcoming ECMAScript feature that allow us to customize classes and their members in a reusable way. huh. i thought this was a bit early to do this but i checked (https://github.com/tc39/proposal-decorators https://github.com/tc39/proposal-decorators) and looks like they've moved to stage 3. curious how this is going to change library/api design in the long term.

deckard1 4y ago
I don't think decorators being a proposal matters at this point. I know I've been using them for 5+ years now, and libraries such as NestJS already use them extensively. If you like them, you're probably already drowning in them. Me, personally, I could take them or leave them.
- madeofpalk 4y ago
  NestJS uses the previous, incompatible decorators implementation IIRC.
  - eropple 4y ago
    And, because it does so, you can fall down really deceptive holes due to the lack of typing around things that decorators apply to, like parameters. I don't think that changes with stage 3 decorators, unfortunately. It makes NestJS really error-prone, in my experience, and it's a big reason I stopped making tooling for NestJS projects.
    - WorldMaker 4y ago
      Yeah, it's going to be really "exciting" for Angular users as well in the next few years because Angular is drowning in those old "experimental decorators" which are not wholly compatible with today's Stage 3 decorators and the transition is going to be error prone and tedious. Up until TS 5.x it at least gave you a compile error if you tried to use decorators in code without the "experimental" flag, but now they will compile (except where they don't) even if you have the wrong flags but the behavior is so different between the flags it likely won't run. That's going to cause some interesting havoc.

azangru 4y ago

> But if you’re already familiar with TypeScript, have no fear! 5.0 is not a disruptive release, and everything you know is still applicable. Do you know what caused the typescript team to make it a major release? Has the decorator api changed sufficiently to become a breaking change?

demurgos 4y ago
Typescript always goes from version x.9 to (x+1).0. Please also note that TypeScript does not claim to strictly follow semver.
cacozen 4y ago
Internal refactors that included moving to ES modules and ended up improving overall performance and size.
- dcre 4y ago
  It's not a major release.
  - jakebailey 4y ago
    There's a full page of API breaks: https://github.com/microsoft/TypeScript/wiki/API-Breaking-Changes#typescript-50 https://github.com/microsoft/TypeScript/wiki/API-Breaking-Ch... Then, a new error about the deprecations of ancient options to be removed in 5.5: https://github.com/microsoft/TypeScript/issues/51909 https://github.com/microsoft/TypeScript/issues/51909
    - zdragnar 4y ago
      I think "major" was used in the semver sense, which is not how the TS team chooses version numbers.
      - jakebailey 4y ago
        Sure, we don't bump according to semver, but it's hard to say that 5.0 _isn't_ a major release given how we used it as a way to get a bunch of breaking changes and cleanups in. It's a very opportune time as people will be forced to manually upgrade and acknowledge that something is changing.

com2kid 4y ago

Question, is there anything decorators can do that higher order functions and higher order classes cannot already accomplish? I typically dislike decorators because they are spooky action at a distance, and whenever I look at code in a language that has decorators, the code almost becomes a DSL of sorts. Not that HoF and HoC don't tend towards the same problems, React used to be famous for how often HoC got used in the ecosystem and the confusion that caused!

epolanski 4y ago
The answer is obviously not since decorators still compile to higher order functions.
recursive 4y ago
"higher order class" is not a term I've heard before. I'm not sure what that could mean. Decorators are syntactic sugar for higher ordered functions. They fundamentally have the same capability, just with better ergonomics.
- zdragnar 4y ago
  Functions can return new class definitions- the "class" keyword represents an expression, not a statement. As such, you could write a function that takes in as an argument a class, and return a new class definition that extends the argument you provided... Or any number of other dubious practices.
- com2kid 4y ago
  Sorry, I meant a function that rips a class open, messes with it, and returns a new class!
anthlax 4y ago
Yes - decorators are syntactically nicer :)
jdlshore 4y ago
The EcmaScript implementation of decorators is quite nice—it’s just syntactic sugar for a higher-order function call. Much better than the spooky reflection-based approach you see in some other languages.

brundolf 4y ago

It's easy to miss, but I'm most excited for "--moduleResolution bundler" (https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/#moduleresolution-bundler https://devblogs.microsoft.com/typescript/announcing-typescr...) My understanding is it should allow you to finally have TypeScript files that import other TypeScript files and include the file extension. This is important because, for one, it means Deno TypeScript modules and non-Deno TypeScript modules are now compatible (can import each other)! As long as no unavailable system APIs are used, of course This has been a problem in a project I've been working on where a Deno back-end service wants to share some code with a Next.js front-end service. Currently, the shared modules are not able to import anything else, because Deno requires file extensions in import paths and non-Deno TS requires no file extensions in import paths

jakebailey 4y ago
"bundler" is definitely not going to be the right resolution mode for using Deno; you may be better served by using ESNext or Node16/NodeNext (the "strictest" mode, really). The "who should use this mode" section here I believe is still accurate: https://github.com/microsoft/TypeScript/pull/51669 https://github.com/microsoft/TypeScript/pull/51669
- brundolf 4y ago
  From the PR (https://github.com/microsoft/TypeScript/pull/51669 https://github.com/microsoft/TypeScript/pull/51669): > New compiler options > - allowImportingTsExtensions: Allow imports to include TypeScript file extensions. Requires '--moduleResolution bundler' and either '--noEmit' or '--emitDeclarationOnly' to be set. To be clear, I'm not using tsc to build code for Deno. I've got module X which imports module Y, neither of which have any platform-specific dependencies. Right now if module X imports Y with the .ts extension, Deno can import X but tsc can't. If module X imports Y without the .ts extension, tsc can import X but Deno can't. With this compiler option, I should be able to include the .ts extension and allow both to (independently) import the same code
  - jakebailey 4y ago

cies 4y ago

Slowly TS becomes a quirky Java. I for one am not cheering annotations (uhum decorators). I understand their power, but I preemptively lament the all the project that will over use them (yeah looking at you Hibernate).

suby 4y ago
I am in agreement with you. I think there is a danger in them over-complicating the language and everyone suffering as a result. I include regular javascript in this too, as Decorators appear to be coming to JS as well. I wasn't sure how to word this thought, but becoming a quirky Java is a good way of putting it.
nosianu 4y ago
TypeScript is ECMAscript. You remove the types and you get pure ECMAscript, apart from some very minor - and nowadays unneeded - additions such as enums or namespaces. TS also lets you do what Babel is for, translate the JS to earlier versions of JS. However, that has nothing to do with TypeScript itself, if your target runtimes support all the ECMAscript features you use you don't need to transpile, you only need to remove the type annotations, none of which are code (apart from the leftovers from early days mentioned above). So you would need to complain about ECMAscript. The decorators in this release, for example, are there because it moved to a stage 3 ECMAscript proposal last year, which means TypeScript must implement it now - because TS ECMAscript and not its own language. So they need to support all of at least stage 3 proposals of ECMAscript.

benatkin 4y ago

Does Number.isInteger() still not serve as a Type Guard? https://github.com/microsoft/TypeScript/issues/21199#issuecomment-357995171 https://github.com/microsoft/TypeScript/issues/21199#issueco...

RyanCavanaugh 4y ago
In TypeScript, type guards are considered to be exhaustive, so if you have a string | number and check it against a function that says it returns "x is number", then TypeScript will think that in the negative case, it's a string. If isInteger was marked as a type guard, then you could write code like this: function f(s: string | number) { if (!Number.isInteger(s)) { console.log(s.substring(0, 0)); } } which is clearly wrong. There's an open feature request for a new kind of "one-sided" type guards that don't cause narrowing when they return false.
- benatkin 4y ago
  That seems like an important feature request. I see TypeScript adding fancy stuff without fixing core limitations.
  - explaininjs 4y ago
    You can get around it pretty easily: const intSymbol = Symbol('integer') type integer = number & {[intSymbol]: never} const isInteger = (n: unknown): n is integer => Number.isInteger(n) function f(s: string | number) { if (isInteger(s)) { const allowed = s.toExponential() } else { // s still string | number } } With this you even get to define functions that must accept integers, which is kinda neat.
    - benatkin 4y ago
      That doesn't seem to address my concern. It seems like more of a curiosity. Whatever floats your boat.

endisneigh 4y ago

I have a strange take - I think Typescript types are better most other languages, including Java, C++ and Go. It's strange since TypeScript is adding types to a weakly typed language. If we could push JavaScript performance to be another order of magnitude faster it wouldn't be necessary to use other languages, imho. Of course, pushing it that far without effectively creating a new one would be difficult, to say the least.

mrits 4y ago
That is a strange take. It sounds like you think the reason people don't use Typescript is because of performance and not what some would consider a irresponsible ecosystem of abandoned frameworks and a language that provides little actual safety while still being unpleasant to use.
- quonn 4y ago
  It‘s not strange at all. I think them same. The type system of TypeScript is in practice much more useful than the one of C# or Java. Nothing is abandoned and in any case typically only a small set of libraries is needed which should be carefully picked.
deleted 4y ago
[deleted]
TOGoS 4y ago
Good take if you ask me. When I want to flesh out an ontology, I find that TypeScript's type syntax more natural than anything else. Generally I find it to do an amazing job of bridging between a very expressive and flexible type system and a language that at runtime knows nothing about your types. Want structural/duck typing? No problem; that's the default. Define new interfaces that old classes happen to implement without having to wrap them. I always wanted that feature! Want nominal types? No problem; just declare a field indicating the type name! interface Square { classRef: "http://example.com/Shapes/Square"; width: number; } interface Circle { classRef: "http://example.com/Shapes/Circle"; diameter: number; } type Shape = Circle|Square; (I like to express things in a way that can be easily translated to RDF, hence my use of URIs for type and attribute names) Since TypeScript types don't runtime checks, you can even do it on atomic types! type USDollars = number & { [Symbol.for("http://ns.nuke24.net/Synx/unit")]: "USD" } type CanadianDollars = number & { [Symbol.for("http://ns.nuke24.net/Synx/unit")]: "CAD" } const someAmount : CanadianDollars = someExpressionReturningUsDollars; // Compile error! Try doing that in Java! I OFTEN WISH I COULD

yanis_t 4y ago

Your regular reminder, that it’s just a regular release, since typescript don’t follow semver. After 4.9 goes 5.0

clarkdale 4y ago
From the release notes, it certainly seems minor / backwards compatible. > 5.0 is not a disruptive release, and everything you know is still applicable. While TypeScript 5.0 includes correctness changes and some deprecations for infrequently-used options, we believe most developers will have an upgrade experience similar to previous releases.
- brundolf 4y ago
  It does have some backwards-incompatibilities, but they're mostly minor/edge-cases
  - lozenge 4y ago
    So did the 4.x releases.
  - WorldMaker 4y ago
    It has one of the largest internal rewrites in TS history (namespaces to ESM switch), so it's somewhat incredible its backwards-incompatibilities list is mostly minor/edge-cases. (Which is to say that Typescript probably couldn't use semver if it wanted to because it has some extreme views on backwards compatibility, but also that this amount of codebase churn is absolutely semver breaking in the strictest semver senses even if it is mostly backwards compatible.)
kypro 4y ago
Is there a reason for this? Why even have the decimal if 4.9 -> 5.0 is just as significant as 4.8 -> 4.9. Just make it v49 -> v50 and remove the ambiguity. What am I missing?
- 4y ago

claytongulick 4y ago

Probably an unpopular opinion, but my favorite thing about typescript is what it's done for the jsdoc community. A bunch of stuff had to be built to support good tooling in vscode for types with JavaScript, and that was leveraged for jsdoc also. I don't use typescript, but I benefit from it in multiple ways, js doc and the occasional .d.ts file have made my life better.

c-hendricks 4y ago
If you use things like `import('some-package').SomeType` in JSDoc I don't think it's fair to say you don't use TypeScript. You do, that's only supported in TS.
- claytongulick 4y ago
  Yep, and I do. That's my point. I don't write typescript, but it has done wonders for the jsdoc ecosystem.
FractalHQ 4y ago
I get triggered by JSDoc and I really wish I didn’t. To me it’s clearly just more verbose Typescript with less features. I can’t understand the appeal, and most arguments I’ve heard for it can be summed up to “typescript is spooky and I don’t want to learn it so I’ll use this inferior thing instead”, which for my personality, is as hard for me to accept as it would be to suffocate myself by holding my breath. The only other argument being “no compile step” which is a non-argument in the age of modern bundlers.

quonn 4y ago

The missing feature I want most is type narrowing across chained functions like: arr.filter(a => a.kind === „bar“).map(a => /* a should now be of type Bar just like in a branch */)

subarctic 4y ago
Wait, are you saying they added that in this release? That's awesome!
- dhritzkiv 4y ago
  This is not part of this release.
acdibble 4y ago
This is possible with type predicates, example: https://www.typescriptlang.org/play?#code/C4TwDgpgBAYg9nKBeKBvKA7AhgWwgLigHIAzBIgbigDcsAbAVwMwZwCMIAnKAXwoFgAUKEhQAQlm4p02PISJtJlGvSaEAzsE4BLDAHNeAwUIDGcDJqjb18RCgAUtRs1tQAPuMkBKQk6ZX1WARkAD4VZwA6WWgkWOIyOEohIQATCBM6SWgzC2AoSU4sEEJ7Vw8JTi8AbQBdI1NzSxJtOmAuCBTkfM5CkAjm1q57a1svIwB6cahpqAA9AH4hIA https://www.typescriptlang.org/play?#code/C4TwDgpgBAYg9nKBeK... docs: https://www.typescriptlang.org/docs/handbook/2/narrowing.html#using-type-predicates https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...
silasdavis 4y ago
It was would be nice for this to be automatic but filter does work like this it you pass a type guard as the predicate: ``` arr.filter((a: A): a is A & { kind: 'bar'} => a.kind === 'bar') ``` If you define: ``` function isKind<K extends A['kind']>(kind: K): (a: A) => a is A & { kind: K } { return (a): a is A & { kind: K } => a.kind === kind; } ``` Then you can write: ``` arr.filter(isKind('bar')) ``` and get a properly narrowed return type array
- quonn 4y ago
  Nice, thank you

pjmlp 4y ago

I wonder when will be Typescript done, there is only so much that one can do adding a type system to JavaScript, without starting to become C++ like complexity language, which arguably already is.

nosianu 4y ago
It's already there. There are less and less new type features, all they do is implement any new ECMAscript proposals that made it to stage 3 at least. If you look at the changes of this and the last few releases, it's mostly internals, tooling and handling and other non-type things. Decorators are in TS 5 now because they made it to stage 3 last year. They have to follow the other current and future ECMAscript proposals and implement them though, so new features to be supported has for quite some time dependent almost entirely on the ECMAscript process. On the pure TypeScript side there was only minor tweaking and small corrections (for example, TS 4.8 brought "Improved Intersection Reduction, Union Compatibility, and Narrowing", clearly not a new feature but improvements to an existing one).
- pjmlp 4y ago
  Meanwhile tsconfig.json keeps getting bigger, with combinatorial explosion of Haskel like feature sets, regarding how a source file is to be understood. At least we get lots of opportunities for interview questions.

ssalbdivad 4y ago

Massive release! `const` generic parameters in particular have been a god-send for our repo’s static inference (https://github.com/arktypeio/arktype https://github.com/arktypeio/arktype) where previously we were forced to constantly rely on complex narrowing logic based on extends checks. I look forward to the day when we support 5.0 as our minimum version and replace all of them with `const` generics for 1:1-inferred definitions like this: const package = type({ name: "string", "version?": "number" }) Plus we’ll finally be able to remove the crazy hack we had to write to allow ts-morph to make type assertions on our codebase by transforming all of our `.ts` imports to `.js` in a virtual file system, which now that I think of it I’m probably looking forward to deleting even more XD Great work, and looking forward to what comes next!

dimitropoulos 4y ago
100%! I have a package that I've been running on nightly just to get this. Felt a bit like the wait for a const generics in Rust (except here, it didn't take long at all)!

syspec 4y ago

Unpopular opinion, but Please stop adding things to typescript

ofchnofc 4y ago
Why?

i_am_toaster 4y ago

I’m always surprised by how much others like typescript. Out of all the languages I have to use, typescript is the one that feels the most like pulling teeth. Maybe I just don’t know how bad it truly was to work with a really large JavaScript project without types and that’s why people love it, but without that experience it just feels like all the hassle of types without most of their benefits.

goda90 4y ago
It is truly bad to work with large Javascript projects without types. But I'm curious, what benefits of types do you feel you are missing in Typescript?
wnolens 4y ago
I feel the same, but when I complain I get blamed. Or someone chimes in with an illegible type/interface definition that solves my issue but is completely out of reach for all but language experts, which in other languages is not an issue.
- eropple 4y ago
  Can you provide an example of something you'd see in common use that is 1) not provided by an existing library (such that you are consuming a complex type rather than writing it) and is 2) "out of reach for all but language experts"?
madeofpalk 4y ago
I'm curious about what languages you're comparing it to. My other experience is with C# and Go, and I find Typescript's type system to be much more expressive and natural to work with.
ggregoire 4y ago
Your experience probably differs from people who like TS. Personally I don't feel any hassle from using it and I couldn't even start listing all the benefits it offers. Even for very small personal projects, first thing I do is installing TS. Not saying it's your case, but I noticed that a lot of people who hate TS like to use techniques and patterns that are usually considered bad practices, which often trigger errors in TS. Mutating an object to add a new property, mutating an array to add an element of a different type, processing apples and oranges in the same function without using generics or the correct union type, etc. Code works but TS doesn't like it and forces them to rewrite it properly and it feels like a hassle with no benefits. I also noticed that lot of people who don't like TS think they need to type everything (every variable, every function's return... which is obviously inconvenient) instead of relying on types inference. There is usually very little to type in TS (compared to Java or C# for example). The two main things are the parameters of your named functions and your external data (i.e. the fetch responses). Almost everything else can be inferred. I also observed that some people refuse to use VSCode (or any code editor with a good TS support). So they don't see any of the benefits while coding and think it's totally useless.

Waterluvian 4y ago

Does anyone else find that Enum is just not worth using and you’re better off with union types?

christophilus 4y ago
Yeah. I never use them. They don’t offer enough benefits vs unions.
- tgv 4y ago
  You can export enums as objects to javascript. And it's easier to change string enums than string unions.
  - WorldMaker 4y ago
    The typescript language server does a great job supporting rename refactors for string unions. It doesn't get much easier than that and is no harder than string enums, in my view. (I've done crazy things like use emoji named types in string unions and then used F2 to rename refactor them to a different emoji or name and not needed to worry if it missed any emoji literals.) The only thing missing from both string enums and string unions is something to support [Symbol.iterator]() to iterate through the available options, but at this point I find that easier to write DRY with string union types (especially with typeof/keyof meta-magic) rather than string enums.
cageface 4y ago
Yes. Now all I want is something like Rust traits or Swift protocols for unions.
spiralx 4y ago
Well as of this release enums are now also union types by default :) https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/#all-enums-are-union-enums https://devblogs.microsoft.com/typescript/announcing-typescr...

prmph 4y ago

I wish MS will fork Typescript into a new language altogether that transpiles to JS or compiles to WASM. In that case, they can remove all JS weirdness from it, simplify it, add a proper standard library, and add other good parts from other (especially functional) languages to it. My wish list for such a language (in addition to what is already in Typescript), in no particular order: - Generic object literals (Why should generic type inference be limited to functions?) - Deep support for an alternative to exceptions using a Failable<TResult, TError> type - Localizable keywords (Why should programming languages be tools of cultural hegemony?) - Dependent types, with no real distinction between values and types (At a certain point, Typescript’s type system begins to look like a separate Turing-complete language within a language. It’s probably time to do away with this dichotomy entirely somehow) - Higher-kinded types (This is a pending issue in TS since 2014) - JSX built-in without the need for any React-like dependency (No need to use it if you don’t like it; in the general sense, it’s just syntactic sugar for composing function invocations) - No return necessary (the last expression in a block is returned). Thus every flow control construct _can_ (but does not have to) be an expression. - No null, undefined, or any of all that, in favor of using a Maybe<T> type - Proper decimal types (it’s shameful for a language to be without it now) - A reasonably extensive standard library (Math, Stats, Collections (pull & push), String, Objects, Date/Time, Async, Functional, DOM, etc.) That would be getting close to the perfect language for me.

dmix 4y ago
> Deep support for an alternative to exceptions using a Failable<TResult, TError> type Is there a good library for this currently? I've been looking for one and a Maybe library. The Maybe one I use is pretty small.
- halfmatthalfcat 4y ago
  fp-ts (and most functional libraries) have a handy Either type just for this: https://gcanti.github.io/fp-ts/modules/Either.ts.html https://gcanti.github.io/fp-ts/modules/Either.ts.html
  - 4y ago

mtone 4y ago

In a monorepo with project references where each symlinked (not paths) package has a src/ and output lib/, I've always had issues with VsCode incorrectly proposing to import from src/ over lib/ from other packages. Never got it to work just right. Does anyone know if the new package.json resolution settings can help resolve these issues?

BLanen 4y ago

New decorators are so good. I absolutely hated how the experimental ones worked and try to avoid using libraries that use it.

chrismsimpson 4y ago

TypeScript is like having a glass of ice cold water in hell.

orange8 4y ago
You drink your glass of water, then continue burning forever and ever.

cutler 4y ago

Decorators - the kiss of death for any programming language.

dimitropoulos 4y ago
I encourage anyone who disagrees with this to give Nest.js a try (note: not Next.js)

harel 4y ago

What happens to TypeScript when ECMAScript brings it's core elements to the language?

WorldMaker 4y ago
Typescript for a while has focused on Stage 3 and Stage 4 proposals, so its "core elements" are almost all already in the language. Unless you mean the type annotations itself? The good news there is that there is a Stage 1 proposal to take the Python/Ruby approach of bringing them into the language: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations Were that to happen, that proposal doesn't apply any type checking semantics for the browsers themselves and you would still want a type checker, such as Typescript, to actually check the types that are annotated. (Just as you want to run Mypy or Sorbet, respectively, in the cases of Python/Ruby.)
- harel 4y ago
  Yes I meant type annotations. To be honest, given a choice, I opt for JavaScript. I personally don't find the benefit of TS is worth than all the extra work it requires, to make what is a dynamic language, not so dynamic. Why go for Python/JavaScript/Ruby if the first thing one does is to eliminate what makes it Python/JavaScript/Ruby? (Well, in the case of JavaScript, granted there's little choice available).
  - WorldMaker 4y ago
    I think tools like Typescript/Mypy/Sorbet exhibit is that there's a lovely "gradually typed" spectrum between "no type information/purely dynamic typed language" and static typing. "Gradual typing" has a lot of best of both worlds to it: write the raw and fast "no types" notebook code to proof of concept, then gradually add types as you test and productionize the same code. Production code can have lots of additional type checking and type testing that adds to robustness, while development and early code still have the benefits of a type system that can move fast and easily break things. It's nice to be able to move across that spectrum as a project matures. It's no longer a "hard binary" between dynamic typed languages and static typed languages, and you can choose much more interesting positions between 0% static types and 100% static types depending on your risk profile and interest.

iainmerrick 4y ago

Really glad to see we’ll now be able to import .ts files directly! Previously you had to import with a .js extension, or no extension at all. The price for doing so is to turn off code generation, so TSC is only used for type-checking. But that’s the best way to use TSC anyway!

Zuiii 4y ago

Has anyone found a way to get TypeScript to run directly in the browser without a build step since Microsoft removed the js files that did this? Basically, Is this following pattern still possible? <script src="cdn/typescript.js"></script> <script src="mycode.ts"></script> If not, what typed language do people here use for buildless front-end dev? I REALLY want to move away from weak-dynamically-typed PLs.

alcuadrado 4y ago
You can use typescript as jsdoc annotations
- Zuiii 4y ago
  Can you please expand further? If I annotated my js, how would the browser check and enforce my types? Would the checks include js-to-js code? What is the js script that I should include at the top of my <head>?
  - binarycrusader 4y ago
    I’m guessing what’s documented here: https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported... I’ve never written TypeScript myself so just a guess. There’s also this for node.js: https://github.com/TypeStrong/ts-node https://github.com/TypeStrong/ts-node
  - schwartzworld 4y ago
    > how would the browser check and enforce my types? If this is what you're looking for, you aren't going to get it with TypeScript, even if you could parse it in the browser. It might be possible to port or build a TypeScript parser that runs in the browser (it might even be done already) but this would mean sending a LOT of code over the wire for something that was designed as a static analysis tool. You can use runtime validation libraries like https://zod.dev/ https://zod.dev/. JS will eventually include its own type system so that you will be able to write typed code and have it run in the browser. However, even then the types won't be checked at runtime. You'll still have to rely on a tool like `tsc` to type check your code.

throwaway09432 4y ago

Typescript is a good try, but ultimately our favourite JS runtime errors still happen, even with all the strictest ts settings. Syntactically it is quite clumsy, you can see the uninspired mix of C++ and Java in there. The typings now although people are doing lots of cute things with them, don't do some really fundamental things. For example there is currently no sensible way to type a non empty array in Typescript. Also the discriminated union with the identifying string literal in there is not terribly elegant. Personally I wish either Rescript or Purescript gained adoption instead.

NoInkling 4y ago
> there is currently no sensible way to type a non empty array in Typescript If we remove the "sensible" requirement: type NonEmptyArray = [any, ...any[]]
- triyambakam 4y ago
  Or better: type NonEmptyArray = [unknown, ...unknown[]]; const nea: NonEmptyArray = []; // ^^^ Type '[]' is not assignable to type 'NonEmptyArray'. // Source has 0 element(s) but target requires 1.
  - throwaway09432 4y ago
    Can you map over this and preserve the NonEmptyArray type?
    - triyambakam 4y ago
      Do you mean pass in a type? type NonEmptyArray<T> = [T, ...T[]];
      - throwaway09432 4y ago
        I mean if I have a NonEmptyArray say xs, and I then xs.map(x=>2*x), will the result of this expression be a NonEmptyArray ?

grtdhfttd 4y ago

awesome

grtdhfttd 4y ago

Really excited for the future of TypeScript! TypeScript ftw

zeroq 4y ago

Now that 5.0 is out let's talk about the roadmap for 6.0. I've heard it finally will be compatible with Java 1.4!