Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript 5.0

devblogs.microsoft.com

Post reply on HN
Print view View original

21–30 of 332 posts

Re: TypeScript 5.0

#21

Post by myth_drannon »

latchkey wrote: post #19
JamesSwift wrote: post #8

Earlier quoted context omitted.

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.

I'm curious what criteria you used to pick Flow vs. Typescript.

Flow allowed gradual typing of the project and Typescript forced you to convert everything at once(at least the first versions of TS)

Re: TypeScript 5.0

#22

Post by anthlax »

com2kid wrote: post #7

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 t…

Yes - decorators are syntactically nicer :)

Re: TypeScript 5.0

#23

Post by dimitropoulos »

latchkey wrote: post #19
JamesSwift wrote: post #8

Earlier quoted context omitted.

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.

I'm curious what criteria you used to pick Flow vs. Typescript.

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)

Re: TypeScript 5.0

#24

Post by jakebailey »

dcre wrote: post #17
cacozen wrote: post #11

Earlier quoted context omitted.

Internal refactors that included moving to ES modules and ended up improving overall performance and size.

It's not a major release.

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

Re: TypeScript 5.0

#25

Post by jdlshore »

com2kid wrote: post #7

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 t…

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.

Re: TypeScript 5.0

#26

Post by zdragnar »

recursive wrote: post #20
com2kid wrote: post #7

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 t…

"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.

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.

Re: TypeScript 5.0

#27

Post by brundolf »

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

Re: TypeScript 5.0

#28

Post by zdragnar »

jakebailey wrote: post #24
dcre wrote: post #17

Earlier quoted context omitted.

It's not a major release.

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

I think "major" was used in the semver sense, which is not how the TS team chooses version numbers.

Re: TypeScript 5.0

#29

Post by spoiler »

latchkey wrote: post #19
JamesSwift wrote: post #8

Earlier quoted context omitted.

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.

I'm curious what criteria you used to pick Flow vs. Typescript.

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).

Re: TypeScript 5.0

#30

Post by dimitropoulos »

epolanski wrote: post #14
dimitropoulos wrote: post #2

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 t…

True, Angular was crucial for adoption of TypeScript 5+ years ago but I think the community would've migrated nonetheless.

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.

Post reply on HN