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?"

Giving guidance on which one should be used and when is well within the scope of external parties.

This is neat, but has the same issue of all similar projects: mobile unfriendly editors for snippets editing.

> 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.

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.

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.

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.

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.

Then comparison will've been Haxe to TypeLua rather TypeScript. Typing addition seems inevitable.

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.

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.