
When to Use TypeScript – A Detailed Guide Through Common Scenarios - stemmlerjs
https://khalilstemmler.com/articles/when-to-use-typescript-guide/
======
externalreality
I agree with this article. Good stuff. One minor gripe:

> if you care about the code, you need to have unit tests for it.

That's not really true. You can test at a differently granularity and still
have the same confidence in your code. Scores of brittle unit tests crowding
your productivity is not what you do to code you care about. I wish people
would just stop propagating this detrimental rumor that is backed by zero
evidence. I prefer to keep my unit test suite lite and sweet (try to test what
is very sensitive at the unit level - easy to miss or algorithmic things) and
then try to get the most out of my acceptance test suite. Sorry, but I just
worked on too many systems where the unit tests suite breaks no matter what
you touch and you spend more time updating the tests than actually getting
shit done.

~~~
eranation
If you write a library, or expose a public interface, I do expect a lot of
unit tests. Unit tests can run offline, fast, during build time. I don’t mind
integ-unit tests that perhaps simulate a database in memory to avoid mocking
the entire storage layer. I rather have tests that are technically integration
tests as they include more than, well, a unit, as long as they are idempotent,
test mainly one thing, and can run fast and offline. Not sure if there is a
term for it but I call these integunit tests... (probably the worst name
possible)

But unit / unit++ tests are not just for you, they are for me, they give me
confidence I can touch your code without inadvertently breaking something
critical that you may have missed in your acceptance tests. It gives you peace
of mind to be able to refactor. An acceptance test may tell you they something
broke, but a good unit test will show you exactly where.

~~~
externalreality
> breaking something critical that you may have missed in your acceptance
> tests.

So you can miss things in your acceptance tests but can't miss them in your
unit tests? Why do you feel more confident with unit tests than with
acceptance tests? Maybe because unit tests break more often so they are
providing you with a false sense of security? Do you know that when a test
fails for a reason other than the specified assertion its a called a false
negative and the failure is meaningless? Do you know if your tests fail and no
functional or non-functional requirements of the program has changed the
failure is also meaningless (you are testing implementation)? Ask yourself how
often does your group give you time to do these hypothetical large refactoring
that give merit to large unit test suites? How many times, even, do you do
small refactorings and find all the test have to go away or significantly
change anyway because they made some implementation assumption that is no
longer true? How many times have you gone into a test suite and have seen that
its been patched up so many times that you can swear its testing something but
you just don't know what? I know that Uncle Bob tells us about test for
refactoring and this and that, but I just don't buy it any more. The emperor
is naked god dammit. Uncle Bob and the like are very famous because people
swallow their anecdote without due scrutiny.

~~~
discreteevent
One thing I can't find much evidence of is Uncle Bob's experience in
delivering commercial software. I get the feeling he works mainly on toy
examples which might explain some of the things he advocates that, like you,
don't match my experience at all.

------
chmln
> will most often write vanilla React.js apps when: the codebase is small

This one never ceases to amaze me. Any codebase is small, until it gets big.
And once it's big, the effort to rewrite is hard to justify.

You don't build a house and add the foundation later.

~~~
a_wild_dandan
I see so many HN comments endorsing "build the product to exact specification
using the minimum reasonable tool set." When you then ask "what happens when
the specification changes?" you get hilarious answers like "just say no to the
user", or "just extend the app!"

This is why I always over engineer a bit, especially on new projects. I'll
happily, for instance, add a framework before it's strictly necessary. I've
_never_ regretted that decision in the end.

If people here want to use a 5 gallon bucket on an initial 5 gallon job, go
for it. Best of luck to you. I'll be over here starting with a 10 gallon
bucket and not sweating when the customer needs to add another gallon...

~~~
justintoon
It’s rare that I find a comment which validates my own practices like this. I
personally love creating systems and abstractions, and admittedly I will
sometimes create one when a simpler solution would suffice. However those
“over-engineered” solutions have frequently saved me lots of time much later
when business requirements change.

~~~
mattmanser
Your stance sounds different to the grandparent's.

There's a world of difference between adding a framework and over-engineering
something that could have used a simpler solution.

My experience has been the exact opposite of yours, whenever I added something
complicated, it either never got used and unnecessarily complicated the code,
or when the time came to use the fandangled cleverness I lovingly wrought, it
never quite met the need I actually ended up having.

So I stopped doing that years ago and now always write the simplest code.
Never regretted it. I will add frameworks early though.

------
lewisl9029
This doesn't seem like a common occurrence, judging from all the praise of
TypeScript sung on this thread and elsewhere, but I've had an overall negative
experience working with TypeScript so far.

Here's some thoughts on what has contributed to that so far:

1\. TypeScript pushes you towards its own build pipeline (based on tsc) that
doesn't play nicely all the time with mainstream JS build pipelines (usually
based on babel).

With babel 7 came @babel/preset-typescript, which I hoped would narrow the
gap, but so far it's very clearly a second class citizen in the TypeScript
ecosystem, with new features built only with tsc-based pipelines in mind
(Project References is the one that stands out because we sorely need it for
our monorepo codebase, but can't use because we chose to adopt @babel/preset-
typescript), and having personally ran into several issues stemming from what
seems to be fundamental incompatibilities between tsc and babel that have no
real workarounds (here's one that I can remember off the top of my head:
[https://github.com/babel/babel/issues/8361](https://github.com/babel/babel/issues/8361)).

The reason this is so frustrating is TypeScript could have been just a type
checker, like Flow. But instead, it had to introduce it's own compilation
tooling which is still vastly inferior to babel in terms of overall
flexibility and extensibility. All of this seems to be due to what I believe
are a few fundamentally poorly thought-out decisions at the beginning of the
project to allow TypeScript to specify its own language features that have
runtime semantics (things like Enums and class visibility modifiers, neither
of which are anywhere close to becoming standardized in JS-proper, by the way,
and both of which are completely orthogonal to TypeScript's main
responsibility of type checking), and implementing them using a separate build
pipeline instead of as extensions to babel & its own type checker.

If I were to use a JS type system for a new project today, I'd personally
choose Flow over TypeScript in a heartbeat because of this.

(this is getting a bit long so will continue in a reply)

~~~
lewisl9029
2\. TypeScript's type checker, at least in its current state, has been
downright painful to work with for functional programming with functional
composition and higher order functions in general, with errors that are
incredibly opaque and unhelpful, and its poor inference introduces so much
seemingly avoidable type-related verbosity that it completely distorts the
signal to noise ratio in our code.

A prime example for this is ramda's pipe function:
[https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/ramda/index.d.ts#L2148)

A simple function that composes functions together in reverse order requires:

1) The definition to be an exhaustive list of all the variations of input
functions that pipe can accept (which of course would technically require an
infinite number of declarations to fully specify, so ramda had to call it
quits at 10).

2) The user of pipe to specify output types for every single function being
composed at every step, even though that should be possible to infer using the
return type of each function in the pipeline.

These kinds of limitations plague our codebase everywhere we try to define
higher order functions in our own code as well, because it means we have to
ask users of the function to specify the result of the function argument as a
generic parameter even though it should be perfectly inferrable from the
function argument itself, and the noise buildup becomes exponential as you
start composing higher order functions together due to pipe suffering the same
limitation. The issue also rears its head when using higher order components
with recompose, which we make heavy use of as well.

I'd love to hear how other teams working with functional programming in
TypeScript work with these limitations. Perhaps we're missing something
fundamental that could vastly improve our experience?

~~~
lewisl9029
3\. TypeScript only supports positional generic parameters (i.e. you can't
give them names).

It's well known that positional semantics don't scale when it comes to
argument lists, because when changing the API of something with a positional
argument list, adding an argument in an arbitrary position becomes a breaking
change that requires all usages to be updated.

Unfortunately, part of the fallout from point 2 means we often need to define
higher order functions that require a decent number of generic parameters, all
of which have to be positional due to this limitation.

There's a hack that we discovered that allows you to have poor-man's named
generics by using a single generic argument with named properties, inspired by
this comment:
[https://github.com/Microsoft/TypeScript/pull/23696#issuecomm...](https://github.com/Microsoft/TypeScript/pull/23696#issuecomment-408717985)

But it's incredibly verbose, and doesn't support optional generic arguments or
defaults as far as I can tell. We still use it despite this, because we
believe the verbosity and having to specify every generic argument is the
lesser of two evils compared to offering APIs that requires breaking changes
for every addition. But that we have to make this choice points to a glaring
omission in the design of the type system.

~~~
phiresky
You can kind of give generics names by declaring them in an interface and
passing T extends Interface as the generic parameter

------
TimTheTinker
The article mentions object-oriented programming several times as a helpful
paradigm (especially for domain-constrained problems where DDD is helpful).

I’d also like to point out that functional programming is tremendously helpful
for solving these types of problems, especially when combined with use of
modules. TypeScript is absolutely capable of modeling, checking, and otherwise
handling types in a functional programming context. — this is one of its best
strengths in my opinion, and one reason I now prefer TypeScript over C#.

~~~
mandeepj
> TypeScript over C#

TypeScript is a transpiler for JS. C# is a server side language. Can you
please clarify how former is the replacement for latter?

~~~
charrondev
I don’t want to speak for the OP here, but when I refer to Typescript in
comparison to other languages I tend to mean Javascript + the type system
provided by the Typescript.

Typescript is not even necessarily the transpiler nowadays. I use Babel for
that and use Typescript exclusively for static type analysis in CI and during
development.

------
_bxg1
It's a default for me now, on every new project. It doesn't slow down
development because TypeScript allows you to easily "step down" type
constraints as desired, and writing nontrivial code without any kind of type
hints is just unimaginable to me now.

~~~
mixmastamyk
> unimaginable

I imagine adding types gradually as a design solidifies, rather than slow
velocity early on. Best not to be dogmatic on these things.

~~~
Retozi
I have never understood why typed languages make you slower at any point in
time (early, late etc.).

Because you have to hit more keystrokes to write your program?

That doesn't compute. typing is the thing you do the least amount of when
programming. In all best practices we are taught to not save keystrokes. Name
your variables expressively. write small functions. document code. Write
tests. All ""excess"" keystrokes nobody questions. But when you have to type "
... : number" it's slow velocity?

In my opinion people vastly over-estimate productivity boosts of saving
keystrokes. It's the tedious, boring part of the work that you would like to
skip entirely, hence excess keystrokes feel way more "slowing you down" than
they acutally are.

Although it doesn't matter, you actualy save keystrokes: autocomplete, auto-
refactors and less low level unit-tests compensate the couple of type
annotations easily.

~~~
seanmcdirmid
Though you have a point, writing down type annotations can seriously slow you
down when you are doing exploratory (prototyping) programming. It can also
make your code less readable as the annotations can get in the way of the
logic you really care about (easily fixed in an IDE, but people want to still
use notepad to edit/read code). Then there is figuring out what the annotation
should be in the first place, again easily enough automated in an IDE but the
notepad problem remains.

~~~
james_s_tayler
What usually slows me down about dynamically typed code is you have some
variable returned by a function only denoted by var myVariable = myFunction();
and I'm sitting there staring at thinking... "what are the contents of that
variable? what properties do I have access to on that object? what can I do
with it?"

And figuring that out becomes a massive time suck when that's a constant
across an entire code base. Statically typed stuff means I can very quickly
find that out even if it's the first time i'm exploring that particular area
of the code.

~~~
seanmcdirmid
I agree, in a type inferred language or a language where annotations can be
supressed, this is just another matter of IDE affordable.

Some dynamically typed languages support type annotations that are only
enforced dynamically; Julia is the primary example of such a language ATM.

------
ravenstine
The amount of fanboyism in these comments is astounding.

TypeScript is a great tool.

At the same time, people have written apps with vanilla JavaScript for a very
long time now, and it works just fine. If types are really that big a deal
that you have a hard time writing an application without a compiler checking
your types, you should reevaluate what you're doing. It's not "dangerous" to
use plain ol' JavaScript, and implying that others are foolish for not using
it reeks of _software snobbery_.

 _Whoa, you mean people really still use plain JavaScript, bruh? I mean, don
't you need like punchcards for that? That's how grandpas program, bruh. You
can't even, like, scale an app without type-checking. An app written without
TypeScript is like a house of cards, dude._

~~~
Arbalest
>If types are really that big a deal that you have a hard time writing an
application without a compiler checking your types, you should reevaluate what
you're doing.

Implying that everyone has exceptional short term memory, and reading old code
has virtually no cost.

~~~
ravenstine
I never said that TypeScript wasn't helpful. The picture painted by some
people that frontend applications without compile-time type-checking are ready
to fall apart at the seams and have knobs and springs go flying everywhere,
like something from a Looney Tunes cartoon, is patently absurd.

~~~
Arbalest
Given what I said, Even for fairly simple examples, it would still be more bug
prone, simply due to humans not having perfect cognition. At scale that can
add up.

Also keep in mind that this both enables, and follows a trajectory of
increasingly complex frontend applications, previously a lot of interactive
stuff was done server side.

Patently absurd, if you take it as a strawman, sure. You ended up using that
to paint the complete opposite picture, which was essentially that Typescript
doesn't actually add any real value, only "perceived" value. Which is true, if
all you value is the execution environment. Keep in mind that Typescript was
not the first attempt at trying to "tame" Javascript. One example that comes
to mind is Coffeescript.

The natural reducto ad absurdum is thus, well why aren't we just writing in
ASM, it all boils down to that anyway, right? People were doing fine then
too... Could it also be said that accusing people of needing "crutches" is
also snobbery?

------
humbleMouse
Typescript is wonderful, especially as someone used to writing a lot of
java/groovy. Typescript is like pouring cement around your javascript house of
cards. It makes writing front end code painless and predictable.

It also has amazing tooling in intelli-j. Code completion, linting, package
recognition, all the good stuff.

~~~
eitland
> It also has amazing tooling in intelli-j. Code completion, linting, package
> recognition, all the good stuff.

... and in the free Visual Studio Code, also crossplatform like IntelliJ.

(Nothing against IntelliJ, JetBrains is a cool company with amazing products
IMO, I just prefer VSCode myself.)

~~~
h1d
I think VS Code is almost like a little brother of IntelliJ now but better at
a few places. (Especially rendering.)

------
vore
Regarding TypeScript, the benefit of catching way more errors at compile time
greatly outweighs the amount of extra work for adding types. If you're
starting a new JavaScript project, you should definitely think long and hard
if you pledge not to use TypeScript.

~~~
a_wild_dandan
And the best part is that TypeScript is just a superset of JS. If you're new
to TS, you can use it like you've been using JS. Just by giving your variables
the `any` type, or disabling null checking, and so on, you can write JS like
you always have. No pressure.

And, eventually, you'll be lulled into properly typing your variables, because
damn it those type annotations are super handy! Oh, and you start defining
your own interfaces because it makes your code more readable and easier to
reason about. Oh, and...etc etc etc.

If you start by gradually adopting the extra features that TS provides, you'll
never want to go back.

------
parhamn
Why does everyone treat TypeScript like a full language? Besides some features
like generics 98% of it is just javascript with type annotations (sorta
similar, including in syntax, to py3 with annotations). And in that view its
probably foolish not to use it as the cost of these annotations is so low
relative to the refactoring/safety/easy-of-use/code-completion/etc it offers.
These type annotations are so easy to add!

I can't even imagine writing JS without these annotations esp given all the
odd behaviors of the language.

~~~
a_wild_dandan
TypeScript is such an unbelievably powerful add-on that I simply refuse to use
vanillaJS unless absolutely necessary. It eliminates entire classes of bugs,
encourages me to write better code by thinking in JS about contracts
(interfaces), and vastly improves my productivity with the aforementioned
annotations. ("What was the signature for method X of class Y in library Z?
Ah, that's it. Thanks, TS/VSCode!")

------
jaequery
Some people love js for it’s functional approach. Mainly because they hated
the whole OOP paradigms and the design pattern baggage that came with it.

But now js is adding classes and there’s typescript , now it’s like Java all
over again.

Welcome to programming, where the fads go back and forth in cycles.

I also read a commment here saying people love React because now they can add
code all over their view file.

Well adding code in view file is ugly and there’s a reason why we tried to get
away from doing that.

Sounds to me people want to just go back to the 90s-00s!

------
flabbergast
> it's actually dangerous for your project to NOT be written using TypeScript
> today.

Wow! Bye bye Javascript! Such arrogance! In a way it always feels like
Typescript developers are way beyond all those poor suckers still coding in
Python, Javascript, Ruby, Coffeescript, etc.. Dynamically typed languages are
DANGEROUS!!! just as C is DANGEROUS!!! I'm so happy C is still being used and
not abandoned in favor of C# or so.

I know I can be way more popular preaching Typescript nowadays, it would make
me really cool, smart and up to date. Not going for Typescript proves I'm
mediocre at best. This is not cynic, this is real when I talk to fellow web
developers.

I believe static type checking should ideally be done by the IDE, we shouldn't
need an entire new language for that with all its shortcomings, issues and
whatsoever. And we'll see what's left when the hype is over and the next big
thing in the Javascript world comes around. At least heaps of Typescript code
bases that need to be rewritten.

~~~
cheerlessbog
> static type checking should ideally be done by the IDE, we shouldn't need an
> entire new language

I am not sure what you are trying to say here. Javascript is barely typed, so
presumably you do need a new language to perform type checking.

Unless you mean that your IDE should be able to infer types, which is unlikely
because typing defines intent, and we've all read plenty of code where we
can't figure out what the code author intended.

------
wesleyfsmith
One challenge I have with TS is that when writing interfaces for untyped libs
it's easy to make a mistake. I've had issues where VScode was telling me
something was the incorrect type because someone else on the team had written
an incorrect type in. Instead of debugging it like I would in normal JS I
banged my head against the wall because I was convinced that is TypeScript was
telling me something was a certain type, it HAD to be true.

------
rasikjain
Coming from C# background, Using Typescript for front-end programming was a
breeze for me. This helped me in picking up newer frameworks and saved
countless hours during debugging and build time errors. I liked strict
validation of props using interfaces while working with restful APIs.

------
FlorianRappl
Such a guide can be reduced to:

If you only have a single file that has a limited set of responsibilities
(e.g., just a small tool) and is not shared / distributed then JS may still be
okay, otherwise always go for TypeScript.

Honestly, TypeScript never slows me down. The enhanced completion / IDE
knowledge, compile-time type checking, and transpilation supporting newer ES
features + React is a huge boost.

------
a-saleh
I wonder if some of the people here, that like Typescript just fine, would
consider less main-stream typed-js solution.

I.e. Elm, ReasonML/ocaml/bucklescript, Purescript, Haskell with ghcjs, Rust
with web-assembly compilation, or even wasm from Go?

I am somebody who really likes to dabble, but is not a fronted person, so I am
thinking, what would make you consider switching?

~~~
maaaats
What I mainly liked about TS is that it's basically plain js with some
typeinfo sprinkled on top. So no barrier of entry for existing js developers.

Now I work on a project with Elm for the frontend. It's not as easy to just
jump into, so wouldn't use it for a project where lots of developers sometimes
have to make additions. But once up to speed, Elm is great.

------
devit
Always, unless it's a very short script that uses packages that have no type
definitions.

~~~
SonicSoul
the issue I run into (and maybe there is a quick solution) but when I work on
a TS React project and want to add a library that does not have Typings
definitions, i get in a world of hurt. trying to quickly add my own typings or
fix TS errors w/out disabling major compiler functions.. usually spend an hour
or two and give up on the library.. is there a good way to deal with this
scenario?

~~~
pault
That is a pain point, but I think of it as spending a few hours to save a few
weeks down the road.

------
overgard
Honestly, the only downside to me of typescript is occasional grief from @type
libraries or some build complications when you're first getting setup. But
having working code completion and non-surprising return values/argument
parameters is so much worth the initial minor pain points.

~~~
burtonator2011
The other issue is dealing with module compilation... this part still always
screws me over.

Once it's up and running TS is freaking amazing

------
leeoniya
i recently learned you can actually have typescript annotations without [imo]
polluting the syntax or requiring the TS compiler:

[http://seg.phault.net/blog/2017/10/typescript-without-
transp...](http://seg.phault.net/blog/2017/10/typescript-without-transpiling/)

does anyone know if there are limitations to this style?

~~~
breck
Cool, thanks. I generally love TS, but I have one project which I converted to
TypeScript, and then reverted back to ES7, because the project is quite
complex and the overhead of TS was not worth it. I wonder if by using this
Jsdoc/ts strategy in critical sections I can get 80% of the benefit.

~~~
monkpit
> the overhead of TS

Do you have any concrete examples? I would argue that a complex project that
is already in TS benefits more from remaining in TS, so I’m curious what your
reasoning was.

~~~
breck
1) Import/export syntax hell. This project is 148 Javascript files, 12k LOC.
Everything runs in both Node and Browser environments. Without TypeScript I
just use CommonJS syntax and rewrite the scripts on the fly via a server-side
pass through for a browser environment. But because of the module hell
(import/export/script modules/relative vs absolute paths/defaults) I couldn't
find a good formula for write once, run everywhere for this large project. I
needed to be outputting 2 different builds to 2 different places which led to
all kinds of path problems. This is very much unique to this project though,
which has unique runtime require requirements.

2) Compile time overhead when iterating. For many visual development tasks it
just takes too long to change something, compile and see results in the
browser. Without TS it's 0 latency. With TS it was a few seconds. Without TS I
could make 10 changes with 2 seconds latency, and perhaps I make 1 type
mistake costing me 20 seconds of debug time, for a total of 40 seconds. With
TS I make 10 changes with 5 seconds latency and zero mistakes but now total
overhead if 50 seconds. I want to be able to get the documentation and static
type checking benefits without giving up that instant feedback.

------
iamtypical
My day to day value from typescript is that when you’re on a make things
happen team that’s burdened by type pendants or grouchy C#/java/r/whatever
“devs” who find themselves career “transitioning” to JavaScript/web-apps throw
them typescript as a Turing Tarpit & then everyone shuts up and then makes a
thing. Dumb arguments get relegated/channeled into PR/issues on the tsconfig.

I say that half in jest but one of the dumbest & most destructive things in
software engineering is tribalism or militant belief systems. Having a
“neutral” way to deal with them (or something like “data” seeming like it’s
neutral) once and for all does wonders for productivity

People who don’t like or trust typescript, what’s your good-faith case against
it. Personal productivity or ugly/confusing syntax are valid reasons I think

------
quickthrower2
> I certainly didn't see the benefit... up until I started experiencing some
> really annoying stuff. Things like builds not failing when they should,
> buggy code and typos finding their way into production code somehow started
> to get to me

It's hard for me to understand how anyone can't see the benefit of types at
compile time. I mean if you write more than 100 LOC you are bound to make a
mistake that a typing system would catch and think "I wonder if there is a way
the my build process could catch such as silly error". I can only imagine that
such programmers are "write only" in that they add lots of features but rarely
need to come back and maintain their code. With an ide with autocomplete it
may mitigate some mistakes and give a false sense of security about non-static
typing.

------
bartimus
On the other hand. If your code base has become so big that you need something
like TypeScript to make your life bearable, you're probably doing it wrong.

Having strongly typed languages has much more to do with those developers who
can't live without the autocomplete feature in their IDE. Especially the army
of ASP.NET developers who are used to working with Visual Studio.

We'll probably be seeing more of those code generator patterns with TypeScript
soon.

Not saying TypeScript is a bad thing. But strongly typed languages do come
with their pitfalls. Massive amounts of code providing a simple CRUD
interface. An entire team working on their complex microservice solution which
is just wrapping some already existing API. Things that can easily be achieved
with a couple of lines of _cough_ PHP _cough_.

------
redact207
I'm writing a DDD helper library in Typescript
([https://www.npmjs.com/package/@node-
ts/ddd](https://www.npmjs.com/package/@node-ts/ddd)), but found it more
difficult doing something similar in Javascript. The richness and safety that
static typings bring to a project compounds as time goes by.

I've also found it easier for new developers to become productive sooner when
the language and framework guides them in the direction they want to go. I'm
all for anything that supports a positive developer experience, and it's more
concise to express my design in terms of static types than it is through
mounds of documentation or exploring the code.

------
ArtDev
Seems like you should just learn javascript instead. Though I can see how
Typescript might be easier, depending on your background.

------
namelosw
Just use it. I found with auto import and other stuff actually writing
TypeScript is almost always faster than JavaScript.

The type system is a little bit more advanced than those languages with
nominal type systems like Java. Sometimes typing old code is tricky. But the
good news is you can escape by using any anytime.

------
giancarlostoro
> For example, it's almost always expected that your app is going to still
> work offline in some capacity; and when users ARE online, it's also usually
> expected that they're going to get real-time notifications without having to
> refresh the page.

I never expect something to work while I'm offline, or do they mean the cached
contents like a page would work if it were just cached HTML and CSS? As for
real-time notifications, I don't know anybody who uses those, the other day
someone was telling me how pissed off they were that they always get them from
some news site, and they didn't mean to enable them, now they can't find where
to turn them off!

------
fergie
Yup- Typescript is mostly used in large-scale enterprise software development
where rigorous unit tests are not in place.

I still suspect that a large part of Typescript adoption comes from developers
who are used to working in an IDE (Visual Studio, Eclipse, etc), and are
uncomfortable with javascript's natural "textfile->compiler->test" workflow.

Its also worth noting that support for typescript (that isn't Microsoft
marketing) tends to come from outwith established tech environments. Using
Typescript outwith MS environments can be challenging.

------
fourseventy
Isn't anyone worried that TypeScript will go the way of CoffeeScript?

~~~
oaiey
I am not. CoffeeScript was never as popular as Typescript already is.
TypeScript is a tool which solves a problem, CoffeScript is a language (IMHO)
no one needed.

~~~
dmit
To be fair to CoffeeScript, it introduced and popularized features that
eventually made it to the EcmaScript standard. You could make a case for it
being the kick that started the wave of improvements to JS that we've seen in
the past decade.

As for GP's post, I can only hope that Typescript leaves a similar legacy,
even if the language itself ceases to exist.

~~~
danso
That kind of historical retrospective is an article I would definitely read.
As much as Coffeescript seems like a dying language when compared to where JS
is today, its appeal was very strong for it to have become a default include
in Rails 3.1, and to have been the primary choice for teams like Dropbox and
Github [0].

0:
[https://en.wikipedia.org/wiki/CoffeeScript#Adoption](https://en.wikipedia.org/wiki/CoffeeScript#Adoption)

~~~
dmit
I'm pretty sure Jeremy Ashkenas has commented before on how he's satisfied
with the role CoffeeScript ended up playing. Don't know if there are full-
fledged articles on the topic, and I can't tag him here, but if you're really
curious you can always reach out at
[https://twitter.com/jashkenas](https://twitter.com/jashkenas)!

------
will_pseudonym
FYI, the link to "concrete classes" is incorrectly linking to
[https://khalilstemmler.com/articles/when-to-use-
typescript-g...](https://khalilstemmler.com/articles/when-to-use-typescript-
guide/wiki/concrete-class/).

I assume the correct link should be pointing to
[https://khalilstemmler.com/wiki/concrete-
class/](https://khalilstemmler.com/wiki/concrete-class/)

~~~
stemmlerjs
I appreciate that. Thank you!

------
ajxs
At the risk of being downvoted into Hades, I feel that if your project is
complex enough to warrant using Typescript, its complex enough to warrant
using a more robust and comprehensive language. After using Typescript
extensively working on a back-end application in a complex problem domain I
feel that while it is definitely a fantastic improvement to the core language,
it doesn't really escape Javascript's worst issues. Issues like Promise-
fatigue, poor ecosystem, terrible native types are still there under the hood.
For the extra tax you pay in terms of build pipeline, tooling and dealing with
the ecosystem, you may as well upgrade to a language more suitable for this
kind of development for little extra cost. I just feel this debate is somewhat
of a false dichotomy. People in this thread are debating Typescript vs
Javascript as if these are the only two possible options for web development.

~~~
bloomca
> Promise-fatigue

JavaScript actually handles async IO nicely, and I've never heard this term
before (callback hell, yes). So promises and async/await sugar actually make
it pretty nice.

> poor ecosystem

Ecosystem is fine, just don't jump on everything new. The well-known problem
is standard library, it is indeed a problem, usually addressed with a mix of
additional packages.

> For the extra tax you pay in terms of build pipeline

This pipeline is norm in the frontend development, so in case you have people
proficient in tooling, it is not that high (of course, it is hard if you have
Java developers).

> Typescript vs Javascript as if these are the only two possible options for
> web development

They are not, but the nice thing about it is that you can have almost the same
tooling as on your frontend, if you have some sort of complex application. So
that increases speed of development, and TypeScript gives you some sense of
scalability.

Last part is that TypeScript can be adopted incrementally, while another
languages will require complete rewrite (and different deployment, etc).

~~~
ajxs
I actually just made the term up myself just then to describe my feelings
about the fact that all of the methods in our service layer are just `await
this(); await that(); await another(); //...` and so on. Please be aware that
this post is describing my own experiences in _back-end_ web-app development
using Node. I feel I'm courting more controversy here, but if you're using
`async/await` ad-nauseum your app might not actually be as async as you think
it is. Of course this is a godsend compared to the callback hell that it
replaced, but I can't help feeling that this is the right solution to the
wrong problem. In my experience, most of the server-side applications I've
seen written in Node are only practically asynchronous at the router level.
Once you get into the controllers they tend to become entirely procedural and
effectively completely synchronous. With the exception of the rare
`Promise.all(...).then(...)`.... If you're using `await` on every single
function call, it stops being syntactic sugar and just becomes more syntactic
salt.

~~~
hn_throwaway_99
I completely disagree. Or rather I'd say if you're making a bunch of remote
calls, and you need the results before taking the next step, then you're going
to need to be doing something like this in any case. FWIW I feel a backend
controller in Node is much easier to write, and to understand, with
async/await than the equivalent patterns in Java.

As you put it, "Once you get into the controllers they tend to become entirely
procedural and effectively completely synchronous" but that's because for most
people it's far easier to think about a problem as a series of individual
steps. Even then, if you have a bunch of serial awaits it's usually pretty
trivial to go back and then await on a Promise.all() if you realize things can
be run concurrently.

~~~
ajxs
I think I might not have explained myself too well up there. I was referring
to entirely sequential async calls. Like: ``` Thing thing = await loadThing();
Thing other = await thing.doSomething(); thing = await saveThing(); // repeat
x1000... ```

I see this over and over.

~~~
mschuetz
And what exactly is the problem with that?

"Thing thing = await loadThing(); ": Start loading thing, then await so the
main thread can continue doing other stuff while thing is loaded.

"Thing other = await thing.doSomething();": Invoke some other function that
does some stuff in the background, then await so the main thread can continue
doing other stuff while thing does something.

"thing = await saveThing();": Saving can often be done in parallel so no need
to block the App while something is saved. Invoke the save function, then
await so the main thread can continue doing other stuff while thing is saved.

This gets you the advantages of async programming while still maintaining a
legible coding style that looks similar to common synchronous code.

------
ChristianGeek
Your DDD link is dead (so technically it’s a DDDD link :)

~~~
stemmlerjs
Haha. Yeah, that's the next article for me to write. I just started this blog
recently. My approach has been to track which dead links have been clicked the
most and then write about that topic next. DDD is far in the lead. Expect it
soon.

Thanks for reading!

------
Scarbutt
This sounded more like an OOP pitch than a TS one.

------
h1d
People don't seem to point out but you need a decent editor to benefit from
using TS. If your editor doesn't support live checking, then it probably feels
like boring additional work by going back and forth between code and
compilation error logs.

------
Humphrey
Recent Typescript convert here: I find Typescript a GREAT tool for those
experimental projects. They are the ones that need constant refactoring as you
build, which is where Typescript shines.

------
kazinator
By the way, fun fact: the _script_ utility for recording a TTY session saves a
file whose default name is "typescript".

------
z3t4
The link to domain driven development wasn't useful. The post should explain
more about that and SOLID.

------
fxfan
4 of the most popular language creators here
[https://www.youtube.com/watch?v=csL8DLXGNlU](https://www.youtube.com/watch?v=csL8DLXGNlU)
agree that type systems are useful.

I would suggest definitely not using Vanilla JS. There are excellent type
systems over JS, TypeScript, Scala.JS, BuckleScript to name a few each with
their pros and cons (I don't know what cons BuckleScript has though, maybe
relatively smaller lib-ecosystem)

~~~
tyingq
Larry Wall is endorsing strong types? I'll have to watch that now. I guess you
can use Perl 6 in a way that approximates it, but it's very optional.

~~~
mst
I believe the idea is 'gradual typing', where you add types as you firm up an
interface.

Lots of the perl6 code I've seen types most stuff at least at interface
boundaries.

