[HN Gopher] TypeScript 5.0
___________________________________________________________________
TypeScript 5.0
Author : dimitropoulos
Score : 396 points
Date : 2023-03-16 17:19 UTC (5 hours ago)
(HTM) web link (devblogs.microsoft.com)
(TXT) w3m dump (devblogs.microsoft.com)
| i_am_toaster wrote:
| 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.
| madeofpalk wrote:
| 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.
| eropple wrote:
| I think that TypeScript, properly managed with things like zod
| or typebox, does an excellent job of giving me those benefits
| of types that I've come to expect while also having a really,
| really first-class development experience that reminds me
| (unsurprisingly?) of how actually-delightful using C# was in
| its heyday, with ReSharper and Visual Studio making it
| enjoyable. I genuinely don't feel any hassle around using it;
| the way that I can start with type signatures and then make the
| red squiggles go away is a really comfortable way to write code
| for me.
|
| For me, I was out of the JavaScript cinematic universe for a
| long time (from about 2011 to 2018) and TypeScript was my
| entree back in. What got me deeply into it, and has kept me
| there, is not that it's better than JavaScript, but that, for
| my purposes, it's better than my at-the-time common languages:
| Ruby, Java, and C#. It gives me most of the linguistic
| flexibility that I'm used to with Ruby, while preventing me
| from dealing with the worst thing about it (Other People's Ruby
| being high on my list of terrible things). At the same time, it
| provides a level of "fall into the pit of success" structure
| around the type system that's superior to Java or C#, while not
| being as difficult to access as Rust can be.
|
| (I like Rust, too! But the level of experience and skill
| necessary for somebody to be a "TypeScript operator" remains
| low, while letting those folks leverage really nice tooling
| built by folks like me who write TypeScript tools and
| libraries.)
| goda90 wrote:
| 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?
| mekster wrote:
| I hope your editor supports TS.
| ggregoire wrote:
| 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.
| wnolens wrote:
| 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.
| hn_throwaway_99 wrote:
| FWIW, when I first started getting into TypeScript from plain
| JS in 2019, I had a similar feeling. Part of it was that I was
| dealing with some object types of libraries I was using that
| were already quite complex. And, given all of the advancements
| in TS over the past few years, writing new types _can_ be quite
| difficult - there is just a ton there. E.g. TypeScript 's type
| language is famously turing complete.
|
| That said, I absolutely _love_ TypeScript, even just for small
| personal projects. The value I get from VSCode typeahead, and
| being able to look up the expected fields on, for example,
| parameters or return values of a function is invaluable, never
| mind its power in refactoring.
|
| I guess I would recommend that, if in the beginning, you feel a
| bit overwhelmed by TS and can't yet see its value, just give it
| some time. At least, that's what happened to me.
| Waterluvian wrote:
| Does anyone else find that Enum is just not worth using and
| you're better off with union types?
| christophilus wrote:
| Yeah. I never use them. They don't offer enough benefits vs
| unions.
| tgv wrote:
| You can export enums as objects to javascript. And it's
| easier to change string enums than string unions.
| dimitropoulos wrote:
| 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.
| no_wizard wrote:
| >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 wrote:
| yes! haha. They love it. I ping them and see if they want to
| identify themselves.
| armacham wrote:
| FB migrated all of its ReScript to Flow and deleted the
| ReScript.
| illusionalsgcty wrote:
| 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 has a list too
| giraffe_lady wrote:
| god just think how good life would be if we _had_ all switched
| to elm or reason instead.
| roebk wrote:
| there's not a day that goes by that I don't think about this
| nikeee wrote:
| 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 wrote:
| 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
| throw_m239339 wrote:
| > 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.
| RyanCavanaugh wrote:
| (I have worked on the TypeScript team since before its
| initial release)
|
| While it's true that TS would have been started with or
| without Angular, I think OP is largely correct in the
| influence that Angular's embrace of TS had in TS's long-term
| success.
|
| It's difficult to see these days, but if you were watching
| TypeScript's adoption numbers back when Angular made its
| TypeScript announcement, there is a marked inflection point
| when that happened. I was running lots of charts and graphs
| at the time tracking all kinds of data, and in every graph,
| you could see the Angular announcement in the chart; it's
| where the line went from kinda slow and linear to kinda fast
| and exponential. It was a true discontinuity in the second
| derivative.
|
| We can't run history twice and see what would have happened
| without Angular, but I think the quantitative impact in this
| timeline is undeniable.
| olingern wrote:
| I chose TypeScript for a large project for the first time
| in early ~2018 and had no idea how much history I had
| missed. I presumed that the adoption was the other way
| around and that TypeScript was chosen because it fit the
| project's needs, but just as grandparent and parent
| suggest, AtScript was very much a thing.
|
| Talk excerpt talking about Angular directives ~8 years ago!
| https://youtu.be/lGdnh8QSPPk?t=275
| jeremycarter wrote:
| Typescript was born of JScript. Check the history and the
| docs.
| dimitropoulos wrote:
| 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 wrote:
| > 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 wrote:
| > 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.
| skratlo wrote:
| We have WASM dude. But TS people are in TS bubble for what it's
| worth.
| mc10 wrote:
| Until WASM can touch the DOM you're still going to need JS
| (and hence, TS).
| oaiey wrote:
| And objects. And so many more things.
|
| Wasm is a cpu or low level operating system and not
| programming language
| nicoburns wrote:
| 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 wrote:
| How does that work?
| amaranth wrote:
| 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/we...
| yCombLinks wrote:
| It's not worth anything. Are you writing raw WASM?
| swatcoder wrote:
| WASM and TypeScript don't really compare or compete. I'm not
| sure what you're saying.
| epolanski wrote:
| True, Angular was crucial for adoption of TypeScript 5+ years
| ago but I think the community would've migrated nonetheless.
| dimitropoulos wrote:
| 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 wrote:
| 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.
| [deleted]
| cies wrote:
| > 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.
| JamesSwift wrote:
| 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.
| beaugunderson wrote:
| we started with Flow and moved to TypeScript a few years ago;
| converted 100k lines of code primarily with sed via regular
| expression find/replace; even then TypeScript was better but
| 80% of the better part was the library of available typings--
| Flow's support for lodash types was awful in comparison and
| we used lodash and lodash/fp all over the place
| brundolf wrote:
| I made the same mistake, though our transition to TypeScript
| was actually very smooth. We just set up Babel to handle
| both, then converted one file at a time. Flow files
| functionally became untyped JS files until they were
| converted. And the syntax/semantics were close enough that
| converting code was really easy
| dimitropoulos wrote:
| 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).
| TOGoS wrote:
| So it would seem that going with the flow turned out to mean
| not going with Flow; how confusing![1]
|
| I went with TypeScript early on because the compiler chain
| felt better integrated than the alternatives. No messing with
| chains of babel translators and source mappings; just use one
| tool. Maybe I liked the syntax better, also. Although as I
| recall, in the beginning, somebody my company interviewed had
| set up TypeScript using Babel, and it was all very over-my-
| head and impressive. He turned out to be too good to work for
| us, but some of his ideas really stuck with me.
|
| [1]This is why I dislike cutesy names for software projects.
| Just call it FacebookTypeAnnotatedJavaScriptFrobulator3003
| (FTAJSF3003) or something.
| latchkey wrote:
| I'm curious what criteria you used to pick Flow vs.
| Typescript.
| a_humean wrote:
| I remember doing a head to head comparison between Flow and
| Typescript back in 2015 or sometime around then, and flow
| came out top at the time. Main pull for flow for me was
| strict null checking and disjoint unions, which typescript
| lacked at the time.
|
| About a year later typescript got strict null checks and
| discriminated unions, and from that point on typescript
| just kept improving, the community type defintiions kept
| getting better, and flow felt like it was stagnating and
| had lots of performance issues (esp on windows machines).
|
| Flow actually still has a few notable features that
| typescript still lacks but are often asked for. For
| example, flow as `Exact` types that ensures that an object
| doesn't have excess properties throughout its lifetime -
| ergonomics are a bit awkward though.
| WorldMaker wrote:
| Typescript in strict mode doesn't allow excess properties
| in an increasing number of situations. Typescript is
| still more structurally typed than nominally typed so
| there's no easy way to opt-in a specific type to stronger
| checks than average. The ergonomics are obviously
| different between Typescript and Flow. There are existing
| practical workarounds today to get more "nominally exact"
| types in Typescript such as using "brands" of various
| sorts (the most common is adding a private unique symbol
| to a type), though the ergonomics of using such branded
| types is also its own sort of awkward.
| spoiler wrote:
| I personally picked Flow because it was (and still is
| probably?) a much sounder and stricter type system than
| TypeScript.
|
| However, keeping up with the constant breaking changes (I
| helped maintained a few complex flow typedefs) led to me
| getting disenchanted and burnt out with Flow.
|
| Also, at one point a change was introduced where most (or
| all) internal errors would just cause a type to decay into
| `any`s, which frustrated me a lot.
|
| I don't hold it against Flow though; its only customer is
| the internal React team, and it's a 0.x software too.
|
| We've migrated our code to TypeScript later and it was a
| bit smoother sailing (although the typedefs for a few
| popular react ecosystem libraries were just... Abysmally
| wrong, it didn't matter at the end of the day; it was still
| easier).
| altano wrote:
| Flow is more sound in a lot of ways (e.g. exact object
| types, by default!) but it also has huge holes (e.g. it
| has no equivalent to --no-implicit-any, the single most
| important strict flag in TS). Neither is strictly more
| sound than the other.
| brundolf wrote:
| We picked Flow because we were using React, and Flow was
| from Facebook, so we assumed the support/integration would
| be tighter than with TypeScript. It also had some appealing
| goals like stronger soundness, and a greater emphasis on
| type inference than TypeScript had at the time
|
| The main reason we switched was the tooling. The language
| server was slow in the best of times, would crash
| constantly, would memory-leak all over the place. Some of
| our devs stopped running it at all because it was so broken
| all the time. Then I tried out TypeScript and the speed and
| stability were breathtaking, and we never looked back.
| JamesSwift wrote:
| This was fairly early days (I want to say early 2016?), so
| its fuzzy now (and pre VS code going mainstream which has
| lowered TS friction pretty significantly) but I think a lot
| of it was a fairly basic pros/cons list with a lot of
| reading peoples opinions of using each technology. I think
| my ultimate reason was that Flow was comment-based and so
| was technically more "rip out"-able if I changed my mind
| later.
|
| EDIT: oh, also as someone else mentioned it was a React
| project, so I'm sure that played a part.
| mirekrusin wrote:
| Flow still has some better sides:
|
| * first class opaque type support
|
| * exact object type
|
| * correct variance, sound liskov oop
|
| * no transpilation support (/*: */ and /*:: */) - so
| simple, so powerful; jsdoc ts doesn't compare, you can't
| import type star, when consuming libraries you have to
| increase maxNodeModuleJsDepth and other shenanigans; in
| flow you simply have access to all flow type language; why
| they don't want to do the same with ts is beyond me, it's
| like half a day of work to do it?
|
| * nominal types for classes, structural for the rest - as
| it should be
|
| * correct spread matching runtime behaviour
|
| Flow is under active development. They recently completed
| ~2 years of work on local type inference which is a big
| deal. But dev team is not interested in external
| contributions - quite opposite to how ts development is
| done.
|
| I did switch to ts as well but do miss above.
| myth_drannon wrote:
| Flow allowed gradual typing of the project and Typescript
| forced you to convert everything at once(at least the first
| versions of TS)
| dimitropoulos wrote:
| 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)
| conaclos wrote:
| I am still attracted by Flow which seems to have a
| simpler and stronger type system. However, Flow seems a
| bit unstable and the lack of support for TypeScript
| declaration files and widely used TypeScript syntaxes are
| stopping me from switching to Flow. I opened an issue for
| bridging the syntax gap between Flow and TypeScript [0].
| Flow v0.201.0 renamed `$Partial` to `Partial` making Flow
| a bit more compatible with TypeScript. I hope it is just
| the beginning...
|
| [0] https://github.com/facebook/flow/issues/8989
| RyanCavanaugh wrote:
| 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.
| dimitropoulos wrote:
| > Flow tries to be as sound and complete as possible.
|
| > https://flow.org/en/docs/lang/types-and-expressions/
|
| That's what I was talking about re: Flow.
|
| That's a really insightful comment you make about the
| "turn of the phrase" between how the two marketed
| themselves. Super interesting stuff.
|
| also, apologies for messing up the timeline on the DT
| repo. My memory failed me there. Has it been that long?!?
| RyanCavanaugh wrote:
| TypeScript tries to be sound too. It wouldn't really make
| sense to write a type checker if that wasn't your goal.
| As the person who wrote the "100% soundness is a non-
| goal" line in the design goals document, that's there to
| serve the same role as "Flow sometimes has to make a
| tradeoff" in the Flow docs in terms of clarifying whether
| or not 100% soundness is a design goal. For both
| projects, the answer is "no".
|
| It's unfortunate that people have, over the years,
| decided that just being upfront about this fact means
| that TypeScript has a vastly different prioritization of
| soundness than Flow. We don't; both checkers use
| soundness as the default assumption when designing
| behavior.
| throwaway56960 wrote:
| TypeScript could be used with React at least since 2015,
| that's when I first used that combo in production.
| dimitropoulos wrote:
| it's going to be really hard for me to find now after all
| these years but there's a video somewhere on YouTube of
| someone at a conference showing their first attempts at
| getting TypeScript to work with JSX involving lots of
| special comments that they would compile out with babel
| or something (it's been a few years, hopefully I remember
| that correctly). It was pretty extreme (and cool!).
| alx__ wrote:
| As an "old person" it still weirds me out to see
| Microsoft get so much praise for their open-source
| developer tools
| martypitt wrote:
| 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.
| spankalee wrote:
| AtScript was always stillborn, and the Angular team absolutely
| could not have made a competitor to TypeScript.
| dimitropoulos wrote:
| 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.
| agency wrote:
| 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.
| dimitropoulos wrote:
| 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 wrote:
| Any links to their apologies? I don't understand why they
| apologized.
| RyanCavanaugh wrote:
| I presume they're referring to https://medium.com/flow-
| type/clarity-on-flows-direction-and-...
| epolanski wrote:
| Flow ultimately served only Facebook purposes and their work
| and the evolution of the language wasn't on par with TS.
| brundolf wrote:
| It's easy to miss, but I'm most excited for "--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
| veidr wrote:
| FYI, I just tested this, and it seems to work. I was a little
| concerned about the commentary in the PR about this new mode
| being "definitely not suitable for Deno", but I think what you
| want to do is the same thing I've been really irritated that I
| couldn't do before.
|
| Namely, I have an Nx monorepo full of standard TypeScript code,
| but that code works with a many things: Node, Electron,
| frontend apps with Angular or Svelte or whatever, etc.
|
| I want to use Deno for some new stuff, but Deno couldn't import
| any of that code without modifying that code so it no longer
| worked with all the non-Deno stuff.
|
| For a quick test, I made a new default Nx monorepo and a
| regular TS library and a Deno library and a Deno app.
|
| I changed all imports to use '.ts', and added this to the
| tsconfig.json: "moduleResolution": "bundler",
| "allowImportingTsExtensions": true,
|
| ...et voila! My Deno code can finally import all that normal
| TypeScript code I have sitting around.
|
| Haven't tested anything else yet, so I am not sure what, if
| any, issues those two changes above, plus including the .ts
| extension, might cause for other existing TypeScript projects.
| brundolf wrote:
| Exciting!
|
| It's weird to see this:
|
| > commentary in the PR about this new mode being "definitely
| not suitable for Deno"
|
| I wonder what they meant by that. I mean, this doesn't
| magically make all TS code Deno-compatible, but nobody
| expects it to. What it does do is remove by far the most
| ubiquitous (and silly) _barrier_ to TS code being Deno-
| compatible. There are others- system APIs, http imports. But
| this change allows a whole lot of code that doesn 't use
| those to become compatible
| veidr wrote:
| Yeah, I didn't get that either, when I read it, but I think
| what andrewbranch is talking about there[1] is that you
| _might_ still be able to have problems importing TypeScript
| code that is using the new "bundle" module resolution --
| because it may allow other things that Deno doesn't allow.
|
| I don't think he is talking about the problem we are, which
| is that because Deno _requires_ the .ts extension, Deno
| doesn 't actually work with standard, non-Deno TypeScript
| code (that imports other standard TypeScript code).
|
| I mean, until now.
|
| I will run some more extensive tests tomorrow or on the
| weekend, and maybe go comment there if I have something
| useful to say.
|
| But anyway, it seems to me that if, like me, your problem
| was "Oh no, I cannot import my code into Deno because I
| cannot add the '.ts' to my imports without breaking it in
| other TypeScript use cases" then that problem is solved in
| TypeScript 5.
|
| I have the same exact problem at work, except the monorepo
| is bigger and there are a lot of people who might not be
| excited to change all their import statements just so my
| own experimental Deno tools can use their code but... step
| by step. This seems like a big step for my personal
| TypeScript projects. :-D
|
| [1]: https://github.com/microsoft/TypeScript/pull/51669#iss
| uecomm...
| jakebailey wrote:
| "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
| brundolf wrote:
| From the PR
| (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 wrote:
| Ah, sorry; I brainfarted and missed the ".ts" part. I was
| thinking of the ".js" extensions, which are required in
| newer resolution modes (but are supported in older ones,
| and therefore using the strictest mode produces the most
| compatible code).
| ssalbdivad wrote:
| Since `.ts` extensions were in alpha, our repo has been set up
| so that you can switch between Node and Deno seamlessly in-
| editor and continue developing with no config or source
| changes.
|
| Personally, I found all the `npm` integration stuff to be a bit
| overkill for what we were looking for, and honestly Deno's
| network requests while installing from npm were constantly
| flaking out in our CI. We ended up just disabling it via Deno's
| `--no-npm` flag (https://github.com/denoland/deno/issues/17916)
| and reverting back to a simple set of import_maps to get the
| node deps we needed. Works like a charm!
|
| Feel free to reference if it's useful:
|
| https://github.com/arktypeio/arktype
| benatkin wrote:
| Does Number.isInteger() still not serve as a Type Guard?
|
| https://github.com/microsoft/TypeScript/issues/21199#issueco...
| RyanCavanaugh wrote:
| 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.
| slooonz wrote:
| How is it wrong ?
| silasdavis wrote:
| If s is a non-integer number
| HeavyFeather wrote:
| I mean, that could be changed.
|
| Currently: either string OR number
|
| Possible: either string | number OR just number
| [deleted]
| yencabulator wrote:
| "string | number | number" is just "string | number" to
| Typescript.
| benatkin wrote:
| The OR doesn't indicate | in TypeScript, it indicates the
| result of the possible future type guard.
| [deleted]
| benatkin wrote:
| That seems like an important feature request. I see
| TypeScript adding fancy stuff without fixing core
| limitations.
| explaininjs wrote:
| 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 wrote:
| That doesn't seem to address my concern. It seems like
| more of a curiosity. Whatever floats your boat.
| explaininjs wrote:
| How does it not address your concern? It's quite
| literally making isInteger into a type guard. The
| 'integer' type above can passed to any place 'number' is
| needed.
| [deleted]
| benatkin wrote:
| if (typeof s === 'number' && Number.isInteger(s)) {
| explaininjs wrote:
| What do you expect me to do with this snippet provided
| with no context?
| benatkin wrote:
| That's what I was wondering when I saw yours.
|
| What I was showing here is that this solution is simpler
| than yours and just as good. Rather than add a utility
| function and a faux primitive type, I just do the normal
| workaround for TypeScript not supporting this, which is
| to redundantly check that something is both a number and
| an integer.
| explaininjs wrote:
| The point of having a utility function is that you don't
| have to do the redundant checks every time you want to
| make sure it's both a number and an integer.
|
| The critical bit is that you need to define a new type
| for `integer`s distinct from `number`s to allow reusing
| the code in a way that doesn't break the type system on
| the negative path, as Ryan and I demonstrated.
| benatkin wrote:
| It isn't redundant in terms of the amount of code
| written, to me. The overhead of having the utility
| function and type is greater IMO.
|
| If it's in terms of performance, that seems like moving
| the goalposts. I also wonder if it could be optimized
| away.
|
| Next time I run into it I might use this:
| if (Number.isInteger(s)) { const allowed = (s as
| number).toExponential()
|
| ...and keep the isInteger check close enough that it's
| readable.
|
| ...or this: if (Number.isInteger(s)) {
| const n = s as number // should be optimized away by the
| compiler I think
| explaininjs wrote:
| You asked for isInteger to work as a type guard and I
| showed you how. If you prefer explicit casts everywhere
| that's fine, but it isn't a type guard. You could even
| use the type anonymously if you really want: (n is number
| & {Symbol(): never}).
|
| Whatever floats your boat, as you say.
| benatkin wrote:
| Oh boy, I never ever asked for a replacement for
| Number.useInteger! I prefer to use native functions.
|
| Have a nice day.
| [deleted]
| claytongulick wrote:
| 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 wrote:
| 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.
| endisneigh wrote:
| 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 wrote:
| 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 wrote:
| 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]
| mekster wrote:
| If performance is the only concern to pick a language, world is
| far simpler.
| TOGoS wrote:
| 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
| TOGoS wrote:
| Addendum to my nominal types: For the 'fake' nominal types
| (you can't put a symbol on a number!) I like to make those
| fields optional, which makes the type less of a lie. "If this
| number _did_ have a [unit symbol] property, the value would
| be 'USD'". That will still prevent accidental USD <-> CAD
| conversion, but allows converting to/from regular numbers
| without explicit casting.
|
| A pile of thoughts on the subject from back when I first came
| up with it: http://www.nuke24.net/plog/32.html
| spion wrote:
| I used to think so too, until I tried Rust.
|
| By comparison, JavaScript (and by extension, TypeScript) is
| still lacking fundamental features and the library ecosystem
| situation is pretty bad.
|
| I wish there was a modern language that took all the good non-
| manual-memory-management things from Rust and added a GC and
| some immutable data structures. Error handling, enums, macros
| (with compile_error! / diagnostics API), traits / approach to
| OOP, embedded tests, doctests and the relentless determination
| to add examples in the docs in general... Everything in Rust
| feels like "oh, they got this right too", which hasn't been the
| case for any other typed lanuage I've used in the past 15 years
| (including typescript, my previous favorite; purescript; go;
| haskell)
| [deleted]
| kaba0 wrote:
| Scala 3, or perhaps OCaml.
| jpgvm wrote:
| For me that's Kotlin.
|
| It's my general purpose language. I also use Rust everywhere
| Kotlin isn't suitable.
| hatuthecat wrote:
| You're basically describing Swift. Swift and Rust had a ton
| of cross pollination during their early years which led to
| those features developing similarly but memory management is
| a lot less targeted for extreme efficiency like Rust.
| Hopefully as the language continues to mature, the
| feasibility to use it outside of apple platforms also does
| because I really enjoy the language design.
| felipeccastro wrote:
| Have you tried Crystal? I got the same "oh, they got this
| right too" feeling about everything as well.
| christophilus wrote:
| Crystal is excellent. I just can't handle the sluggish
| compilation times. Has that improved?
| felipeccastro wrote:
| Nope, but working with fewer/smaller dependencies (like
| Kemal) it seems more manageable. Also, the feedback from
| type system is much faster than the full build, so I've
| noticed I don't need to run the app to test every small
| change like I do with ruby. There is also an interpreter
| mode available for testing, but I haven't tried it yet
| since that currently requires building the language from
| source. I'm hoping the interpreter will solve that DX
| issue entirely once it's ready.
| evntdrvn wrote:
| That's basically F#. It's great.
| jiggawatts wrote:
| I've been saying the same thing: We need an ahead-of-time
| compiled high level, _business_ language. Something as
| _efficient as Rust_ , but not designed for embedded
| microcontrollers or systems software.
|
| I feel like the entire industry has had a "kneejerk reaction"
| to C++ and its abysmally slow compile times. Everyone jumped
| onto the interpreter bandwagon and ended up throwing the baby
| out with the bathwater.
|
| It is definitely possible to have sub-second compile times
| for large, complex software! Just look at Jonathan Blow's Jai
| language. He can recompile and reload an entire 3D game
| engine in about that time.
|
| We can have our cake and eat it to. We can have efficient,
| compiled languages and still have safety and fast
| compilation.
| epolanski wrote:
| Well he said better than most, not best of every.
| jdthedisciple wrote:
| Have you tried C#? Sounds like it would fit your needs
| perfectly, additionally benefitting from a huge ecosystem
| behind it.
| rrishi wrote:
| How does the verbosity in C# compare to Java's? And are big
| C# codebases littered with annotations and "dependency
| inversion" Java Spring boilerplate-y crap?
|
| I ask because I have never delved into C# only heard it's
| Microsoft's Java. And I am no fan of the original Java at
| all so C# gives me pause.
| cutler wrote:
| C#11 defaults to nullability and has top-level functions
| giving it a big advantage over Java. The idiomatic Pascal
| case takes some getting used to but it's worth it.
| tester756 wrote:
| We don't do annotation-oriented-programming in C#
|
| DI is almost always in web, but via constructor instead
| of annotations.
| theshrike79 wrote:
| C# is pretty much Java done right.
|
| Speaking as someone who started with Java 1.2 and saw all
| the crap that happened to it.
|
| C# is currently lightyears ahead of Java in every way,
| especially now that MS is not Micro$oft to people on the
| internet any more =)
| spion wrote:
| I did, and I should've listed it. Its my third favorite
| typed language. At the time I was trying it, its type
| system wasn't as expressive as TS is today (no algebraic
| data types, no Result<T> error modelling in the type system
| etc), but LINQ with its clean syntax and ease of use is
| something I've missed in every language since (scala `for`
| syntax looks really awkward by comparison).
| MrJohz wrote:
| C# doesn't have algebraic data types and pattern matching
| though, right? I'm not the same person, but at least for me
| that's one of the big advantages of Rust, and it's one of
| those features that outside of Rust you only really find in
| ML-family languages. I know it's possible to simulate it
| partially using sealed classes in some languages, but
| that's always seemed like a lot of boilerplate in
| comparison.
| roebk wrote:
| Pattern matching was recently added to C#. I can't say
| quite how well it's been embedded into the language. I
| always hear great things about F#, ADTs, pattern
| matching, nice type system and it integrates nicely into
| the rest of the .NET ecosystem.
| physPop wrote:
| F# is great. Simple, small, straightforward, great
| interop with .NET
| virtualwhys wrote:
| > it's one of those features that outside of Rust you
| only really find in ML-family languages
|
| Or in Scala, technically not an ML, but is as close as
| you'll get in a nominally typed language.
| enum RGB: case Red, Green, Blue
| def log(x: RGB) = x match case Red =>
| print("red") case Green => print("green")
| // error, not exhaustive
|
| Obviously Scala can do a lot more, including GADTs, which
| Rust will never have until HKTs are supported.
|
| Ton of powerful languages to choose from these days, good
| times...
| WorldMaker wrote:
| C# has a lot of pattern-matching support today, including
| an expression-switch form:
| https://learn.microsoft.com/en-
| us/dotnet/csharp/fundamentals...
|
| C# can fake algebraic data types in some ways/some cases.
| Though if you are expecting to do a lot of it you are
| still better off in F# or C#/F# hybrid projects. (F# of
| course being a proper ML-family language.)
| [deleted]
| hackandthink wrote:
| >If we could push JavaScript performance to be another order of
| magnitude faster
|
| And it would speed up the TypeScript Compiler.
|
| My bet is:
|
| TypeScript typechecker in Rust:
|
| https://github.com/dudykr/stc
| epolanski wrote:
| TS is implementation-defined, it doesn't have a spec like C
| or Java.
|
| It's simply impossible to keep up with TS for competing
| compilers.
| treis wrote:
| The jankiness of JS combined with the correctness of TS really
| is a powerful combo. Especially stuff like string keys and
| const arrays as enums make safe and readable code without a lot
| ceremony.
|
| The big problem is the gap between TS and JS. User defined
| typeguards are a usable work around but it would be nice to be
| able to use a native isMyType function.
|
| Also would be nice to have constraints natively in types. Like
| string lengths or max ints.
| epolanski wrote:
| You can do all you list with effect-ts/schema.
|
| Arguably the highest quality TS lib out there.
|
| https://github.com/Effect-TS/schema
| epolanski wrote:
| Better is hard to qualify but I'll add my 2 cents:
|
| - for functional programmers TS offers lots of flexibility and
| power many other languages including statically typed and pure
| don't
|
| - TS functions or methods that throw don't show up in the type
| system (they do in Java)
|
| I hope TS keeps getting stricter.
| smt88 wrote:
| After using structural typing in TS, it's very hard to go back
| to nominal typing.
| throw_m239339 wrote:
| > 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.
|
| Typescript types don't exist at run time, at all. So it's easy
| to be better when your language is merely about static analysis
| as it will not enforce any sort of type system during runtime.
| Java, Go or C++ have different constraints.
| dimitropoulos wrote:
| that's a false equivocation in the sense that you just moved
| the goalposts by defining what "runtime" means.
|
| There are no types whatsoever as far as processors are
| concerned. No types in assembly Not for Go or Java, not for
| C, and not for Rust. All you gotta do is keep compiling.
| yencabulator wrote:
| Runtimes exist above processors, you know.
|
| Here's types existing at runtime: https://go.dev/play/p/rc
| --yVzJ9bt
| throw_m239339 wrote:
| > that's a false equivocation in the sense that you just
| moved the goalposts by defining what "runtime" means.
|
| I disagree, Javascript does have types and runtime type
| errors, just not all the ones Typescript compiler has, it
| makes Typescript extremely leaky as a Javascript
| abstraction. Typescript compiler cannot represent every
| single Javascript type combination either, it will would
| have to be a Javascript interpreter at first place.
| [deleted]
| rr888 wrote:
| I agree TS is great. Not really multi threaded kills it for me
| though.
| jdlshore wrote:
| Threads are a function of the environment, and are available
| in TS and other compiles-to-JS languages:
|
| Node.js: https://nodejs.org/api/worker_threads.html
|
| Browser: https://developer.mozilla.org/en-
| US/docs/Web/API/Web_Workers...
|
| However, threads are very rarely needed. The common use case
| in other languages is I/O, and JS environments handle that
| with async I/O--a superior choice, IMO.
| illiarian wrote:
| Neither of those are proper threads, and they have various
| limitations placed on them.
|
| And the language and the VM has been, and will be for any
| foreseeable future, single-threaded.
| mtone wrote:
| 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?
| chrismsimpson wrote:
| TypeScript is like having a glass of ice cold water in hell.
| azangru wrote:
| > 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?
| styfle wrote:
| There's a section in the article called "Breaking Changes and
| Deprecations"
|
| > TypeScript 5.0 has a minimum version requirement of at least
| Node.js 12.20 and later
|
| https://devblogs.microsoft.com/typescript/announcing-typescr...
| demurgos wrote:
| Typescript always goes from version x.9 to (x+1).0. Please also
| note that TypeScript does not claim to strictly follow semver.
| cacozen wrote:
| Internal refactors that included moving to ES modules and ended
| up improving overall performance and size.
| dcre wrote:
| It's not a major release.
| jakebailey wrote:
| There's a full page of API breaks:
| 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
| zdragnar wrote:
| I think "major" was used in the semver sense, which is
| not how the TS team chooses version numbers.
| jakebailey wrote:
| 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.
| martypitt wrote:
| 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 wrote:
| 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.
| swyx wrote:
| > 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) and looks like
| they've moved to stage 3. curious how this is going to change
| library/api design in the long term.
| deckard1 wrote:
| 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.
| dmix wrote:
| What do you use decorators for? I've never used them and I'm
| curious what the usecases are. The logging thing looks
| helpful.
| deckard1 wrote:
| silly things, mostly. Redux used them such as "@connect" if
| I recall. But I haven't touched those in awhile. Other team
| members invented various ways to use them, but none ever
| seemed to make things clearer or save much typing.
| madeofpalk wrote:
| NestJS uses the previous, incompatible decorators
| implementation IIRC.
| eropple wrote:
| 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.
| swyx wrote:
| yeah also feel quite ambivalent about them. theyre opaque
| syntax sugar. dont provide enough value to me personally but
| i wont begrudge others
| prmph wrote:
| 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.
| modeless wrote:
| If you're breaking backwards compatibility then my number one
| request is replacing UTF-16 with UTF-8 for strings and nothing
| else comes close.
| yencabulator wrote:
| You're asking Microsoft to undo a very Microsoft oddity that
| Microsoft seems to use just about everywhere. Good luck!
| modeless wrote:
| Windows finally added a UTF-8 locale. Sanity may yet
| prevail!
| dmix wrote:
| > 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.
| pjmlp wrote:
| 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 wrote:
| 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 wrote:
| 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.
| com2kid wrote:
| 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!
| jdlshore wrote:
| 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.
| super256 wrote:
| > 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.
|
| Yes, decorators are not evil by themselves, but they allow
| people to make poor choices easier. Having to debug decorators,
| fiddling with order of execution + scope binding/closures when
| setting multiple decorators, can (not sure!) become a
| nightmare; depending on the code base. Or we just go straight
| to the hibernate spaghetti. Imagining having to use three
| decorators with the same name, but different functions, makes
| me not to want to work with this.
|
| Having worked with (old) Java EE and Jakarta code bases, I've
| seen decorators being abused in 300 ways and breaking ABI in
| 600 ways, so let's hope we stay sane this time.
| ajkjk wrote:
| They're the same, but decorators encourage a programming style
| that is much easier to follow than HOF do. This way of using
| them is pretty standard in Python and it works well, imo.
| seanalltogether wrote:
| My favorite usage for decorators in java is for defining http
| requests, it lets you write stuff like this
| @GET("/users/{id}") function loadUser(id: int):
| Promise<User> {} @PUT("/users/{id}")
| function updateUser(id: int, user: User): Promise<User> {}
| topspin wrote:
| Can't fathom why annotation are used for this, except maybe
| as a holdover from years ago when Java didn't have certain
| language features. Other approaches in Java are much nicer
| and involve zero annotations. Example (from the Spark Java
| microframework documentation): path("/api",
| () -> { before("/*", (q, a) -> log.info("Received
| api call")); path("/email", () -> {
| post("/add", EmailApi.addEmail);
| put("/change", EmailApi.changeEmail);
| delete("/remove", EmailApi.deleteEmail); });
| path("/username", () -> { post("/add",
| UserApi.addUsername); put("/change",
| UserApi.changeUsername); delete("/remove",
| UserApi.deleteUsername); }); });
|
| All your endpoints concisely and composibly mapped out in
| code, and not smeared across dozens or hundreds of methods
| and classes. Not an annotation in sight; just plain old Java.
| syspec wrote:
| That looks worse.
|
| Shorter code is not always better code
| seanalltogether wrote:
| The code I posted above is used for client side apps, not
| server side. Client code typically has to accommodate
| calling different systems that use different patterns so
| having more flexibility in mapping endpoints to results is
| more important.
| imbnwa wrote:
| Did't know Java had a `Promise` type
| tlarkworthy wrote:
| It has an equivalent but that code is typescript
| divs1210 wrote:
| I didn't know Java had a `function` keyword.
|
| That is TS, not Java. Not sure why the gp is calling it
| Java.
| Jcowell wrote:
| They're not . They're saying it allows stuff like what's
| it's Java and the decorators in the TS code is exactly
| what it's like in Java.
| nobleach wrote:
| That's not Java. I believe they're demoing in Typescript a
| pattern they like from Java/Spring/Quarkus/Micronaut.
| imbnwa wrote:
| Ah yikes, read that too quickly
| epolanski wrote:
| The answer is obviously not since decorators still compile to
| higher order functions.
| recursive wrote:
| "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 wrote:
| 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 wrote:
| Sorry, I meant a function that rips a class open, messes with
| it, and returns a new class!
| anthlax wrote:
| Yes - decorators are syntactically nicer :)
| spankalee wrote:
| Decorators enable metaprogramming over class fields. Nothing
| before them has done that.
| swatcoder wrote:
| > almost becomes a DSL of sorts
|
| For mature projects with experienced, cohesive teams, that's a
| good thing. You _want_ a DSL that blends right in with your
| fully capable base language.
|
| But yeah, just like with any powerful feature, people can get
| excited and carried away.
| rcme wrote:
| I think some people want things to be DSL-like. However, I
| don't think, long-term, using a DSL-like syntax wins. Ruby
| was famous for abusing Ruby's unique syntax to make
| everything into a DSL and it turned off newcomers. Similarly,
| Java's DI frameworks meet a lot of resistance because of
| their heavy use of annotations. Ultimately, DSLs are separate
| languages. Most people don't want to learn a new language.
| swatcoder wrote:
| The countless users of popular third-party frameworks are
| the opposite of a "experienced, cohesive team" so I agree
| with you that it can and has caused problems there.
| BLanen wrote:
| New decorators are so good.
|
| I absolutely hated how the experimental ones worked and try to
| avoid using libraries that use it.
| ssalbdivad wrote:
| Massive release! `const` generic parameters in particular have
| been a god-send for our repo's static inference
| (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 wrote:
| 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)!
| cies wrote:
| 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 wrote:
| 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 wrote:
| 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.
| syspec wrote:
| Unpopular opinion, but Please stop adding things to typescript
| ofchnofc wrote:
| [dead]
| cutler wrote:
| Decorators - the kiss of death for any programming language.
| quonn wrote:
| 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 wrote:
| Wait, are you saying they added that in this release? That's
| awesome!
| dhritzkiv wrote:
| This is not part of this release.
| acdibble wrote:
| This is possible with type predicates, example:
| https://www.typescriptlang.org/play?#code/C4TwDgpgBAYg9nKBeK...
|
| docs:
| https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...
| silasdavis wrote:
| 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
| yanis_t wrote:
| Your regular reminder, that it's just a regular release, since
| typescript don't follow semver. After 4.9 goes 5.0
| clarkdale wrote:
| 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 wrote:
| It does have some backwards-incompatibilities, but they're
| mostly minor/edge-cases
| lozenge wrote:
| So did the 4.x releases.
| hbn wrote:
| Why have decimals at all then? Just increment by whole numbers
| every release. It's the exact same thing except with the
| decimal moved over to a sensible place.
| kypro wrote:
| 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?
| janaagaard wrote:
| One downside to having a version 4.10 is that some sorting
| algorithms put this release between 4.1 and 4.2 and not after
| 4.9.
|
| But yeah, they should just go ahead and follow semver from
| now on.
| Kwpolska wrote:
| Python went from 3.9 to 3.10 some time ago. And many people
| with YAML-based pipelines found out that 3.10 is turned
| into decimal 3.1, and ended up trying to build with an
| ancient version, because quoting was optional (and because
| YAML is a terrible language).
___________________________________________________________________
(page generated 2023-03-16 23:00 UTC)