
Deno will stop using TypeScript - diablo1
https://startfunction.com/deno-will-stop-using-typescript/
======
inimino
There are so many uninformed and misinformed comments on this post. Please
read the design doc[1] before commenting if you assume the Deno team is doing
it wrong, or hasn't ever considered some obvious solution you came up with in
0.7 seconds.

[1]:
[https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...](https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview?pru=AAABcrrKL5k*nQ4LS569NsRRAce2BVanXw#)

First paragragh of that document:

> Update June 10 2020: I saw that this design doc was being discussed more
> widely. Most people don't have the context to understand this narrow
> technical document - it is only applicable to a very particular, very
> technical situation in the internals of Deno. This is not at all a
> reflection on the usefulness of TypeScript in general. It's not a discussion
> about any publicly visible interface in Deno. Deno, of course, will support
> TypeScript forever. A website or server written in TypeScript is a very very
> different type of program than Deno - maybe much more so than novice
> programmers can appreciate - little of Deno is written in TypeScript. The
> target audience is the 5 to 10 people who work on this particular internal
> system. Please don't draw any broader conclusions.

~~~
snek
Gotta appreciate the part implying that anyone who finds this document amusing
is a "novice" programmer.

~~~
dbnoch
I thought the "novice" programmer remark was a pretty cringe-worthy comment.

The original reasons listed by Deno for removing TS had the undertones of
"senior engineer who hates certain tech because they didn't use it right".
Naturally, their response was to say "you probably don't understand cause
you're a novice".

~~~
Aeolun
I can sympathize with their issues. TS compiles are slow as fuck, and if I
could find anything that was just as nice without the long compiles I’d switch
in a heartbeat.

But I don’t think I’d ever want to go back to plain Javascript.

~~~
112
There are efforts to provide faster compilation times: \-
[https://github.com/evanw/esbuild](https://github.com/evanw/esbuild) \-
awesome, I use it for most of my ts projects \- [https://swc-
project.github.io/](https://swc-project.github.io/) \- also awesome, but has
some bugs

~~~
Aeolun
Esbuild is cool, but if it doesn’t check the types then using Typescript is a
bit pointless in the first place.

Guess a combination of esbuild during development, and tsc during commit would
be the best of both worlds.

~~~
satvikpendem
Not necessarily, TS issues are found in the editor which is where most of the
use is. I don't test types only on compile but usually through VSCode itself.

------
whoisjuan
This is gonna be an unpopular opinion but as someone who learned to program in
loosely typed languages, I have never seen the TS appeal.

TS feels like something that was created to lure programmers who couldn’t wrap
their heads around JS loose nature. Almost like it was created to convince
Java and C# developers to use JS.

It have never felt about it like something that would make my code better or
more organized. It definitely slows me down with very little benefits in
return. (Again, can’t stress enough that this is a personal opinion based on
personal use cases)

I appreciate that it forces me to be more intentional about organizing my code
but I also get that when I use frameworks.

Of course I also appreciate when I can identify that an error is coming from a
type mismatch, but as I said I learned to program in loosely typed languages
first, so I never created that concept of defining types in my head. I’m
always extra-aware of types mismatches in my JS code and is usually the first
thing I check when something goes wrong. But I have never felt the need to
have a way to explicitly define the types that I’m working with. I honestly
fail to see the benefit when a large amount of code that you have to interact
with (libraries and such) was written in classic JS.

Once again. Probably unpopular opinion, so I don’t mind the downvotes.

~~~
mimixco
I've been programming for 40 years and I agree. Strong typing has a religious
quality. You have to believe that most errors are caused by type mismatch, and
I simply don't believe that. Most errors, in my experience, are caused by bad
architecture, poor documentation, and poor communications strategies between
MVC, etc.

~~~
elmo2you
I have a little less experience, only 30 years, but I have to fully agree with
you. Not sure why you got down voted (maybe the religious popularity crowd
rearing its head).

I have seen my share of "innovations" come and go, but I too fail to see the
empirical evidence that most bugs/errors are caused by type mismatch. In fact,
I would even go as far as to argue that in my experience the benefits of typed
languages (and the class of bugs they prevent) do not outweigh the usually
larger code size (and often even additional complexity).

Maybe I've just tried the wrong languages, but I was never convinced of the
great improvements usually promised. At the same time, I have seen other
people twist and jump through hoops, while vigorously holding on to their
conviction how all that is an improvement.

Sure, some errors will move from run time to compile time with typed
languages. But if those are a systemic problem in your code, you probably have
even bigger things to worry about (the ones you already keenly pointed out).

From a cynical point of view, I can understand why corporate entities would
love typed languages (for the increased code size and complexity), but that's
another story.

~~~
balfirevic
> Not sure why you got down voted

For the (pretty obvious) logical error of claiming that you have to believe
that most errors are caused by type mismatch to consider stating typing
beneficial.

------
echelon
Why such a large, important project would want to drop static types is beyond
me.

> TypeScript isn’t proving itself helpful to organize Deno code. On the
> contrary, the Deno team is experiencing the opposite effect. One of the
> issues mentioned is that they ended up with duplicate independent Body
> classes in two locations

This feels like process immaturity or unfamiliarity. Thousands of other
projects manage to do just fine.

These folks are free to do what they want with their project, but this is not
a good look, especially to those that are skeptical of the javascript
ecosystem.

~~~
mimixco
Lisp is large, important, and also not statically typed. It's worked out ok
for Lisp programmers. JS itself isn't strongly typed and is the most
successful and important language in the world (probably in the history of
programming), so that's two game-changers that don't require static typing.

~~~
BiteCode_dev
Lisp is not popular.

Remove the browser practical monopoly, and JS popularity would vanish.

~~~
searchableguy
I disagree on the current sentiment but agree that browser monopoly pushed js
on people. If js didn't evolve over the last few years (since es5), I would
have believed removing it from the browser would kill it.

Right now, you have options to avoid writing js at all. There might be some
glue code in js but you can write vast majority of your code in other
languages and target js. People still choose to write in js.

Purescript, elm, clojurescript, kotlin, bucklescript, and the list goes on.
There is a to-js transpiler for every popular language. Why aren't they seeing
more usage?

~~~
shirshak55
tbh JS is popular only because of browser monopoly. JS became popular because
of internet usage otherwise it would just die. It started with 1997 changed
little at 1998 and 4th edition was even abandoned lol. and it took so long to
evolve after that. in 2019 there was update and from 2015 we are seeing good
progress. no we still cannot avoid because browser needs it. Hopefully wasm
can replace but it still has long way to go.

So i don't subscribe to idea that js is not popular because of browser
monopoly.

~~~
searchableguy
I am not disagreeing with that?

------
vimslayer
Here's the Deno Design document with the reasoning and some discussion about
the decision:
[https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...](https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview)

This post adds little to what's already said there.

------
diffrinse
I'm a little shocked at some of the outcry in this thread. People are making
it sound like they're switching from Rust to Ruby or extolling the virtues of
types: TypeScript does absolutely nothing for you at runtime. There are no
types, there are no type checks, its all the same guarantees as good ol'
JavaScript. You still can't trust function parameters to be what they say.
It's a Babel configuration with inline doc annotations.

If people are serious about types, then why isn't more front-end moving over
to Elm, Reason, PureScript, OCaml etc? Hell, GWT is still out here even.
TypeScript has convinced people they're getting the benefits of (strong?)
types when they're just populating the auto-complete in VS Code.

~~~
samhh
TypeScript is really about type safety within the confines of your
application. You can address the unsafety at the edges with something like io-
ts.

~~~
diffrinse
But this is a niche application of TypeScript, most day-to-day front-end devs
I've interviewed aren't reaching for fp-ts, let alone io-ts, whatever the
benefits.

Even then, why not just use any one of Elm, PureScript, Reason, ScalaJS, etc?
Why implement yet another FP runtime? If something like this is the surest way
to make optimal use of TypeScript then I feel like we're just right back where
we started.

For most devs, I'd wager they're still ending up writing all the same tests
they were before TypeScript.

tsc even offers to just consume jsdoc annotations for crying out loud. If its
just some kind of type convention sandbox, what did it really bring to the
table?

~~~
samhh
Elm's got questionable support; I wouldn't feel comfortable recommending that
at work, it'd be irresponsible.

PureScript I really like but it's a massive jump from JS/TS to PS/HS.

All of these languages are harder to abandon than a library in the same
language you'll keep using if you decide against the paradigm down the road.
Do I like this compromise? Not really, but it makes sense.

Also, advertising use of a functional language might open you up to candidates
who wouldn't otherwise apply.

------
jakear
I’m a long time fan of TS, but I think this is a very exciting decision —- I
have always been of the opinion any reasonably large project should workout a
doubt use TS, so hearing about how this goes for them in 2/5/10 years in terms
of how easily people are able to maintain code they didn’t create, how readily
large refactorings can be made, how often runtime type errors occur (not just
the literal TypeError, but all the things TS can catch, like null checks,
index typing checks, etc) will be quite interesting.

I wish them luck!

One note of concern though: in their design doc they say incremental
compilation is the number one problem and list multi-minute compile times.
That’s huge! I wouldn’t use TS either of it took minutes to compile my
projects. However, I think there’s room for improvement in their tooling if
they took some time to explore what other large TS projects do instead of just
giving up on it entirely —- VSCode for instance has incremental compilation in
hundreds of ms or less.

~~~
smhmd
What a measured response!

------
searchableguy
They should just use deno to run their setup, there would be no compilation if
they did that. ;)

Someone is trying to rewrite tsc in rust for speed up here -
[https://github.com/swc-project/swc](https://github.com/swc-project/swc)

Cool project for runtime checking with ts - [https://github.com/gcanti/io-
ts](https://github.com/gcanti/io-ts)

Edit: Remove unmaintained runtime type checking library.

~~~
wereHamster
Instead of ts-runtime, use io-ts ([https://github.com/gcanti/io-
ts](https://github.com/gcanti/io-ts)). That one is actually maintained, unlike
ts-runtime!

------
mirekrusin
I found sweet spot for myself - flow with types in comments. As weird as it
sounds it works for me on quite complex projects very well. Unlike typescript,
which is language transpiler like coffeescript - flow is just typechecker with
guarantee that after stripping types the output is valid js. It wouldn't work
with ts, which generates runtime code ie. enums etc. Very good type inference
means types appear as type declarations and when declaring functions and
pretty much nowhere else. The code has interesting haskell'ish feel to it, ie.
most of the code looks something like this:

    
    
      const ofId /*: (Sql, number) => Promise<User> */ =
        (sql, id) =>
          ...
    

I'm very happy with it after using it on quite complex projects, writing
libraries (ie. functional combinators for parsers, assertions/runtime types,
template sql generators; and the rest from apis, business logic to anything
that is needed).

Lack of libdefs is not a huge problem in my case. I have strong preference for
shallow or no dependencies in projects and for things I use 3rd party code
there are types or were converted from ts or simply added. Better support
would help here but it was not a deal breaker.

Code editor support is not as good as ts but it does the job.

Another interesting effect is that arbitrarily deep npm linking is so much
easier, the code is just js, doesn't need transpilation step, can be edited as
is; I'm free to use any directory structure, ie. I often use root directory to
drop files, they have natural require/import paths, no configuration etc.

For me, it's a joy to code like this.

~~~
emptysea
typescript also supports type checking js code:
[https://www.typescriptlang.org/docs/handbook/type-
checking-j...](https://www.typescriptlang.org/docs/handbook/type-checking-
javascript-files.html)

I've found this very useful for gradually migrating a node.js project to a
more maintainable state. Types also mean autocomplete works!

Additionally since it's typescript we can download the `@types/` packages for
our dependencies and get type checking for those as well.

~~~
mirekrusin
You can't do too many things with jsdoc, can you? Ie. generics are not
supported or basic things like importing types from other file, right?
Ergonomy/verbosity/look and feel of those types in jsdoc is a bit poor IMHO as
well. It's absolutely not the same thing. With flow you get the whole flow,
with jsdoc it seems some scraps of typechecking. Am I wrong?

~~~
emptysea
Generics are supported via `@template`
[https://www.typescriptlang.org/docs/handbook/type-
checking-j...](https://www.typescriptlang.org/docs/handbook/type-checking-
javascript-files.html#template)

types can be imported either explicitly via `require()` or via the `@type
{import("foo").Bar}`

There are definitely some limitations and caveats, like `Object` being aliased
to `any` (I think this is being changed in a new version), but it's still way
better than untyped JS, and having typescript integration is nice since our
devs are already using typescript in other places.

Can even using things like [https://github.com/typescript-eslint/typescript-
eslint](https://github.com/typescript-eslint/typescript-eslint)

Flow is both more advanced and faster than Typescript, but the community isn't
as large, so Typescript continues to gain marketshare

~~~
mirekrusin
If it supports many constructs, why they don't switch to using it in deno?

~~~
vimslayer
I assume most of the minutes-long compile times they are running into are
because of type checking. Moving types to comments wouldn't help that.

I don't konow why they aren't separating type checking and dev builds from
each other, but there is just absolutely no way simple TS to modern JS (no
compiling to old ES5) conversion would take that long for a 10k LOC project,
it must be the type checking. I'm using TS through Babel and it has been a
breeze for much larger projects than that. Babel just strips away the TS types
and we do type checks via editor integration and a separate CI step. Can't
recommend this setup enough.

~~~
mirekrusin
It's not only compile times, it's also runtime code it generates and issues it
creates in some cases, article mentions it.

------
zdragnar
> It’s worth mentioning that Deno will stop using TypeScript only for the
> internal Deno code: the Deno user code will still be in TypeScript and thus
> type checked.

------
devit
It seems it might be an issue with their development abilities or problem-
solving motivation:

1\. It seems that they write a ".d.ts" file manually in addition to using
TypeScript for the code. This is dumb, since TypeScript generates the
declarations automatically. However, for them "it was too much overhead and
complexity when we attempted it before", which caused them to give up, a very
dubious course of action.

2\. They claim that changes take minutes to recompile, but TypeScript can
compile incrementally, so this shouldn't happen assuming they are organizing
their code properly. Also, you can just translate without type checking, which
is no worse than using JavaScript instead.

3\. They claim that "having two Body classes is obviously wrong" (?!). Of
course having two classes with the same name in different namespaces/packages
is perfectly fine in properly designed languages (including both JavaScript
and TypeScript). Their "Header" shadowing problem also might be due to a lack
of understanding of namespaces.

4\. They seem to conflate JavaScript vs TypeScript with single file vs
multiple files. Of course you can have a single TypeScript file or you can
have multiple JavaScript files and bundle them with any JS bundler or just
concatenate them.

Given that their codebase seems to be complex according to their compile time
claims and that they don't seem particularly skilled given their claims, using
a type-deficient language will most likely result in software full of bugs.

~~~
war1025
> 2\. They claim that changes take minutes to recompile, but TypeScript can
> compile incrementally, so this shouldn't happen assuming they are organizing
> their code properly. Also, you can just translate without type checking,
> which is no worse than using JavaScript instead.

Interested to know how you're actually supposed to do this. I don't do much
web development, but the few times I've had to dive into our typescript code
at work, I end up just modifying the compiled javascript to debug things
because the compile loop is painfully slow.

~~~
Kaze404
It's a relatively new thing

[https://www.typescriptlang.org/docs/handbook/release-
notes/t...](https://www.typescriptlang.org/docs/handbook/release-
notes/typescript-3-4.html#faster-subsequent-builds-with-the---incremental-
flag)

------
eatonphil
I don't remotely see TypeScript as the end state of statically typed
JavaScript. I think it was the first major project to prove how static typing
could work and benefit browser applications. Flow and TypeScript are just the
first generation. In the future I expect the type system to be integrated with
the runtime. While there are projects that give you this (Elm, Reason,
Bridge.net, Fable, etc.), they are nowhere near as universal as TypeScript nor
is that really their aim.

~~~
searchableguy
I am a newbie reason user. I like the language and ocaml ecosystem but it is
_just a bit_ of a pain to do anything practical with it. Soon you are writing
a lot of js in reason. Compared to typescript, js and reason mixed code stings
like a sharp contrast between sun and moon.

Until those languages make themselves feel just like js or completely remove
excessive js interlop, they won't be as mainstream.

~~~
kqr
Huh, I don't share your experience at all. I maintain an F#-and-JS application
and I'm constantly surprised by how well interpretation works. You literally
just import F# code in JavaScript and use it, as well as the other way around.

Sure, if you want to make maximal use of the strong typing of F#, you'll have
to annotate JS data as it comes in, but that is necessary complexity, not
incidental. And if you're happy with having your F# code "dynamically typed",
there's zero ceremony around importing JS stuff.

------
root_axis
> _I never have the class of bugs in my projects that people seem to laud
> about typing to solve. It’s kind of ridiculous_

You do have that class of bug. That's like a cpp programmer saying they don't
need smart-pointers because they never introduce memory leak bugs. You're a
human.

------
brown9-2
> One of the issues mentioned is that they ended up with duplicate independent
> Body classes in two locations

... choice of programming languages is irrelevant here.

------
nathancahill
Needs "internally" at the end of the title.

------
pvg
Discussion from two weeks ago:
[https://news.ycombinator.com/item?id=23462506](https://news.ycombinator.com/item?id=23462506)

------
koolba
Why remove it entirely rather than split off compilation and type checking?
I’m not familiar with the Deno codebase, but a similar problem with large
webpack projects is solved by having the type checking be an async process.
This gives the best of both worlds as you transpiling alone is near instant.

~~~
anonymousCar
As other's have pointed out, it really sounds like the deno devs were
unfamiliar with what's available with build options for typescript. An
unanswered question everyone is asking, why do they handwrite the .d.ts that
can be autogenerated?

------
IBCNU
I used Typescript for 2 years, and I'm happy to report I'm dropping it and
encouraging my team to do the same. Types are for compilers, not people, and
personally I think there's more disadvantages than advantages re: time.

~~~
qayxc
> Types are for compilers, not people, and personally I think there's more
> disadvantages than advantages

The Haskell community strongly disagrees...

~~~
verdagon
I dont know Haskell that well, but I thought it had strong static typing?

Though, Haskell figures out the types for you, instead of you typing them in,
maybe thats a big difference. In Haskell, do you find you have to think about
the types anyway, or can you code it like you would clojure?

~~~
IBCNU
I come from a clojure background, maybe that's why I don't enjoy TS. I find
that large projects, so much code is un-necessary, people spend a lot of time
troubleshooting types instead of building functionality. Of course it depends
on the project. Social security #'s is a different scenario than something
like a game or frivolous retail...

------
RivieraKid
I wish Dart was more popular as a JS alternative. I've been using it recently
it's really surprisingly productive and fun.

~~~
heavyset_go
Does Dart still allow you to compile to JS or was that feature dropped?

~~~
Rapzid
It must; the SASS reference implementation is written in Dart and the npm
package is transpired from that.

------
pjmlp
So it happens again, yet another project discovers that whatever improvements
a guest language brings into a platform, using it also has its costs versus
using the main language of the platform.

------
fbn79
This is a great victory for Ecmascript. Typescript is a great hinting support
language, I use it with JsDoc to check my (not transpired, vanilla js) code.
But it cannot replace JavaScript and is not a JavaScript superset. I think If
anyone what to accept the drawbacks of have transpiration of source files can
choose better alternative to typescript.

------
smhmd
Everyone is drawing conclusions without much context. Read the design doc[0].

[0]:
[https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...](https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview?pru=AAABcrrKL5k*nQ4LS569NsRRAce2BVanXw#)

------
holtwick
I can fully understand that an additional tool layer can cause additional
problems, but static type checking is a large quality win for large projects.
There are workarounds to achieve similar results:

(1) Use a faster bundler like esbuild, here vite's similar considerations [1]

(2) Use Flow [2] and just strip it away before distribution like this Babel
module [3]

\---

[1]
[https://github.com/vitejs/vite#typescript](https://github.com/vitejs/vite#typescript)

[2] [https://flow.org/](https://flow.org/)

[3] [https://babeljs.io/docs/en/babel-plugin-transform-flow-
strip...](https://babeljs.io/docs/en/babel-plugin-transform-flow-strip-types)

------
k__
"Always bet on JavaScript" holds true, I guess.

------
thayne
There are tools to transpile typescript only, without doing typechecking,
which dramatically reduces "compile time." It's very useful for a quick
development iteration cycle, and then do a full type checking pass before
merging and during CI.

------
zvmxczxvmcz
I'm doing a medium/large project in Coffeescript 2 and it's totally awesome.
Rarely a type related bug and I'm progressing waaay faster than having to deal
with TS in my way.

But for anyone enjoying to specify their types in detail, have fun!

~~~
holler
wow that’s cool to hear! I read about coffee 2 awhile ago and then heard
nothing of it. I used to love coffeescript, arguably more than vanilla js, but
forces that be led me to move on.

are you working with a team? if so was it easy to get buy-in?

------
hakcermani
Was using JS for about 6 yrs now and decided will start using TS for a new
Node.js project. Admitted it has its warts ... hit my first bottleneck
rightaway when parsing the request query param. TS Express bindings declare it
as string | string[] | ParsedQs | ParsedQs[]. Ok extract it 'as' string and
move on. But I find as I am using it more and more it is getting better (or I
am getting more disciplined!) .. maybe I am reading this wrong re the long
compile time reported, could the code not be broken into modules so the
compile is more isolated ??

~~~
emptysea
just a heads up, casting `as string` isn't safe since the request param could
turn out to be an array.

If the request ends up with the query param as an array, there isn't a runtime
to validate the cast and now the variable is typed as `string` but is actually
`string[]`.

I think a safer approach is to use a validation library or refine the type
with an if stmt and returning an error when it isn't a string.

I use the following lint to prevent all casts except `as const`:
[https://github.com/typescript-eslint/typescript-
eslint/blob/...](https://github.com/typescript-eslint/typescript-
eslint/blob/master/packages/eslint-plugin/docs/rules/consistent-type-
assertions.md)

~~~
hakcermani
Thanks for the headsup. I did realize that. It was a specific case of pulling
a username from the query .. checking out the library ..

------
gjpowell
It seems weird to ask other projects to use Typescript when running on Deno
when Deno isn't using typescript internally? If you're the Deno team wouldn't
you want to dogfood Typescript?

~~~
hashbig
Different use cases = different technologies.

------
Peteris
This seems to lend more credit to ReasonML. Compile times are faster and it
doesn't bring the associated complexity of object types while still retaining
the benefits of static typing.

------
chvid
Thank you.

Finally people are speaking out against the madness of TypeScript.

Don't get me wrong. It is a technical achievement to put a static type system
on top of JavaScript. And for libraries, it is useful. It let's the users of
the library get hints and direction from an editor like Visual Studio.

But as a language. It is just not good. No way anyone would end up with a
design like that had it been built from scratch without going through
JavaScript first.

Remember when Java did generics and got flak because of type erasure? Compare
with TypeScript ...

------
WClayFerguson
Using JS instead of TypeScript is very short-sighted and they will regret it,
eventually. Sounds like they got frustrated and gave up.

Their arguments remind me of someone saying they want to use Assembly Language
instead of C++, because assemblers are faster than compilers, or to not have
to worry about memory heap issues, etc.

All you're doing by switching from TS to JS, is trading one set of minor
problems (which are solvable) to a more vast set of even larger problems that
are NOT solvable.

~~~
inimino
Spoken like someone who's never solved problems with medium-to-large scale JS
projects... criticising people who have.

~~~
WClayFerguson
Here's a pretty sizable project I wrote in pure TypeScript:

[https://github.com/Clay-Ferguson/quantizr](https://github.com/Clay-
Ferguson/quantizr)

I have 5 years experience in TS and 20 in JS. Trust me, if you don't yet
understand the value of type-safety, it's only because you haven't lived long
enough yet.

~~~
inimino
I do understand the value, thanks mostly to Haskell. I also know that
(language- or tool-enforced) type safety and type discipline are separable
concerns. I also understand when the former gets in the way, thanks to JS, TS,
Rust, Lisp, and projects large and small, slow and then fast, fast and then
slow, slow and then slow, and fast and then fast.

~~~
WClayFerguson
Every developer, regardless of skill level, makes mistakes and typos. The
beauty of type-safety in TypeScript is that the compiler catches it instantly,
in a way that is simply humanly impossible.

If I misspell something, or provide the wrong argument type to a method, or
have args in wrong order, etc, it's caught instantly.

With JS you can have a typo that causes user malfunctions for YEARS before
being found by a developer and fixed. Any developer who's done many years of
both TS and JS would never in a million years consider going back to JS.
Absolutely out of the question.

~~~
inimino
> Any developer who's done many years of both TS and JS would never in a
> million years consider going back to JS.

Except, apparently, for the topic of this article.

> If I misspell something, or provide the wrong argument type to a method, or
> have args in wrong order, etc, it's caught instantly.

Yes, I've heard the pitch before. I've even given it more than a few times.

Of course, if both of your arguments happen to be 64-bit floats, then the type
system won't help you much if you get them in the wrong order.

However, when you want to change that function to take a closure instead of a
number, the type system can be invisible or it can fight you. Some of us love
the structure that a type system can provide. Some of us, like the one who
started this website we're on now, also appreciate the power of languages that
get out of your way and let you make your own brilliant mistakes. And some of
us can appreciate the beauty of different language designs and approaches, and
try to rise above dogma. Which, if you've been in this line of work for 20+
years, should be you.

~~~
WClayFerguson
> Except, apparently, for the topic of this article.

Well, Deno devs _did_ try to use TypeScript, and just ran into some
challenges, and decided to throw the baby out with the bath water. I've seen
this a lot in my 30yrs exp.: some developer/team runs into problems, gets
frustrated, gives up, and decides the best decision is to _remove_ some
important piece rather than _solve_ the actual problems.

The reason Deno is giving up TypeScript is representative of failure, and
_not_ an indication them wanting JS instead of TS. What they _want_ is TS.

The rest of your reply is just stating some minor imperfections that are a
billion miles from invalidating TS. And yeah, there's a place for JavaScript
still, for small-scale tinkering, or perhaps even prototypes with only a few
hundred lines of code. Any large scale project in JavaScript (not TS) is
simply unfathomable to any modern developer worth his salt.

~~~
inimino
You're a dogmatic true believer, and it's rarely worth arguing with dogmatic
true believers. Just notice that you threw everyone that disagrees with you
(or rather, that comprehends a wider range of circumstances than you do) under
the bus as "not worth [our] salt". That was not the right thing to say.

And you dismiss my reply (including the part where I point out that the
website we are on was first developed in a Lisp) as "some minor
imperfections". It's like you're satirizing the tunnel vision of the
fundamentalist.

And, true to form, you "know" what the deno team wants better than they
themselves do! I hope you can come back to this thread in a year or two with
some perspective.

~~~
WClayFerguson
In the above discussion I focused on the technologies, programming languages,
and the core of the technical issue. You seem to focus on personalities,
feelings, and emotions. To each his own, I guess.

And about me knowing Deno _did_ want to, and _did_ attempt to use TypeScript:
the _way_ I know that is because I _read_ the article, lol. Apparently you did
not.

~~~
inimino
I did read the article, and also the design doc which I linked in my top-level
comment.

The facts are that they started with TypeScript and moved away (for a
particular internal component). The interpretation of that as _wanting_ to use
it and _failing_ is yours. You could just as well see it as having made a
mistake and then realizing it. But all of these _interpretations_ , by those
of us who didn't have to make the choice and weren't there when it was made,
aren't very helpful.

~~~
WClayFerguson
That's correct. They failed to get TypeScript to work. Thanks for reading
that.

------
j1elo
I just hope in 5 years we're not seeing a talk saying that in retrospective,
dropping static types was a huge error... and DoNe is a new project to fix
issues like that!

(I'm just referring to this nice talk about the regretful mistakes done in
Node: [https://youtu.be/M3BM9TB-8yA](https://youtu.be/M3BM9TB-8yA))

------
jeswin
Typescript may not work for all types of applications - in fact there is no
language that does. So picking one project and generalizing it often comes out
of inexperience.

As a counter example, VSCode is easily bigger than the Deno codebase. Again,
that doesn't mean it's good for your project.

------
oliwarner
You know when you say a word over and over again and it starts to lose
meaning?

Well, I didn't have a clue what Deno was before, but now it's barely letters
in a screen. This post says Deno _way_ too much. Deno.

------
mikl
> While TypeScript is sometimes seen as an improved version of JavaScript,
> this case is showing that in fact, it’s not. It has flaws like any other
> language.

This is not a language flaw. It is a tooling problem.

------
burtonator
I've migrated to Typescript and have been using it for about 2 years now.
Maybe 1.5...

TS is the best language I've used. It supports frontend and backend and strict
typing and it's scalable so I can refactor and know that my code still works.

The one thing its not good at is ML where Python is better but that's mostly
because Python has better library support (not language design).

Here's the deal. When dealing with a large amount of code 80% of your dev time
is spent maintaining code - NOT writing new code.

You can save a lot of time now writing new code and not using strict typing.
OR you can spend a little bit of time now, maintaining your types, and save a
MASSIVE amount of time later.

> \- TypeScript compile time when changing files takes several minutes, making
> continuous compiling an excruciatingly slow process

I have a HUGE typescript repo and using a Macbook Pro from 2015...

With --incremental and --watch my build takes like 5 seconds. About 1 minute
on the first build then about 5 seconds after that.

If your build is taking a long time - you're doing something wrong.

> The internal code and runtime TypeScript declarations must be manually kept
> in sync since the TypeScript Compiler isn’t helpful to generate the d.ts
> files

What? How? That doesn't make any sense. You're doing something wrong here. If
all the code is in typescript, you have no additional work to do. If it's in
JS you just have to write your own .d.ts files manually.

Honestly it seems like this team just needs to sit down and understand how
their tools actually work.

The one issue where Typescript DOES kind of suck is when dealing with webpack,
typemaps, and types.

Many older projects just don't publish types and if you rely on them, and they
refuse to publish types, you're going to be in a bit of pain.

You can write your own types though and we've been doing this internally and
for some repos just forking them so it's a bit easier to work with them. They
usually lag on publishing their types.

If you want to avoid all this pain you can just use webpack for your build
system and Typescript for your code. We use lerna to build a multi-module
system with --hoist to avoid duplicate dependencies.

[https://github.com/burtonator/polar-
bookshelf](https://github.com/burtonator/polar-bookshelf)

... is the project we're working on if you want to check it out. Our internal
build system isn't fully published yet as we're in the process of reworking it
but we're open source so you can take a look if you want.

~~~
electrotype
I'm wondering about "\--watch" too... My projects are compiled in the
background, like pretty much _instantly_. The only time I wait is when I
restart the applications.

But I suppose they are aware of this flag.

------
jimbob45
Is there a reason we can ONLY use JavaScript in the browser? The world would
immediately become better if we added a different language compiler on in
instead.

------
wufufufu
Has anyone else experienced these issues? This reads more like product
placement for Deno than a sincere criticism of TS.

~~~
war1025
I've definitely noticed that compiling typescript is slow and extremely
resource hungry. It's amusing to me that our "web" stack is the most resource
intensive part of our entire codebase at work.

A sign of the times I guess that a build system requires 8gb of ram to run.
Could be we're doing something wrong, but from what I understand we're using a
pretty vanilla setup.

~~~
inimino
Unfortunately the state of web dev in 2020 is such that using a vanilla "best
practice" setup is very much doing something wrong.

------
untog
> While TypeScript is sometimes seen as an improved version of JavaScript,
> this case is showing that in fact, it’s not.

Woah, woah, hold on. This case is showing that in the very specific, atypical
case the Deno team are using it in, TypeScript is not the right fit.

I’d rather read something that actually interviews the Deno folks about what
they are doing, the underlying document is a pretty free ranging discussion
and this writeup is making a few assumptions.

~~~
karmakaze
May as well drop tests and code reviews if it feels like it's slowing you
down. For one-person or very small teams who have full context of a'll changes
this can actually work very well. It's with more contributors participating in
a mature project that you'd wish these things weren't dropped. Types can be
added later so it's not like using php and later wishing you'd used Kotlin.

~~~
karmakaze
I'll add a datapoint of an analogous case. I updated a legacy java 1.x
codebase that was running java 6/7 without generics. Having spent a small
amount of effort over a course of months, all the type annotations were
updated. It uncovered exactly one bug. The main improvement is for quickly
gaining context in unfamiliar code and being able to enable warnings for newly
written code without noisy error messages.

------
errantspark
I'm stoked on this change, frankly the TS layer being included in Deno felt
like a mistake from the get-go and I'm glad they've come around on it. I've
seen many transpile-to-JS languages come and go. Javascript is eternal.

(Though I also think TS is a verbose mess made so that enterprise
programmers/managers can feel safe, but even if it was great I still think
this would have been a good choice)

------
nojvek
When Deno initially mentioned they run Typescript directly I was intrigued.
It’s like running GCC every time you want to invoke the script.

That being said I run ts-node all the time with transpile-only and that is
decently fast. Even on production where the minimal cost is incurred once when
loading the module.

As for their problems mentioned on the document. That Header class has a .d.ts
conflict on an interface. That could be solved with having namespaces in .d.ts
or having I prefix for class interfaces. We do this all the time in our
codebase.

I’m not entirely sure why they have two copies of things. The doc doesn’t give
much detail.

If you want things to be fast like nodejs, then the other option is to use
//@ts-check comments on JS files, or with compiler allowJS and checkJS
settings. Webpack checks all their JS.

TSC now also has an option to automatically generate .d.ts from JS files with
jsdoc comments. With declarationOnly compiler flag. Many existing JS projects
already do that.

So TLDR is. You don’t have to ditch Typescript totally. Typescript can purely
just be a checker that you run at CI time and it will work quite well with
existing JS code. Although if you want super strict safety the .ts syntax is
less verbose and nicer to write. Even then transpile only mode is much faster
than running full tsc.

Remember: TS is a superset of JS. All JS is valid typescript. Sometimes we
gotta structure the JS properly and that’s where the issue is rather than the
typesystem.

------
dbnoch
I felt like the article and associated google doc were fishing for reasons to
remove TS until ry finally mentioned "typescript provides an extra 500 lines
and the namespaces make the code harder to reason with (V8 ingests these files
directly)". IMO that was the only solid reason for the change.

------
aogaili
Always bet on Javascript.

------
chadlavi
oh I thought at first that this meant they were dropping _support for_
typescript, not that they were stopping using ts under the hood.

Getting closer to the metal seems good!

------
kumarvvr
HN gods, an off topic question.

Would Deno become the new Node?

Do you see a vibrant ecosystem building around Deno?

What I am interested to know primarily is, is the architecture / stack / goals
and vision that resulted in Deno viable in the long term?

~~~
zodiakzz
Deno's main selling point over Node.js seems to be some dubious sandboxing.
Unlikely to be compelling enough for people to rewrite their applications from
using Node's stdlib to Deno's.

Personally, it makes me cringe to see hard-coded HTTP URLs in source code
files for loading dependencies. They present it like we're stupid for using
package managers all this time. What used to be a simple command line option
(changing a package repo) is now a thousand file edit. Excellent.

------
moogly
Has anyone seen any comments by the TS team on this? Maybe they would be
amenable to helping out if the Deno team contacted them.

~~~
apetrovic
Honestly, what is a meaningful answer when someone blames language for problem
with having two separate classes with the same name?

------
underdeserver
Due respect, these are issues with how the Deno team uses Typescript, not with
the language itself.

> TypeScript compile time when changing files takes several minutes, making
> continuous compiling an excruciatingly slow process

Umm, you can compile single files, and serve them individually. It's no
different from bundling (e.g. with webpack) Javascript.

> The Typescript structure that they’re using in the source files that create
> the actual Deno executable and the user-facing APIs is creating runtime
> performance problems

Then use a better structure?

? TypeScript isn’t proving itself helpful to organize Deno code. On the
contrary, the Deno team is experiencing the opposite effect. One of the issues
mentioned is that they ended up with duplicate independent Body classes in two
locations
[https://github.com/denoland/deno/issues/4748](https://github.com/denoland/deno/issues/4748)

Then consolidate the two classes...? How is the the language's fault?

> The internal code and runtime TypeScript declarations must be manually kept
> in sync since the TypeScript Compiler isn’t helpful to generate the d.ts
> files

Well, it can be. Fix your build rules.

> They’re maintaining two TS compiler hosts: one for the internal Deno code
> and another other for external user code even though both have a similar
> goal

Again, not the language's fault.

\---

We've been using Typescript for a couple of years now, and it's been great. By
trying to do things the right way, it actually _forces_ us to organize our
code better. I think the Deno project would benefit from refactoring their
code to solve their issues, instead of blaming the tools.

~~~
baddox
Your main point seems to be that these problems aren’t the language’s fault.
But I don’t see the Deno team claiming that to be the case. There’s nothing
wrong with choosing a language that works with how your team likes to develop
software, and rejecting a language that doesn’t work well for your team.
Doesn’t need to be anyone’s “fault.”

~~~
erikerikson
It's entirely valid for them to decide they don't want to change their ways.
However, it is frequent that technologies will be rejected because the
requisite learning to understand why and how to best use the technology is not
done. A common example of this (in my observation and ignoring the application
of the technology where it's entirely unnecessary) is NoSql where teams have
attempted to use those databases as they used their relational counterparts
which obviously didn't work because they didn't shift how they were thinking
about using storage and structuring their systems. Anyway, that was how I read
the GPs post, as attempting to note that the Deno team may not have pushed
through the mental shift required to really get the most out of TypeScript.

[edit: not trying to take a stance in support of the GPS post or either side
of this discussion, to be clear]

------
seemslegit
Why Deno ?

~~~
kybernetikos
Deno Deno deno deNo deNodeNodeNo...

~~~
seemslegit
That wasn't a question about the naming.

~~~
kybernetikos
You might need to say a bit more about what it is a question about if you want
an answer.

~~~
seemslegit
"Why X ?" is a common shorthand for "What is the raison d'être of X ?"

~~~
kybernetikos
Well, in all the initial presentations Ryan Dahl gave about Deno, he phrased
it as solving the things he'd come to realise he hated about Node. So that's
what I take as the raison d'être of Deno - taking the lessons he'd learned
from some years mainly coding Go and thinking about what he'd learnt from
Node, and fixing what he could. Here's the classic video on the topic:
[https://www.youtube.com/watch?v=M3BM9TB-8yA](https://www.youtube.com/watch?v=M3BM9TB-8yA)

------
jackjeff
I’m very perplexed about the reasoning.

Aside from the compiling takes time issue, the rest sounds like trolling.

If the code was organized in a way which is inefficient and confusing, I fail
to see why checking types at runtime instead of compile types improves the
structure. It’s a completely separate problem.

------
jbverschoor
Yeah. Same same. Not working, so let’s just fix it by creating another
ecosystem instead of fixing compiletimes etc.

I will refuse deno. Too much ego in JavaScript-land. “Everybody wants to be
like Mike”. Errr Linus... Lowrey

~~~
untog
Deno is made by the guy who made Node. So no change in notoriety there.

------
chmln
> TypeScript compile time when changing files takes several minutes, making
> continuous compiling an excruciatingly slow process

They must be doing something horribly wrong, because tsc takes literally 1
second for my 3KLOC codebase[1] in incremental mode.

[1]
[https://github.com/flatpickr/flatpickr](https://github.com/flatpickr/flatpickr)

------
meowzero
We were actually considering Deno because of its TypeScript support. We have a
sizeable TypeScript codebase written for Node. This will probably make us more
likely to stay in Node.

EDIT: I didn't read the article thoroughly. It looks like they're still
supporting Typescript user code.

~~~
smhmd
In the design doc, you can read this disclaimer:

> Most people don't have the context to understand this narrow technical
> document - it is only applicable to a very particular, very technical
> situation in the internals of Deno. This is not at all a reflection on the
> usefulness of TypeScript in general. It's not a discussion about any
> publicly visible interface in Deno. Deno, of course, will support TypeScript
> forever. A website or server written in TypeScript is a very very different
> type of program than Deno - maybe much more so than novice programmers can
> appreciate - little of Deno is written in TypeScript. The target audience is
> the 5 to 10 people who work on this particular internal system. Please don't
> draw any broader conclusions.

------
cocktailpeanuts
Thank God, I would really appreciate this. The TypeScript usage was the one
thing that I didn't like about Deno.

Why add complexity to a new project which starts from scratch? JavaScript is
good enough and there's no need to make it confusing by adding another layer.

~~~
lowercased
> JavaScript is good enough and there's no need to make it confusing by adding
> another layer.

To some people, JS itself is relatively confusing, and TypeScript reduces that
confusion.

EDIT: And... someone's clarification is saying this is internal framework
code, not userland support for TS. Seems like a non-issue, really. They don't
want to use it, but want to provide support for others to use it in their
projects.

