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

51–60 of 332 posts

Re: TypeScript 5.0

#51

Post by rcme »

swatcoder wrote: post #43
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…

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

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.

Re: TypeScript 5.0

#52

Post by oaiey »

mc10 wrote: post #45
skratlo wrote: post #32

Earlier quoted context omitted.

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

Until WASM can touch the DOM you’re still going to need JS (and hence, TS).

And objects. And so many more things.

Wasm is a cpu or low level operating system and not programming language

Re: TypeScript 5.0

#53

Post by jakebailey »

brundolf wrote: post #46
jakebailey wrote: post #37

Earlier quoted context omitted.

"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

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

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

Re: TypeScript 5.0

#54

Post by throwaway56960 »

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…

TypeScript could be used with React at least since 2015, that's when I first used that combo in production.

Re: TypeScript 5.0

#55

Post by RyanCavanaugh »

benatkin wrote: post #47

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

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.

Re: TypeScript 5.0

#57

Post by mrits »

endisneigh wrote: post #50

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…

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.

Re: TypeScript 5.0

#58

Post by tlarkworthy »

imbnwa wrote: post #44
seanalltogether wrote: post #34

Earlier quoted context omitted.

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

Did't know Java had a `Promise` type

It has an equivalent but that code is typescript

Re: TypeScript 5.0

#59

Post by dimitropoulos »

RyanCavanaugh wrote: post #40
dimitropoulos wrote: post #23

Earlier quoted context omitted.

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.

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

Re: TypeScript 5.0

#60

Post by swatcoder »

rcme wrote: post #51
swatcoder wrote: post #43

Earlier quoted context omitted.

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

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.

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