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).
TypeScript 5.0
41–50 of 332 posts
Re: TypeScript 5.0
#42Earlier quoted context omitted.
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.
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.
Re: TypeScript 5.0
#43Question, 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.
Re: TypeScript 5.0
#44Question, 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 {}
Did't know Java had a `Promise` type
Re: TypeScript 5.0
#45Without 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.
Until WASM can touch the DOM you’re still going to need JS (and hence, TS).
Re: TypeScript 5.0
#46It'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
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
Re: TypeScript 5.0
#47Does Number.isInteger() still not serve as a Type Guard?
https://github.com/microsoft/TypeScript/issues/21199#issueco...
Re: TypeScript 5.0
#48Slowly 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).
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.
Re: TypeScript 5.0
#49> 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 tho…
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.
Re: TypeScript 5.0
#50I 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.