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

31–40 of 332 posts

Re: TypeScript 5.0

#31

Post by ajkjk »

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…

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.

Re: TypeScript 5.0

#32

Post by skratlo »

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…

We have WASM dude. But TS people are in TS bubble for what it's worth.

Re: TypeScript 5.0

#33

Post by brundolf »

JamesSwift wrote: post #8
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…

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

Re: TypeScript 5.0

#34

Post by seanalltogether »

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…

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 {}

    @PUT("/users/{id}")
    function updateUser(id: int, user: User): Promise {}

Re: TypeScript 5.0

#35

Post by yCombLinks »

skratlo wrote: post #32
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…

We have WASM dude. But TS people are in TS bubble for what it's worth.

It's not worth anything. Are you writing raw WASM?

Re: TypeScript 5.0

#36

Post by cies »

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…

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

Re: TypeScript 5.0

#37

Post by jakebailey »

brundolf wrote: post #27

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

"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

Re: TypeScript 5.0

#38

Post by brundolf »

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.

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.

Re: TypeScript 5.0

#39

Post by swatcoder »

skratlo wrote: post #32
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…

We have WASM dude. But TS people are in TS bubble for what it's worth.

WASM and TypeScript don’t really compare or compete. I’m not sure what you’re saying.

Re: TypeScript 5.0

#40

Post by RyanCavanaugh »

dimitropoulos wrote: post #23
latchkey wrote: post #19

Earlier quoted context omitted.

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

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.
Post reply on HN