28 ms·

Ten Years of TypeScript

215 points by kbhomes 4y ago

Xeoncross 4y ago
Also see https://rescript-lang.org/ https://rescript-lang.org/ if you're considering learning Typescript Looking forward to more great ideas in the future of ways to 'fix' Javascript.
- argentinian 4y ago
  Does Facebook use it abundantly, or only on a few experimental projects?
- CharlesW 4y ago
  > Also see https://rescript-lang.org/ https://rescript-lang.org/ if you're considering learning Typescript I'd never heard of this, so here are a couple things I think are true after poking around a bit: • TypeScript is a strict superset of JavaScript that compiles to JavaScript, while ReScript is unique language that compiles to JavaScript. • ReScript is apparently a re-brand of "Reason(ML)", which is apparently derived from OCaml.
dynamite-ready 4y ago
Given the number of codebases littered with 'any', and the fact that TS is known to produce app bundles that perform slower than handwritten JS code, I'm in two minds about celebrating those ten years... But it is strange to think it's been ten years.
- mumphster 4y ago
  Do you have examples of slower code generated by typescript? TS is a superset of JS so it changing anything that has a large performance impact seems odd, but maybe I’m missing something here. The types aren’t even available at runtime, what’s the biggest slow down you’ve seen?
  - redox99 4y ago
    Most likely polyfills because he's targeting some old ES version.
  - dynamite-ready 4y ago
    https://thenewstack.io/which-programming-languages-use-the-least-electricity/ https://thenewstack.io/which-programming-languages-use-the-l...
    - int_19h 4y ago
      This claims that TypeScript is an order of magnitude slower than JavaScript, which is obvious nonsense if you know how TypeScript works, unless they counted transpiling in execution time.
- jmull 4y ago
  > TS is known to produce app bundles that perform slower than handwritten JS code I’m curious about this, and runs counter to my understanding of typescript. Do you have any sources on this? I’m googling a bit but not really finding anything.
- laundermaf 4y ago
  > TS is known to produce app bundles that perform slower than handwritten JS code Wrong. TS doesn’t bundle files. TS doesn’t produce code unless you target an earlier ES version than what you write, in which case there’s no way around it: native for-of loops and await/async will always be faster regardless of what you use to transpile it. I think you’re confusing the tool with something else.
  - mirekrusin 4y ago
    Ts does produce code, ie. for enums, modules/namespaces.
    - ksbrooksjr 4y ago
      Const enums get completely erased by the compiler, and modules are a native js feature. Non-const enums and namespaces are probably the only aspects of typescript that actually have any significance at runtime, but they get compiled into simple objects. The compiler output is very close to what you'd write by hand. Take a look at this compiler output here [1]. Unless you're constantly recreating enums and namespaces inside of a loop (which you'd never do in real life code), I can't imagine there'd be any performance penalty. [1] https://www.typescriptlang.org/play?target=99#code/HYQwtgpgzgDiDGEAEBlA9pAcuadFIG8AoJJCADxjQCcAXJeNYKegMzTSQF4kByAIxDVeRAL5EJEYAFcwqDBACiMucVKl2nHgKEjxRAPQGktABYBLKAyYsyKpAHdzAG2dJ+yCNRBQIAE3cATxNTZEYwGBcvIkZmeilZeUgAYRtaZUS1dQBHaXJuPlzyPSA https://www.typescriptlang.org/play?target=99#code/HYQwtgpgz...
      - mirekrusin 4y ago
        So ts does produce code.
        ksbrooksjr 4y ago
        It can (depending on which features you're using), but the comment that started this thread claimed that the produced code was much slower than handwritten js. I was just pointing out that the examples you gave (enums and namespaces), don't change the performance of your code.
mirekrusin 4y ago
We need: - exact object type - match expression flow is still better at: - OO - nominal typing for classes, conforming to liskov substitution principles - first class opaque types - first class exact object types - better flow based inference - comment types - no extra dsl, full access to the language, so simple, so powerfull for the times you don't want transpilation phase - [edit] spread types map to spread in runtime
- qudat 4y ago
  You can’t type generators properly a la redux-saga
- krosaen 4y ago
  I don’t understand the benefit of nominal typing when structural typing is available?
  - mirekrusin 4y ago
    You can't use `instanceof` ie. for your error types, actually every time you use class that extends something - it'll not be typed correctly. Basically nothing OO/class/inheritance related is typed correctly. Flow does it correctly.
  - nine_k 4y ago
    The idea is that two types with the same structure aren't always the same thing. This is easily solved by a tagged type in TS [1], though a bit of syntactic sugar over it would be nice. [1]: https://kubyshkin.name/posts/newtype-in-typescript/ https://kubyshkin.name/posts/newtype-in-typescript/
    - mirekrusin 4y ago
      Tagging doesn't solve inheritance problems - object oriented inheritance needs to follow liskov substitution principles, support variance correctly. Tagging is good for making sum types out of union types, but that's not enough for class inheritance. Flow does it better by having first class opaque type aliases btw (and having nominal types with oo inheritance support on classes of course).
ht85 4y ago
As a web-focused software engineer, I can safely say TypeScript is the best thing that happened to my work in the last decade. Aside from the known direct benefits of safety and self-documentation, I've found over time that having a pleasant, smooth coding experience and producing elegant code required me to think differently. I work on a project with very complicated and overloaded business logic, but nowadays my code looks very... "algebraic"? state machines within state machines, exhaustive switches everywhere... Maintaining and modifying such code has been a joy compared to the old ways. Most of the work is just adding a new member to some union or an attribute to a type, following the red trail fixing errors and voilà.
- dccoolgai 4y ago
  The real genius of it is that it's really not a "type" system at all: it's a contract system. The nearest thing like it was Eiffel. The new "satisfies" feature in 4.9 makes this even more clear. Honestly there's so much space to cover here, I think it's just going to keep getting better and better.
  - dalmo3 4y ago
    Wow! `satisfies` solves a problem I was working on yesterday. Remarkably, it's not the first time a new TS feature immediately makes way into my code.
    - dccoolgai 4y ago
      It's such a powerful complement to the "no rules" JS when you layer it on top. You really get to have your cake and eat it, too. I feel like there's another huge step to take in "layering" invariant checking on top of TS for QA/test systems... Imagine like "in all 500 of my tests, make sure this variable is an integer greater than 10 at all times no matter what". I'm waiting for this to show up
  - eyelidlessness 4y ago
    I’m curious what you’re distinguishing here. To me a type system and a contract system are identical concepts with different descriptions. It seems like you might be highlighting the structural typing aspects of TypeScript’s type system versus nominal or concrete types in many others, but that’s been clear for most TS usage for since well before `satisfies` so I’m not sure if my interpretation is right.
david2ndaccount 4y ago
The number one problem with typescript is how slow it is. Compiling a 14k line project takes 5s. This is absurdly slow.
- Tajnymag 4y ago
  Typescript by itself is just the language. You could try a different typescript compiler like esbuild for example.
  - david2ndaccount 4y ago
    > However, esbuild does not do any type checking so you will still need to run tsc -noEmit in parallel with esbuild to check types.
    - Tajnymag 4y ago
      You're right, I didn't count with that
    - jcparkyn 4y ago
      Personally, I find that I don't really need full type checking on every build. For most small changes, the errors shown in vscode are sufficient while editing, and then full type checking can be run occasionally when needed (and in CI of course).
    - DangitBobby 4y ago
      Your IDE can be doing type checks on whatever file(s) you're working on, you can use esbuild or swc to compile to javascript to make sure it runs correctly, and you can periodically use tsc to fully compile and typecheck your entire codebase to catch anything that you somehow missed in the IDE.
- wwwigham 4y ago
  When you can write a busy beaver machine in the type system, LOC ceases to be a good indicator or how long something should take to typecheck, imo. If you're frustrated with your build, you should use the trace tools on the TS wiki[1] to track down what types are slow to check, so you can attribute the slowness to the appropriate library authors/yourself and decide for yourself if the speed/correctness tradeoff they've made is right for you. [1]https://github.com/microsoft/TypeScript-wiki/blob/main/Performance-Tracing.md https://github.com/microsoft/TypeScript-wiki/blob/main/Perfo...
cehrlich 4y ago
TypeScript is the best thing to happen to web dev, and it keeps getting better. My only gripe is that sometimes in a codebase that is heavy on inferred types I need to restart the TS server occasionally. Nonetheless, unless there is a specific requirement that TS isn't the right choice for, it's the language I reach to for everything.
- nesarkvechnep 4y ago
  Do you have interests beyond the JS world? TypeScript being the best thing to happen to web dev sounds a bit hyperbolic.
  - schwartzworld 4y ago
    The vast majority of web apps have JS on the front end. It's not even close.
  - cehrlich 4y ago
    There are a lot of other great languages, but none of them run in the browser. Once you know that your frontend is in TS, there are a lot of advantages to writing the BE in it also. Like I said, there are exceptions, but it has become my default.
gavinray 4y ago
TypeScript has my second favorite type system, right behind Scala 3 To me, that's saying something.
Yahivin 4y ago
This seems like a great time to announce my successor to CoffeeScript: Civet, a language that transpiles to TypeScript. https://github.com/DanielXMoore/Civet https://github.com/DanielXMoore/Civet
- msoad 4y ago
  TBH I have 99 problems but the syntax is not one
  - Yahivin 4y ago
    Civet also fixes: `import x from "./x.ts"` and unifies `readonly` and `const`. I'll get back to you when I fix the other 97 but until then there's no accounting for taste.
- bilalq 4y ago
  Oh, I like this. A pure syntactic sugar over a language that otherwise preserves semantics is neat. Nice work on documenting what was kept/changed/removed too. Really easy to see at a glance what the project is all about. Love that there's an online playground, LSP, and VSCode extension along with it.
  - Yahivin 4y ago
    Thanks! It's still a work in progress (especially the LSP) but it is usable in its current state and is getting better all the time.
- elwell 4y ago
  I used to love CoffeeScript. Will check this out!
- runes 4y ago
  Very cool! For years I've wanted to fork LiveScript and integrate it with the TS checker somehow (and remove `on/off/yes/no`, good call), sort of an F# to TypeScript's C#
- 4y ago
michaelwww 4y ago
Debate (almost 10 years ago) TypeScript vs. Dart about the best way to improve JavaScript Anders Hejlsberg (Microsoft) and Lars Bak (Google): TypeScript, JavaScript, and Dart https://www.youtube.com/watch?v=5AqbCQuK0gM https://www.youtube.com/watch?v=5AqbCQuK0gM
mr_johnson22 4y ago
Honest question: why did TypeScript succeed while ActionScript 3.0, another ECMAScript-superset language with typing and OOP (and predates TS by a few years), is all but a distant memory? Is it more than just Adobe being a terrible steward of its tech? With that said, TS is definitely a blessing; I recently had the privilege of migrating to it after having written a hobby project in plain JS, and the difference in usability between the two is night and day. But I can't help but feel that I've seen this all before years ago in AS3.
- blackoil 4y ago
  Wasn't fate of ActionScript strongly tied to Flash? As much as some open source community try, they can't beat the full force of the investment done and talent assembled by Microsoft.
- jmull 4y ago
  I liked AS3 quite a bit, but it was limited to Adobe products. I don’t think it was ever given a chance to make an impact beyond Flash and Air.
  - throw_m239339 4y ago
    Well no it wasn't limited to Flash, since it was supposed to be ES4. This is why ES4 doesn't exist as a standard, Javascript went from ES3 to ES5.
    - jmull 4y ago
      I'm aware of how they were related... AS3 was based on ES4 ideas, and, as the major implementation of ES4, AS3 influenced the evolving direction of ES4. But ES4 was never really finished to the point where everyone who needed to actually agreed on it. I think MS, who had a browser monopoly at the time, was never going to agree to something that made Adobe Flash more important. It seems crazy now, but at the time it seemed like a real possibility that browsers could end up mere shells for the real internet runtime, Flash Player.
umvi 4y ago
I like the idea of typescript. I tried to port a vanilla js browser game to typescript and I found it introduced a lot of complexity to the project. It sucked me into the npm ecosystem and forced me to rewrite every file to use js modules import/export syntax and a bundler like webpack to resolve all the modules business for browsers when none of those were needed before. Of course I could set TS modules to none but then I lose access to typing of any third party libraries I'm using like PixiJS. And my CI pipelines are like 10x slower now because I need npm to install and compile and bundle stuff which is really slow compared to my previous CI pipeline which simply concatenated the js files together with `cat`. Does this sound right or an I missing something? What I want: To be able to just type annotate my existing JS without needing modules, but also have TS be able to pull in type information of 3rd party libraries by pointing it to the appropriate .d.ts file. I suppose that's having your cake and eating it too in this case.
- dynamite-ready 4y ago
  This is closer to my opinion. I write a fair amount of Typescript, but it's frustrating to see it used so ubiquitously, when in a lot of cases it's just not necessary. A strongly typed language definitely has a place in web UI development though. But my hope is to see it replaced by a WASM based language, or better still, a choice of WASM based languages.
  - pragmatic 4y ago
    In what cases do you see it when when not necessary?
    - dynamite-ready 4y ago
      If you look at how Python is used in 3D graphics (or similar DSLs in the more esoteric 3D apps), they've been using the scripting system in the likes of Maya and Blender to create inordinately complicated systems for decades. Like 3D graphics, a lot of UI code is visual, ephemeral, complex. The development process for such features, benefits from from the speed of iteration and flexibility that dynamically typed code can provide. Granted, a checkout, or a clinical case management form (for example) will definitely benefit from the kind of precision a strong type system will encourage. Beyond that, we should think more about the how and why, because type wrangling can slow down delivery, experimentation, and cannot guarantee the prevention of bugs. Gmail and Google Maps for example, at least when those projects started out, had no TypeScript in their UI code. Google Maps, even in it's earliest iteration, far outstrips the complexity of most TypeScript applications in the wild today. And also has a greater requirement for precision than many of the applications that we can call to mind, outside of Finance, Transport, Construction, or Medicine. People seem to talk as though certain applications were impossible to build without without TypeScript, but that is simply not true. So TLDR, answering the root of your question, TS is not at all necessary. But it can be helpful. Yet we're in a position now where it's almost intractable, and I don't think that's an ideal situation.
stephen 4y ago
Great post/looking back at the core decisions/bets that worked out really well (from the post): * "Impose no runtime overhead on emitted programs." * "Align with current and future ECMAScript proposals." * "Preserve runtime behavior of all JavaScript code." * "Avoid adding expression-level syntax." * "Use a consistent, fully erasable, structural type system." I also really liked the callout of their approach to "innovating in the type system around conventions and patterns found 'in the wild' of the JavaScript ecosystem." This "you can still write the JS-style APIs you want, just safely" is a stark contrast to the Dart/ActionScript/others options mentioned in the HN thread, which said "you have to give up the JS-style APIs you have, and instead write 'basically Java'". It's also amazing how TS 1.x itself was "basically Java" (in terms of a type system, albeit except being structural), but so many of the TS 2.x type systems innovations (mapped types, conditional types, etc) look as if they were designed in the language from day 1. One other point, the post calls out they didn't add extra syntax to JS, only types; in this regard, I think TypeScript frankly got lucky by how much JavaScript itself has evolved in the last 10 years. Like if JS had been going through a "10 years of sterility" period like Java did from ~2005-2015, then TS itself would have been greatly hindered and probably would have had to jump to syntax-level changes, like the Scalas and Koltins and other Java.nexts had to do. So, kudos to JS itself for also evolving extremely well from its ~2010 everything-is-a-callback early days, and letting TS stand on its shoulders.
- Sankozi 4y ago
  In most programming languages JS style APIs (i.e. give me anything and I will try to interpret it somehow in an undocumented or poorly documented way) are antipatterns. TS is often bringing sanity to libraries that switch from JS to TS. I think TS team is doing really great job. I would not call it standing on the shoulders of predecessor, more like trying to build something stable on the swamp. JS definitely does not have a positive influence on TS. TS is not a great programming language, but it is really great accomplishment considering that it supports and extends JS in a such good way.
- pas 4y ago
  If JS were slow to add new features TS would probably not have the wait and see policy.
blackoil 4y ago
Is there any effort ongoing to add optional type declaration to Javascript? Runtime type info. would make lot of use cases possible.
rektide 4y ago
Generally a huge positive. With tools like swc, there's really fast compilation & typechecking now. With --watch, the DX is pretty good but yeah sometes has to be restarted anyways. A couple not so greats: Typescript has added a lot fo confusion & chaos to the ESM transition. A lot of typescript code is in ESM style, byt if you pull the package, it outputs cjs or what not. TypeScript 4.8- very recent- is the first to actually have a semi-viable Node.js + ESM story going; being a respectably modern package hasnt even really been possible with typescript until just recently. Not fully typescript's issue, but writing a package.json that fully helps consumers is quite difficult, and there's a lot more to grol.woth typescript in the mix. There's such a long long tail of typescript packages that are going to be the long long hold up for getting to ESM cleanly. It's not that hard to change, but awareness is just low, and friction is high while we are still so stuck-in-the-middle. Typescript makes writing code easy, but outputting a good respectable usable library has been impossible & is still not easy. Woe. I really hope EcmaScript does get type annotations, which could eliminate so much of the need to compile & let typed code just run untyped, elide so many of these difficult transpilation challenges. Another major issue for typescript is that it is stil so compile-time focused, that type metadata isnt kept intact. It's wild to have such a vast typing system, but to just throw it all out at compile time. To be fair, object metadata in js has been tied to annotations, which has been long long delayed, a huge struggle for the language, so there's not clear targets for how to output type information, but there have been some goes, some works to add runtime type information to typescript & there's so little follow up, so little engagement. All TypeScript feels like such a sharply more limited less useful less ambitious project than what it should be doing, than what a real language+runtime would be. It feels like typescript lives in the shadow of a much more clear & visible greatness.
- david2ndaccount 4y ago
  I thought swc still doesn’t do type checking and just strips the type annotations?
  - rektide 4y ago
    Hrrmmm. I've been using the newer Jest testing library releases & they are supposedly powered by SWC. I definitely see some typechecking errors, & assumed this was also swc. But I see little evident in the swc project they've made headway here. Im not sure what Im experiencing in jest. It's definitely not the same level of typechecking. But there's definitely something there & it's definitely much faster start time. Thanks for writing; Im curious too.
bluepnume 4y ago
I was a long time Flow hold-out, switched to TypeScript a year ago and never looked back. There are a few things I miss, and a few things that Flow did do better; TS is obviously not perfect. But it's a real joy to use. As for people writing JS in 2022 without any kind of static typing: I fear for you.
repox 4y ago
I've spent the last two years working with TypeScript solely. Coming from ~20 years with PHP and using Kotlin and Dart for some years as well, I feel that I'm doing something wrong. I absolutely loathe working with TypeScript. The community is the most fragmented I've ever experienced, the silly amount of package managers, builders... TypeScript just doesn't fit with me.
- rroot 4y ago
  Typescript itself is fine. But yes, if you are using 3rd party libraries and frameworks with typescript, you might wonder if it's too late to change career and become a monk.
- int_19h 4y ago
  You're describing issues with the underlying JS ecosystem. TS builds on that, and while it can paper over the language deficiencies, the libraries and frameworks are down to the larger community with its culture of constant churn.
- robocat 4y ago
  That is the same as saying you hate Kotlin because Android annoys you. Or blaming JavaScript for the browser DOM. Please correctly blame the ecosystem that you dislike, instead of thoughtlessly using a language as a label for an ecosystem.
  - eyelidlessness 4y ago
    It’s my impression GP doesn’t have a clear picture of where TypeScript ends and the rest of the tooling ecosystem begins. Which is totally understandable, especially given how pervasive TypeScript is and how it nearly totally overlaps with the rest. I think you and I have similar perspectives on the details, but you could be kinder expressing them.
    - robocat 4y ago
      I assumed repox prefers bluntness, due to their writing style. I was careful with the words and tone that I chose. Checking comment history, repox wrote that they are a Dane (which I didn't know). My experience of friends from other nearby countries is that their style of interaction can be seen as rude by many people. In particular my stereotype is that Americans often prefer a more gentle approach. I think you are assuming I am not being respectful. However I believe that a blunt reply is definitely showing respect to them in this situation. I do need to be careful not to make comments that are personal attacks (or that could be mistaken for), which I certainly was not trying to do. (To quote you: "you’re making the claim, you defend it. Otherwise the assumption is just, like, your opinion man." ;) Hopefully repox can reply, although they don't often comment, so I would guess they are unlikely to check replies. Anyways, definitely off topic!
gherkinnn 4y ago
The way TS stuck such an expressive type system in top of such a dynamic and somewhat clumsy language is nothing short of witchcraft. And as a dev it all feels so effortless.
- bricss 4y ago
  IMO, it feels more like witchcraft lang for clumsy developers
rlp 4y ago
I've always been a big proponent of TypeScript, but does anyone else feel like the type system has gotten a bit too flexible? I recently had to fix some errors when upgrading packages on an old project, and it was not at all clear what was wrong by just reading the compiler output. For some errors, there were like 5-10 lines of confusing info/context, it felt like trying to understand the errors reported in template-heavy C++.
- eyelidlessness 4y ago
  It’s always been too flexible. That’s its raison d’être.
azangru 4y ago
> "Align with current and future ECMAScript proposals." But they admitted namespaces, enums, and interfaces into the language (the latter becoming more and more confusing as type aliases got more expressive), > "Avoid adding expression-level syntax." Is "as", "is", or "satisfies" expression-level? > "Use a consistent, fully erasable, structural type system." But the enums!
- eyelidlessness 4y ago
  > But they admitted namespaces, enums And decorators. But this was very early on and they won’t ever do it again unless there’s a drastic change on principle and probably a reorg of global proportion. They categorically reject anything with runtime implications now, and to the point of decorators are actively working to align them with the standard as it’s approaching stability. > and interfaces into the language (the latter becoming more and more confusing as type aliases got more expressive) […] Is "as", "is", or "satisfies" expression-level? No. All of this is completely separate from the runtime and on a standards course to be treated effectively as comments. > But the enums! I’m one of the minority who actually likes TS enums, but I strongly suspect they’ll be deprecated, alongside namespaces, as soon as there’s general consensus around types as comments. The TypeScript team considers these mistakes and would very much like to be able to drop them. I’d welcome that too even though I quite like enums. The fact is TS has considerable backwards compatibility expectations, and aligning their mistakes with their goals is great on principle but something which would require thousands upon thousands of hours of labor for people to accommodate. You can snipe all you want, but if you think it’s that easy to resolve maybe I can direct you to https://github.com/microsoft/TypeScript/pulls https://github.com/microsoft/TypeScript/pulls I’m not affiliated with the team in any way but I’m almost totally certain they’d welcome a contribution that gets them closer to their stated principles where historical designs are entrenched, without breaking workflows for thousands of people and interrupting releases for millions.
smcleod 4y ago
Typescript as a language isn't too bad but the ecosystem is an absolute dumpster fire. NPM is terribly fragmented, costs a fortune in effort to maintain dependencies, security updates etc... Every Typescript/JS project I work on is full of a dangerous amount of third party dependencies - it can be hundreds if not thousands in a single repo - many of them fragile in their own special way. Language packages management is hard - but it seems especially hard with TS/JS.
- Eric_WVGG 4y ago
  That’s not a Typescript problem, that’s a modern JavaScript stack problem. let Typescript have it’s win here… I want to hate it because I loath Microsoft so deeply, but it really has changed everything in the web world, I wouldn’t hire a front-end dev who couldn’t work in it now.
- losvedir 4y ago
  Typescript as a language is better than "isn't too bad", it's great! I love the syntax for unions and how normal things like "if" will narrow types. But I agree that it's a shame that the JS ecosystem is such a mess. Granted, dealing with it is essentially Typescript's purpose, but I would love for it to be a full fledged language on its own, divorced from JS. How cool would it be if you could write normal backend apps in it and compile them to native code? I use Deno a bit and pretend, but it's not quite the same.
  - smcleod 4y ago
    I agree, I wish there was more incentive for developers (especially on the front end side!) to not install every package under the sun and instead be a little less "fancy" or aim for satisfying the 90% rather than the 100%.
  - k__ 4y ago
    I wished Flow or ReScript would have won. TypeScript is too C#-ish for my taste. Well, still better than nothing, I guess.
iainmerrick 4y ago
TypeScript has lots of great features and a few bizarrely bad ones. It’s great in spite of itself. The main misfeature is their dogmatic refusal to rewrite import paths (citing the “Preserve runtime behavior of all JavaScript code” principle mentioned in this article). Here’s a good summary of the problems this causes: https://github.com/microsoft/TypeScript/issues/42151 https://github.com/microsoft/TypeScript/issues/42151 I’m curious, how many people are using TSC only for type-checking, and a different system (eg esbuild or ts-node) to actually compile/bundle/execute their code? I think TypeScript would be even stronger if they focused fully on type-checking, and relaxed some of those dogmatic restrictions (and the many, many confusing config options) imposed by the JS code generator.
- eyelidlessness 4y ago
  They're beginning to yield on file suffixes, and even have module resolution tracked on the 4.9 iteration plan. I agree it’d be better for them to focus on type checking but gratefully that’s what they seem to be moving towards with their types as comments proposal.
peanut_worm 4y ago
TypeScript has always worried me a little because of MicroSofts old “EEE” policy but damn its just so nice to use. Building a complex JavaScript project without it feels wrong now.
russellbeattie 4y ago
Someone please point me to a project using TypeScript that isn't an over-engineered steaming pile of excrement. Please. Enlighten me. I've yet to see one where the code is even somewhat mentally parsable. Abstractions galore, needless separations of concern, indecipherable build scripts that take forever to run, insane JS output and more. It's basically a write-only language extension where only the people actively working on a project can actually understand any of it. Look at this thread. So many comments about how great the language is, but with the caveat about how horrible the ecosystem is. Think about that for a second and maybe you'll get it. What is it about strongly typed languages that attracts developers enamored with their own cleverness? I'd rather work with Java. And I loathe Java.
noduerme 4y ago
Reading this thread gave me my first encounter with `satisfies`. While I love the concept, the syntax really bothers me. I'm used to seeing the type right after the variable name when it's being defined, not looking after the assignment for it. The placement after assignment almost seems to imply that if you `let x = 1 satisfies number` with an implicit "any" you could reassign x and have it satisfy something else further on in the code, which would be an unbelievably terrible antipattern. (I'm assuming you can't do that?) To me it seems more logical to use something like a double-colon or some other syntactic sugar to imply `satisfies` when you declare a variable... and possibly a <Satisfies Classname> or just <Classname*> prepend for casting.
qxxx 4y ago
am I the only one who hates typescript?... development time is extended because you need to create all the types / interfaces for every variable and function. And you blow up the already complex / almost unreadable code with type definitions. Some of the definitions can be very complex, a dev needs time to decrypt what other dev wrote and what I can finally use as a parameter in a function. Sometimes even if you put the correct parameters, it still doesn't work, and you need to fiddle around with webpack or other config files or spend hours on google to find a possible solution for a "simple" thing. I just want to create code and solution... I used to work on a project with typescript only, and it was a huge pita, especially because the ts was very complex. Never again typescript projects for me.
- rikroots 4y ago
  I don't "hate" TS. I understand how useful it can be. But I don't enjoy working with TS code - especially in large codebases which have been touched by many developers, each with their own understanding of how to use TS. When it comes to the world of professional web development it's up to me to adapt to the project's coding requirements, not the other way around.
  - sngz 4y ago
    I agree and this has been my experience too
- pragmatic 4y ago
  "And you blow up the already complex / almost unreadable code with type definitions." I don't thing your problem is Typescript.
roflchoppa 4y ago
I switched this year to working at a company who uses typescript for backend systems after working as a python dev for 3 years. It’s not that I hate it, it’s just that TS/JS does not give you anything in terms of built-ins. This testing suite is so fragmented, it’s this ugly thing that I dread working with. Anyone have advice for repos I can use that have rich testing frameworks? Or books? I’d love to learn to love TS, but it’s not there yet.
- pragmatic 4y ago
  Jest?
toastercat 4y ago
I overall like TypeScript. But one thing I have encountered in every TypeScript codebase I've worked on are types with a crazy amount of optional properties like this: type Foo = { prop1?: number; prop2: string; prop3?: boolean }; I'm sure there is some value to having this than not having it at all, but I find it hilarious the amount of times I'm writing TypeScript that I can't even trust the types given to me. Of course this isn't a fault of TS itself, but I think what TS has inadvertently done is give programmer yet another outlet to express their bad habits.
- lucasyvas 4y ago
  Sounds like a shitty function. Count your lucky stars it's at least statically typed! TS unfortunately can't solve people not understanding the benefits of a type system as it pertains to foundational design - they have to learn that on their own.
  - toastercat 4y ago
    Amen!
huqedato 4y ago
Sorry guys but here I got 20 years of JS without TS. Never really felt the need. Just learned to code carefully.

215 points by kbhomes 4y ago

Also see https://rescript-lang.org/ https://rescript-lang.org/ if you're considering learning Typescript Looking forward to more great ideas in the future of ways to 'fix' Javascript.

argentinian 4y ago
Does Facebook use it abundantly, or only on a few experimental projects?
CharlesW 4y ago
> Also see https://rescript-lang.org/ https://rescript-lang.org/ if you're considering learning Typescript I'd never heard of this, so here are a couple things I think are true after poking around a bit: • TypeScript is a strict superset of JavaScript that compiles to JavaScript, while ReScript is unique language that compiles to JavaScript. • ReScript is apparently a re-brand of "Reason(ML)", which is apparently derived from OCaml.

dynamite-ready 4y ago

Given the number of codebases littered with 'any', and the fact that TS is known to produce app bundles that perform slower than handwritten JS code, I'm in two minds about celebrating those ten years... But it is strange to think it's been ten years.

mumphster 4y ago
Do you have examples of slower code generated by typescript? TS is a superset of JS so it changing anything that has a large performance impact seems odd, but maybe I’m missing something here. The types aren’t even available at runtime, what’s the biggest slow down you’ve seen?
- redox99 4y ago
  Most likely polyfills because he's targeting some old ES version.
- dynamite-ready 4y ago
  https://thenewstack.io/which-programming-languages-use-the-least-electricity/ https://thenewstack.io/which-programming-languages-use-the-l...
  - int_19h 4y ago
    This claims that TypeScript is an order of magnitude slower than JavaScript, which is obvious nonsense if you know how TypeScript works, unless they counted transpiling in execution time.
jmull 4y ago
> TS is known to produce app bundles that perform slower than handwritten JS code I’m curious about this, and runs counter to my understanding of typescript. Do you have any sources on this? I’m googling a bit but not really finding anything.
laundermaf 4y ago
> TS is known to produce app bundles that perform slower than handwritten JS code Wrong. TS doesn’t bundle files. TS doesn’t produce code unless you target an earlier ES version than what you write, in which case there’s no way around it: native for-of loops and await/async will always be faster regardless of what you use to transpile it. I think you’re confusing the tool with something else.
- mirekrusin 4y ago
  Ts does produce code, ie. for enums, modules/namespaces.
  - ksbrooksjr 4y ago
    Const enums get completely erased by the compiler, and modules are a native js feature. Non-const enums and namespaces are probably the only aspects of typescript that actually have any significance at runtime, but they get compiled into simple objects. The compiler output is very close to what you'd write by hand. Take a look at this compiler output here [1]. Unless you're constantly recreating enums and namespaces inside of a loop (which you'd never do in real life code), I can't imagine there'd be any performance penalty. [1] https://www.typescriptlang.org/play?target=99#code/HYQwtgpgzgDiDGEAEBlA9pAcuadFIG8AoJJCADxjQCcAXJeNYKegMzTSQF4kByAIxDVeRAL5EJEYAFcwqDBACiMucVKl2nHgKEjxRAPQGktABYBLKAyYsyKpAHdzAG2dJ+yCNRBQIAE3cATxNTZEYwGBcvIkZmeilZeUgAYRtaZUS1dQBHaXJuPlzyPSA https://www.typescriptlang.org/play?target=99#code/HYQwtgpgz...
    - mirekrusin 4y ago
      So ts does produce code.
      - ksbrooksjr 4y ago
        It can (depending on which features you're using), but the comment that started this thread claimed that the produced code was much slower than handwritten js. I was just pointing out that the examples you gave (enums and namespaces), don't change the performance of your code.

mirekrusin 4y ago

We need: - exact object type - match expression flow is still better at: - OO - nominal typing for classes, conforming to liskov substitution principles - first class opaque types - first class exact object types - better flow based inference - comment types - no extra dsl, full access to the language, so simple, so powerfull for the times you don't want transpilation phase - [edit] spread types map to spread in runtime

qudat 4y ago
You can’t type generators properly a la redux-saga
krosaen 4y ago
I don’t understand the benefit of nominal typing when structural typing is available?
- mirekrusin 4y ago
  You can't use `instanceof` ie. for your error types, actually every time you use class that extends something - it'll not be typed correctly. Basically nothing OO/class/inheritance related is typed correctly. Flow does it correctly.
- nine_k 4y ago
  The idea is that two types with the same structure aren't always the same thing. This is easily solved by a tagged type in TS [1], though a bit of syntactic sugar over it would be nice. [1]: https://kubyshkin.name/posts/newtype-in-typescript/ https://kubyshkin.name/posts/newtype-in-typescript/
  - mirekrusin 4y ago
    Tagging doesn't solve inheritance problems - object oriented inheritance needs to follow liskov substitution principles, support variance correctly. Tagging is good for making sum types out of union types, but that's not enough for class inheritance. Flow does it better by having first class opaque type aliases btw (and having nominal types with oo inheritance support on classes of course).

ht85 4y ago

As a web-focused software engineer, I can safely say TypeScript is the best thing that happened to my work in the last decade. Aside from the known direct benefits of safety and self-documentation, I've found over time that having a pleasant, smooth coding experience and producing elegant code required me to think differently. I work on a project with very complicated and overloaded business logic, but nowadays my code looks very... "algebraic"? state machines within state machines, exhaustive switches everywhere... Maintaining and modifying such code has been a joy compared to the old ways. Most of the work is just adding a new member to some union or an attribute to a type, following the red trail fixing errors and voilà.

dccoolgai 4y ago
The real genius of it is that it's really not a "type" system at all: it's a contract system. The nearest thing like it was Eiffel. The new "satisfies" feature in 4.9 makes this even more clear. Honestly there's so much space to cover here, I think it's just going to keep getting better and better.
- dalmo3 4y ago
  Wow! `satisfies` solves a problem I was working on yesterday. Remarkably, it's not the first time a new TS feature immediately makes way into my code.
  - dccoolgai 4y ago
    It's such a powerful complement to the "no rules" JS when you layer it on top. You really get to have your cake and eat it, too. I feel like there's another huge step to take in "layering" invariant checking on top of TS for QA/test systems... Imagine like "in all 500 of my tests, make sure this variable is an integer greater than 10 at all times no matter what". I'm waiting for this to show up
- eyelidlessness 4y ago
  I’m curious what you’re distinguishing here. To me a type system and a contract system are identical concepts with different descriptions. It seems like you might be highlighting the structural typing aspects of TypeScript’s type system versus nominal or concrete types in many others, but that’s been clear for most TS usage for since well before `satisfies` so I’m not sure if my interpretation is right.

david2ndaccount 4y ago

The number one problem with typescript is how slow it is. Compiling a 14k line project takes 5s. This is absurdly slow.

Tajnymag 4y ago
Typescript by itself is just the language. You could try a different typescript compiler like esbuild for example.
- david2ndaccount 4y ago
  > However, esbuild does not do any type checking so you will still need to run tsc -noEmit in parallel with esbuild to check types.
  - Tajnymag 4y ago
    You're right, I didn't count with that
  - jcparkyn 4y ago
    Personally, I find that I don't really need full type checking on every build. For most small changes, the errors shown in vscode are sufficient while editing, and then full type checking can be run occasionally when needed (and in CI of course).
  - DangitBobby 4y ago
    Your IDE can be doing type checks on whatever file(s) you're working on, you can use esbuild or swc to compile to javascript to make sure it runs correctly, and you can periodically use tsc to fully compile and typecheck your entire codebase to catch anything that you somehow missed in the IDE.
wwwigham 4y ago
When you can write a busy beaver machine in the type system, LOC ceases to be a good indicator or how long something should take to typecheck, imo. If you're frustrated with your build, you should use the trace tools on the TS wiki[1] to track down what types are slow to check, so you can attribute the slowness to the appropriate library authors/yourself and decide for yourself if the speed/correctness tradeoff they've made is right for you. [1]https://github.com/microsoft/TypeScript-wiki/blob/main/Performance-Tracing.md https://github.com/microsoft/TypeScript-wiki/blob/main/Perfo...

cehrlich 4y ago

TypeScript is the best thing to happen to web dev, and it keeps getting better. My only gripe is that sometimes in a codebase that is heavy on inferred types I need to restart the TS server occasionally. Nonetheless, unless there is a specific requirement that TS isn't the right choice for, it's the language I reach to for everything.

nesarkvechnep 4y ago
Do you have interests beyond the JS world? TypeScript being the best thing to happen to web dev sounds a bit hyperbolic.
- schwartzworld 4y ago
  The vast majority of web apps have JS on the front end. It's not even close.
- cehrlich 4y ago
  There are a lot of other great languages, but none of them run in the browser. Once you know that your frontend is in TS, there are a lot of advantages to writing the BE in it also. Like I said, there are exceptions, but it has become my default.

gavinray 4y ago

TypeScript has my second favorite type system, right behind Scala 3 To me, that's saying something.

Yahivin 4y ago

This seems like a great time to announce my successor to CoffeeScript: Civet, a language that transpiles to TypeScript. https://github.com/DanielXMoore/Civet https://github.com/DanielXMoore/Civet

msoad 4y ago
TBH I have 99 problems but the syntax is not one
- Yahivin 4y ago
  Civet also fixes: `import x from "./x.ts"` and unifies `readonly` and `const`. I'll get back to you when I fix the other 97 but until then there's no accounting for taste.
bilalq 4y ago
Oh, I like this. A pure syntactic sugar over a language that otherwise preserves semantics is neat. Nice work on documenting what was kept/changed/removed too. Really easy to see at a glance what the project is all about. Love that there's an online playground, LSP, and VSCode extension along with it.
- Yahivin 4y ago
  Thanks! It's still a work in progress (especially the LSP) but it is usable in its current state and is getting better all the time.
elwell 4y ago
I used to love CoffeeScript. Will check this out!
runes 4y ago
Very cool! For years I've wanted to fork LiveScript and integrate it with the TS checker somehow (and remove `on/off/yes/no`, good call), sort of an F# to TypeScript's C#
4y ago

michaelwww 4y ago

Debate (almost 10 years ago) TypeScript vs. Dart about the best way to improve JavaScript Anders Hejlsberg (Microsoft) and Lars Bak (Google): TypeScript, JavaScript, and Dart https://www.youtube.com/watch?v=5AqbCQuK0gM https://www.youtube.com/watch?v=5AqbCQuK0gM

mr_johnson22 4y ago

Honest question: why did TypeScript succeed while ActionScript 3.0, another ECMAScript-superset language with typing and OOP (and predates TS by a few years), is all but a distant memory? Is it more than just Adobe being a terrible steward of its tech? With that said, TS is definitely a blessing; I recently had the privilege of migrating to it after having written a hobby project in plain JS, and the difference in usability between the two is night and day. But I can't help but feel that I've seen this all before years ago in AS3.

blackoil 4y ago
Wasn't fate of ActionScript strongly tied to Flash? As much as some open source community try, they can't beat the full force of the investment done and talent assembled by Microsoft.
jmull 4y ago
I liked AS3 quite a bit, but it was limited to Adobe products. I don’t think it was ever given a chance to make an impact beyond Flash and Air.
- throw_m239339 4y ago
  Well no it wasn't limited to Flash, since it was supposed to be ES4. This is why ES4 doesn't exist as a standard, Javascript went from ES3 to ES5.
  - jmull 4y ago
    I'm aware of how they were related... AS3 was based on ES4 ideas, and, as the major implementation of ES4, AS3 influenced the evolving direction of ES4. But ES4 was never really finished to the point where everyone who needed to actually agreed on it. I think MS, who had a browser monopoly at the time, was never going to agree to something that made Adobe Flash more important. It seems crazy now, but at the time it seemed like a real possibility that browsers could end up mere shells for the real internet runtime, Flash Player.

umvi 4y ago

I like the idea of typescript. I tried to port a vanilla js browser game to typescript and I found it introduced a lot of complexity to the project. It sucked me into the npm ecosystem and forced me to rewrite every file to use js modules import/export syntax and a bundler like webpack to resolve all the modules business for browsers when none of those were needed before. Of course I could set TS modules to none but then I lose access to typing of any third party libraries I'm using like PixiJS. And my CI pipelines are like 10x slower now because I need npm to install and compile and bundle stuff which is really slow compared to my previous CI pipeline which simply concatenated the js files together with `cat`. Does this sound right or an I missing something? What I want: To be able to just type annotate my existing JS without needing modules, but also have TS be able to pull in type information of 3rd party libraries by pointing it to the appropriate .d.ts file. I suppose that's having your cake and eating it too in this case.

dynamite-ready 4y ago
This is closer to my opinion. I write a fair amount of Typescript, but it's frustrating to see it used so ubiquitously, when in a lot of cases it's just not necessary. A strongly typed language definitely has a place in web UI development though. But my hope is to see it replaced by a WASM based language, or better still, a choice of WASM based languages.
- pragmatic 4y ago
  In what cases do you see it when when not necessary?
  - dynamite-ready 4y ago
    If you look at how Python is used in 3D graphics (or similar DSLs in the more esoteric 3D apps), they've been using the scripting system in the likes of Maya and Blender to create inordinately complicated systems for decades. Like 3D graphics, a lot of UI code is visual, ephemeral, complex. The development process for such features, benefits from from the speed of iteration and flexibility that dynamically typed code can provide. Granted, a checkout, or a clinical case management form (for example) will definitely benefit from the kind of precision a strong type system will encourage. Beyond that, we should think more about the how and why, because type wrangling can slow down delivery, experimentation, and cannot guarantee the prevention of bugs. Gmail and Google Maps for example, at least when those projects started out, had no TypeScript in their UI code. Google Maps, even in it's earliest iteration, far outstrips the complexity of most TypeScript applications in the wild today. And also has a greater requirement for precision than many of the applications that we can call to mind, outside of Finance, Transport, Construction, or Medicine. People seem to talk as though certain applications were impossible to build without without TypeScript, but that is simply not true. So TLDR, answering the root of your question, TS is not at all necessary. But it can be helpful. Yet we're in a position now where it's almost intractable, and I don't think that's an ideal situation.

stephen 4y ago

Great post/looking back at the core decisions/bets that worked out really well (from the post): * "Impose no runtime overhead on emitted programs." * "Align with current and future ECMAScript proposals." * "Preserve runtime behavior of all JavaScript code." * "Avoid adding expression-level syntax." * "Use a consistent, fully erasable, structural type system." I also really liked the callout of their approach to "innovating in the type system around conventions and patterns found 'in the wild' of the JavaScript ecosystem." This "you can still write the JS-style APIs you want, just safely" is a stark contrast to the Dart/ActionScript/others options mentioned in the HN thread, which said "you have to give up the JS-style APIs you have, and instead write 'basically Java'". It's also amazing how TS 1.x itself was "basically Java" (in terms of a type system, albeit except being structural), but so many of the TS 2.x type systems innovations (mapped types, conditional types, etc) look as if they were designed in the language from day 1. One other point, the post calls out they didn't add extra syntax to JS, only types; in this regard, I think TypeScript frankly got lucky by how much JavaScript itself has evolved in the last 10 years. Like if JS had been going through a "10 years of sterility" period like Java did from ~2005-2015, then TS itself would have been greatly hindered and probably would have had to jump to syntax-level changes, like the Scalas and Koltins and other Java.nexts had to do. So, kudos to JS itself for also evolving extremely well from its ~2010 everything-is-a-callback early days, and letting TS stand on its shoulders.

Sankozi 4y ago
In most programming languages JS style APIs (i.e. give me anything and I will try to interpret it somehow in an undocumented or poorly documented way) are antipatterns. TS is often bringing sanity to libraries that switch from JS to TS. I think TS team is doing really great job. I would not call it standing on the shoulders of predecessor, more like trying to build something stable on the swamp. JS definitely does not have a positive influence on TS. TS is not a great programming language, but it is really great accomplishment considering that it supports and extends JS in a such good way.
pas 4y ago
If JS were slow to add new features TS would probably not have the wait and see policy.

blackoil 4y ago

Is there any effort ongoing to add optional type declaration to Javascript? Runtime type info. would make lot of use cases possible.

rektide 4y ago

Generally a huge positive. With tools like swc, there's really fast compilation & typechecking now. With --watch, the DX is pretty good but yeah sometes has to be restarted anyways. A couple not so greats: Typescript has added a lot fo confusion & chaos to the ESM transition. A lot of typescript code is in ESM style, byt if you pull the package, it outputs cjs or what not. TypeScript 4.8- very recent- is the first to actually have a semi-viable Node.js + ESM story going; being a respectably modern package hasnt even really been possible with typescript until just recently. Not fully typescript's issue, but writing a package.json that fully helps consumers is quite difficult, and there's a lot more to grol.woth typescript in the mix. There's such a long long tail of typescript packages that are going to be the long long hold up for getting to ESM cleanly. It's not that hard to change, but awareness is just low, and friction is high while we are still so stuck-in-the-middle. Typescript makes writing code easy, but outputting a good respectable usable library has been impossible & is still not easy. Woe. I really hope EcmaScript does get type annotations, which could eliminate so much of the need to compile & let typed code just run untyped, elide so many of these difficult transpilation challenges. Another major issue for typescript is that it is stil so compile-time focused, that type metadata isnt kept intact. It's wild to have such a vast typing system, but to just throw it all out at compile time. To be fair, object metadata in js has been tied to annotations, which has been long long delayed, a huge struggle for the language, so there's not clear targets for how to output type information, but there have been some goes, some works to add runtime type information to typescript & there's so little follow up, so little engagement. All TypeScript feels like such a sharply more limited less useful less ambitious project than what it should be doing, than what a real language+runtime would be. It feels like typescript lives in the shadow of a much more clear & visible greatness.

david2ndaccount 4y ago
I thought swc still doesn’t do type checking and just strips the type annotations?
- rektide 4y ago
  Hrrmmm. I've been using the newer Jest testing library releases & they are supposedly powered by SWC. I definitely see some typechecking errors, & assumed this was also swc. But I see little evident in the swc project they've made headway here. Im not sure what Im experiencing in jest. It's definitely not the same level of typechecking. But there's definitely something there & it's definitely much faster start time. Thanks for writing; Im curious too.

bluepnume 4y ago

I was a long time Flow hold-out, switched to TypeScript a year ago and never looked back. There are a few things I miss, and a few things that Flow did do better; TS is obviously not perfect. But it's a real joy to use. As for people writing JS in 2022 without any kind of static typing: I fear for you.

repox 4y ago

I've spent the last two years working with TypeScript solely. Coming from ~20 years with PHP and using Kotlin and Dart for some years as well, I feel that I'm doing something wrong. I absolutely loathe working with TypeScript. The community is the most fragmented I've ever experienced, the silly amount of package managers, builders... TypeScript just doesn't fit with me.

rroot 4y ago
Typescript itself is fine. But yes, if you are using 3rd party libraries and frameworks with typescript, you might wonder if it's too late to change career and become a monk.
int_19h 4y ago
You're describing issues with the underlying JS ecosystem. TS builds on that, and while it can paper over the language deficiencies, the libraries and frameworks are down to the larger community with its culture of constant churn.
robocat 4y ago
That is the same as saying you hate Kotlin because Android annoys you. Or blaming JavaScript for the browser DOM. Please correctly blame the ecosystem that you dislike, instead of thoughtlessly using a language as a label for an ecosystem.
- eyelidlessness 4y ago
  It’s my impression GP doesn’t have a clear picture of where TypeScript ends and the rest of the tooling ecosystem begins. Which is totally understandable, especially given how pervasive TypeScript is and how it nearly totally overlaps with the rest. I think you and I have similar perspectives on the details, but you could be kinder expressing them.
  - robocat 4y ago
    I assumed repox prefers bluntness, due to their writing style. I was careful with the words and tone that I chose. Checking comment history, repox wrote that they are a Dane (which I didn't know). My experience of friends from other nearby countries is that their style of interaction can be seen as rude by many people. In particular my stereotype is that Americans often prefer a more gentle approach. I think you are assuming I am not being respectful. However I believe that a blunt reply is definitely showing respect to them in this situation. I do need to be careful not to make comments that are personal attacks (or that could be mistaken for), which I certainly was not trying to do. (To quote you: "you’re making the claim, you defend it. Otherwise the assumption is just, like, your opinion man." ;) Hopefully repox can reply, although they don't often comment, so I would guess they are unlikely to check replies. Anyways, definitely off topic!

gherkinnn 4y ago

The way TS stuck such an expressive type system in top of such a dynamic and somewhat clumsy language is nothing short of witchcraft. And as a dev it all feels so effortless.

bricss 4y ago
IMO, it feels more like witchcraft lang for clumsy developers

rlp 4y ago

I've always been a big proponent of TypeScript, but does anyone else feel like the type system has gotten a bit too flexible? I recently had to fix some errors when upgrading packages on an old project, and it was not at all clear what was wrong by just reading the compiler output. For some errors, there were like 5-10 lines of confusing info/context, it felt like trying to understand the errors reported in template-heavy C++.

eyelidlessness 4y ago
It’s always been too flexible. That’s its raison d’être.

azangru 4y ago

> "Align with current and future ECMAScript proposals." But they admitted namespaces, enums, and interfaces into the language (the latter becoming more and more confusing as type aliases got more expressive), > "Avoid adding expression-level syntax." Is "as", "is", or "satisfies" expression-level? > "Use a consistent, fully erasable, structural type system." But the enums!

eyelidlessness 4y ago
> But they admitted namespaces, enums And decorators. But this was very early on and they won’t ever do it again unless there’s a drastic change on principle and probably a reorg of global proportion. They categorically reject anything with runtime implications now, and to the point of decorators are actively working to align them with the standard as it’s approaching stability. > and interfaces into the language (the latter becoming more and more confusing as type aliases got more expressive) […] Is "as", "is", or "satisfies" expression-level? No. All of this is completely separate from the runtime and on a standards course to be treated effectively as comments. > But the enums! I’m one of the minority who actually likes TS enums, but I strongly suspect they’ll be deprecated, alongside namespaces, as soon as there’s general consensus around types as comments. The TypeScript team considers these mistakes and would very much like to be able to drop them. I’d welcome that too even though I quite like enums. The fact is TS has considerable backwards compatibility expectations, and aligning their mistakes with their goals is great on principle but something which would require thousands upon thousands of hours of labor for people to accommodate. You can snipe all you want, but if you think it’s that easy to resolve maybe I can direct you to https://github.com/microsoft/TypeScript/pulls https://github.com/microsoft/TypeScript/pulls I’m not affiliated with the team in any way but I’m almost totally certain they’d welcome a contribution that gets them closer to their stated principles where historical designs are entrenched, without breaking workflows for thousands of people and interrupting releases for millions.

smcleod 4y ago

Typescript as a language isn't too bad but the ecosystem is an absolute dumpster fire. NPM is terribly fragmented, costs a fortune in effort to maintain dependencies, security updates etc... Every Typescript/JS project I work on is full of a dangerous amount of third party dependencies - it can be hundreds if not thousands in a single repo - many of them fragile in their own special way. Language packages management is hard - but it seems especially hard with TS/JS.

Eric_WVGG 4y ago
That’s not a Typescript problem, that’s a modern JavaScript stack problem. let Typescript have it’s win here… I want to hate it because I loath Microsoft so deeply, but it really has changed everything in the web world, I wouldn’t hire a front-end dev who couldn’t work in it now.
losvedir 4y ago
Typescript as a language is better than "isn't too bad", it's great! I love the syntax for unions and how normal things like "if" will narrow types. But I agree that it's a shame that the JS ecosystem is such a mess. Granted, dealing with it is essentially Typescript's purpose, but I would love for it to be a full fledged language on its own, divorced from JS. How cool would it be if you could write normal backend apps in it and compile them to native code? I use Deno a bit and pretend, but it's not quite the same.
- smcleod 4y ago
  I agree, I wish there was more incentive for developers (especially on the front end side!) to not install every package under the sun and instead be a little less "fancy" or aim for satisfying the 90% rather than the 100%.
- k__ 4y ago
  I wished Flow or ReScript would have won. TypeScript is too C#-ish for my taste. Well, still better than nothing, I guess.

iainmerrick 4y ago

TypeScript has lots of great features and a few bizarrely bad ones. It’s great in spite of itself. The main misfeature is their dogmatic refusal to rewrite import paths (citing the “Preserve runtime behavior of all JavaScript code” principle mentioned in this article). Here’s a good summary of the problems this causes: https://github.com/microsoft/TypeScript/issues/42151 https://github.com/microsoft/TypeScript/issues/42151 I’m curious, how many people are using TSC only for type-checking, and a different system (eg esbuild or ts-node) to actually compile/bundle/execute their code? I think TypeScript would be even stronger if they focused fully on type-checking, and relaxed some of those dogmatic restrictions (and the many, many confusing config options) imposed by the JS code generator.

eyelidlessness 4y ago
They're beginning to yield on file suffixes, and even have module resolution tracked on the 4.9 iteration plan. I agree it’d be better for them to focus on type checking but gratefully that’s what they seem to be moving towards with their types as comments proposal.

peanut_worm 4y ago

TypeScript has always worried me a little because of MicroSofts old “EEE” policy but damn its just so nice to use. Building a complex JavaScript project without it feels wrong now.

russellbeattie 4y ago

Someone please point me to a project using TypeScript that isn't an over-engineered steaming pile of excrement. Please. Enlighten me. I've yet to see one where the code is even somewhat mentally parsable. Abstractions galore, needless separations of concern, indecipherable build scripts that take forever to run, insane JS output and more. It's basically a write-only language extension where only the people actively working on a project can actually understand any of it. Look at this thread. So many comments about how great the language is, but with the caveat about how horrible the ecosystem is. Think about that for a second and maybe you'll get it. What is it about strongly typed languages that attracts developers enamored with their own cleverness? I'd rather work with Java. And I loathe Java.

noduerme 4y ago

Reading this thread gave me my first encounter with `satisfies`. While I love the concept, the syntax really bothers me. I'm used to seeing the type right after the variable name when it's being defined, not looking after the assignment for it. The placement after assignment almost seems to imply that if you `let x = 1 satisfies number` with an implicit "any" you could reassign x and have it satisfy something else further on in the code, which would be an unbelievably terrible antipattern. (I'm assuming you can't do that?) To me it seems more logical to use something like a double-colon or some other syntactic sugar to imply `satisfies` when you declare a variable... and possibly a <Satisfies Classname> or just <Classname*> prepend for casting.

qxxx 4y ago

am I the only one who hates typescript?... development time is extended because you need to create all the types / interfaces for every variable and function. And you blow up the already complex / almost unreadable code with type definitions. Some of the definitions can be very complex, a dev needs time to decrypt what other dev wrote and what I can finally use as a parameter in a function. Sometimes even if you put the correct parameters, it still doesn't work, and you need to fiddle around with webpack or other config files or spend hours on google to find a possible solution for a "simple" thing. I just want to create code and solution... I used to work on a project with typescript only, and it was a huge pita, especially because the ts was very complex. Never again typescript projects for me.

rikroots 4y ago
I don't "hate" TS. I understand how useful it can be. But I don't enjoy working with TS code - especially in large codebases which have been touched by many developers, each with their own understanding of how to use TS. When it comes to the world of professional web development it's up to me to adapt to the project's coding requirements, not the other way around.
- sngz 4y ago
  I agree and this has been my experience too
pragmatic 4y ago
"And you blow up the already complex / almost unreadable code with type definitions." I don't thing your problem is Typescript.

roflchoppa 4y ago

I switched this year to working at a company who uses typescript for backend systems after working as a python dev for 3 years. It’s not that I hate it, it’s just that TS/JS does not give you anything in terms of built-ins. This testing suite is so fragmented, it’s this ugly thing that I dread working with. Anyone have advice for repos I can use that have rich testing frameworks? Or books? I’d love to learn to love TS, but it’s not there yet.

pragmatic 4y ago
Jest?

toastercat 4y ago

I overall like TypeScript. But one thing I have encountered in every TypeScript codebase I've worked on are types with a crazy amount of optional properties like this: type Foo = { prop1?: number; prop2: string; prop3?: boolean }; I'm sure there is some value to having this than not having it at all, but I find it hilarious the amount of times I'm writing TypeScript that I can't even trust the types given to me. Of course this isn't a fault of TS itself, but I think what TS has inadvertently done is give programmer yet another outlet to express their bad habits.

lucasyvas 4y ago
Sounds like a shitty function. Count your lucky stars it's at least statically typed! TS unfortunately can't solve people not understanding the benefits of a type system as it pertains to foundational design - they have to learn that on their own.
- toastercat 4y ago
  Amen!

huqedato 4y ago

Sorry guys but here I got 20 years of JS without TS. Never really felt the need. Just learned to code carefully.