
Design Doc: Use JavaScript instead of TypeScript for internal Deno Code - rkrishnaan
https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/edit#heading=h.cx5nx247bag
======
temporallobe
This cones as no surprise to me, as TypeScript is a transpiled language. I
know this is probably an unpopular opinion at HN, but I am a huge supporter of
plain old JavaScript and have never really seen the benefits of DSLs like
this. Coffeescript was especially pointless to me when I had to use it on a
project. My reasons are simple: debugging becomes much more difficult when you
add a layer of abstraction. It compiles to JavaScript anyway, and sometimes it
does so in very odd ways that makes it difficult to understand the
relationship between what you wrote and what it produced. IMO, straight
JavaScript is more than adequate for most scenarios if you know the language
well enough, especially with the powerful features built into the more recent
versions. In my 20 years as a (mostly) front-end developer, I have not heard
any convincing argument in favor of a transpiled JavaScript pseudo-language.
Of course there are advantages, but most of these can be solved with better
code organization and architecture.

I will say I don’t quite feel as strongly about CSS pre-processors like SCSS,
which I really enjoy, however I still prefer plain old CSS for the same basic
reasons.

~~~
Agent766
My team started development of a React SPA. It was initially written with jsx.
As we're starting to implement more, I'm finding more and more cases where the
js code was wrong; property names that don't exist, wrong types being passed
around, and non-existent props being used.

How do you suggest addressing this in a 10 dev team when developing in js?

~~~
thegreatpeter
Check out [https://reasonml.org](https://reasonml.org) \- created by Jordan
Walke, the creator of React. Reason offers the best of both worlds - type
safety without getting in the way and faster JS than what you'd write by hand.

~~~
searchableguy
As much as I would shill reasonml. Think before you adopt - it still requires
more upfront work than typescript (you will have to write bindings for most
things even popular stuff. You might end up fighting it too.) but as parent
said, you get more expressiveness (algebraic types, powerful pattern matching,
immutability, partial application etc) and sound type system with a speedup on
both transpile times and actual run time.

You can leverage ocaml/ml as well as js ecosystem. Mix different files and
syntax.

Bsb is also faster than tsc.

~~~
giantDinosaur
To add to this, there are at least 3-4 pain points which... are just a pain
with ReasonML, that can kinda counteract its type system.

\- non-standard ordering of arguments between belt/standard library

\- Ocaml's standard library actually generally avoiding the Option/Result
type, in preference of exceptions, which is unexpected and a pain since it's
an ML.

\- package management involves manually adding things to the bsconfig (has
this changed?)

\- things randomly break between relatively minor Bucklescript versions, they
broke something pretty important in like a .x release when I was messing
around with it

\- server side isn't good. It technically works but all the bindings are old
or terribly documented, and you never really know if it's not going to blow up
at some point.

Otherwise, I actually quite like it! None of those are actual core language
complaints.

~~~
mbrock
The way it deals with async/await also seems pretty tedious.

------
esperent
It's important not to read this as a critique of Typescript. Rather, it's a
note that it's not a good fit for this one particular performance critical
piece of code.

It sounds like they are discussing the central code runner of deno. I would
have expected this to be compiled to JS in any case, but it seems like they
are compiling the runner, then compiling user code. Of course that's slow.
It's also not representative of a normal TS use case, which is unfortunate
because I expect we'll see this discussion shared all over the web as an
argument for dropping TS.

~~~
_bxg1
a) Any static type system has things that it can't express elegantly or maybe
at all. In my experience, the more "meta" your project is, the more you're
going to run up against these bounds. So it makes sense that this could be the
wrong use-case for TypeScript.

b) There is a valid, broader point to be made here that while TypeScript
_itself_ doesn't carry any runtime overhead (by design), it can in some cases
force you to contort your code, so that it can be type-verified, in ways that
have a runtime impact. In my experience (a couple of years writing TypeScript
professionally) this is uncommon and not a huge problem, but does happen
occasionally. It's also worth noting that the vast majority of these cases can
be papered-over using //@ts-ignore, "as" casting, etc. if necessary.

------
eatonphil
I started using Evan Wallace's TypeScript [0] implementation (and bundler)
written in Go and it's pretty fast (there are benchmarks too). I'm surprised
this kind of thing is not something Deno's pursuing. Having used esbuild I see
the future of web tooling as not necessarily written in (or compiled to)
JavaScript.

[0] [https://github.com/evanw/esbuild](https://github.com/evanw/esbuild)

~~~
uasi
They are considering switching from tsc to a TypeScript compiler written in
Rust[0][1], and `deno fmt` subcommand already uses it internally.

[0]
[https://github.com/denoland/deno/issues/5432](https://github.com/denoland/deno/issues/5432)
[1] [https://github.com/swc-project/swc](https://github.com/swc-project/swc)

~~~
yawaramin
swc is not a TypeScript compiler, it doesn't do any typchecking. It just
strips out types and outputs JavaScript.

------
dfabulich
JS engines should be able to ignore TS annotations, out of the box.
[https://github.com/samuelgoto/proposal-pluggable-
types](https://github.com/samuelgoto/proposal-pluggable-types)

~~~
CGamesPlay
It's interesting, I wonder why the proposal doesn't talk about leaving TS code
and simply ignoring the syntax using something like babel to preprocess it out
(without needing to run the type checking outside of CI).

~~~
mikewhy
tsc can also do that, but I think there's something else here.

I'm not really sure what this post is getting at. I trust Ry knows the issue
better, but from what I've read I have the same questions as everyone else
here:

\- Why is Deno defining interfaces and classes like that?

\- Will this mean losing type checking in projects using deno?

\- Why not strip types in development and only check at commit/push/build
times?

------
untog
This is quite difficult to make sense of beyond the initial description so I’m
not sure about the current status. But it would be a shame to lose valuable
type info because compile times are long... isn’t there a tool out there that
does nothing except strip types from TS files? If you used that you could get
quick rebuilds when developing but retain type checking when you do a full
build.

EDIT: Sucrase! That’s what I was thinking of:

[https://github.com/alangpierce/sucrase#transforms](https://github.com/alangpierce/sucrase#transforms)

~~~
alangpierce
Hi, Sucrase author here. I'm also having a hard time understanding the
rationale here, but it looks like it's maybe a nuance around self-hosting. In
general, for any regular TS project, I'd certainly recommend decoupling
typecheck and transpile as separate operations and running typecheck alongside
lint. IMO one of the nicest things about TypeScript is that you can run your
code before you've figured out how to get the types to check out.

They do consider swc (which has roughly the game goal as Sucrase) in the
conversation, so it seems like there's some consideration of a transpile-only
approach. TypeScript's built-in `transpileModule` is probably the most
reliable and officially-supported way to get the equivalent, and is much
faster than running TSC with typechecking.

------
mcintyre1994
Does this mean that their standard lib won’t have types, in the same way that
Node’s doesn’t? I’m not entirely sure how it works but VSCode seems to have
types for the Node standard library somehow and it’s really helpful. I assume
that’s Microsoft’s work so does this basically mean that unless Microsoft do
the same thing for Deno it’ll be a worse editing experience compared to Node
in VSCode?

Or would the Typescript internals not have been available in that way anyway?
It just seems hard to compete on ease of use with Node in VSCode without
whatever magic is making the editor so smart - which I assume is something to
do with Typescript.

~~~
davnicwil
No - you don't have to write the code in Typescript to get types - you can
manually write type definitions for Javascript code.

In this case it would be even easier since it's already in Typescript and
would presumably be a straight port, so all of those type definitions can be
automatically generated from the existing code and will just work.

~~~
mcintyre1994
I was going by this quote:

> ry So - to make a long story short - we're removing the types from internal
> code and making it pure JS this reduces complexity and helps us ship a
> faster product. I acknowledge it's unfortunate to lose the type information,
> but it's really masking larger problems. It's not going to happen
> immediately tho. We have a bit more work to figure out how exactly it should
> be done. It's not going to be one big 9000 line file either. But it might
> not be ES modules. depending on if we can make that work or not.

The “lose the type information” there suggested to me that they’re not
planning to ship them at all.

~~~
davnicwil
I think that's in reference to losing the type information for their own
development of that code. I'm almost certain they don't mean they will stop
shipping type definitions for the public APIs.

------
kbenson
This doesn't seem all that odd. I read this as a temporary solution to the
fact that there's some real problems that TypeScript causes for the way their
project is laid out and used with regard to certain types of introspection
(noting duplicate classes) and performance (it's damn slow).

It's like them running the TypeScript compiler to generate one large JS file
and using that intermediate as what people build against instead of the
original TypeScript source. I'm not sure if this is what they're actually
doing (or if they're somewhat manually doing the equivalent of it), but as a
hopefully short-term workaround that allows them to solve the problems, that
doesn't seem too bad (but it does possibly highlight some TypeScript
problems).

Even if they actually move to a large core JS file that is the active
development target, as long as they keep track of the TypeScript specifics
(and don't code themselves into a corner assuming something works that they
find much later errors), it may not necessarily be hard to go back to
TypeScript from that (possibly with a lot of it automated with a lot of
structured comments).

~~~
esprehn
Part of what's slow is that they're type checking and compiling the code at
the same time. Best practice for a project of this size would be to run type
checking as a unit test and only transpile during the build. An incremental
type check is also super fast, it's possible they don't have caching setup.

To me this reads more like a list of issues in the deno architecture, and how
they integrated TypeScript, than any issue with TypeScript itself.

------
yashap
This makes me generally curious about Deno’s architecture/design. Anyone known
much about it? Would love to learn more!

I know the JS engine is V8 (C++), and the rest is Rust and TypeScript, but
which parts are Rust, which parts TypeScript? Why 2 languages? Is it mostly
Rust, mostly TypeScript, or a bit of both?

Also, what are the hardest problems that Deno solves internally? Like if
you’re working on Deno, are you mostly working on ... the dependency
resolution/package management? Automatic compilation of user TypeScript code?
The standard library? Something else entirely?

------
MBCook
What is ‘deno code’?

~~~
mikewhy
As mentioned, Deno is the new project from the creator of NodeJS.

Here, as far as I can tell, "Deno code" specifically related to the code
shipped to the developer / user using Deno, the compiler / runtime.

~~~
csours
deno

de no

no de

node

heh.

------
ecares
So, you mean the people who were supposed to make the best choices to fix
server-side JavaScript with the ultimate knowledge of what's best just
realized that some of their pre-made opinions are actually not-silver bullet?

Shocking

------
errantspark
This is amazing. I'm legitimately excited for Deno, I will start migrating all
of my dependency-less node over soon.

------
fearingreprisal
At what point are people going to just admit that implementing applications in
Javascript outside the browser is a poor idea? The ecosystem has been in this
poor state for years. It's not like the ecosystem is getting worse. This is
the best it's ever been, and it's still horrible. There's so many better, more
mature alternatives with much better ecosystems: Python, Java, C#, Ruby, Go,
Haskell, Perl... The list goes on.

~~~
hn_throwaway_99
Your comment is somewhat incomprehensible, because this article is not about
building end user applications in Typescript. It's about building _the
container itself_ in Typescript. I switched to Node from Java a couple years
ago, and to Typescript within the past year, and I have never been on a team
that has had this level of productivity.

~~~
fearingreprisal
What part of it couldn't you comprehend? I understand what the article is
saying. I'm talking about the dysfunctional Node.js ecosystem, which includes
Typescript.

In response to your personal experience, I'll share my own: I switched from
C++ to Java, to .net, to Node.js, to Typescript. Working on Node/TS I have
never been on a team that wastes so much time fixing silly problems that a
better language would simply not allow to happen in the first place. I have
also never worked on a team that spends so much time dealing with issues in
poorly written community packages, or arguing with package maintainers who
could never in a million years pass a technical skills test at the company I
work for.

~~~
zdragnar
> arguing with package maintainers who could never in a million years pass a
> technical skills test at the company I work for.

So why on earth are you using their packages?

------
Der_Einzige
Aw, the famous game design YouTube channel "Design doc" is nowhere to be found
here. I thought he was pivoting to dev advice...

