Many people fail to see that the real benefit of using TypeScript is better tooling (code completion, intenseness, refactoring capabilities, self-documenting code) and not the mere ability to catch some stupid runtime errors at compile time.
This is one of the reasons I find it hard to like TypeScript. Despite proclamations about reducing errors and maintainability, I have seen many developers largely motivated to introduce TypeScript for no reason other than the ability to hit "." and see what comes next. While that is a good goal, transmogrifying a type system (and a rather weak one at that) into an IntelliSense annotation mechanism seems excessive.
It's comments like this that make me feel better about my own decisions.
Because if that was the only benefit typescript had, it would be a win. I mean that was the whole point with JSDOC.
Anything that shortens the feedback loop from writing the code to seeing if it works is a win.
This is the equivalent of saying, "I see many people switching jobs for no reason other than to make more money". Like... That's the not the only reason but it's a big one.
Then you get into algebraic data types, and encoding logic constraints into the type system, and you can make entire classes of bugs impossible to write.
Do you have an alternative suggestion? Because the ability to type "." and see what comes next, go-to-definition, find all references, rename symbol, etc. are all enormous time savers.
Just as yanis_t said, they're easily worth it even if you ignore the significant bug reduction (approximately 15%).
I don't know of any other way to get that kind of productivity boost. What would you suggest instead?
Why do you think the type system is weak? I was using PureScript (Haskell derivative) prior to TypeScript, and I have found its typing capabilities to be very impressive.
If history is an indication, any part of the JavaScript ecosystem that is not part of a formal standard, no matter how widely used or deeply integrated into the industry, is prone to getting replaced or obsoleted. There was a time when front-end development without jQuery was unthinkable. We now seem to be slowly coming out of any era when front-end development without reactive component based SPAs (React, Angular etc.) was unthinkable. I suspect that in the long run, compile-to-JS type systems will go the same way. Perhaps the alternative is a set of optional run-time validation capabilities built into ECMAScript (syntactic sugar over `typeof`?), whatever that may be.
Disclaimer: I’m not a frontend dev so what I’m about to say might very well be nonsense, but I thought that jquery became popular not due to shortcomings in the JS language, but in the DOM API. So I think TypeScript is a very different case, as it fills a void in the language itself (lack of types). That doesn’t mean that in the future types won’t be added to the lang spec, but if that happens I think it would be very heavily influenced by TypeScript (e.g. like what happened with Hibernate and JPA).
Correct, at least from my experience. In my personal projects I was heavily Vanilla JS, but I also didn’t care if IE didn’t have full functionality (I did try to use graceful degradation when functionality was important, like navigation), but in any professional setting it would be maddening to rely on JS and not use something like jQuery. Coding around how each browser decided to give scroll position or the differences in accessing other DOM properties by hand could be tedious depending on what you wanted to do, and jQuery abstracted that effectively.
I think you’re correct that, if the language formally adopted types, it would look similar to TypeScript. How _much_ of TS would be mirrored may be a different story - it’s incredibly extensive in some areas, I’m still learning new things about it as I’ve only recently started getting into it for work, and there’s a lot to it beyond basic type support.
Jquery became popular because at the time there were all these browsers and none of them did things the same. They weren’t standards compliant like most browsers are today. So you ended up writing a ton of code and css that basically said, “if browser x - do this - else if browser y - do this”. Then jQuery came along and took care of all of that for you. They made it so you could just write for jquery and it would take care of translating it into what browser the person viewing the site was using. It made things so much easier. jQuery was basically write once, run everywhere, for the browsers of those days.
If types were added to javascript it could also dramatically improve the performance of javascript virtual machines (V8 and friends). It seems so silly to me that I write typescript, then the types are erased from my code, sent to the browser, and then the browser tries to infer them as part of its own optimization process.
Adding types to javascript proper would be fantastic.
After having used WASM on the client side, I have my doubts.
It is too much of a drag on productivity using less featureful developer tools, and JavaScript is already plenty fast enough. WASM is good for things that need to be as fast as possible, but for the vast majority of use cases it simply doesn’t offer any benefits.
The advantage of JS is that the browser is aware of your object graph and can provide dev tools around that.
I actually think about this I’m entirely the opposite way. The moment all browser APIs especially the DOM become usable from WASM it’s over for JS and would no longer be the obvious choice as it’s suddenly not the only game in town and the hacks that were required before such as compile to JS for example stop mattering.
jQuery is a bit of a poor example in the context since most of the stuff jQuery provides HAS been integrated into the standard making the lib obsolete. If the ES standard introduces types in a good way that will of course make TS obsolete.
I find TypeScript's type system
fascinating, especially the intersection types. I wish there was an article contrasting TS's type system with that of other languages and just pointing out the unique to TS parts.
Flow supports both nominal types for classes with correct variance and structural types for everything else. This is correct model for js, flow is ahead of typescript in this case.
Objects passed to a function that accepts an object type can generally have more properties that needed given Typescript’s structural typing. That is unless you pass a literal directly to the function (I.e. inline the obj variable in the linked example). In which case Typescript will complain about the excess properties. Ergonomic but confusing the first time you come across it.
Those are exact object types which have first class support in flow and no support with exception of literals like you mention in typescript. Flow is ahead in this case.
It feels like the same information is repeated often 2, sometimes even 3 times. And overall, I don't think this book has anything more than what's already in official docs.
Perhaps it is LLM generated, as git says it is ~3 months old - but it links to a page on the TypeScript website which was removed a long time before that, https://www.typescriptlang.org/dt/search
I would actually love a “Typescript: The good parts” as a spiritual sequel to Javascript: The good parts. [0] Something that starts at the basics and builds upon that knowledge layer by layer like this handbook, but doesn’t dedicate more than a page to any one topic, and doesn’t repeat itself. Not a tutorial, but more like a glossary ordered by abstraction.
Plus, there’s a lot of Typescript I would consider not part of the “good stuff”, we can leave out enums.
Try Dan Vanderkam's "Effective Typescript: 62 Specific Ways to Improve YourTypeScript" (O'Reilly). I'm no TS guru, but IMHO it's pretty well-grounded in first principles.
yeah I took a look and couldnt help but feeling like it was a laundry list with minimal examples and not always telling you why or when you would use a certain feature of TypeScript. Example: TypeScript _does_ enable you to overload functions, but overloading functions is nearly never the best way to do something, often cited as a spaghetti code pattern
recently there are a few stories about "using jsdoc for static typing instead of typescript as a JS programmer", I wonder when JS can add support of static typing directly as Python did, that will be nicer without learning a new language like TS.
TS is great, I just never could find time to learn one more language.
The projects that are using JSDoc for typings are doing so because they are way, way out on the edge in ways that stress Typescript compilers. They're doing weird stuff. It isn't a recommended path unless you absolutely need it; it's sacrificing a lot in order to yield faster round-trip time on codebases that have no other option.
Typescript isn't really "a new language", either. It's a pretty mild superset.
> because they are way, way out on the edge in ways that stress Typescript compilers
I don't think this is true at all. Probably the main reason people typecheck js with jsdoc annotations is because they don't want a TS compile step.
Nodejs ES modules, and typescript, make it more complicated that it needs to be to write JS specifically for nodejs/cli scripts (not bundling to run in the browser). I now just prefer to // @ts-check my js files when writing node scripts.
The best thing with TS is you can apply as much or as little as you want. Start by adding the compiler to your workflow and get it to work without making any changes to your code. Then add a couple types and see how it goes.
You can achieve the same thing TS does with JSDoc, it's just a lot harder to control it across teams. TS wouldn't be very useful on its own for our usage, but once you couple ESlint with TSconfig and setup your ourganisationwide vsc .settings for TS usesage you can really control the flow of how every developer on your team works with TS. I'm not sure JSDoc has the equivalent to @typescript-plugin rulesets for linting purposes, or if you can build the rules directly into your CI pipeline in a way that prevents rulebreakers from comitting their code.
Aside from that, it's a little different to work with JSDoc. It doesn't have quite the same intellisense integration in VSC. It's also a little different for many developers who aren't necessarily used to writing their documentation first or along with their code, but are used to working with things like C#, Java or similar.
If you want to put in the effort, you can likely setup a JSDoc dev environment for JS where you're getting the benefits of TS without the compiling. I don't see us doing it any time soon, but as someone who's very fond of TS I also wouldn't be surprised if we won't be using it for JavaScript in 5 years.
Yes, no language has static typing until you run a static typechecker; for some languages you don’t notice because it is integrated into the normal compiler, etc.
Every time I say "I'm not gonna beed typescript for something this small", something happens that makes me think typescript may have been better anyway.
I agree, but I do wonder why the knee jerk reaction is "I'm not going to need it". The setup cost is basically zero! If TypeScript offers any benefit at all, why _not_ use it, since the benefits will come at near zero cost?
IMO the benefits of TS are huge, but probably the biggest benefit is that refactoring becomes almost trivial in most cases - just change the type of a variable/function/etc and the compiler will tell you every line in your codebase that needs to change in real time.
> refactoring becomes almost trivial in most cases
And when it does not become trivial, it is an indicator it would be borderline impossible without it.
After a rather extensive refactor I once did the compiler gave me over 4.000 typescript errors. It would be a tremendous effort for all of these to be identified and ironed out, probably taking years because many issues were very circumstantial.
Very timely. I've been using some inherited Typescript on a project for a while and was looking for exactly this kind of concise laying out of the language that you can read in an hour or two.
I think GP wants something akin to Beej’s guides, where he presents you with like 10 formats on the homepage and you pick the one that works best for your device and use case: https://beej.us/guide/bgnet/
Many people fail to see that the real benefit of using TypeScript is better tooling (code completion, intenseness, refactoring capabilities, self-documenting code) and not the mere ability to catch some stupid runtime errors at compile time.
All of those (apart from intenseness hehe) are consequences of using a decent type system. I don’t think people ignore that IME.
Just yesterday I ran into a runtime error when I forgot the round brackets in`Buffer .contact`. This wouldn't have happened with Typescript.
For a moment was intrigued what contact would do on a buffer but I think you meant concat.
This is one of the reasons I find it hard to like TypeScript. Despite proclamations about reducing errors and maintainability, I have seen many developers largely motivated to introduce TypeScript for no reason other than the ability to hit "." and see what comes next. While that is a good goal, transmogrifying a type system (and a rather weak one at that) into an IntelliSense annotation mechanism seems excessive.
It's comments like this that make me feel better about my own decisions.
Because if that was the only benefit typescript had, it would be a win. I mean that was the whole point with JSDOC.
Anything that shortens the feedback loop from writing the code to seeing if it works is a win.
This is the equivalent of saying, "I see many people switching jobs for no reason other than to make more money". Like... That's the not the only reason but it's a big one.
Then you get into algebraic data types, and encoding logic constraints into the type system, and you can make entire classes of bugs impossible to write.
Type systems are about safety and productivity.
Do you have an alternative suggestion? Because the ability to type "." and see what comes next, go-to-definition, find all references, rename symbol, etc. are all enormous time savers.
Just as yanis_t said, they're easily worth it even if you ignore the significant bug reduction (approximately 15%).
I don't know of any other way to get that kind of productivity boost. What would you suggest instead?
4 replies →
Why do you think the type system is weak? I was using PureScript (Haskell derivative) prior to TypeScript, and I have found its typing capabilities to be very impressive.
2 replies →
If history is an indication, any part of the JavaScript ecosystem that is not part of a formal standard, no matter how widely used or deeply integrated into the industry, is prone to getting replaced or obsoleted. There was a time when front-end development without jQuery was unthinkable. We now seem to be slowly coming out of any era when front-end development without reactive component based SPAs (React, Angular etc.) was unthinkable. I suspect that in the long run, compile-to-JS type systems will go the same way. Perhaps the alternative is a set of optional run-time validation capabilities built into ECMAScript (syntactic sugar over `typeof`?), whatever that may be.
Disclaimer: I’m not a frontend dev so what I’m about to say might very well be nonsense, but I thought that jquery became popular not due to shortcomings in the JS language, but in the DOM API. So I think TypeScript is a very different case, as it fills a void in the language itself (lack of types). That doesn’t mean that in the future types won’t be added to the lang spec, but if that happens I think it would be very heavily influenced by TypeScript (e.g. like what happened with Hibernate and JPA).
Correct, at least from my experience. In my personal projects I was heavily Vanilla JS, but I also didn’t care if IE didn’t have full functionality (I did try to use graceful degradation when functionality was important, like navigation), but in any professional setting it would be maddening to rely on JS and not use something like jQuery. Coding around how each browser decided to give scroll position or the differences in accessing other DOM properties by hand could be tedious depending on what you wanted to do, and jQuery abstracted that effectively.
I think you’re correct that, if the language formally adopted types, it would look similar to TypeScript. How _much_ of TS would be mirrored may be a different story - it’s incredibly extensive in some areas, I’m still learning new things about it as I’ve only recently started getting into it for work, and there’s a lot to it beyond basic type support.
Jquery became popular because at the time there were all these browsers and none of them did things the same. They weren’t standards compliant like most browsers are today. So you ended up writing a ton of code and css that basically said, “if browser x - do this - else if browser y - do this”. Then jQuery came along and took care of all of that for you. They made it so you could just write for jquery and it would take care of translating it into what browser the person viewing the site was using. It made things so much easier. jQuery was basically write once, run everywhere, for the browsers of those days.
Honestly the TC39 is the best case scenario. https://tc39.es/proposal-type-annotations/
Forget runtime type validation, TS is really for preventing bugs at development time as well as IDE integration.
If types were added to javascript it could also dramatically improve the performance of javascript virtual machines (V8 and friends). It seems so silly to me that I write typescript, then the types are erased from my code, sent to the browser, and then the browser tries to infer them as part of its own optimization process.
Adding types to javascript proper would be fantastic.
6 replies →
I suspect that in the long run, compile-to-JS type systems will go away and will be replaced by compile-to-WASM type systems.
After having used WASM on the client side, I have my doubts.
It is too much of a drag on productivity using less featureful developer tools, and JavaScript is already plenty fast enough. WASM is good for things that need to be as fast as possible, but for the vast majority of use cases it simply doesn’t offer any benefits.
The advantage of JS is that the browser is aware of your object graph and can provide dev tools around that.
4 replies →
I actually think about this I’m entirely the opposite way. The moment all browser APIs especially the DOM become usable from WASM it’s over for JS and would no longer be the obvious choice as it’s suddenly not the only game in town and the hacks that were required before such as compile to JS for example stop mattering.
“The moment”? You’re living in a fantasy. JavaScript would still be highly relevant and used for decades to come.
jQuery is a bit of a poor example in the context since most of the stuff jQuery provides HAS been integrated into the standard making the lib obsolete. If the ES standard introduces types in a good way that will of course make TS obsolete.
> I suspect that in the long run, compile-to-JS type systems will go the same way.
I think the plan was to compile to WASM. The hype phase seems to be over, but afaict it’s been delivering on at least some of it’s promises no?
indeed, it's almost a certainty that every framework and tool in the JS ecosystem becomes obsolete as time goes by.
I find TypeScript's type system fascinating, especially the intersection types. I wish there was an article contrasting TS's type system with that of other languages and just pointing out the unique to TS parts.
I've found the biggest difference is structural vs. nominal types.
https://www.typescriptlang.org/play#example/structural-typin...
It seems particularly suited to dealing with random JSON payloads.
Flow supports both nominal types for classes with correct variance and structural types for everything else. This is correct model for js, flow is ahead of typescript in this case.
Java has intersection types.
But Java is nominally typed so I’d argue it’s not really the same
One thing I’ve never found a name for (and, as a result, a good way to reference to people) is Typescript’s interesting behaviour around the Erased Structural Types mentioned here: https://github.com/gibbok/typescript-book#erased-structural-....
Objects passed to a function that accepts an object type can generally have more properties that needed given Typescript’s structural typing. That is unless you pass a literal directly to the function (I.e. inline the obj variable in the linked example). In which case Typescript will complain about the excess properties. Ergonomic but confusing the first time you come across it.
Those are exact object types which have first class support in flow and no support with exception of literals like you mention in typescript. Flow is ahead in this case.
I believe this implements an exact object type in Typescript:
Credit goes to Manan Tank: https://twitter.com/MananTank_/status/1677610004743086080
1 reply →
It feels like the same information is repeated often 2, sometimes even 3 times. And overall, I don't think this book has anything more than what's already in official docs.
Perhaps it is LLM generated, as git says it is ~3 months old - but it links to a page on the TypeScript website which was removed a long time before that, https://www.typescriptlang.org/dt/search
I would actually love a “Typescript: The good parts” as a spiritual sequel to Javascript: The good parts. [0] Something that starts at the basics and builds upon that knowledge layer by layer like this handbook, but doesn’t dedicate more than a page to any one topic, and doesn’t repeat itself. Not a tutorial, but more like a glossary ordered by abstraction.
Plus, there’s a lot of Typescript I would consider not part of the “good stuff”, we can leave out enums.
[0] https://www.goodreads.com/book/show/2998152-javascript
Try Dan Vanderkam's "Effective Typescript: 62 Specific Ways to Improve YourTypeScript" (O'Reilly). I'm no TS guru, but IMHO it's pretty well-grounded in first principles.
What's wrong with enums? Enum types in general are very useful.
6 replies →
I thought it was this official "Handbook"
https://www.typescriptlang.org/docs/handbook/intro.html
There's also this one (not official)
https://basarat.gitbook.io/typescript/
yeah I took a look and couldnt help but feeling like it was a laundry list with minimal examples and not always telling you why or when you would use a certain feature of TypeScript. Example: TypeScript _does_ enable you to overload functions, but overloading functions is nearly never the best way to do something, often cited as a spaghetti code pattern
recently there are a few stories about "using jsdoc for static typing instead of typescript as a JS programmer", I wonder when JS can add support of static typing directly as Python did, that will be nicer without learning a new language like TS.
TS is great, I just never could find time to learn one more language.
The projects that are using JSDoc for typings are doing so because they are way, way out on the edge in ways that stress Typescript compilers. They're doing weird stuff. It isn't a recommended path unless you absolutely need it; it's sacrificing a lot in order to yield faster round-trip time on codebases that have no other option.
Typescript isn't really "a new language", either. It's a pretty mild superset.
> because they are way, way out on the edge in ways that stress Typescript compilers
I don't think this is true at all. Probably the main reason people typecheck js with jsdoc annotations is because they don't want a TS compile step.
Nodejs ES modules, and typescript, make it more complicated that it needs to be to write JS specifically for nodejs/cli scripts (not bundling to run in the browser). I now just prefer to // @ts-check my js files when writing node scripts.
1 reply →
The best thing with TS is you can apply as much or as little as you want. Start by adding the compiler to your workflow and get it to work without making any changes to your code. Then add a couple types and see how it goes.
You can achieve the same thing TS does with JSDoc, it's just a lot harder to control it across teams. TS wouldn't be very useful on its own for our usage, but once you couple ESlint with TSconfig and setup your ourganisationwide vsc .settings for TS usesage you can really control the flow of how every developer on your team works with TS. I'm not sure JSDoc has the equivalent to @typescript-plugin rulesets for linting purposes, or if you can build the rules directly into your CI pipeline in a way that prevents rulebreakers from comitting their code.
Aside from that, it's a little different to work with JSDoc. It doesn't have quite the same intellisense integration in VSC. It's also a little different for many developers who aren't necessarily used to writing their documentation first or along with their code, but are used to working with things like C#, Java or similar.
If you want to put in the effort, you can likely setup a JSDoc dev environment for JS where you're getting the benefits of TS without the compiling. I don't see us doing it any time soon, but as someone who's very fond of TS I also wouldn't be surprised if we won't be using it for JavaScript in 5 years.
Python doesn't have static typing until you add a library to check your "hints". This is valid in Python 3.10:
Yes, no language has static typing until you run a static typechecker; for some languages you don’t notice because it is integrated into the normal compiler, etc.
Gotta say I’ve tried using TS and frankly haven’t seen too much benefit. This makes me suspicious since I’m clearly in the minority about this.
I find it mildly useful as a form of documentation - and the intellisense is nice, but otherwise find it cumbersome to use.
In general - while I’ve experienced some issues with types in JS, it usually isn’t the root cause of most bugs I encounter.
Every time I say "I'm not gonna beed typescript for something this small", something happens that makes me think typescript may have been better anyway.
I agree, but I do wonder why the knee jerk reaction is "I'm not going to need it". The setup cost is basically zero! If TypeScript offers any benefit at all, why _not_ use it, since the benefits will come at near zero cost?
2 replies →
IMO the benefits of TS are huge, but probably the biggest benefit is that refactoring becomes almost trivial in most cases - just change the type of a variable/function/etc and the compiler will tell you every line in your codebase that needs to change in real time.
> refactoring becomes almost trivial in most cases
And when it does not become trivial, it is an indicator it would be borderline impossible without it.
After a rather extensive refactor I once did the compiler gave me over 4.000 typescript errors. It would be a tremendous effort for all of these to be identified and ironed out, probably taking years because many issues were very circumstantial.
The benefit is, your project needs a compiling phase in order to run. It's safer than just deploy and run your javascript code without that phase.
If this is concise, I'd hate to see verbose...
Very timely. I've been using some inherited Typescript on a project for a while and was looking for exactly this kind of concise laying out of the language that you can read in an hour or two.
Typescript errors are the worst errors give ever seen
You've obviously never done any C++ involving template metaprogramming.
many thanks! Many backend jobs are suddenly requiring typescript knowledge, seems to be in high demand right now.
thanks, but I'll ask "copilot for docs" to save time and get better answers.
You will not ask about things if you don't know they even exist.
Quite au contraire mon amie, you can just ask him to tell you typescript and keep prompting as you see fit. It will match your exact needs and style.
There's also a beta copilot for docs which includes typescript
https://githubnext.com/projects/copilot-for-docs
How can you prompt copilot like chat? It only does autocomplete well.
You need to have access to Copilot Chat, which is only available as an extension in VSC Insiders.
[flagged]
ok great how do i read this on the train when i have no internet?
Take the README.md, print to pdf and transfer to your reading device before leaving?
I think GP wants something akin to Beej’s guides, where he presents you with like 10 formats on the homepage and you pick the one that works best for your device and use case: https://beej.us/guide/bgnet/
git clone