321–330 of 469 posts
The main thing that makes it shine is refactoring.
Besides that, the reast isn't that mind blowing.
I still get crazy bugs just like I did in JS, TS just removed the countless small and easy to fix bugs. Which is good, because they can really slow you down. But when you get something ugly, tests and experience are the only thing that saves you.
I worked in two different team in two different companies where a full rewrite of the core system was done in typescript. The technology itself had few issues like compilation time and inability to run the application locally because of reasons. The new systems were so complicated that everything ended in neverending bike shedding. The people pushing for "everything to be written in typescript including other teams t…
These don't sound like they have much to do with Typescript itself, but just the hell of rewriting a project.
If I’m going to write a bit of JavaScript, I’ll write JavaScript with the minimal feature set possible. It’s not a good thing that the language has continued to accrete features.
If I’m going to write something non-trivial, I’ll go straight to Elm — an actual sane language.
In my company we built a lot of web apps in very small teams (mostly just 2 people). We use mostly c# as a backend and typescript + mostly angular, sometimes react as a frontend. When typescript came out I built a conversion utility that allows me to generate typescript definitions and metadata from my c# type definitions. In angular I built my own type safe reactive forms, access control and API framework. Often we use ef core as a database layer on the backend, so we have a single source of truth (the c# types) for database and frontend types for the API. I use mapped types in typescript a lot to reuse the generated API types in my frontend code. If a field in a class is renamed ef core takes care of the database migration. On the frontend I get notified of every error because of the rename. Is there a table column for the field, I get an error. Is there a form that maps to the field I get an error. Do I check for write permissions of the field with the old name somewhere, I get an error. I use exhaustive matching to ensure that all cases of enums or union types in general are handled. Everything is type safe and the types come from a single source of truth.
It's so insanely productive it feels like magic!
Edit: also wanted to add I mostly do not use libraries outside of framework libs for angular or react in my frontend. Generally most library code I need (with few exceptions) is built by myself rather fast and easily. I avoid libraries because of the npm ecosystem mess but it also has the upside that I don't have problems with outdated type declarations or typescript incompatibilities.
I am quite surprised at the turn out in the comments here against adding type checking to JavaScript. In my opinion, TypeScript is not only essential in the context of any professional project, but it features one of the most ergonomic type systems I have ever worked with. There are certainly pain points with certain TypeScript features (e.g. enums) but any project that takes me longer than 5 minutes to write, I need…
> it features one of the most ergonomic type systems I have ever worked with. This is surprising. Which other type systems have you worked with?
What I read is static typing is a good thing but the costs of using it in TS aren't convincing really. I feel that using it optionally where it's easier to maintain and feel its value is the best of both worlds.
I'm old enough to have worked on two different large enterprise applications which predated TypeScript and it was a nightmare. Personally I've found that JavaScript lends better to a functional style of coding but there are no protections in the language to enforce this and both codebases I saw had a weird mismatched set of object oriented and functional style principals. Defined classes, prototypical inheritance, mo…
> I agree the TypeScript compiler's error messages are confusing but you should have see the types of stack traces JavaScript produces. Non-transpiled js produces fairly sane and useful stack traces. Its just a shame that non-transpiled js is so rare these days.
That said, I still love TypeScript
Typescript is great but be aware that sometimes it can annoyingly slow you down. Consider these scenarios: - You want to use a third party library but it is completely untyped - You need an object but you're just prototyping it. You don't yet know which keys will be optional - You type a key of one of your objects. Now you load or fetch data from an API and want to assign that to it. But typescript complains because…
If you don't know what parameters are optional, just add the little question mark to every variable and remove the ones that turn out mandatory? Better to have some type info than nothing at all. If you fetch data and TS tells you the result may be undefined then I guarantee you your code would've randomly crashed at some point in the future because of it. That error is a feature, not a bug!
I'm old enough to have worked on two different large enterprise applications which predated TypeScript and it was a nightmare. Personally I've found that JavaScript lends better to a functional style of coding but there are no protections in the language to enforce this and both codebases I saw had a weird mismatched set of object oriented and functional style principals. Defined classes, prototypical inheritance, mo…
> especially when you're 20 function calls down a stack trying to understand what's happening. Yeah I hate code like that too, but it's not clear to me how type checking would help.