
TypeScript is weakening the JavaScript ecosystem - timdaub
https://timdaub.github.io/2020/09/01/typescript/
======
virtue3
I think comparing typescript to coffeescript is a very amateur call.

Coffeescript specifically decided to throw out ECMA script. Typescript
embraces it.

There was SO SO SO much waiting around the ".?" operator in TS because they
specifically did NOT want to do what coffeescript did (make their own, and
then get hosed when the official spec came out and they were different from
their own implimentation).

The -only- difference between TS and JS is the type annotations. It should be
perfectly readable JS aside from that.

Objective-C can actually compile C. Objective-C is a -superset- of C. So
again, the argument is misguided.

All the typescript webpack plugin does is strip out typescript stuff. And that
leaves you with the underlying JS.

Typescript projects should be pushed up to NPM with their transpiled modules.

I believe any small bug that the author of this article was hoping to fix in
subprojects should have been caught by the typing system. You should see about
25% less bugs in TS code vs JS (number pulled semi-out of my ass, pulled from
some strong blog with strong opinions against TS).

I believe, if anything, that TS's impact on the JS ecosystem is incredibly
important for the long term survivability and reliability of it. As our sub
projects get larger and more complicated, having the compiler save our
collective butts is huge.

~~~
genuine_smiles
> The -only- difference between TS and JS is the type annotations. It should
> be perfectly readable JS aside from that.

TypeScript has a few differences:

Automatic class properties from arguments:

    
    
      class Foo {
        constructor(
          public bar: string,
        ) {}
      }
    

Enums, and probably other stuff I've forgotten. I think they're avoiding
adding any other differences though.

~~~
timdaub
I find this argument weird. JS doesn't have Public Class fields yet [1] (stage
3), hence any TS or JS code making use of such concept will differ.

Similarly, as reliance of types in JS is not guaranteed, as it may in TS, will
produce code with different assumptions too.

So while you may "easily" go from (1) JS => TS, it may be much harder going
from (2) TS => JS, as in (1) you're preserving all information and in (2)
you're losing information.

My point being, TS !== JS.

\- [1]: [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Classes/Public_class_fields)

------
gvkhna
The author admits to not using Typescript and not knowing how it works but is
quick to point out that it’s polluting the JavaScript community?

He does state that typescript is a subset of JavaScript and this compiles to
JS so I largely don’t see the problem. TS is making complex projects in JS
more tenable and I believe we should encourage TS.

A separate repo for TS doesn’t make sense, Microsoft owns npm now by extension
of github and is doing fantastic work supporting TS and by extension JS.

My hope is the opposite, at some point TS is the gold standard for a package,
it is self documenting and again the types can be stripped out (and usually
are for distribution).

~~~
digitaltrees
But the point is it creates fragmentation.

~~~
ryandvm
No, JavaScript being the kind of language that requires 3rd parties to
implement what should be core features is what creates fragmentation.

There was similar fragmentation with JavaScript's async patterns. Callbacks,
promises, async/await also resulted in fragmentation as you had different
projects supporting different patterns as 3rd parties introduced new
capabilities (that eventually graduated into fully-fledged language features).

Hopefully the best of what TypeScript provides will make its way into the
ECMAScript spec eventually...

~~~
danShumway
Agreed. And importantly, the fragmentation of the Javacript ecosystem is _on
purpose_ :
[https://github.com/extensibleweb/manifesto](https://github.com/extensibleweb/manifesto)

I think about the fragmentation that shows up in the form of multiple
frameworks and patterns as a necessary part of that. It's not something that I
want to fix.

So to draw a line and say, "extending core Javascript features is fine, but
compiling into Javascript isn't" \-- I just don't get that. Typescript is a
testing ground not just for typed programming in general, but also for
features like decorators and meta-programming features. It's good to have a
diversity in what people are building and using, that's how we get real world
data on what works.

------
paxys
> My context is that I've not looked into TypeScript yet. That means I have no
> idea how it works.

This is all you need to know about this article. There is no such thing as a
"TypeScript package" on npm. It's simply a JavaScript package with a bundled
type definition file. A pure JavaScript project can use this package as they
normally would, and just ignore the types. So I don't understand where the
question of fragmentation even comes from.

If the author is concerned that they aren't going to be able to contribute to
projects written in TypeScript, then it's really the same problem as having
JavaScript projects that enforce ES6 syntax, a specific module strategy, have
custom linting rules, file structures, use Promises vs callbacks etc. Should
those be disallowed as well?

~~~
watt
The author's context is that he has no context. No frame of reference. Out of
his element. I wonder who's more misguided, author, or the person who decided
this link is worth posting.

~~~
oaiey
That was the author himself. A lot of ppl do instead of a comment section
under posts.

------
anandchowdhary
> My context is that I've not looked into TypeScript yet. That means I have no
> idea how it works.

The main problem Tim has is that he doesn't write TypeScript, so he wouldn't
be able to contribute to dependencies. I don't think that's a huge problem
since learning limited TypeScript to make patches to projects isn't very hard.
In most cases, some patches might not require any TypeScript features at all.

> So essentially, the problem is that TypeScript authors publish their
> packages on npm, the package manager for Node.js. And to me, that's what is
> weakening the JavaScript ecosystem.

This doesn't make much sense to me, because the convention is to publish the
"dist" folder to npm that has compiled JavaScript with declaration files, not
the TypeScript source. To the Node.js engine, a package written in TypeScript
is indistinguishable from one written in plain JavaScript. Declaration files
have the added advantage of intellisense in IDEs that support language tools
like VS Code.

> However, continuing to publish TypeScript packages to npm is, in my opinion
> weakening the JavaScript ecosystem as it's splitting its community and
> polluting the npm namespace.

Again, I point out that you can use TypeScript packages in Node.js/JavaScript
projects. The pollution argument doesn't hold for me. npm packages already
have a lot of "versions", like publishing ES Modules, compiled JS, legacy
Node.js modules (module.exports), etc., so having TypeScript-compiled code
that doesn't require additional tooling is the least of our problems. :)

------
danShumway
> Since its inception, and throughout trends like Coffeescript, npm has mostly
> held the promise of only hosting JavaScript packages.

I don't think this is true. There are multiple NPM packages that rely on non-
JS extensions and external binaries to run. The entire `node-gyp` ecosystem,
which is a pain because it makes it impossible to vendor dependencies in a
portable way.

On that front, compiled Typescript isn't that hard to read. I'm less concerned
about someone cross-compiling a language into Javascript than I am about
someone pushing a C binary alongside their code as part of the install script.
WASM modules are going to start becoming more common in Node eventually.
Deciphering Typescript with a pure-JS background is way easier than
deciphering Rust.

I see this argument come up with frameworks and libraries as well: "Javascript
has too many frameworks, it makes it impossible to evaluate a 3rd-party
package." I don't think the argument stands up to much scrutiny there, and I
don't think it stands up to a ton of scrutiny here.

------
AaronFriel
TypeScript strengthens the JavaScript ecosystem by making it easier to write
correct code, and easier to use code correctly. I suspect the author's self-
professed lack of knowledge of TypeScript is the biggest barrier, but that's
not why I decided to write this comment.

I wonder how many times the author has used node-gyp, node-sass, or even a
wasm-pack packaged NPM package? The latter allows writing NPM packages in any
language that compiles to web assembly. That's quite a few languages already,
most of which are much further removed from JavaScript.

Despite that, I think that strengthens the NPM ecosystem, even if it "weakens"
the JavaScript ecosystem. (I don't think it does, actually.) It means NPM is
one the first and largest polyglot package repository. It's certainly the
largest public source code and library repository in the world, and now or
very soon, it will be possible to reap the benefits of packages using
webassembly to get (nearly) bare metal performance without compromising
security.

I would also argue this strengthens the JavaScript ecosystem too because all
of these languages work transparently with JavaScript. The first-class citizen
remains JS, for now, and people writing C/C++, Rust, Scala, ML, and others to
webassembly are making their code available with JS bindings that just work.
That's pretty amazing.

The closest thing to this is Python, and it's so nontrivial to contribute
native or FFI code that works reliably to pip that it's not done outside of a
handful of extremely performance sensitive data science projects. For this
reason, I think JS (and webassembly) is ascendant, and Python's star is at its
peak.

~~~
oaiey
Also why thinking NPM to limit to a language. The browsers and node are
essentially virtual machines (evidence: see wasm). NPM is the package manager
of this VM and not the JS language (ignoring that there is no TS code
shipped).

------
msoad
What the OP is talking about? Nobody is publishing TypeScript to npm. Maybe
they need to understand how things work before writing a lengthy blog post.
Those packages have types built in because of the emitted .d.ts files.

~~~
arusahni
I think he's suggesting that one of his criteria for package selection is his
ability to contribute changes to the upstream project if needed, which he
feels he can't do for TypeScript on account of him not knowing the language.

~~~
timdaub
Yep that's what I intended to say.

~~~
oaiey
That is a valid point, but honestly, avoiding (learning) TypeScript as a
modern day JavaScript developer is a mistake.

I know it is annoying that there is a breach into the purity of the JavaScript
language by a different actor. But let us face it: TS is useful, it is the
right tool for the job and it is not niche. It complements JavaScript and
solves problems JavaScript is structurally unable to solve. It helps and
improves the JavaScript language. It helps millions of developers with static
typing backgrounds to accept and deal with the imperfections of JavaScript.

In my primary language - C# - there is tons of influx of functional
programming nowadays (sourced via F# and OCaml). I could fight against it but
I do not. I embrace change and adapt. Take the Linux Kernel: After three
decades of C code they are talking/merging support for Rust. Why: it is the
right thing and it is a good complement for their C tooling.

~~~
timdaub
> That is a valid point, but honestly, avoiding (learning) TypeScript as a
> modern day JavaScript developer is a mistake.

You're probably right. My argument, however, was purely about separation of
concerns: different language means different package manager (or
namespace...).

~~~
oaiey
I disagree. Node and the browsers script engines are virtual machines
nowadays. Package managers go by VMs not by language.

~~~
timdaub
Not sure I get your argument. As far as I understand there's no VM for
Typescript specifically. Hence as "no VM" is different from Spidermonkey/V8,
Typescript packages _should_ go into its own package manager?

~~~
virtue3
A kotlin project is going to use both java and kotlin sources (and maybe
closure).

We're going to start seeing a lot more WASM stuff on npm, which is going to be
whatever language anyone wants.

The VM for typescript is node/browser. Because it gets compiled to target
those.

------
jpnelson
By this argument, JSX shouldn't be published to NPM either.

You might argue that you know what you're consuming if you're importing, say,
a React component, and it's likely written in JSX, but it's really a
categorization issue.

A standard field in the package.json indicating what the source is written in
might be useful, but would probably be left unpopulated. Personally, I find it
fairly straightforward to tell what a package is written in just by looking at
the source.

------
ncphillips
IMO including TS packages in JS ecosystem strengthens rather then weakens the
ecosystem. A library consumer doesn't have to know whether a package is
written in JS or just compiled to JS. Either way, it's still useful.

And TS isn't so magically different from plain JS that it's not
understandable. Most TS ends up being plain JS, so the comparison to
CoffeeScript or even Objective-C doesn't see fair to me.

------
oaiey
I would highly recommend the author to "pause" this post, learn the little of
TS you need to understand, and then rewrite the post.

I mean there is a valid argument about TS making JS more typed than the
ecosystem should (not my personal opinion) but that was not even scratched as
a topic here.

------
fbn79
I think Typescript as a standalone language will reach is maximum adoption in
a couple of years. Than we will gradually see more and more packages roll-back
to standard ECMA script eventually with typescript checks by JsDoc annotation
and .d.ts files. That's the more trational solution. Take as case Deno
migrating from Typescript to Javascript [https://startfunction.com/deno-will-
stop-using-typescript/](https://startfunction.com/deno-will-stop-using-
typescript/)

~~~
WorldMaker
I only see that happening if TC39 pulls a PEP 3107 [1] approach and adds type
annotations as optional part of the JS language directly that browsers don't
need to understand and can ignore but should parse. The Typescript format of
type annotations is much more convenient than the JSDoc style (and think
Typescript surpassing Flow is in part because of that; among several other
reasons), so there likely will always be people wanting it. At that point a
PEP 3107 approach would both mean a lot less need for Typescript and also a
lot more use of Typescript-like type annotations.

Deno's odd choices made on V8 performance issues (failures) also does not look
to implicate a trend so much as Deno making some interesting choices. (There
too a PEP 3107 approach would have helped them as the performance issue they
were trying to fix was type stripping as V8 itself doesn't today have any
reason to performantly type strip TS-like annotations, but of course that
would change tomorrow if TC39 made that a first class citizen of the JS parser
directly.)

[1]
[https://www.python.org/dev/peps/pep-3107/](https://www.python.org/dev/peps/pep-3107/)

------
WorldMaker
I would think most Typescript packages today would fall under the author's
second criterion:

> picking packages that are well-maintained by a large community

Whether or not the author feels they can directly contribute to a Typescript
package, overall Typescript seems to balancing the scale on npm in favor of
well-maintained and large community. Admittedly, I've been a fan of Typescript
since 0.97 so I'm biased but I very deeply feel that you cannot have well-
maintained in JS overall without Typescript.

I don't see that as weakening the ecosystem at all, in that the rising tide of
Typescript quite clearly seems to me to reflect a rising tide of maintenance
in the ecosystem.

Obviously opinions will continue to vary, but I certainly invite the author to
spend at least a bit more time with Typescript before jumping to the
conclusion that Typescript is neither well maintained nor encourages a large
community as it this article implies if the author truly does not feel
comfortable under their own criteria of worse case treating typescript as a
blackbox similar to C/WASM and trusting communities that do use Typescript.

I think the attempted analogy between C and Objective-C especially points out
that probably at least a bit more familiarity with Typescript might help the
author a ton. The comparison between C and Objective-C seems pretty weak to
me. Objective-C makes a ton of syntax changes to the language. Typescript
makes relatively few. About the best comparison I can think of is Python and
MyPy with the only missing piece being a PEP 3107 [1] equivalent asking
browsers to support Typescript annotations even if they don't understand them.

What the analogy says to me, if Typescript looks foreign enough from JS to the
author as Objective-C to C is much more that JS itself has changed so much in
the last few years that the author is perhaps behind on what ES2015+ flavors
of JS look like as most of what makes Typescript look "foreign" today really
is just JS today. It may be worth digging more into Typescript simply to learn
more about how JS is evolving/has evolved.

[1]
[https://www.python.org/dev/peps/pep-3107/](https://www.python.org/dev/peps/pep-3107/)

------
devit
> My context is that I've not looked into TypeScript yet. That means I have no
> idea how it works.

The problem lies in the author, since knowing TypeScript is an essential skill
if you are doing anything browser-related or JavaScript-related.

Also TypeScript produces readable JavaScript, and anyway it's trivial to
mentally strip the types when reading TypeScript, and also very easy to learn
enough to fully understand most TypeScript code.

------
backspaces
Actually, it should be: JavaScript is weakening the JavaScript ecosystem.

In the olden days, html, css, js were it. But each were "subclassed" by better
solutions compiling to html, css, js.

Then huge frameworks arrived to try to organize the mess we'd created. Making
devs further than ever from html, css, js.

Remember the old saw: Sure I understand JS, I use jQuery every day! Er, but
how about closures? direct DOM use via JS? And so on.

To be fair, jQuery and later CoffeeScript, improved JS considerably.

I don't get the feeling that TS is going to help JS, but hopefully I'm wrong.
But unarguably it is SPLITTING the JS ecosystem into warring camps.

------
tanilama
Typescript is SUPERSET of JavaScript, not subset...

~~~
timdaub
Right. I think it should be fixed soon.

~~~
legerdemain
What needs fixing is not just replacing the word "subset" with the word
"superset," but the entire argument in the paragraph. Your argument is based
on your misunderstanding. Valid TS in not necessarily valid JS. No informed
person will claim that you can just drop TS into a JS project the same way you
can drop JS into TS. Also, no one is publishing TS to NPM, and certainly not
for the (mistaken) reason you describe.

~~~
timdaub
I think there may be a misunderstanding. I too know that nobody published
TypeScript packages directly in NPM, but they always include a transpiled
version. Nevertheless it'd consider it a "TypeScript package (that was
transpiled to JS and then published to NPM)".

Edit: To make sure this misunderstanding is avoided, I've adjusted a section
in the blog post to make it super clear.

~~~
legerdemain
If your claim is that it's impossible to contribute to a package written in TS
without writing TS, even if the authors publish a JS version to NPM, I
completely agree. I also agree that this creates a divide between authors who
write TS/publish JS, and those who write JS directly.

~~~
timdaub
OK. Then I guess we're on the same page.

------
kyranjamie
As your run-of-the-mill web dev who's been using TypeScript professionally for
about 5 years, I find posts like this fascinating.

Other comments address the main themes in this guys article, mostly not having
any context on which to base the argument.

If you don't keep up with the trend, you're going to lose out.

------
soneca
It is getting in the way of the way the author decided to select the packages
for their projects, just that. It is not weakening the JavaScript ecosystem in
the least.

In my opinion, by solving a pain point that a relevant part of the developers
involved in the JavaScript ecosystem have, it is making the ecosystem
stronger. An ecosystem that make more people happier is a more robust one.

