However sometimes I kinda miss some functional stuff that you can for example find in Scala or Rust, like pattern matching. Specifically, we've had experience using/developing an input validation library for the backend in Typescript (https://github.com/StrontiumJS/Framework/) that is composable and also returns the correct type in one go. We used a lot of try catches for that, but that makes validation slow. So we started using "maybe promises" which are similar to Scala's Futures with Success/Failure. But the fact you don't have pattern matching in Typescript like in Scala makes it a bit ugly.
Its such a powerful pattern, I'm a bit surprised to see so much negativity about it. I'm aware there's alternatives and reasoned opinions, but I bet a significant number of people have never seen or programmed in this style and aren't aware of what they are missing. For me, I can't imagine using another typed language that doesn't support implicit interfaces in this manner.
That would be one of the hello-world test cases for a type checker bolted on to a dynamic language.
That type checker itself has introduced the syntax for declaring Cat and Dog classes; yet is neglecting to do the obvious with it.
* All fields of Dog are also present in Cat, with compatible type signatures
* All functions of Dog are also present in Cat, with comaptible type signatures
"compatible type signatures" does seem to leave some suprising co/contravariance holes still when using wider union types, but C#/Java arrays also have co/contravariance holes and we don't automatically write off their entire type systems because of it. Or, well, at least I don't ;).
As a meaningless point of ancedata: Making these types sufficiently equivalent to fall through this type safety hole appears to be rare enough that I've never done so by accident - allowing me to be suprised by the article's example of passing a class Cat to a class Dog-accepting function being legal. While typescript has never been my primary dayjob, it's been a significant secondary part of my dayjob and hobby junk.
(EDIT: Minor clarifications)
Still much better than working in C or some other weakly typed languages.
However:
- The language primarily uses structural typing. If two classes are compatible, it's not completely unreasonable to expect them to also behave in a structural way (though I would prefer them not to).
- Adding a private field to a class makes it work as a nominal type (https://michalzalecki.com/nominal-typing-in-typescript/#appr...). It feels a bit hacky and it's not very well documented, but you could argue that until a class has some private state you can't publicly access, there's no reason to prevent you from declaring a compatible class.
- From my experience idiomatic TypeScript rarely uses classes, the primary exception being React components. In teams I've been a part of we've always written TypeScript (and JavaScript) like an (impure) functional language, taking full advantage of ADTs, simple structurally typed data and more-or-less pure functions.
It’s just a different kettle of fish to learn.
https://en.wikipedia.org/wiki/Duck_typing#Structural_type_sy...
> Duck typing is similar to, but distinct from structural typing. Structural typing is a static typing system that determines type compatibility and equivalence by a type's structure, whereas duck typing is dynamic and determines type compatibility by only that part of a type's structure that is accessed during run time.
With structural typing, the type system will check that the "duck" not only quacks but also looks like and walks like a duck, before it is allowed to be asked to quack.
EDIT: of course with small enough interfaces you can get structural typing pretty close to duck typing, if you have interfaces "QuacksLikeDuck", "WalksLikeDuck", "LooksLikeDuck", etc. instead of one big "Duck" interface.
If you have compatible method, fields and types, in a duck-typed ecosystem like Javascript it is a major boon that it is possible to interchange them, because it happens all the time in the ecosystem.
The standard way to do enforce exactly the right interface in typescript if you need to is to add a `type: "cat" | "dog"` field to your Animal interface and have the Cat interface have `type: "cat"`. If works well and is very similar to a JVM Class object or .NET Type object.
Structural typing, literal types and dependant types are major blessings to have available sometimes, and I'd really like languages to adopt some of Typescripts power and simplicity in this. So far I've only seen Julia have some of it, although Scala 3 also introduces some bits.
That has some downsides; it can be abused to create a ball of mud.
However, a middle-of-the-road type check which insists that an object must have all of the properties of Dog, even ones you're not using, isn't very useful. It kills the above dynamism, and yet allows abuses to sneak through.
You will not find that cats are being passed to Dog functions until you try to maintain Dog. And then you will discover that, oops, everything you add to Dog has to be replicated in Cat.
Basically, a typecheck which says that an object coming in has to have all the properties of Dog might as well just be a subclass check. The smart way to ensure that a non-Dog class has all the properties of Dog is inheritance.
A properly done static version of this structural type check would validate that the object being passed to the function doesn't have all the properties of a Dog, but that it has all the properties which just that function requires (including transitively: through any functions it calls).
const cat = new Cat();
if (cat instanceof Dog) console.log('this should never be possible!');
- Living documentation: types are a clear description of how your code and its data are laid out, and this structure is kept always up-to-date with the code, regardless of future changes. If the "documentation" (the typing) is wrong, the compiler will complain.
- Better tooling: autocomplete, more robust auto-refactoring
- Elimination of an entire class of bugs. This class may include: 1. `Cannot read property 'foo' of undefined` 2. forgeting a case in a switch statement 3. `'foo' is not a function` 4. in general, your code receiving data that isn't laid out in a way you expected
(Property typos is one within this class of bugs, but it is not all of it)
Yes tests catch these bugs as well. But tests are also manually written. And often not written at all. A compiler makes these (mundane) sanity checks automatic and mandatory.
---
Typescript's slogan is "JavaScript that scales" because static typing improves: dev documentation (via types living inside the code) and dev tooling (refactoring and autocomplete), both of which help immensely as a project grows in age (devs become forgetful), team size (new developers get lost), and convolutedness (e.g. tech debt).
auto-refactoring.. yeah we all trust that. Until you come to the boundaries where all the types don't exist, like from the client to the server, to the database via its message system, etc. All the stuff coming in and out of your code is untyped.
Autocomplete works without typescript, even if it uses "the typescript engine". The types aren't needed.
Eliminates an entire class of bugs that nobody has ever had a problem with.
Regarding typing at the boundaries, this is precisely where typescript shines. The types exist whether they are documented explicitly in your code (in the form of interfaces, types, protocols, etc), or not. This is where the documentation aspect come in to play - it is far easier to read a type definition than having to chase up API documentation, mentally parse tests, or console logging out api responses, to understand your boundary. Your refactoring argument is a strawman, because you wouldn’t just go and refactor names of things at the boundaries of your code in typescript, or any other language, without understanding the API spec. What typescript gives you is precisely the ability to refactor at the boundary when the spec changes and be much more confident that your changes aren’t going to break a whole bunch of thing, especially when it comes to the “class of bugs” that literally every JavaScript developer has dealt with, whether you are aware of them or not.
Until you automate building TypeScript definitions from your external code. We do this to varying degrees and are always trying to improve.
What makes you say so? I find it more readable than javascript.
With my iterative test-driven approach, I probably iterate about once every minute on average (also, my development iteration time gets faster as I become more experienced in the project). So 30 seconds represents 50% of my total development time. Meaning that I could have written 50% more tests or 50% more features in the same amount of time. And that's not even accounting for my loss of focus incurred as a result of waiting 30 seconds to see the result of my code change. By the time I see the result, the concept in my mind is not as fresh as it was 30 seconds earlier.
Combined with other live-reloading tools like nodemon or jest --watch you can have almost the same speed of your development-test-run-debug loops as in plain JS. But you do gain an additional instant feedback channel from the compiler.
Let us know when you are willing join the rest of us in the real world.
My typescript compiler catches typoed property names every time.
> I can't remember the last time I merged code with a typo in a property name.
I can't remember the last time my newly written code made it into the runtime/browser with a typo in a property name.
> ...if you typoed a property name and your tests didn't catch it, it means that either your tests are poorly written or your object didn't need that property to begin with.
The types are much more than just property names.
For me, TypeScript really started to shine once I started taking advantage its generic support, higher-level utility types like Pick<> and Optional<> (and really anything involving keyof), and creating static type checks via the unknown and never types.
This is especially effective when working on legacy JS code bases where unit tests and other good engineering principles were not used well, or at all.
I have many stories on the subject but most recently I did a significant refactoring for a JavaScript project (a popular open source library I created) to move from callbacks to async/await and was able to re-use pretty much all of the existing integration test logic with only aesthetic changes (to account for the new async/await API).
When I finished the refactoring, I had modified at least 70% of the entire source code of the project and I took it as an opportunity to make significant structural changes to my code to align with the new async/await flow in the most optimal way possible. This kind of big refactoring would have made code highlighting completely redundant and would have prevented me from looking at the problem with a fresh mind and taking into account the new features offered by async/await. It was a very successful refactoring; no new issues were uncovered after the point that I managed to get all the original tests passing again and the code was a lot simpler than before.
I think TS has a way of locking down old structures in a way that make it sub-optimal in the long run. Feature-oriented tests are by far the best way to ensure that product quality is maintained after a refactoring IMO.
In a project with >90% coverage, I would find refactors dreadful. After any substantial change beyond adding stuff, there were always a myriad of tests failing. Not hard to fix, but simply tedious and dreadful.
On the other hand, I have an Elm project with no unit test, only some e2e tests. I can do huge transversal changes, and I don't find ot tedious at all. It gave me back the fun in programming. The Elm project is a game, so there should me an order of magnitude more bugs, but the opposite was the case.
I write unit tests once the project is stable and usually only for parts of the logic that are either very complicated or operationally critical. I try to avoid implementing 'very complicated' modules as much as possible.
Unit tests can't really lock down code, or then we shouldn't call those "unit" anymore.
You mean Microsoft managed to get traction? It seems most TS proponents don't realize TS is a success because they fell for smart marketing and serious money behind the project, not because it's a better language than 'other efforts' like for example Purescript or Dart.
But every comment I make against TS seems futile. TS proponents defend their little language very fiercely regardless of all the flaws it has. It's almost worth a study how Microsoft managed to do that. Overall a real pity, because there are so many better options and ideas for those who want static typing. TS is actually the worse choice IMAO.
It's almost as if Microsoft learned the techniques of linguistic evangelism from Sun when they studied the ideas behind Java to design C#, but they left out the anti-linguistic-miscegenation Java-supremacist ideals of "100% Pure Java [TM]" when they made it easy to integrate other mongrel languages with COM and P/Invoke.
I get how folks coming from "natively" static type systems could find all this weird, but I think by targeting "JS but with better checks" instead of a more fundamental redesign, the TypeScript crew have managed to build something that can get traction where other efforts have not.