by diablo1 on 6/21/20, 3:24 PM with 343 comments
by inimino on 6/21/20, 6:05 PM
[1]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...
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.
by whoisjuan on 6/21/20, 3:36 PM
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.
by echelon on 6/21/20, 3:38 PM
> 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.
by vimslayer on 6/21/20, 3:36 PM
This post adds little to what's already said there.
by diffrinse on 6/21/20, 5:33 PM
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.
by jakear on 6/21/20, 3:54 PM
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.
by searchableguy on 6/21/20, 3:37 PM
Someone is trying to rewrite tsc in rust for speed up here - https://github.com/swc-project/swc
Cool project for runtime checking with ts - https://github.com/gcanti/io-ts
Edit: Remove unmaintained runtime type checking library.
by mirekrusin on 6/21/20, 7:41 PM
const ofId /*: (Sql, number) => Promise<User> */ =
(sql, id) =>
...
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.
by zdragnar on 6/21/20, 3:34 PM
by devit on 6/21/20, 3:51 PM
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.
by eatonphil on 6/21/20, 3:52 PM
by root_axis on 6/21/20, 7:21 PM
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.
by brown9-2 on 6/21/20, 3:58 PM
... choice of programming languages is irrelevant here.
by nathancahill on 6/21/20, 3:42 PM
by pvg on 6/21/20, 4:47 PM
by koolba on 6/21/20, 3:58 PM
by IBCNU on 6/21/20, 4:34 PM
by RivieraKid on 6/21/20, 4:10 PM
by pjmlp on 6/21/20, 5:24 PM
by WClayFerguson on 6/21/20, 4:19 PM
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.
by fbn79 on 6/21/20, 5:00 PM
by smhmd on 6/21/20, 4:28 PM
[0]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...
by holtwick on 6/22/20, 7:16 AM
(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
[3] https://babeljs.io/docs/en/babel-plugin-transform-flow-strip...
by k__ on 6/21/20, 4:36 PM
by thayne on 6/22/20, 1:10 AM
by zvmxczxvmcz on 6/21/20, 4:00 PM
But for anyone enjoying to specify their types in detail, have fun!
by hakcermani on 6/21/20, 3:43 PM
by gjpowell on 6/21/20, 4:49 PM
by Peteris on 6/21/20, 4:44 PM
by chvid on 6/21/20, 4:45 PM
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 ...
by j1elo on 6/21/20, 4:50 PM
(I'm just referring to this nice talk about the regretful mistakes done in Node: https://youtu.be/M3BM9TB-8yA)
by jeswin on 6/21/20, 4:17 PM
As a counter example, VSCode is easily bigger than the Deno codebase. Again, that doesn't mean it's good for your project.
by oliwarner on 6/21/20, 6:27 PM
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.
by mikl on 6/21/20, 8:55 PM
This is not a language flaw. It is a tooling problem.
by burtonator on 6/21/20, 4:22 PM
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
... 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.
by jimbob45 on 6/21/20, 9:48 PM
by wufufufu on 6/21/20, 3:46 PM
by untog on 6/21/20, 3:33 PM
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.
by errantspark on 6/21/20, 7:23 PM
(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)
by nojvek on 6/22/20, 3:12 PM
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.
by dbnoch on 6/21/20, 9:18 PM
by aogaili on 6/21/20, 5:43 PM
by chadlavi on 6/21/20, 7:10 PM
Getting closer to the metal seems good!
by kumarvvr on 6/21/20, 5:01 PM
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?
by moogly on 6/21/20, 4:08 PM
by underdeserver on 6/21/20, 3:58 PM
> 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
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.
by seemslegit on 6/21/20, 4:46 PM
by jackjeff on 6/21/20, 4:17 PM
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.
by jbverschoor on 6/21/20, 3:32 PM
I will refuse deno. Too much ego in JavaScript-land. “Everybody wants to be like Mike”. Errr Linus... Lowrey
by chmln on 6/21/20, 4:26 PM
They must be doing something horribly wrong, because tsc takes literally 1 second for my 3KLOC codebase[1] in incremental mode.
by meowzero on 6/21/20, 4:21 PM
EDIT: I didn't read the article thoroughly. It looks like they're still supporting Typescript user code.
by cocktailpeanuts on 6/21/20, 3:32 PM
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.