The Concise TypeScript Book
github.com
github.com
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?
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.
https://www.typescriptlang.org/docs/handbook/typescript-in-5...
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.
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.
Also it would have been interesting sto ser what influence Haxe would have had on javascript itself
With Haxe this would never have been a problem, as the compiler (written in ocaml) was always fast as anything out there.
The creators of TypeScript realized early on that people don't need yet another ecosystem, but a migration path that won't pause development.
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.
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.
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!
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.
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'.
> 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.
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.
> 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.
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.
A benefit of living in a house is that you don't get wet when it rains. If you didn't live in a house, you might get wet when it rained. But there are other things you could also do to not get wet, such as living in a tent.
It would not be reasonable to say "that's not a benefit of living in a house, because if I lived in a tent, or wore a rain-coat, I would not get wet".
The benefit of "staying dry" belongs to both "a house" and the superclass of "a sheltering structure".
If you defined benefits only on single dimensions, and only allowed them to belonging to level of abstraction at which they are exclusive, then you could argue that no language or technology has any benefit whatesover.
I think most people would think of "benefits of X" as an aggregation of individual specific benefits which may also belong to other aggregations.
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.