
JavaScript libraries should be written in TypeScript - ingve
http://staltz.com/all-js-libraries-should-be-authored-in-typescript.html
======
STRML
I completely agree with the sentiment that typed libraries are more stable and
self-documenting. You can autogenerate documentation from typescript and it's
guaranteed to be up to date, unlike JSDoc comments.

I personally have converted a few of my libraries [1] [2] over to Flow. It
helps me personally, catches a lot of bugs, and does a great job of self-
documenting while not getting in the way.

Flow has a lot of bugs and a lot of growth ahead of it, but it is far easier
to get started with than TS. I highly recommend it.

1\. [https://github.com/STRML/react-grid-
layout/blob/master/lib/u...](https://github.com/STRML/react-grid-
layout/blob/master/lib/utils.js)

2\. [https://github.com/mzabriskie/react-
draggable/blob/master/li...](https://github.com/mzabriskie/react-
draggable/blob/master/lib/utils/positionFns.es6)

~~~
Eridrus
> Flow has a lot of bugs and a lot of growth ahead of it, but it is far easier
> to get started with than TS.

I know this was definitely the case when I started using TS a few years ago,
but they recently added support for compiling .js files in your typescript
projects, so you only need to deal with the compiler one file at a time.

Admittedly I haven't used it, but I think it should have made the migration
easier. Probably still not as easy as Flow, but easier...

~~~
STRML
That does help a lot and was a long time coming.

TS is a little harder to get started with for a few reasons. For one, it
simply does more, with features like interfaces (which "sort of" exist in
Flow), and public/private accessors.

One distinct advantage of Flow is that it is _not_ a build step, but is more
like a linter. I like this - it doesn't re-invent the wheel, so you don't have
to choose between having the latest features or being fully TS-compatible. On
the other hand, Flow's typechecking is far less complete, and it still uses
its own home-rolled parser which occasionally has issues parsing certain
ES2016+ features, such as decorators.

If I were starting a project from scratch, I would likely use TS as it's
simply more complete. But if I were migrating an existing project, Flow starts
paying off right away and is easy to integrate.

~~~
Akkuma
As you mentioned, Flow not being a build step seems to be a big win to me. A
lot of different tools use or encourage you to use babel and babel is ahead of
TypeScript in ES6/ES7, [http://kangax.github.io/compat-
table/es6/](http://kangax.github.io/compat-table/es6/). If you use TypeScript
your chain suddenly becomes much slower/more complex.

------
mstade
Starts off with:

> Typed vs dynamic is a rather controversial topic, so I’m not trying to spark
> that discussion all over again.

Goes on to explain that typed is betterer...

The article doesn't really offer up any real arguments as to why you should
specifically use TypeScript, but really just says typed is nice and everyone
lints anyway (not true) so the step up to a type system really isn't that big
of a deal (also not true.)

Not really sure what point the author is trying to make.

~~~
nateabele
Context matters. Some people, _while writing their own application code_ ,
find types to be annoying, a nuisance, or whatever. That's a personal (or
team) decision.

This article is targeted at authors and maintainers of high-adoption
libraries. It says so right in the second paragraph.

And, frankly (speaking as someone with experience on this topic), he's right.
Maybe static isn't always the answer, but in the context of high-adoption
libraries, a little bit of effort to improve clarity and strictness is a huge
lever for cutting down on wasted time of thousands of developers everywhere.

> _The article doesn 't really offer up any real arguments as to why you
> should specifically use TypeScript_

Did you read it? He offers the Git/Mercurial comparison of TypeScript's
growing popularity.

~~~
zamalek
He mentioned "contracts." You can throw off the shackles and use the `any`
type internally, but at the very least your public interface should have a
well-defined contract. TypeScript is one [very good] way to achieve that and
it even spits out machine-readable "contract summaries" for you (.d.ts files).

------
jowiar
I think this is a bit of a hasty claim with a bit of truth to it, sort of like
if someone said "All JavaScript libraries should be authored in CoffeeScript"
in 2010. A cambrian explosion occurred, then the community eventually
coalesced. Coffeescript itself isn't (and wasn't) perfect, but it pioneered an
approach that led to a whole lot of progress in JS.

A better framing of this is: "Type systems are good. The JS community should
sort this out in the next couple of years and will probably a standard
approach, but it's worth diving into the assorted tools that exist --
TypeScript, Flow, and any others -- to understand the ecosystem and find pain
points."

~~~
betageek
Unfortunately a few of the more visible members of the JS community seem
intent on writing blog posts like this, I'm super tired of 'I have seen the
light, this is the 1 true way, anybody who doesn't do this is an idiot'
ragebait. I guess it's a sound content strategy (296 points!) but makes me
think a lot less of the people who do it.

------
impostervt
I still run into libraries written in Coffeescript, and hate it when I do,
because I don't use it and have a hard time following it.

Javascript libraries should be written in Javascript. Worship the one true
God!

~~~
cpitman
Except this really isn't an issue for TypeScript, it reads that close to
JavaScript.

~~~
sametmax
It's not about reading, it's about the tooling you need to set it up. JS
initial strengh was ease of dev for beginers. Throw in a transpiler, a
dependancy manager, a package manager, a bundler with FS watching, and source
maps and what you got is wall for the very same type of dev that were
producing all those fantastic jQuery plugins 10 years ago.

And actually even for me.

I do know how to install and use all those. I just don't want to take the
afternoon to do so.

Why ?

\- Only one project out of 5 are big enough to justify it. \- The stack will
change in 6 months; \- I will need to train anybody who gets on board, and
document it, and maintain it. \- All this tooling integration is terrible in
JS, because they are an agglomerate of stuff we are stacking after the fact to
compensate JS bad initial design. The same stack for any other language is 10
times easier to setup and maintain (the stdlib is here for you in Python, you
don't need to load a deendancy to generate a uuid), or it's just here out of
the box (type hints ? embded in Php) or event completly uneeded (nobody use
transpilers in Ruby hence no source maps, etc).

So yes, it's annoying.

~~~
lloyd-christmas
> It's not about reading, it's about the tooling you need to set it up.

npm install typescript -g

This is the only addition on top of vanilla js, which is what you should be
comparing with instead of the massive crap of build-tool-of-the-month. All
said and done, if you're using those build tools in typescript, you'd be using
them for javascript as well.

~~~
talmand
Wait, you mean I can start up a brand new Windows machine and type "npm
install tsc -g" and stuff magically happens?

~~~
Avenger42
Visual Studio 2015 and Visual Studio Code both support npm. I don't even think
you have to type "install", I think it's just a matter of listing "tsc" in
your package.json file.

(I haven't tried it myself yet, but I just got back from VS Live in Vegas
where the ease of package management in VS 2015 was brought up in several
sessions.)

Check it out here: [http://webtooling.visualstudio.com/package-
managers/npm/](http://webtooling.visualstudio.com/package-managers/npm/)

------
ungzd
And then new transpiler language appears, with "real" type system, not java-
grade. And everyone stops using typescript, treating it as outdated
technology.

~~~
bodhi
It already appeared, and is called Purescript. It's great, and it's about as
likely to gain traction as Haskell.

~~~
kachnuv_ocasek
>it's about as likely to gain traction as Haskell

So rather unlikely?

Haskell has a JavaScript compiler as well, by the way (GHCJS).

~~~
MadcapJake
> So rather unlikely?

He means it already exists and hasn't overtaken TypeScript's popularity.

------
robert_tweed
I'm not certain I agree. I agree with better type systems, but does anyone
remember ECMAScript 4? Which Microsoft vetoed after Macromedia had gone ahead
and adopted it as ActionScript 3 (coincidentally around the time they were
trying to get everyone to adopt Silverlight). Well that's basically what
TypeScript is (with slightly more advanced type support). It's a nonstandard
dialect of JavaScript. Something that everyone (especially MicroSoft)
ostensibly agreed was not what was wanted or needed.

The alternative to that of course is Babel. Which is standard JavaScript,
mostly. Including the draft stuff that isn't ratified yet. But you don't have
to use any of that if you don't want. And things like Flow and JSX, which are
just plugins so again, you can take them or leave them.

The authors argument eventually distills down to a choice between TypeScript
and Flow. He concludes that TS is the best choice because it has the momentum,
but that's a false choice. The choice is between Microsoft's TypeScript
transpiler and Babel.

If you use Babel you can choose to use Flow, but if you use TypeScript you
lose out on everything else Babel has to offer.

And outside of the .Net+Angular world, Babel has all the momentum.

~~~
maaaats
What does one miss out from Babel, given that TS is a superset of ES6?

~~~
robert_tweed
It depends. The problem isn't so much what you might miss out on if all you
are doing is writing a library, the problem is what limitations it places on
consumers of your library.

The most obvious Babel plugins are JSX and Flow. If your library is using
TypeScript then it cannot go through the same build process* as any downstream
project that is using any Babel plugin. That means you need to publish your
library as ES5 and the client loses most the advantages of your library being
in TypeScript in the first place.

Also, Babel appears to be doing a slightly better job of keeping up with the
draft ES standards, so if you want to use cutting-edge JS features (like
async/await) that are on the standards track, you may need to wait a bit
longer for TS adoption to get there.

I also think it's unlikely TypeScript is going to win out in the long run, so
if you commit to TS now you're probably going to be rewriting in a few years.
It's better to stick to standard JS where possible. The history of ES4
strongly suggests that TS is never going to become an ECMA standard.

* You can, at least in theory, do a two-stage transpile that goes through both Babel and TS, but IMO, nothing good is likely to come from such a setup.

~~~
danielmason
I'm not sure I understand what you mean by "the client loses most the
advantages of your library being in TypeScript in the first place." Your
library still exposes a more clearly-defined API by making types explicit. And
saying that the downstream consumer doesn't get the benefit of compile-time
type checking if they've chosen not to use type checking is...kind of a
truism?

~~~
robert_tweed
The problem is with the author's assertion that _all_ libraries should be
using TypeScript and not, say, Flow, or some other alternative that achieves
the same goals, perhaps better.

~~~
MadcapJake
Does Flow offer type definition files?

~~~
AgentME
Yes. Also, there isn't a need to maintain a separate definitions file[1] if
the library was developed as Flow-typed code. I've made a few small
libraries[2] that were written with Flow-typed code, and are built so that the
types are automatically enforced if you use the library in a Flow-typed
project.

[1] A hand-maintained definitions file:
[https://github.com/facebook/immutable-js/blob/master/type-
de...](https://github.com/facebook/immutable-js/blob/master/type-
definitions/Immutable.d.ts) . Sure, it's nice as documentation, but that is a
lot of redundant effort if you already have separate documentation, and types
and documentation in the original source code too. [2]
[https://github.com/AgentME/contain-by-
screen](https://github.com/AgentME/contain-by-screen) is one simple example.

------
mbrock
Or at the very least, library documentation _really needs_ to _clearly_
specify the types of parameters and return values.

I'm positively surprised when I come across a JavaScript API whose
documentation actually specifies this very basic information.

Coming from the static typing world, it's astounding...

~~~
Maarten88
Yes. And, having worked with typescript, its quite annoying how poor most
typings files are that you get from the definitelytyped repository. It's
better than nothing, but they are unversioned (so always behind) and often
very incomplete.

I agree with the author: types are there anyway, typescript seems to work well
enough and has traction now, so please, if you write a library: add those type
annotations bottom-up in the library and let typescript generate a nice .d.ts
declaration file and standardized module stub around that final javascript
library.

~~~
moron4hire
I don't agree. Bad documentation is worse than no documentation. At least with
no documentation, I _start_ with the expectation that I have to figure
everything out on my own.

------
rtpg
I've been porting over a reasonably sized project to Typescript for about a
year now, well worth it.

Most of the time, the change is just to rename the file to `.ts`. Sometimes
you have to change things because (surprise!) there was a bug.

The biggest painpoint is that you usually have to go pick up some type
definition files from DefinitelyTyped for third party libs, but it's well
worth it. Second biggest painpoint is type signatures (depending on the
context, writing out types/definitions can be subtly different... or maybe I'm
doing something wrong).

To anyone who's considering moving their JS stuff to Typescript but have hit
some issues, please feel free to ask me. I really think it's a plus for sanity
when writing JS.

------
bsr203
I love static typing, but prefer flowtype for js project.

I used Typescript during the initial days while developing Angular 1 apps.
Things might have improved now, but transpiling to JS was slow then and had
non standard module system. It may make sense to use it for Angular apps as
Angular 2 and related projects are written in it. but, for me, it always felt
as another language farther away from JS.

Once started using Babel + Webpack, I couldn't think about leaving the
flexibility and standard compliance to Typescript (mostly react apps). Also,
gave Nuclide and Flowtype a second chance this week, and they dramatically
improved. As a drawback, there are tons of open issues on Flow tracker and
seems more investment needed.

~~~
AgentME
+1 for Flow. I've loved the fact that it's _not_ a build step, so it was
really easy to add Flow into my Babel+Browserify projects. I looked at
Typescript before, but I didn't want to leave Browserify, and
Typescript+Browserify did not look like it was a well-supported path.

Also its strictness about nulls has saved me so many times and has forced me
to make better APIs that carefully consider or prohibit them, instead of
treating null as a boogeyman that I don't think about until it inevitably
bites me.

------
bitinn
As a js library maintainer and contributor, I do find these arguments flawed:

> There is a culture in the JavaScript community that “types don’t matter”

I don't think that's the case, particularly among seasoned developers: we do
care about types and interfaces, but we just don't think writing them down in
code is as big a deal as Typescript claims it to be.

> We are already linting because we believe it makes better code.

Linting doesn't require you to write non-javascript, it just works (after
configurations). It doesn't force you to write code in any particular ways
(see ESLint for example). That's why we find it more acceptable.

> Types are stronger. Types matter.

TS isn't automatically stronger, since TS is a superset of JS, developers can
still omit the types. So you either write in proper TS-style and get its
benefits, or don't.

And referring to earlier points:

> The types are there. Instead of leaving them implicit, you can just make
> them explicit.

IMO: there are many ways to setup this contract. And I question the % of type-
related issues within a library when you have 100% test coverage and proper
linting already.

> Often in JS libraries, the types are vaguely defined as an afterthought when
> writing docs.

TS can't force you to write strong types, just as JS can't force you to write
good doc. You need a stronger will, not a better nag.

My case for writing your next popular library in vanilla JS: your users will
already know how to contribute. And you get to choose how to enforce good
variable types.

For TS vs JS details, see [http://stackoverflow.com/questions/12694530/what-
is-typescri...](http://stackoverflow.com/questions/12694530/what-is-
typescript-and-why-would-i-use-it-in-place-of-javascript)

Disclaimer: my libraries are nowhere as popular as angularjs or immutablejs,
but I do intend to maintain them to a degree that may serve thousands of
developers.

(Plus the author uses one of my library so I guess they are not that bad)

------
BuckRogers
This makes sense. For the same reasons you'd want your display driver written
in a statically typed language like Rust. I think a good case can be made that
Python(3) libraries should be using type annotations as well. Some net gains
on software reliability that you may not want or need in your webapp, but is
welcome in underlying libs.

While type errors are a small part of problems in software reliability, we
should take everything we can get. At least in things thousands of millions of
users are going to rely on.

------
onli
The title is needlessly inflammatory (hope that's the right word). It's the
original one, but the article states clearly that it is an advice for
libraries that _are intended to be used by thousands of developers_. Maybe the
title could be changed to "All big JavaScript libraries…"?

~~~
alimbada
What's a "big" JavaScript library? How do you know how widely adopted your
JavaScript library will be?

~~~
gopz
Regardless, it's difficult to think of any situation where a _All_ _______
should use _______ is really justified.

~~~
amelius
It works for "people" and "common sense".

~~~
talmand
Depends on what you define common sense as and the context you are using it
in.

------
zimmerx
This does not solve the problem of bad documentation or bad libraries. Points
to make his case are weak. Better autocomplete? Reliable libraries? The
library still compiles to JS and you can still use TypeScript naively and
incorrectly and ignore typesetting altogether.

TypeScript doesn't solve the problem at all. It merely adds another layer of
complexity/knowledge to a Library that still compiles to JavaScript. Write it
in JavaScript, deliver it in JavaScript. If your documentation and implicit
typesetting is giving you pains, then you should revisit what you have written
and how you've built your library. Not switch to something that tries to
enforce better behaviour.

------
andrewingram
I've recently started using Flow alongside Nuclide IDE (a Facebook-developed
suite of Atom extensions), which allows me to easily see the type of a given
variable.

What's nice is how much types can be inferred from just a handle of type
annotations. My editor can start pointing out potential bugs at the cost of
relatively little effort on my part, and that's a good place to be.

~~~
tommyd
How are you finding Nuclide? When I tried it a few months ago it seemed pretty
slow and unstable, and eventually ended up consistently using all my CPU after
a while. There wasn't a great deal of documentation/help setting it up
available (true of Flow as well to a lesser extent), which was why I chose TS
at the time, but am definitely interested in seeing how Flow is progressing.

~~~
andrewingram
I had the same problems when I tried it roughly the same time as you, but I
tried it out again this week and it seems to be working much better now.

~~~
bsr203
+1 I just give a second chance to Nuclide + Flow, and works great

------
phazelift
I was kind of frustrated for a while with the broken type system of
Javascript, as well as with the lack of easy type checking. I then wrote a
simple small library to make my life a little easier. It's called types.js, in
NPM as well..

Changing my entire code to TypeScript just feels a bit over the top to achieve
only static type checking. I now only dynamically check if needed. I believe
there are so much worse and important problems we are dealing with as
Javascript developers today that need attention.

I really believe WASM will become the base for a great new language that
eventually will make Javascript, TypeScript and so many others deprecated,
solving a zillion problems at once.

~~~
STRML
Try Flow, if you haven't yet. It's not as complete as TS, but it gets out of
your way and requires minimal investment. I find that the `(foo: string, bar:
number)` annotation style is just far more readable than e.g. JSDoc. You don't
even really need to be running Flow (babel will strip them), but it's
practically free - why not.

------
crudbug
People should embrace the functional expect of JavaScript. I am starting to
see ES6 classes flying around everywhere.

Flow allows you to add Types by following Progressive Enhancement [1].

All libraries should support Functional APIs.

[1]
[https://en.wikipedia.org/wiki/Progressive_enhancement](https://en.wikipedia.org/wiki/Progressive_enhancement)

------
highwind
All x should be y is a bad statement to make, especially if you are an
engineering. Every problem domain is different. And every choice has pros and
cons.

~~~
cantagi
This. Qualifying with "All" rejects all the cases where the statement might
not be true for unforeseen reasons. Disclaimer: I generally agree with the OP
despite the presumptive title.

------
jfe
In my limited experience working with JavaScript, I've found the lack of the
following to cause more problems when writing modular, reusable code than the
lack of type annotations:

* a single, definitive method for creating namespaces without using a framework or library

* a single, definitive method for defining classes and using inheritance without using a framework or library

* a single, definitive method of allowing async functions to modify the state of an object without having to declare that object in the global scope, without using a framework or library

If these problems are already solved, please let me know!

~~~
Mchl
The one about classes is solved by not using classes. Prototypal inheritance
works well (and besides, most implementations of 'class-like' behaviour are
using prototypes underneath anyway)

I'm playing a bit of a devil's advocate here ;)

------
al2o3cr
Alternate title: "Everyone else should invest the effort to support my use of
TypeScript"

------
BinaryIdiot
Absolutely not. This is the opposite of what you should do in my opinion.

If you're writing an API to be consumed in language X then you need to write
the API itself in language X. This will help you capture and handle edge
cases, language idiosyncrasies and other similar issues the way you want.

Using a different language that gets transpiled into a target language also
increases your surface area for bugs because now you have to worry about
typescript and JavaScript bugs. After using CoffeeScript a few years back and
spending HOURS debugging issues in its transpiling to JavaScript I decided it
just wasn't worth the hassle. Besides JavaScript, while not perfect, is pretty
damn good.

I love the idea of type script but transpiling it down into a language that
isn't as type strict just seems silly to me. Now when it can be compiled to
WebAssembly? Count me in.

~~~
radicalbyte
Have you used TypeScript? Try it out for a month or two on a real project.

It's the best thing that has happened to web development in recent years - it
improves Javascript in a completely compatible and future proof way.

The most amazing thing is that Microsoft created it. It's the polar opposite
of Old Microsoft - standards are being followed (not subverted), it's simple
pragmatic and has no lock-in.

~~~
Hurtak
Is TypeScript really future proof? I mean unless types, exactly implemented as
they are in TypeScript, will become part of the spec, we can't really call it
future proof. Also how is it compatible with anything, JavaScript is
compatible with TypeScript, since TypeScript is superset of JS, but it is not
compatible the other way around.

~~~
nothrabannosir
Yes, it is. Compiling TS just removes type annotations; the compilation output
(.js) is as readable as your original .ts. It has the same structure, same
indentation, same variable names, same whitespace, same comments, same
everything. This also makes debugging the code in the browser very easy.

TS does not add any semantic features, it only adds type annotations. Which it
checks at compile time, and then removes. That's it.

Want to switch away from TS? Compile all your .ts files, save the .js, check
that into your repo and continue from there.

(As other commenters sort-of pointed out: you will need to keep Babel in your
pipeline.)

~~~
Roboprog
Thanks for the concrete description. Can I still use dynamic constructs such
as string subscripts to associative arrays and code generation via eval()?

~~~
nothrabannosir
You mean in TS?

Yes. ∀ x: I can do x in JS → I can do x in TS

But, let's assume for a second that you couldn't: this thread is about TS
being future-proof. I.e.: ∃ x: I can do x in TS & I cannot do x in JS? No,
false.

This implies TS = JS. And that's the point: semantically, TS = JS.

~~~
Roboprog
OK, that's a good start. Is there a tool analogous to JSDoc for TypeScript
that gathers the same docs without repeating the type info already in the
code?

~~~
elisee
[http://typedoc.io/](http://typedoc.io/) might be what you're looking for.

~~~
Roboprog
Thanks. Also, some informative samples of what TypeScript itself looks like.

[https://github.com/sebastian-
lenz/typedoc/blob/master/src/li...](https://github.com/sebastian-
lenz/typedoc/blob/master/src/lib/application.ts)

------
hokkos
I would use Typescript, but its type system isn't smart enough to handle the
complexity of JS ecosystem. The other day I wanted to move my project to
typescript, the first module needed ambient definition that didn't exist in
Definitely Typed repo, it was quite annoying to create, and I am not even sure
it's correct, then I wanted to type some parsed JSon that had a TYPE_NAME
property with a string giving its type, it's basically tagged union and it
doesn't exist in Typescript but only in Flow ... but flow doesn't work on
Windows. [http://flowtype.org/docs/dynamic-type-tests.html#tagged-
unio...](http://flowtype.org/docs/dynamic-type-tests.html#tagged-unions)

So I completely abandoned my typing adventure.

~~~
Matthias247
I often use tagged union like interfaces in TS. It's definitly doable, but it
might be a little more work than in Flow. For the definitions I do things like
interface BaseInterface { TYPE_NAME: string }, interface DervicedInterface
extends BaseInterface { ...content }. And to safely access the content of one
or the other type I'm using user defined type guards like function
isDerived(a: BaseInterface): a is DerivedInterface { return a.TYPE_NAME ===
... }

~~~
hokkos
Thanks, I didn't think of that, it's a little more work and error prone with
functions and else/if code and less aesthetic than the switch/case that works
with Flow, but I might restart my typing goal knowing that.

~~~
Matthias247
Yeah, the if/else cascades that you need when there are lots of cases are
definitly not on the most elegant side. But maybe some support for type guards
in combination with switch/case will follow. In can live with the current
situation, because it isn't really better in most other programming languages
without sum types (you mostly need some instanceof followed by a type cast).

------
thegayngler
I've been down this path before. I used coffee script on a few projects. Every
time I have to go down that path I end up having to write more complex code
just to do basic things. This blows up the project timeline when I could've
done the same things in basic javascript in a few minutes.

I read lets discard the benefits of writing javascript as javascript in favor
of something else because of a few people refuse to learn javascript. If you
don't want to learn the language of the web then maybe just maybe it's not for
you.

I think people coming to javascript from statically typed languages need to
stop trying to fight javascript or trying to force paradigms on javascript
that don't need to exist/never meant to happen and instead embrace javascript
as it is and with an open mind.

~~~
douche
There's too many dumb things in Javascript that should have gotten
straightened out long ago.

I shudder to think of the countless man-hours that have been wasted working
around and debugging issues caused by stupid design decisions in the
Javascript language.

------
andridk
The Immutable.js API might be good, but the documentation is cryptic on a good
day, awful on a bad one.

------
golergka
Exact same arguments that I use when arguing that any software above a certain
complexity level and intended for a long life and maintenance should be
written in a strongly typed language with working generics system.

Seems ironic that JS community is starting to come around to that finally.

~~~
alessioalex
It's more like a vocal minority rather then the "JS community". Apart from
Angular && .NET people, Babel has the momentum.

------
tantalor
Or not, and add type annotations instead.

[https://developers.google.com/closure/compiler/docs/js-
for-c...](https://developers.google.com/closure/compiler/docs/js-for-compiler)

~~~
flatline
I don't understand the lack of love for - or at least general community
attention to - the Closure toolchain. Type annotations make a lot of sense for
JS - they are native JS, they are optional, and generally conform to the jsdoc
standards that people are used to. The Closure type system is pretty decent,
as well. I have yet to see a really compelling implementation of a JS-like
language that cross-compiles to JavaScript.

------
josep2
People spending their free time writing open source software should write it
in whatever they want. There is no way anyone should be forced to comply with
any standard when they are freely sharing their code. This article perfectly
reflects my thoughts when it comes to asking open source authors to do
anything: [http://hueniverse.com/2016/01/26/how-to-use-open-source-
and-...](http://hueniverse.com/2016/01/26/how-to-use-open-source-and-shut-the-
fuck-up-at-the-same-time/)

~~~
coldtea
This arguments boils down to "they are free persons" which is besides the
point and doesn't tell us anything.

This is not about where you start from (totally free, their own time, can do
anything) nor about whether they can be forced to do X or Y.

It's about what kind of community and software they (we) want to build, and
what would be the best practices and suggestions.

Developers aren't forced to package their libs for npm distribution, write
comments, ensure they play well with latest browsers, etc. either, but they do
-- not because they are forced to, but because they agree that it's a nice
thing to do.

FOSS developers do all sorts of stuff to make their software better for users
already -- writing documentation, packaging for various platforms,
evangelizing it, conforming to certain standards even when they don't
personally use them or care for them etc.

Software development, especially community OSS is not about proving how
"individual" one is, and doing everything for fun. It's also about wanting to
contribute to a common cause and build some common foundations and best
practices for a platform or language etc. Most projects agree to that idea, or
at least pay lip service to the idea.

In this case, the TFA is not about forcing anyone to do something they don't
want, so your reaction is besides the point. It's about suggesting what the
author thinks is the better way for developers to do going forward.

> _There is no way anyone should be forced to comply with any standard when
> they are freely sharing their code._

Force them not, but nudge them towards complying, or convince them to comply,
yes, there are TONS of ways. Advocacy for some specific practice, like TFA
does, is one.

------
nickbauman
People make basic mistakes routinely with types. Even with very sophisticated
type systems, like the one used in Haskel. There's evidence that in rare cases
where people could have been "helped" by a type system, the cost of finding
and fixing such a bug is far lower than using a type system to enforce
correctness in the first place. You will write automated tests whether you're
using a type system or not.

~~~
vchynarov
I am hesitant to start the whole typed vs untyped debate here, but this is
exactly what your comment is highlighting. Where does all this evidence come
from? I have recently started using Scala and while initially the learning
curve was quite high, I have been so happy to have such a comprehensive type
system.

~~~
brightsize
I was wondering why no one has mentioned scala.js here. It would seem to have
a good story to tell - strong typing and, according to the project site[1],
good interop with JS. As a Scala developer with some front-end experience,
exclusively with CoffeeScript (which I think is beautiful BTW, not a popular
opinion in these parts), I wonder what are perceived to be the downsides,
other than learning-curve and relative immaturity, of "client-side Scala"? I
can imagine developers being adverse to working with a heavyweight toolset,
but are there in fact interop (or other) problems?

[1] [http://www.scala-js.org/](http://www.scala-js.org/)

------
KuhlMensch
By adopting this stance, you are saying "The Javascript 'type story' is over.
It's Typescript from now on"

I rather hope that is not the case.

------
mark_l_watson
While parts of the article seem over the top, I do agree with the basic
premise of the advantage of type safe languages.

I struggle with the issue of type safety because while I really enjoy using
Haskell on side projects, I find Ruby a giant mound of non-type safe glue that
collects my ideas together into code. I use Ruby a lot.

I imagine that many JavaScript programmers like the lightness and malleability
of their language also.

------
hajile
There's a big misconception that JS has _zero_ typechecking. This is not true;
rather, JS has _dynamic_ typechecking. It turns out that when you're making an
API for an external call, you will need to manually check the types of the
incoming data anyway (and this is where I see 99% of JS type errors). This is
something that JS is equipped to do fairly easily when necessary.

A typical type problem would be sending a float instead of an integer. Sending
a float instead of a regex would not be a typical problem.Static types are
necessary in less dynamic languages because they have multiple competing types
which can't be distinguished otherwise (eg. all the integer subtypes) and they
have structs/classes that cannot be dynamically modified. JS types are simple
(number, object, string, etc) and very different in nature. In addition, this
kind of error will be caught quite quickly with even the most rudimentary unit
tests. Half-way decent docs where modules interact should solve the remaining
issues. Running into type errors within the same file or two is probably
symptomatic of a lack of composition.

Enter Typescript. It has one major positive in that it prevents some dynamic
techniques that can tank performance (though performance graphing and reducing
dynamism is probably a better solution). Because you cannot depend on everyone
using typescript, all external APIs must STILL have dynamic type checking.

This leaves you with type checking within your own project. Typescript can be
turned off anywhere a programmer wants making it unable to guarantee type
safety. It adds a lot of extra typing and visual overhead. Unlike C# (where it
gets it's type syntax inspiration), the types do nothing for the JIT because
the JIT never sees them.

There's no reason for a modern type system to not be based on Hinley-Milner.
There's no reason for 95% of typing to be inferred by the computer rather than
forcing it to be typed out. There's no reason to use a system that's only good
for the assembler when the assembler will never even see it.

------
theptip
Does TypeScript suffer from the same performance issues that Gradual Typing
systems share [1], or does it sidestep these by virtue of being transpiled?
Naively I'd guess not, which would mean that converting a library to
Typescript would often impose a severe performance impact on JS users, but
potentially afford significant gains for TypeScript users.

In TypedRacket, for example, using types in some (but not all) of your code
can result in up to 100x slowdowns, until eventually breaking through into
performance gains once most or all code is converted.

[1]: [http://blog.acolyer.org/2016/02/05/is-sound-gradual-
typing-d...](http://blog.acolyer.org/2016/02/05/is-sound-gradual-typing-dead/)

------
scotty79
I wouldn't say that writing them it TypeScript would be good. But rewriting
them in TypeScript at some point of their development might be good. Might
expose some bugs (even some conceptual ones).

TypeScript doesn't feel like a boon when you write things with it because
avoiding type bugs is further on the list. On the top of the list when you are
writing something is figuring out what you actually want to write and what
should be the APIs everywhere. TypeScript might make it harder to figure that
out because you are getting invested too early in the shape of your
interfaces. You'd get just yet another Java lib if you started writing in
TypeScript. But once you have the right APIs there's no harm in formalizing
them with bit of types.

------
jfmercer
IME, breathless superlatives such as "all x should be y" are almost never
true. That said, the author did go to great lengths to support his argument.

------
cm3
Let's hope WebAssembly will help to relegate JavaScript to obsolescence and
allow a productive and safe language to gain momentum. I also hope WebAssembly
will solve the debugging (no DWARF) story universally.

Web browsers are one of the most popular attack vectors and hence would
benefit from an APL-like rigid language profile for web applications.
JavaScript is too imprecise and bug prone for anyone to use.

~~~
oblio
Javascript is evolving and it also has probably the largest number of
developers in the world (both those working on JS VMs/tools and JS users).

Given that there are Cobol users still out there, it's entirely likely that JS
will outlive both of us and maybe even our species :)

Plus JS is one profile away from becoming a very sound language. And it's not
like it hasn't moved that way already (strict mode).

------
ninjakeyboard
How so? Anyone can contribute to javascript but only a very small subset of
javascript developers can contribute to the typescript library. Javascript
will be around and in vogue as long as it's the ubiquitous browser language.
Typescript? Who knows - some other language transpiling to js might be in
vogue in a few months and then nobody would be around to maintain your
libraries.

~~~
emodendroket
If you know JavaScript, I honestly don't think it would take more than a day
to understand everything TS offers.

------
moron4hire
I like static typing and I like dynamic typing. Gradual typing gives you the
constraints of both without the benefits of either.

~~~
danielmason
I'm sympathetic to the worst-of-both-worlds problem, but can this actually be
true? In the case of types, constraints actually are the benefit, right? Do
you mean that if you don't have compile-time assurance for 100% of the code,
the value of whatever % type coverage you have isn't very useful?

As someone who's evaluating Typescript and Flow for a team of JS devs, my
intuition is that having some typed code would give you beachheads of type
safety, which seems like a reasonable win and an incremental path to
improvement. I'm curious if this intuition is incorrect from the perspective
of those who have used gradual typing in the real world.

~~~
moron4hire
When in Rome, do as the Romans do.

If you're programming in a dynamic language, there are things that you do that
would not easily fly in a static language. Things like tests for truthiness.
On first blush, from a static background, something like "var p = x && x.y &&
x.y.z || w;" look terrible, but they're pretty standard ways of cascading
through different options without causing null pointer exceptions in a
language like JS. When you start introducing type constraints, you are
committing yourself to getting rid of all those dynamic shortcuts.

Yes, shortcuts can sometimes get you in trouble, but they can sometimes get
you down the road so fast that trouble doesn't have a chance to find you.
That's sort of the tradeoff you make: we can be super-fast 90% of the time, at
the cost of having difficult to debug problems occasionally.

On the other hand, when you have a requirement to have type constraints in
your code, any other code you interact with has to also have type constraints.
But in JS, that's not a lot of projects. There is the DefinitelyTyped
repository, but it's incomplete and of unknown quality.

I had thought the same thing as you, "beach-heads of type safety". The problem
is that dynamic code tends to infect static code. I eventually gave up on
TypeScript after not being able to wrangle the combination of a few code
generation and graphics tools. My project was already reasonably OO organized
and not dynamic, but there was just no easy way to handle the boundaries of
the APIs. To deal with it, I had to... start using the dynamic features of JS,
giving up on the type safety.

For example, you can't do function overloading in JavaScript, because you
don't have any information about types on which to differentiate functions.
Well, it turns out that means you also can't do function overloading in
TypeScript. The only reason Math.min works in TypeScript is because JS only
has _one_ number type, and it is 64-bit IEEE floats.

But some libraries in JS, and especially in DOM, do overload functions. You
test the type of parameters at runtime and decide what each positioned
parameter _actually_ means. So if you want to use such a library in
TypeScript, you need to have a type definition that uses Any for each of the
parameters, meaning you've lost type safety and you're back to testing the
type of things.

So it just leaves you in this limbo zone where you don't get to use the
features of the native language that make up for it being so crappy, nor do
you ever get to use the features of the transpiled language that promises to
keep your code easy to modify over time. So that's what I mean about "worst of
both worlds".

It's like trying to introduce rules on a group of anarchists: you're more
likely to get burned at the stake than to make more productive anarchists. Or
try letting a bunch of corporate lifers work without a direct boss: you're
more likely to end up with a lot more donuts eaten than code written. What ES6
gets right is that it doesn't try to bolt on a type system into an ecosystem
that just won't tolerate it. It has features for making it easier, less error-
prone, more ergonomic to do things that people are already doing in ES5. In
particular, people are already trying to make classical classes with
inheritance out of the prototype-based class functions in ES5, so ES6
introduced a new syntax for just that use case that gets rid of all the
repetitive and goofy "Object.create" and "MyClass.prototype.myMethod =
function(){ blah blah blah blah }" stuff.

~~~
olmo
Sorry moron4hire but you are underestimating TS types system.

You can write quite crazy expressions abusing Boolean operators and he
successfully keeps the static type.

You can also have different method overloads signatures as long as you have a
more general implementation that does the dynamic checks at run-time manually.
Most of the time you can use Union types anyway.

The big collection of definition files for almos any JS library out there is a
living proof of how is possible to describe statically almost any JS API.

Let's face it, dynamic languages are about laziness, not about 'unconstraibed
creativity'

~~~
moron4hire
Laziness is the root of computer science. There is no virtue in hard work for
hard work's sake.

------
awinter-py
paraphrasing some 20th century poet:

    
    
      from what I've tasted of typescript build times
      I hold with those who favor javascript
      But then I've seen enough of bugs
      To think that for frontend dev work typescript
      is also great
      and would suffice

------
je42
Types are nice, but in the end a type doesn't convey all the semantics.

Types also add overhead. They can be also superfluous and unnecessary.

Getting your types in a application right and to gain the optimum from them is
quite some work.

Over the years, i learned to appreciate more unittests over more types.

------
paukiatwee
All of these "You should use X instead of Y" articles is really not much can
debate because there is no perfect languages/tools where in this case, the
author think TypeScript is better than JavaScript.

I stop find perfect language because there is none.

------
wangchow
With WebAssembly making its rounds it would be cool if Javascript libraries
are able to be written in C/C++ or other lower-level languages then exposed
via an API. That way a lot of algorithms can be shared with native code-bases
too.

~~~
edtechdev
That could more easily be accomplished if they had chosen a proper bytecode,
like LLVM, even JVM. It's still possible, but WebAssembly is just a Javascript
AST.

------
tosh
I just hope this will not be yet another point of fragmentation for
JavaScript.

Not looking forward to not only having to use different build tools for all
libraries I work with but also different pre-processors and type analyzers. Oh
my.

~~~
moron4hire
Why would you? Just don't use those libraries that don't fit your work flow.
This is where "framework fatigue" comes from, this word insistence on trying
to include every project under the sun into your project.

------
issaria
Not sure if it's still true, last time I checked TypeScript it's not
compatible with ES2015 as babel does, so I chose babel instead. It's good to
have type safety, but there is also flowtype.

------
gjvc
Is this like saying that JS is the moral equivalent of assembly language for
the web platform, and high-level development on the web platform should be
done using something like GWT and/or GXT?

------
puppetmaster3
It's open source. Get it?

Nothing all stoping, DIY, in fact encouraged. I agree .ts is great, and who
ever desires a lib to be .ts, the only questions is: if you desire it, than
make it so.

------
partycoder
Nope, in fact you should not use JSDoc, and you should not follow Google's
JavaScript standard, despite the fact they authored V8. Instead, you should
follow a self-proclaimed "standard", that adopts unsafe practices such as not
using semicolons, something that Google itself factually demonstrated as being
unsafe. But even that doesn't matter.

Let's let humans do the job that computers can do faster and more reliably,
like validating the types of variables and function signatures. Let's do
everything by hand. Let's give control of our programming future to people
that don't care at all about programming.

------
fiatjaf
I think it is much more important that final apps -- not libraries -- are
written in Typescript.

------
ape4
Someday soon JS libraries will be shipped in asm.js. Imagine jquery in asm.js.

------
fiatjaf
There was project somewhere to do type-checking with JSDoc. Where is it?

~~~
muraiki
[http://usejsdoc.org/tags-type.html](http://usejsdoc.org/tags-type.html)

------
Un1corn
Why not just using JSDoc for you library?

------
mcs_
we probably should start doing new 'hello world' in ES6.

------
meshko
L All HN posts titles and comments should start with letter L!

------
bricss
types only matters if you are stupid

------
merb
No.

------
klibertp
> but transpiling it down into a language that isn't as type strict just seems
> silly to me

You obviously have no idea what you're talking about. Almost all statically
typed languages get compiled to something much less type-strict. This is one
of the reasons for writing compilers in the first place! Case in point:
Haskell gets compiled to assembler. You can't get a much bigger difference
between typing disciplines than that.

~~~
nothrabannosir
Good point, but is the first sentence necessary? :(

~~~
klibertp
Are you implying that it's factually incorrect? Also, the word "silly"
appeared in the BinaryIdiot's comment first. You have to be prepared for not
exactly polite responses when you do something like this.

~~~
nothrabannosir
Incendiary language like "you obviously have no idea what you're talking
about" is bad for the quality of your comment, and this entire discussion.

Not everyone is capable of looking past personal attacks like yours. It is the
first step to a flame war.

You have something to say? Great. Just say it, no need to talk about how
little the other person knows.

Aside from "two wrongs don't make a right," do you really feel that this is
comparable?

 _I love the idea of type script but transpiling it down into a language that
isn 't as type strict just seems silly to me. _

And..

 _You obviously have no idea what you 're talking about._

If you honestly, in your heart of hearts, feel that both statements are
ballpark same level of cordiality, then ok.

~~~
klibertp
No, to be honest - and I really expected you to drop this argument, which is
why I didn't bother elaborating earlier - it was an emotional response from my
side. The first version of my previous comment didn't focus on the word
"silly", it read something like this: "it may not be right to call the other
person ignorant, but, for this particular person, it felt soooo good!"

Just as you say, we're human, which is why "not everyone is capable of looking
past personal attacks". Moreover, what we regard as "personal attacks" varies
from person to person. Personally, I felt insulted by the specific kind of
ignorance displayed by BinaryIdiot in his posts in this thread.

I _know_ I shouldn't have and I don't think the downvotes are undeserved. On
the other hand, I obviously have my reasons for feeling that way; judging by
the font color of many BinaryIdiot's posts I wasn't the only one.

I read through all the posts in this thread before posting. BinaryIdiot
talking about how he experienced "transpiling languages" in the form of
CoffeeScript and so he knows everything there is to them... That was
excruciating. Him talking about compilation and compilation targets was
similarly painful. One of the versions of my first reply to you read: "I've
been hurt in enough ways and enough times [by people behaving like that] to
develop a little bit of aggressiveness towards them."

In all honesty, the point about how compilers work was just an excuse. I
suppose what I really wanted to do was to tell BinaryIdiot how wrong he is
about some things, and how irritating it is for me personally (especially
today!) to see him talking about programming languages, compilers, and whatnot
without first investing any time on research.

Well, it's still wrong and I should have just ignored the whole thread.

~~~
nothrabannosir
Ok, I think you have a point and I blew the thing out of proportion. Sorry for
that.

------
halis
Maybe when it asks you to upgrade to Windows 10 this guy's picture could pop
up like Clippy.

------
alz
only siths deal in absolutes

------
ebbv
This is akin to saying "Every C++ library should be written in Objective C."

EDIT:

Hey people down voting me; it literally is the same. C++ is a standard, JS is
a standard. TypeScript is (like Objective-C) a compatible alternative.

~~~
codemusings
Absolutely not. Objective-C started out as a superset for C. Emphasis on
'started out'. It has nothing to do with C++. You can combine the two of them
but they are hardly compatible. Messaging on the side of Objective-C vs.
custom operators on the side of C++ being just one example.

~~~
ebbv
Yeah and TypeScript has Types and JS doesn't. So, there's incompatibilities
there too. Granted, the relationship is backwards so maybe I should have
reversed the comparison, but it still stands. This was an asinine suggestion.

------
raverbashing
Oh of course, because it is strongly typed

Title just reinforces my belief that people have this feeling towards strongly
typed languages like it's some kind of religious saviour and will try to
preach it _everywhere_

------
plugnburn
All JavaScript libraries (!) should be authored in JavaScript.

All complex code that uses them should be authored in CoffeeScript.

Nothing more is needed.

P.S. TypeScript is M$ invention -> must burn in hell.

