Something I love about advanced TypeScript types: they're easy to consume given some documentation, even when the programmer doesn't understand them. Defining the types is another story.
Editors give great autocomplete suggestions (usually covers it for properties and return values). Documenting with examples is often helpful. If all else fails, cast.
Without advanced types, code needs documentation to prevent invalidity. With advanced types, code gets logical guarantees, but it often requires the same documentation. It's not necessary for everyone on a team to have cutting edge knowledge when there's sensible documentation.
Types create a synergy with documentation. Provable(ish) guarantees with good documentation is the best of both worlds.
I especially love typescript when it comes to refactors or API changes...on my team we strictly type as much as possible and it has made refactors and API changes so much easier and fail-proof.
For example if an API change occurs on backend, the first step is to make the change to the request/response typings in the frontend...from there the source code will light up with all the errors you have to fix. I can just click through each one in VS Code and fix them, then re-run tests to validate...love it.
Using something like io-ts gives you the benefits of static types and runtime types. JSON Schema typically just provides runtime guarantees but doesn't come with the same development experience. I've been very happy with io-ts so far.
We generate JSON Schema from our TypeScript interfaces, then use that to validate data at relevant points in the application. Best of both worlds, assuming the type definitions are relatively straightforward.
I love typescript but its types are becoming so complicated it's turning into a dynamic language...
I mean one can't represent the all possibilities of JavaScript "types" without re-implementing JavaScript itself, only a subset. I wonder where Typescript will stop.
I'd like to see Typescript compiling to "native" as well.
The vast majority of people using TypeScript in their projects won't run into the deeper complexity of the type system. For the average TS user the only visible impact of features like template literal types and recursive conditional types will be fewer bugs because maintainers of popular libraries used them to provide better types.
You don't have to personally understand TS's more complicated features to benefit from using TS in your project. I hope they continue adding richness to the type system so I can eliminate more bugs from my code.
Always when typescript is
is compared with js, people talk about you get less bugs in typescript. I am honestly curious to see some evidence.
In my opinion application bugs are usually in the flow itself and have nothing to do with wrong types. I work a lot with both plain and Typescript projects. I used to like Typescript. But not anymore. With typescript applications tend to become bigger and more complex. Most devs using it have never seen vanilla js and are more java minded that prototype minded.
IDE code completion works better for typescript. For sure. But is that really essential? Sounds a bit like the typical Java developer who works with giant spring applications containing classes with hundreds of methods spread in many files in a 10 layer deep folder structure.
I've seen the same claim made about the more obscure features found in application frameworks, and in both cases the problem is the same: there will always be that one guy on your team who takes delight in finding a complicated and mentally burdensome solution to an otherwise simple problem, which requires everyone on the team to at least be aware that certain constructs exist.
It's great that Typescript is catching on, and we're starting to adopt it in my team, but I hope the TS people don't think they can keep adding new features to it in perpetuity, otherwise it's going to turn into C++.
Stage 0: JavaScript without types is too hard to maintain.
Stage 1: Put types into JavaScript.
Stage 2: TypeScript types are not expressive enough.
Stage 3: Put JavaScript into types.
I'm looking forward to stage 4 where the expressions inside TypeScript type annotations get so complex and hard to maintain that someone creates TypeTypeScript that lets you put type annotations inside the code inside type annotations.
It's not without precedent - Haskell has a Turing complete type system. (There's also Scala, Rust, and C++ templates which are all arguably Turing tarpits.)
At some point it would be better to just ditch Javascript, which was a mistake anyway, for Typescript or a (non Google controlled) language as default browser language.
I don't understand this type of cynical criticism. You don't have to use features you believe are "so complicated". Just don't use them. You said you love typescript, and everything you love about typescript remains intact to your satisfaction. It's not as if these features emerge spontaneously from a vacuum, the typescript team is working with the community to address specific needs. You didn't even offer any specific criticisms, just a vague dismissal. Just don't use it.
> I don't understand this type of cynical criticism.
I don't think my comment sounds cynical.
> You don't have to use features you believe are "so complicated".
One has to be fluent with reading type definitions thus have good understanding of the type syntax. I must admit, from time to time I could not make sense of them easily when reading declaration files from third parties.
I think is valid criticism ... even if you pick a subset sometimes the types are "forced on you" by libraries or even by code written by coworkers.
TypeScript advanced types are there to model existing JavaScript codebases, but when designing software from scratch I've seen that is too tempting to go crazy with the types, ending with something pretty messy (JavaScript! :-).
All that flexibility only has use when the TypeScript code needs to interact with something terribly unruly: JavaScript code or some API that isn't typed properly. While it's nice that you can model in your code, it brings the distinct possibility that people will start using it to write very sloppy types and/or patch things up afterwards, leading to worse code.
Fascinating - thanks for mentioning this work at Microsoft Research.
> [A Static TypeScript] program is compiled to machine code in the browser and linked against a precompiled C++ runtime, producing an executable that is more efficient than the prevalent embedded interpreter approach, extending battery life and making it possible to run on devices with as little as 16 kB of RAM (such as the BBC micro:bit).
The expressiveness of the type system far outweighs its complexity, imo.
To give a commonly-encountered example, rather than the easily-introspectable options object whose schema is specified by a zero-runtime-cost TS interface, in a traditional OOP language like Java you would write an XOptions / XOptionsBuilder class to maintain type safety, which is at once more opaque, with less predictable behavior.
It's an unfortunate situation, because so long as people are writing popular frameworks/libraries that horribly abuse the dynamic nature of JavaScript, the TypeScript team sort of has no choice but to try and wrestle the language into supporting it. But I agree that this is getting out of hand. I still like TypeScript but with each new release it's getting harder to claim with a straight face that it's "easier" than vanilla JS when you have to grok this increasingly convoluted type system.
It's not a horrible abuse if you aren't trying to make the framework/library statically typed in the first place.
Idiomatic APIs for dynamically typed languages use the flexibility of dynamic types. Idiomatic APIs for statically typed languages use the structure of static types.
The problem comes when you try to put one into the other's world. It's like watching a fish flop around on land. There's nothing intrinsically wrong with fish locomotion, it's just not optimized for that environment.
Presumably, to work with the original JavaScript, you still had to understand the convoluted type system that you created, or else be ok with not being able to reason about your code. At least with typescript you have the computer helping you reason about it.
My favorite part about typescript becoming ubiquitous is that it is making people into more disciplined JavaScript programmers. The amount of cutesy overloading that was common in the early node days seems to be slowly waning.
I love how TypeScript makes the rich semantics of JavaScript visible.
When some programmers favored dynamic languages over the statically typed others looked at them like at mad.
The thing is that dynamic languages fans just wanted to have semantics as rich as this one and were willing to sacrifice even type checking altogether for it because no statically typed language was willing to deliver this semantic in any reasonable manner.
What? It only turns back into a dynamic language if you give up and start using “any”. The more detailed your type system, the more distinctions you can represent in it, and the more unintended behavior you can catch early. It can become more challenging to work with, but you’ll get end results that are more robust, which is one of the goals of strong typing.
I think a lot of the complexities of the type system come from the fact that types have to describe complex behavior in a static way, while still being useful (you could type everything in your code as `any`[0], but that wouldn't be very useful). JavaScript is complex, so statically describing its behaviors is also complex. At the same time, most of the complex types are types you never have to see or use, unless you're the maintainer of a complex library and you want to provide really useful types.
With C++ the usual solution is to use only a defined subset of it and make sure that lint checker is used in presubmit checks. Exceptions to other types should be allowed, but strongly discouraged when working in a team (which TypeScript is used for)
This is actually why I stopped using it. Forcing types on a dynamic language like this seems to inevitably lead to really, really complex type definitions which just confuse things tremendously. It almost seems easier and better to just straight up use JSDoc with some good standard documentation to back it.
It's more characters/more noise to the code to add a JSDoc comment block than it is to add a colon & typename next to the variables/values they belong to.
I was talking to a friend the other day about the backlash against Clippy in Office. Reading these release notes, can't help wonder if IDE's will soon need an equivalent.
Something like -> "Hey! it looks like your function only accepts a fixed set of strings. Would you like to use String Literals?"
I don't only code in Typescript so it's not practical for me to keep up with every language I work with.
Search works great if you know what you want, then you'll end up on these excellent release notes or a stackoverflow post and off you go. The trouble is when you don't know what you don't know.
Have you ever used Visual Studio? It sounds like you're describing the code analyzers that have been available for several years now.
For example, with an opportunity for string literals, there will be a light bulb in the left border. Pressing "Ctrl ." will bring up a list of suggested fixes. You can opt to select one, hit Enter, and the changes are automatically applied.
I believe there are similar extensions for VS Code.
VS Code does this for TypeScript out of the box. For example if you have a function with Promises it will suggest it be rewritten (and rewrite it for you) using async.
I use modern IDEs exclusively, and yet I have to fish for features like this (typically by searching for an error message) all the time. I'm sure there are many instances where I've come out with sub-optimal fixes because I didn't not know about a feature and my IDE didn't either.
Automated code sniffing sounds like a fantastic idea. Perhaps we’ll look back to the 2010s as the dark ages, when all we had at our disposal was peer review of our codes?
Review early and (fairly) often, lest you embark on implementing a FrobNibulatorFactory from the ground up only to be told there is one already in lib/util/frob/util/tools/misc/nibulation.
Not everyone has peers, alas. The imaginary ones help (rubber ducky, you’re the one...)
This has been around for years in .NET and Java IDEs and I'm sure in many more places. Jetbrains' ReSharper is famous for its complex code analysis with useful hints to improve code readability and robustness. A single click can refactor your code.
.NET's Roslyn compiler supports analyzers that you can write yourself which also support code fix providers to automatically refactor code. All analyzers and code fix providers are written in .NET languages (C#, F#, etc.), so the possibilities are endless.
They don’t cover everything and it requires setup, but I like using linters for this kind of thing - these types of suggestions can often be standardized in a codebase and auto fixed by tools like ESLint nowadays, it’s also a good way to make people aware of features.
And the JavaScript/TypeScript equivalent would be eslint. (Which doesn't have as brilliant a name and has less information available to it, but it's still very helpful.)
I always joked about how IntelliSense is just Clippy for your IDE. But yeah, it's pretty useful. coc.vim and tsserver save me from getting fired on a daily basis.
For C# there is an extension called Sharpen [0] that alerts you of new features in the new languages, it is quite nifty when you are ready to move to the next version of .net core for example and want to know where you can remove code etc.
> The trouble is when you don't know what you don't know.
At least the pain is a good indicator that there's something you're missing :) IRC has been somewhat useful for TS, albeit with mixed results compared to say, the gentle gods you will find in #postgresql.
To pile on, Typescript has been a lifesaver so far. Yes, the type system is rather complicated, but one can progressively use the advanced type, starting with typing numbers, strings, interfaces etc.
Having worked with Clojure for 4 years, and a JS (ES6 and +) codebase, static typing is amazing.
There are far fewer bugs at runtime because of incorrectly setting or forgetting to set keys in a map or a property or accidentally passing the wrong value to the property. Yes, interop with JS is a little messy, because of the dynamic nature of JS, but a large class of errors can be significantly reduced by Typescript.
As for the argument , unit tests can catch most of the problems Typescript solves, my counter is that
It reduces the amount of tests you need, to check getter/setters,types etc SIGNIFICANTLY. You can focus your unit tests on the more functional aspects than having to worry about basic property access.
All high-level languages have a learning curve. I don't expect to pick up the nuances and all the little bits of Typescript in a matter of weeks or months.It might even take years, but I think Typescript and its experimentation with providing a well typed Frontend interface is amazing !
> incorrectly setting or forgetting to set keys in a map or a property or accidentally passing the wrong value to the property
When you wrote/write Clojure, did you ever use spec? Any insights into how it compares with TS? They seem to give similar guarantees for this aspect, but I haven’t played with spec yet.
It is kinda hard to compare both, as the paradigms are quite different (FP vs OO),
spec , IMHO, seemed oriented towards validating properties and values in maps, as Hickey mentions in his talk, it is all about manipulating data.
Spec is opt-in. unless you are working with code that has already been spec-ed , you will run into the same problem that TS + JS interop has.
I found spec a little too intrusive (especially the namespaced keywords) and sometimes I wasn't sure what it was meant for, TBH.
In my first company, it was a bunch of cowboy programmer that didn't really care about typing the codebases, too cool to write unit tests and simply wrote enough end-to-end tests cases to solve the problem. I was just starting out and had NO idea on what was good programming practice.
In the second firm , we had used schema to type the codebase partially and it worked. But the type checks weren't compile time , but rather during unit tests and when running with type-checking enabled (I think this is the same for spec as well)
I think the advantage of TS comes from the static types (+ checking). You get immediate feedback before you can even compile it into javascript.
TypeScript is so powerful at this point I think the only really big thing they're missing is typed exceptions. After that they maybe should just close it for new language features and just optimize performance and add editor features (more automatic refactors) :D
Unfortunately that’s not idiomatic in many common JS/TS scenarios, and requires deep familiarity with the internals of any APIs or third party libraries that throw errors. Optional typed exceptions would be right in line with the TS approach of modeling real world JS usage, but for the syntactical question of exhaustive error handling. (Of course that could be addressed separately or not at all.)
Readit News
Editors give great autocomplete suggestions (usually covers it for properties and return values). Documenting with examples is often helpful. If all else fails, cast.
Without advanced types, code needs documentation to prevent invalidity. With advanced types, code gets logical guarantees, but it often requires the same documentation. It's not necessary for everyone on a team to have cutting edge knowledge when there's sensible documentation.
Types create a synergy with documentation. Provable(ish) guarantees with good documentation is the best of both worlds.
Part of it is just being able to write code that is extremely dynamic, yet still provides an amazing developed experience.
For example if an API change occurs on backend, the first step is to make the change to the request/response typings in the frontend...from there the source code will light up with all the errors you have to fix. I can just click through each one in VS Code and fix them, then re-run tests to validate...love it.
Much more effective.
I mean one can't represent the all possibilities of JavaScript "types" without re-implementing JavaScript itself, only a subset. I wonder where Typescript will stop.
I'd like to see Typescript compiling to "native" as well.
You don't have to personally understand TS's more complicated features to benefit from using TS in your project. I hope they continue adding richness to the type system so I can eliminate more bugs from my code.
It's great that Typescript is catching on, and we're starting to adopt it in my team, but I hope the TS people don't think they can keep adding new features to it in perpetuity, otherwise it's going to turn into C++.
Dead Comment
Stage 1: Put types into JavaScript.
Stage 2: TypeScript types are not expressive enough.
Stage 3: Put JavaScript into types.
I'm looking forward to stage 4 where the expressions inside TypeScript type annotations get so complex and hard to maintain that someone creates TypeTypeScript that lets you put type annotations inside the code inside type annotations.
https://github.com/capsadmin/nattlua
You can see some examples in the readme.
To me it makes sense that the typesystem is basically lua rather than a mathematical ish looking language.
It could prove to be more difficult to work with but I guess I'll find out.
It's not without precedent - Haskell has a Turing complete type system. (There's also Scala, Rust, and C++ templates which are all arguably Turing tarpits.)
Dead Comment
I don't think my comment sounds cynical.
> You don't have to use features you believe are "so complicated".
One has to be fluent with reading type definitions thus have good understanding of the type syntax. I must admit, from time to time I could not make sense of them easily when reading declaration files from third parties.
TypeScript advanced types are there to model existing JavaScript codebases, but when designing software from scratch I've seen that is too tempting to go crazy with the types, ending with something pretty messy (JavaScript! :-).
> [A Static TypeScript] program is compiled to machine code in the browser and linked against a precompiled C++ runtime, producing an executable that is more efficient than the prevalent embedded interpreter approach, extending battery life and making it possible to run on devices with as little as 16 kB of RAM (such as the BBC micro:bit).
To give a commonly-encountered example, rather than the easily-introspectable options object whose schema is specified by a zero-runtime-cost TS interface, in a traditional OOP language like Java you would write an XOptions / XOptionsBuilder class to maintain type safety, which is at once more opaque, with less predictable behavior.
It's not a horrible abuse if you aren't trying to make the framework/library statically typed in the first place.
Idiomatic APIs for dynamically typed languages use the flexibility of dynamic types. Idiomatic APIs for statically typed languages use the structure of static types.
The problem comes when you try to put one into the other's world. It's like watching a fish flop around on land. There's nothing intrinsically wrong with fish locomotion, it's just not optimized for that environment.
https://blog.joshuakgoldberg.com/type-system-game-engines/
Except all of it can be tested and validated at compile time so... not dynamic?
When some programmers favored dynamic languages over the statically typed others looked at them like at mad.
The thing is that dynamic languages fans just wanted to have semantics as rich as this one and were willing to sacrifice even type checking altogether for it because no statically typed language was willing to deliver this semantic in any reasonable manner.
[0]:https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...
In years of using TS I have had to craft a few exotic generics, but have otherwise never ran into "really complex" types.
Yeah I'd love something that just compiles .ts to a binary. But I can already hear the cries of "embrace, extend extinguish" if that happened.
https://www.typescriptlang.org/play?ts=4.1.0-beta#code/PTAEB...
Something like -> "Hey! it looks like your function only accepts a fixed set of strings. Would you like to use String Literals?"
I don't only code in Typescript so it's not practical for me to keep up with every language I work with.
Search works great if you know what you want, then you'll end up on these excellent release notes or a stackoverflow post and off you go. The trouble is when you don't know what you don't know.
For example, with an opportunity for string literals, there will be a light bulb in the left border. Pressing "Ctrl ." will bring up a list of suggested fixes. You can opt to select one, hit Enter, and the changes are automatically applied.
I believe there are similar extensions for VS Code.
Review early and (fairly) often, lest you embark on implementing a FrobNibulatorFactory from the ground up only to be told there is one already in lib/util/frob/util/tools/misc/nibulation.
Not everyone has peers, alas. The imaginary ones help (rubber ducky, you’re the one...)
.NET's Roslyn compiler supports analyzers that you can write yourself which also support code fix providers to automatically refactor code. All analyzers and code fix providers are written in .NET languages (C#, F#, etc.), so the possibilities are endless.
The Rust compiler exposes a lot of information, so it's actually quite powerful in my experience.
[0] https://marketplace.visualstudio.com/items?itemName=ironcev....
https://elm-lang.org/news/compiler-errors-for-humans
At least the pain is a good indicator that there's something you're missing :) IRC has been somewhat useful for TS, albeit with mixed results compared to say, the gentle gods you will find in #postgresql.
Having worked with Clojure for 4 years, and a JS (ES6 and +) codebase, static typing is amazing.
There are far fewer bugs at runtime because of incorrectly setting or forgetting to set keys in a map or a property or accidentally passing the wrong value to the property. Yes, interop with JS is a little messy, because of the dynamic nature of JS, but a large class of errors can be significantly reduced by Typescript.
As for the argument , unit tests can catch most of the problems Typescript solves, my counter is that
It reduces the amount of tests you need, to check getter/setters,types etc SIGNIFICANTLY. You can focus your unit tests on the more functional aspects than having to worry about basic property access.
All high-level languages have a learning curve. I don't expect to pick up the nuances and all the little bits of Typescript in a matter of weeks or months.It might even take years, but I think Typescript and its experimentation with providing a well typed Frontend interface is amazing !
Exactly! unit testing a return type is such a backword step in programming
When you wrote/write Clojure, did you ever use spec? Any insights into how it compares with TS? They seem to give similar guarantees for this aspect, but I haven’t played with spec yet.
spec , IMHO, seemed oriented towards validating properties and values in maps, as Hickey mentions in his talk, it is all about manipulating data.
Spec is opt-in. unless you are working with code that has already been spec-ed , you will run into the same problem that TS + JS interop has.
I found spec a little too intrusive (especially the namespaced keywords) and sometimes I wasn't sure what it was meant for, TBH.
In my first company, it was a bunch of cowboy programmer that didn't really care about typing the codebases, too cool to write unit tests and simply wrote enough end-to-end tests cases to solve the problem. I was just starting out and had NO idea on what was good programming practice.
In the second firm , we had used schema to type the codebase partially and it worked. But the type checks weren't compile time , but rather during unit tests and when running with type-checking enabled (I think this is the same for spec as well)
I think the advantage of TS comes from the static types (+ checking). You get immediate feedback before you can even compile it into javascript.
Why is alignment accepting a color? It doesn’t matter how good the type checking is if you are creating the wrong type to begin with.
That aside, congrats on the release!
By any other name would smell as sweet.
So Romeo would, were he not Romeo call'd,
Retain that dear perfection which he owes
Without that title.
https://davidtimms.github.io/programming-languages/typescrip...
Dead Comment