Deno will stop using TypeScript • Hacker News Board

Re: Deno will stop using TypeScript

#31

Post by devit » Sun, Jun 21, 2020, 3:51 PM UTC

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.

Re: Deno will stop using TypeScript

#32

Post by emptysea » Sun, Jun 21, 2020, 3:51 PM UTC

hakcermani wrote: post #21

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…

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/...

Re: Deno will stop using TypeScript

#33

Post by mimixco » Sun, Jun 21, 2020, 3:51 PM UTC

efficax wrote: post #19

mimixco wrote: post #16

Earlier quoted context omitted.

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.

there's plenty of huge software projects in dynamically typed languages. There are also huge classes of bugs that exist in these projects that a statically typed language completely eliminates! If they're running into trouble from having to have types, it's almost certainly design and architecture issue and does not make me think that deno is going to be a solid project.

I didn't read that types were causing problems. My understanding was TS, itself, was causing problems. Specifically waiting around for it to compile.

Strong typing is from OOPS, itself an optional programming methodology. There are many JS programs that simply access other (JSON) objects directly without going through an interface. In these instances, typing is counterproductive.

One of the beautiful things about JS (and Lisp) is that variables and functions are interchangeable and, the case of JS, both can be accessed directly without worrying about an interface.

Re: Deno will stop using TypeScript

#34

Post by eatonphil » Sun, Jun 21, 2020, 3:52 PM UTC

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.

Re: Deno will stop using TypeScript

#35

Post by searchableguy » Sun, Jun 21, 2020, 3:52 PM UTC

whoisjuan wrote: post #29

halfmatthalfcat wrote: post #15

Earlier quoted context omitted.

You don’t see the benefits of a strongly typed language?

I do. But not for JS in particular. At the end of the day 95% of JS that is written in classic JS and is used in thousands of high-scale projects like that.

I would say for me, typechecking part of ts is less useful than the information it provides me about the project. I can jump in a new project and quickly see what kind of data structures are there, what are the parameters, get really nice intellisense and documentation.

All of this is possible with jsdocs and flow but they are not nearly as powerful as ts and often times verbose. I don't like polluting the comments.

You don't need to use typescript everywhere although the popular zeitgeist will tell you to avoid any or ts-ignore. It's fine to write some parts in ts and others in js. Think of ts as eslint, jsdocs or flow. You don't need to be religious about it. Take its benefits wherever you can or do you think all the other tools are useless as well?

Re: Deno will stop using TypeScript

#36

Post by kd913 » Sun, Jun 21, 2020, 3:53 PM UTC

dtagames wrote: post #25

whoisjuan wrote: post #10

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…

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.

Why is it one or the other? Type errors also certainly occur.

If you eliminate a class of errors by doing so, isn't that still less errors overall?

Re: Deno will stop using TypeScript

#37

Post by austincheney » Sun, Jun 21, 2020, 3:53 PM UTC

echelon wrote: post #14

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…

This is enough reason for me to completely forget Deno. They clearly cannot write code or organize it without using classes, which is the core of their current error. The fact that they would choose that stupidity over the organizational benefits of interfaces and static types is not something I can reconcile.

Re: Deno will stop using TypeScript

#38

Post by jakear » Sun, Jun 21, 2020, 3:54 PM UTC

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.

Re: Deno will stop using TypeScript

#39

Post by karmakaze » Sun, Jun 21, 2020, 3:54 PM UTC

untog wrote: post #5

> 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…

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.

Re: Deno will stop using TypeScript

#40

Post by meowzero » Sun, Jun 21, 2020, 3:55 PM UTC

mimixco wrote: post #16

echelon wrote: post #14

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…

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.

That's appeal to popularity. At least lisp is strongly typed. JS happened to be created first, and the world was stuck with it as Web grew and no other alternatives came out.