you're not meant to scroll ahead, the intention is to create a time sink in each chapter. I figured this out after reading the first chapter forever, then I was like "wait a second this is the concise book? how can I read the introduction forever?"
I've read the introduction part and I've seen no "time sink." I genuinely don't know what your comment means. Do you really have a hard time reading the introduction part?
So we know there are types and interfaces. One support declaration merging, one does not. Both can extend others, but in different ways. But why? Why there are two of them? When should I use them? Is one better than the other?
Determining the motivation for design decisions is outside the scope of what any external party can and/or should do. The most the author could do is echo what's in the docs (if present), or give their own guess on why things are the way they are.
I love the Typescript handbook, but wanted the examples to be "runnable". It turns out that the TypeScript compiler runs pretty fast in the browser for trivial code snippets, so I threw together https://ts.coach (TypeScript handbook with code examples that execute in the browser + instant type checking)
Thank you for the excellent feedback. I had this realization a while back that I'm a mobile user during "consumption" (e.g. browsing HN late at night), but a desktop user for "production" - now I see how it applies to this side project as well. Also, I still need to figure out some React performance issues which make it virtually unusable on pre-2020 machines :(
This comment actually invigorated me to try the site from my phone and improve the experience, so I sincerely thank you for the motivation.
I've considered doing a similar project to yours writing or using some mobile friendly editor and hooking it directly into TypeScript's LSP, which can be easily added to a web page, but was never motivated/disciplined enough to push through it.
It should be your first resource when looking something up, it's usually quite clear and often helpful, but I find it somewhat confusingly organized and rather incomplete. It's more of a reference than a tutorial or guidebook, per se.
I show people coming from object oriented backgrounds this page first in order to correct the perception that TypeScript is best used with that programming paradigm.
> I show people coming from object oriented backgrounds this page first in order to correct the perception that TypeScript is best used with that programming paradigm.
I think you're confusing things. Languages like Java or C# impose an artificial constraint that free functions don't exist and functions can only exist as members of a class. You don't see this constraint in OO languages such as C++.
Also, it's a simplistic assertions to claim that classes have no place in TypeScript or aren't idiomatic. That's just nonsense based on specious reasoning. Classes/objects with function members are still the best way to implement some features. I'm seeing too many people writing absurd typescript code who go through great lengths to avoid a class because they think a class is taboo. They pull out convoluted stunts like passing closures as object members, just to avoid the sin of rolling out a class.
To clarify, I’m not claiming that classes have no place in Typescript. What I’m saying is that many people coming from OOP backgrounds tend to have the mistaken belief that TypeScript is best written with that paradigm. While it can be in some cases, it should not be assumed to be the best way. In fact, the documentation linked above asserts that “free functions over data” are extremely powerful, and “tend to be the preferred model for writing programs in JavaScript.”
I don't know, the number of people that know what a mapped or sum types are is strikingly low, let alone some of the more advanced concepts or even tsconfig.
I've always thought that typescript is in the real of technologies that developers use for years but never really master such as css. Maybe not as severe as css, but it's the same direction.
I know why typescript "succeeded", but always wonder what kind of web we would have if infact Haxe had become more popular for web in the early days. My guesstimate is we would have had bundlers in native code much, much earlier, and generally much faster and more robust tooling. Its only now we see projects like esbuild, and even TS being written in a compiled language (go), and other efforts in rust.
Also it would have been interesting sto ser what influence Haxe would have had on javascript itself
Thats true, but comes with a cost. TS has become an incredibly complex language, even it only provides types. Thats being said is will always lack features as it only "javascript".
Haxe has a more robust, but simpler typesystem, that comes from ocaml.
Haxe also compiles to C++ so making native tools would have been a breeze.
TS sits at the top chair, but there is many "better" options out there, like Elm (even its kild of a dead languge) and ReScript/ReasonML etc.
TS is good, but will never be a perfect language for javascript. It will always be a mediocre option, that is growing more and more complex in every new release.
Yes, amazing language - I recall having a look at it in 2013 when I was scrambling for a replacement for Flash (also amazing platform). Shame it doesn't solve the problem at hand.
Hardly anyone cares TypeScript isn't perfect when they can migrate their (or anyone else's) terrible, but business-critial JS library to TS and continue development without skipping a beat.
For the same reason ReasonML took years to overtake fartscroll.js in the number of stars on GitHub.
A huge part of TS's complexity is there so that library authors can describe some exotic behaviours seen normally only in dynamically-typed languages. When you're writing an app you don't need the vast majority of those features. Personally I regret every usage of `infer` in application code.
> For the same reason ReasonML took years to overtake fartscroll.js in the number of stars on GitHub.
Wow, that's a fascinating statistic! Certainly puts the popularity delta into a different light.
On a separate note, the fartscroll.js demo page[0] no longer works since code.onion.com is no longer accessible. Truly disappointing. Luckily their release zip contains an example.html!
Please provide a PDF as well. I cannot read books in HTML format because I need to keep track of where i left. That means I either have to leave the browser tab open (but this is prone to accidentally closing it) or I need to bookmark every progress, which creates noise in my bookmarks. With a PDF I simply leave it, the reader remembers my last page. I also have a sense of progress with pdf.
Unfortunately most of the content hasn't been updated for two years straight, which is quite a lot considering how much ECMAScript and TypeScript have been changing in recent years. I guess it's still a good reference, though.
The thing is, documentation isn't a monolithic thing --- it really needs to be sub-divided/categorized into subsets which are useful to specific categories of folks working on, or working with, a project:
That does make a huge difference, though I have found you also need to divide by the audiences. There are usually two main audiences that need addressing:
1. The new user. They typically know nothing about the product, not even why it exists. The CTO/CIO bought it and now you have to use it. They need lots of hand-holding and needs concrete instruction. Tutorials and explanations are focused on them so they can build accurate mental models of how the software work.
2. The experienced user. They have a pretty good idea of how the product works, but business requirements have changed in some way and know needs to make adjustments to their processes. Or just needs reminders of less used features. Good how-tos and reference material is vital.
If you don't take care of these things the customer will abandon your product sooner than later.
Agreed, but IMHO it should be layered so one can enter at the highest conceptual level and drill down and back up so there's a continuous flow of understanding.
My experience is that if there's too much documentation for a given representation, a not insignificant number of folks will not read it --- divide and conquer seems to be a workable approach.
I agree -- my point was to have the details linked in a drill down manner so that one can skim the high level parts but easily expand upon any topic directly from where it's being referenced.
What you describe sounds a lot like Diátaxis[1], which is a strategy for writing and organizing technical documentation. It categorizes docs into one of four categories: tutorials, explanations, how-tos, and references.
Category is derived from a fairly simple heuristic: whether the content informs action or cognition, and whether the content serves the reader’s application or acquisition of a skill[2]. I’m a fan and it’s simple enough that most anyone can learn it in an afternoon.
Damn, I wasn't aware that since I avoid TS, I cannot use ES6 and ES7, and my vanilla JavaScript doesn't run in all browsers :(
I guess over-hyping the technology that the book is about is to be expected, but it still leaves a slightly sour taste in my mouth when people oversell what they're talking about it.
I think the point is that you can write your code using ES6 and ES7 and the TypeScript compiler allows you to output ES6 or ES5 compatible code if you want to make sure it runs in older browsers as well. You can do that with non-TypeScript ES code as well but you’re bound to use another transpiler. With TypeScript you get it „for free“ since you need to compile your code either way.
Ah yeah, kind of like how I get a drink for free if I get the hamburger menu, even if it costs more? Kind of weird perspective, but I can accept that it's something zealots tell themselves so "we're doing it differently" actually computes for them.
Don't be like this. Don't spit bile at people because they have different needs and preferences to you.
As I understand it, the TS compiler can translate newer JS features/syntax into backwards-compatible polyfills for you, automatically. I don't really use TS myself, but I'm not going to pretend like that isn't a useful feature.
I have used JS before TS entered the scene, and being able to transpile features/syntax like that is not a TS innovation, nor only available in TS. That's why flagging that as something "you get for free, since you added a compiler anyways" feels dishonest. Ultimately it's true, but if that's what you're out after, then adding TS to your project is going way above and beyond just "transpiling new syntax to old syntax".
> is not a TS innovation, nor only available in TS
> since I avoid TS, I cannot use ES6 and ES7, and my vanilla JavaScript doesn't run in all browsers
Where was that claim made? I don't see it in any Typescript docs, or in the book.
You seem to be saying that the TS docs say that these features are unique. They obviously aren't, the documentation is clearly not saying they are, and no reasonable person would say they were.
Transpiling to another platform is a multiplying benefit when combined with other benefits though.
For example: Clojure and Kotlin both target the JVM. The language design of each brings certain benefits. These benefits are clearly more useful if they have a wide deployment base in the form of the JVM.
> Where was that claim made? I don't see it in any Typescript docs, or in the book.
In the article, you know, linked in this submission, which my original comment quoted verbatim. Again:
> > Some of the benefits of TypeScript:
> > Access to ES6 and ES7 features
I'm saying that these are not "benefits of TypeScript" but benefits of doing transpiling in general with a tool that can "downcast" features like that, which is in no way exclusive to TypeScript nor even began with TypeScript, but AFAIK with Browserify.
When I talk about "benefits of language X" I try to keep it to things that are actually about the language, not particular implementation details also broadly available and used by others, because I feel like it'd be misleading.
> I have used JS before TS entered the scene, and being able to transpile features/syntax like that is not a TS innovation, nor only available in TS.
I used JS back in the 1990s. Transpiling to JS is a relatively new phenomenon.
No one said transpiling is a TS innovation, nor that it is unique to TS.
> That's why flagging that as something "you get for free, since you added a compiler anyways" feels dishonest. Ultimately it's true, but if that's what you're out after, then adding TS to your project is going way above and beyond just "transpiling new syntax to old syntax".
That's silly. Transpiling is something TS can do, so it's not dishonest to advertise it as something TS can do. If you think TS is too hefty, don't use it. But don't be toxic towards those that do.
You're moving the goalposts to try and defend a bad take. That's how you get brownie points on the Internet for extreme takes, but also how you prevent yourself from learning and growing in the long run. Learn to take an L. You'll be better for it.
I don't know if I'd call a book with 61 chapters "concise".
They aren't book-length chapters. E.g. https://gibbok.github.io/typescript-book/book/strictnullchec... is one paragraph, https://gibbok.github.io/typescript-book/book/void-type/ is 1 sentence plus 1 3-line example. Near all of those "chapters" seem to be bit more than that. 1~2 paragraphs plus 1~2 code examples.
you're not meant to scroll ahead, the intention is to create a time sink in each chapter. I figured this out after reading the first chapter forever, then I was like "wait a second this is the concise book? how can I read the introduction forever?"
I've read the introduction part and I've seen no "time sink." I genuinely don't know what your comment means. Do you really have a hard time reading the introduction part?
It didn't included the JavaScript subset, so that's pretty concise.
What I miss in this book is the reasoning.
https://gibbok.github.io/typescript-book/book/differences-be...
So we know there are types and interfaces. One support declaration merging, one does not. Both can extend others, but in different ways. But why? Why there are two of them? When should I use them? Is one better than the other?
Determining the motivation for design decisions is outside the scope of what any external party can and/or should do. The most the author could do is echo what's in the docs (if present), or give their own guess on why things are the way they are.
Giving guidance on which one should be used and when is well within the scope of external parties.
I was wondering what is the community's opinion on the official TypeScript Handbook
https://www.typescriptlang.org/docs/handbook/intro.html
I love the Typescript handbook, but wanted the examples to be "runnable". It turns out that the TypeScript compiler runs pretty fast in the browser for trivial code snippets, so I threw together https://ts.coach (TypeScript handbook with code examples that execute in the browser + instant type checking)
This is neat, but has the same issue of all similar projects: mobile unfriendly editors for snippets editing.
Thank you for the excellent feedback. I had this realization a while back that I'm a mobile user during "consumption" (e.g. browsing HN late at night), but a desktop user for "production" - now I see how it applies to this side project as well. Also, I still need to figure out some React performance issues which make it virtually unusable on pre-2020 machines :(
This comment actually invigorated me to try the site from my phone and improve the experience, so I sincerely thank you for the motivation.
The typescript documentation has the same issue.
I've considered doing a similar project to yours writing or using some mobile friendly editor and hooking it directly into TypeScript's LSP, which can be easily added to a web page, but was never motivated/disciplined enough to push through it.
Speaking only for myself, not for the community:
It should be your first resource when looking something up, it's usually quite clear and often helpful, but I find it somewhat confusingly organized and rather incomplete. It's more of a reference than a tutorial or guidebook, per se.
I show people coming from object oriented backgrounds this page first in order to correct the perception that TypeScript is best used with that programming paradigm.
https://www.typescriptlang.org/docs/handbook/typescript-in-5...
> I show people coming from object oriented backgrounds this page first in order to correct the perception that TypeScript is best used with that programming paradigm.
I think you're confusing things. Languages like Java or C# impose an artificial constraint that free functions don't exist and functions can only exist as members of a class. You don't see this constraint in OO languages such as C++.
Also, it's a simplistic assertions to claim that classes have no place in TypeScript or aren't idiomatic. That's just nonsense based on specious reasoning. Classes/objects with function members are still the best way to implement some features. I'm seeing too many people writing absurd typescript code who go through great lengths to avoid a class because they think a class is taboo. They pull out convoluted stunts like passing closures as object members, just to avoid the sin of rolling out a class.
To clarify, I’m not claiming that classes have no place in Typescript. What I’m saying is that many people coming from OOP backgrounds tend to have the mistaken belief that TypeScript is best written with that paradigm. While it can be in some cases, it should not be assumed to be the best way. In fact, the documentation linked above asserts that “free functions over data” are extremely powerful, and “tend to be the preferred model for writing programs in JavaScript.”
I prefer this over everything else I've seen so far, it actually is concise.
Good, but it only gives a very brief overview, no explanations
I don't know, the number of people that know what a mapped or sum types are is strikingly low, let alone some of the more advanced concepts or even tsconfig.
I've always thought that typescript is in the real of technologies that developers use for years but never really master such as css. Maybe not as severe as css, but it's the same direction.
Popular in 2023 (215 points, 91 comments) https://news.ycombinator.com/item?id=36641634
And I have this roadmap if anyone interested in
https://nemorize.com/roadmaps/typescript
What's the "Sign in to study" button? Nothing happens when I click on it. If I click above it takes me to am explanation of the subject.
It should in theory allow you to answer the questions associated with the section. Let me cross check.
Yep it is broken, will be fixing 5 min.
Fixed. please retry. Thanks for reporting.
I know why typescript "succeeded", but always wonder what kind of web we would have if infact Haxe had become more popular for web in the early days. My guesstimate is we would have had bundlers in native code much, much earlier, and generally much faster and more robust tooling. Its only now we see projects like esbuild, and even TS being written in a compiled language (go), and other efforts in rust.
Also it would have been interesting sto ser what influence Haxe would have had on javascript itself
I assume you meant that the TypeScript compiler is being rewritten in Go. (At first I read it as something entirely different.)
Indeed i ment the compiler being rewritten from JS->Go
With Haxe this would never have been a problem, as the compiler (written in ocaml) was always fast as anything out there.
Same could be said about Java Applets or Flash and, in a way, about Elm. We've been there and this approach doesn't work.
The creators of TypeScript realized early on that people don't need yet another ecosystem, but a migration path that won't pause development.
Thats true, but comes with a cost. TS has become an incredibly complex language, even it only provides types. Thats being said is will always lack features as it only "javascript".
Haxe has a more robust, but simpler typesystem, that comes from ocaml.
Haxe also compiles to C++ so making native tools would have been a breeze.
TS sits at the top chair, but there is many "better" options out there, like Elm (even its kild of a dead languge) and ReScript/ReasonML etc.
TS is good, but will never be a perfect language for javascript. It will always be a mediocre option, that is growing more and more complex in every new release.
Yes, amazing language - I recall having a look at it in 2013 when I was scrambling for a replacement for Flash (also amazing platform). Shame it doesn't solve the problem at hand.
Hardly anyone cares TypeScript isn't perfect when they can migrate their (or anyone else's) terrible, but business-critial JS library to TS and continue development without skipping a beat.
For the same reason ReasonML took years to overtake fartscroll.js in the number of stars on GitHub.
A huge part of TS's complexity is there so that library authors can describe some exotic behaviours seen normally only in dynamically-typed languages. When you're writing an app you don't need the vast majority of those features. Personally I regret every usage of `infer` in application code.
> For the same reason ReasonML took years to overtake fartscroll.js in the number of stars on GitHub.
Wow, that's a fascinating statistic! Certainly puts the popularity delta into a different light.
On a separate note, the fartscroll.js demo page[0] no longer works since code.onion.com is no longer accessible. Truly disappointing. Luckily their release zip contains an example.html!
[0]: https://theonion.github.io/fartscroll.js/
Well, it was actually slightly less than two years:
https://www.star-history.com/#theonion/fartscroll.js&reasonm...
I remember the hype back when it was released, though. You don't hear much about it any more.
Is this a serious take? Do we now measure popularity based on github stars? Thats sort of like measuring how good software is by the amount of LOC.
Or Lua... :>
Then comparison will've been Haxe to TypeLua rather TypeScript. Typing addition seems inevitable.
Please provide a PDF as well. I cannot read books in HTML format because I need to keep track of where i left. That means I either have to leave the browser tab open (but this is prone to accidentally closing it) or I need to bookmark every progress, which creates noise in my bookmarks. With a PDF I simply leave it, the reader remembers my last page. I also have a sense of progress with pdf.
https://github.com/gibbok/typescript-book/tree/main/download...
They have a PDF in the downloads, and an epub one if you have an ebook reader like a kindle or kobo
Thanks for sharing, this is useful.
To the author, congrats and thank you. I have one piece of feedback:
When you are typing Typescript on your keyboard you are typing types using a strongly typed language.
Some definitions would be useful to novices: 'type' as a noun or verb, in the mathematical context + the notion of 'strong'.
Unfortunately most of the content hasn't been updated for two years straight, which is quite a lot considering how much ECMAScript and TypeScript have been changing in recent years. I guess it's still a good reference, though.
Would also recommend https://types.kitlangton.com/ as a companion — sometimes many examples can illustrate the point more succinctly than text.
[dead]
The thing is, documentation isn't a monolithic thing --- it really needs to be sub-divided/categorized into subsets which are useful to specific categories of folks working on, or working with, a project:
https://diataxis.fr/
(originally developed at: https://docs.divio.com/documentation-system/)
divides into 4 types of documentation:
- Tutorials
- Explanation
- How-to Guides
- Reference
My own documentation got much better when I broke it up along those lines.
That does make a huge difference, though I have found you also need to divide by the audiences. There are usually two main audiences that need addressing:
1. The new user. They typically know nothing about the product, not even why it exists. The CTO/CIO bought it and now you have to use it. They need lots of hand-holding and needs concrete instruction. Tutorials and explanations are focused on them so they can build accurate mental models of how the software work.
2. The experienced user. They have a pretty good idea of how the product works, but business requirements have changed in some way and know needs to make adjustments to their processes. Or just needs reminders of less used features. Good how-tos and reference material is vital.
If you don't take care of these things the customer will abandon your product sooner than later.
Agreed, but IMHO it should be layered so one can enter at the highest conceptual level and drill down and back up so there's a continuous flow of understanding.
My experience is that if there's too much documentation for a given representation, a not insignificant number of folks will not read it --- divide and conquer seems to be a workable approach.
I agree -- my point was to have the details linked in a drill down manner so that one can skim the high level parts but easily expand upon any topic directly from where it's being referenced.
I would like to see a UI/toolkit which implements that easily and works well.
What you describe sounds a lot like Diátaxis[1], which is a strategy for writing and organizing technical documentation. It categorizes docs into one of four categories: tutorials, explanations, how-tos, and references.
Category is derived from a fairly simple heuristic: whether the content informs action or cognition, and whether the content serves the reader’s application or acquisition of a skill[2]. I’m a fan and it’s simple enough that most anyone can learn it in an afternoon.
1. https://diataxis.fr/
2. https://diataxis.fr/compass/
You have an interesting commenting style. ~
Lots of sentences occupying an entire paragraph.
Sometimes ending with "~". Usually (always?) your posts end with a question.
You are clearly using some sort of framework for your posts.
Care to elaborate? ~
Please take your slop comments elsewhere. We are trying for something different here on HN.
> Some of the benefits of TypeScript:
> Access to ES6 and ES7 features
> Cross-Platform and Cross-browser Compatibility
Damn, I wasn't aware that since I avoid TS, I cannot use ES6 and ES7, and my vanilla JavaScript doesn't run in all browsers :(
I guess over-hyping the technology that the book is about is to be expected, but it still leaves a slightly sour taste in my mouth when people oversell what they're talking about it.
I think the point is that you can write your code using ES6 and ES7 and the TypeScript compiler allows you to output ES6 or ES5 compatible code if you want to make sure it runs in older browsers as well. You can do that with non-TypeScript ES code as well but you’re bound to use another transpiler. With TypeScript you get it „for free“ since you need to compile your code either way.
Ah yeah, kind of like how I get a drink for free if I get the hamburger menu, even if it costs more? Kind of weird perspective, but I can accept that it's something zealots tell themselves so "we're doing it differently" actually computes for them.
> it's something zealots tell themselves
Don't be like this. Don't spit bile at people because they have different needs and preferences to you.
As I understand it, the TS compiler can translate newer JS features/syntax into backwards-compatible polyfills for you, automatically. I don't really use TS myself, but I'm not going to pretend like that isn't a useful feature.
I have used JS before TS entered the scene, and being able to transpile features/syntax like that is not a TS innovation, nor only available in TS. That's why flagging that as something "you get for free, since you added a compiler anyways" feels dishonest. Ultimately it's true, but if that's what you're out after, then adding TS to your project is going way above and beyond just "transpiling new syntax to old syntax".
> is not a TS innovation, nor only available in TS
> since I avoid TS, I cannot use ES6 and ES7, and my vanilla JavaScript doesn't run in all browsers
Where was that claim made? I don't see it in any Typescript docs, or in the book.
You seem to be saying that the TS docs say that these features are unique. They obviously aren't, the documentation is clearly not saying they are, and no reasonable person would say they were.
Transpiling to another platform is a multiplying benefit when combined with other benefits though.
For example: Clojure and Kotlin both target the JVM. The language design of each brings certain benefits. These benefits are clearly more useful if they have a wide deployment base in the form of the JVM.
> Where was that claim made? I don't see it in any Typescript docs, or in the book.
In the article, you know, linked in this submission, which my original comment quoted verbatim. Again:
> > Some of the benefits of TypeScript:
> > Access to ES6 and ES7 features
I'm saying that these are not "benefits of TypeScript" but benefits of doing transpiling in general with a tool that can "downcast" features like that, which is in no way exclusive to TypeScript nor even began with TypeScript, but AFAIK with Browserify.
When I talk about "benefits of language X" I try to keep it to things that are actually about the language, not particular implementation details also broadly available and used by others, because I feel like it'd be misleading.
> I have used JS before TS entered the scene, and being able to transpile features/syntax like that is not a TS innovation, nor only available in TS.
I used JS back in the 1990s. Transpiling to JS is a relatively new phenomenon.
No one said transpiling is a TS innovation, nor that it is unique to TS.
> That's why flagging that as something "you get for free, since you added a compiler anyways" feels dishonest. Ultimately it's true, but if that's what you're out after, then adding TS to your project is going way above and beyond just "transpiling new syntax to old syntax".
That's silly. Transpiling is something TS can do, so it's not dishonest to advertise it as something TS can do. If you think TS is too hefty, don't use it. But don't be toxic towards those that do.
You're moving the goalposts to try and defend a bad take. That's how you get brownie points on the Internet for extreme takes, but also how you prevent yourself from learning and growing in the long run. Learn to take an L. You'll be better for it.