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…
TypeScript 5.0
151–160 of 332 posts
Re: TypeScript 5.0
#152I’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.
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.)
Re: TypeScript 5.0
#153Re: TypeScript 5.0
#154Without 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…
> 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…
Re: TypeScript 5.0
#155I’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.
Re: TypeScript 5.0
#156Without 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…
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.
Re: TypeScript 5.0
#157Earlier quoted context omitted.
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.
NestJS uses the previous, incompatible decorators implementation IIRC.
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.
Re: TypeScript 5.0
#158I 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…
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…
A pile of thoughts on the subject from back when I first came up with it: http://www.nuke24.net/plog/32.html
Re: TypeScript 5.0
#159Earlier quoted context omitted.
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.
That doesn't seem to address my concern. It seems like more of a curiosity. Whatever floats your boat.
Re: TypeScript 5.0
#160Earlier quoted context omitted.
Have you tried Crystal? I got the same "oh, they got this right too" feeling about everything as well.
Crystal is excellent. I just can’t handle the sluggish compilation times. Has that improved?