Live data from Hacker News

Deno will stop using TypeScript

startfunction.com

341–350 of 359 posts

Re: Deno will stop using TypeScript

#341
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.

Re: Deno will stop using TypeScript

#342

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... First paragragh of that document: > Update June 10 2020: I saw that this design doc was being discussed mor…

I mean, the design doc is wrong. Instead of

  Object.defineProperty(HeaderImpl, "name", { value: "Header" });
you can just use

  export let Header = class Header { }
to avoid creating a conflict between the header type declaration and this header implementation, since that way the type will be locally constrained to the class expression and only the variable gets out.

> Who knows if this kicks Header out of some optimization path in V8

It doesn't.

---

Forgive me for being suspicious of the whole thing because a couple of the rationalizations don't make sense, I'm sure there are some valid points raised there.

Re: Deno will stop using TypeScript

#343
post #321

Earlier quoted context omitted.

That quote is not really relevant: TS is as functional as JS.

Not really in the same way, though. I mentioned that paradigms of functional programming languages like Clojure translate well to JavaScript. They do not to typescript, because it is a statically typed language. If you are interested in why are you dynamically typed language has benefits for functional programming, please see this talk: https://youtu.be/oytL881p-nQ

That talk is not about the benefits of dynamically typed languages over statically typed languages. Do you have a specific point in mind?

Re: Deno will stop using TypeScript

#344
post #168

Earlier quoted context omitted.

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.

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

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.

Re: Deno will stop using TypeScript

#345

Earlier quoted context omitted.

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

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

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.

Re: Deno will stop using TypeScript

#347

Earlier quoted context omitted.

That wasn't a question about the naming.

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

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

Re: Deno will stop using TypeScript

#348
post #134

Earlier quoted context omitted.

> Types are for compilers, not people, and personally I think there's more disadvantages than advantages The Haskell community strongly disagrees...

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?

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

Re: Deno will stop using TypeScript

#349
post #91

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.

> Types are for compilers, not people, and personally I think there's more disadvantages than advantages re: time. Hard disagree. Types are for people. They're for people to tell compilers what to tell people. Which is incredibly useful. They are first and foremost a communication and code-navigation/wayfinding tool—for people. As for all this extra time some folks keep complaining about, we must be using TypeScript…

My experience is by definition anecdotal, but what I've found is as the team grows more and more work seems to focus on defining the types, futzing with the types, talking about the types instead of talking about features. I come from a Clojure/script background so I suppose I'm trying to say if (in building UI's) if you bake in strong immutability and a functional approach (like re-frame... but JS) types, to me, become less and less of a concern. Of course it's highly dependent on the business requirements.

Re: Deno will stop using TypeScript

#350
post #136

Earlier quoted context omitted.

What is it about a large team that causes it to stop offering an advantage? If anything I’d expect it to be more useful as a code base grows in complexity

Agreed, as the team gets larger and an given individual doesn’t necessarily know how everything works from memory the need to rely on the compiler and type safety should grow.

I guess it tends to be superseded by other forms of rot, people writing a bunch of tests that aren't against the critical path, money going down the drain... I agree, it _seems_ like what you say is true. I'm not a computer scientist, I'm just saying I've tried TS at a couple of shops, and as they team grows TS slows us down. Maybe it's just stochastic or random, but at the end of the day there's no academic "proof" types improve developer productivity. The only thing that sort of gets me is how everyone sort of assumes TS is 'best practice' but there's really no evidence besides gut feeling. My gut feeling is now telling me TS is not beneficial... I'd love to play devils advocate against my own position so feel free to tear me apart...
Post reply on HN