Live data from Hacker News

Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

docs.google.com

101–110 of 115 posts

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#101

Earlier quoted context omitted.

Yes, you have the illusion of type safety but all you need is a slightly different JSON from an API to realize that typescript isn't that interesting.

TypeScript is better at documenting intent for other developers (where "other developers" includes your future self) than either tests or comments/readmes. It just about entirely takes care of the "what" so comments and docs can be reserved for the "why". It's an outstanding communication tool and recording what it does, at function/method boundaries at least, is something you should be doing anyway, so might as well…

I agree it's important to document. But if you need types to understand what's the code doing, there is a problem.

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#102

Earlier quoted context omitted.

TypeScript is better at documenting intent for other developers (where "other developers" includes your future self) than either tests or comments/readmes. It just about entirely takes care of the "what" so comments and docs can be reserved for the "why". It's an outstanding communication tool and recording what it does, at function/method boundaries at least, is something you should be doing anyway, so might as well…

I agree it's important to document. But if you need types to understand what's the code doing, there is a problem.

It's less "need" and "does the same thing but far more efficiently and can't rot because a machine makes sure it's correct".

I like letting my tools do stuff for me. If a tool can go look up what arguments this function expects, and their types, and tell me that, rather than my having to go check, and then also warn me if I typo one of them, then also take me straight to the definition of the function if I decide I want to read it, without my having to go hunt it down manually, all at zero cost (again, these things should be documented anyway), then why the hell not?

[EDIT] I guess I just don't understand why people consider it burdensome. You probably ought to know your function's going to take a string. Is it that hard to type "string" in the signature? You're gonna have to figure out what it's supposed to return—when you do, write it down. It's a little more work for more complex structures but it still amounts to typing out things you already have to think through anyway, and the more complex the more important it'd be to record that somewhere, so may as well be machine-readable type information. In return, when you accidentally try to treat your string like a number you'll immediately know you've missed a step, you'll get comprehensive autocomplete on hashes and classes and such, jump-to-definition, instant typo-spotting, automatic refactoring, and so on, and you can hand it over to someone else and they'll get those same things, instantly. The payoff is 10x, at least.

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#103

Earlier quoted context omitted.

Typescript has been around since 2012. Going by the quote, it is likely to still be around in the next 8 years.

TypeScript has been around since 2012, and it has since won in the marketplace of ideas, becoming the single most popular language to transpile to ES# and beating a well-resourced competitor in Flow. The type war was "won" by TypeScript, and I expect it's just a matter of time before types make it into the standard. The benefit of winning so completely and having such enormous popularity is that its ideas are very li…

> just a matter of time before types make it into the standard

I hope so too. TypeScript has done so many things right in its design and implementation - starting from Anders Hejlsberg, with expertise in creating numerous languages; backward compatibility to allow gradual and seamless migration from JS to TS; structural typing; editor/IDE integration via language server; good documentation; corporate backing (maybe not necessary, but like React, I think it was a big factor in its wide adoption).

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#104
post #62

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

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 [1] https://github.com/swc-project/swc

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

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#105

Earlier quoted context omitted.

I think there is a way to get all of the "good parts" of Typescript, mainly type checking, without introducing the bad, mainly transpiling. I recently started just running Typescript on Javascript files, where all of the types are specified via JSDocs. It was a refreshing experience, and I highly recommend. The Typescript website[1] has pretty good documentation for it. [1]: https://www.typescriptlang.org/docs/handbo…

Unfortunately their jsdoc stuff only exposes a subset of their typing capabilities, so you're leaving some advanced type goodies on the table.

They've been adding features on every release for at least a couple releases. Not sure when you last checked, but regardless, it's getting better.

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#106

Earlier quoted context omitted.

Typescript has been around since 2012. Going by the quote, it is likely to still be around in the next 8 years.

I don't understand. So in 2016, Typescript was around for 4 years so it only had 4 years left, yet here we are.

its 'at least another X years'

so in 2016 typescript was around for 4 years, and here we are now 4 years later. its still around. seems to be holding.

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#107
post #37

Earlier quoted context omitted.

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?

You should absolutely use TypeScript for this. This is exactly what TS is for, to assert your types (proptypes, interfaces, classes, etc.) Switch to .tsx files too. There's a bit of a learning curve for TS, but it's well worth it. You should also type your global store (whether it's in react or redux), your dispatchers, and your action creators. And if you're doing redux, consider redux-toolkit. Turn off implicit any…

As someone who's recently jumped into a TS codebase after using just JS for years, a blog post or resource with these tips would be very nice (even though some are obvious, a lot of people don't know they exist. Disabling implicit any was a PITA/huge help for me.) Do you say don't use ! because you can't make just anything truthy in TS, or is there another reason?

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#108

Earlier quoted context omitted.

You need less tests in a type safe language. Especially in a good one like reason / scala.js / elm. Typescript is just not very safe, its type system is unsound by design because compatibility with JS is their #1 priority.

Yes, you have the illusion of type safety but all you need is a slightly different JSON from an API to realize that typescript isn't that interesting.

All you need is a bug in your tests or mocks or fixtures to realize that tests aren't 100% foolproof either. Nothing is, we all know that.

That said, in proper type safe development at least your own API comms should be type safe. It's easy if you use the same language on client and backend, which is possible with Typescript, Reason/Ocaml, Scala, Rust, etc.

The problem with Typescript is that it's half assing type safety in the language itself and people generally half ass type safety in other aspects of development too. You just can't expect to reap the benefits of real type safety with such an approach.

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#109

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

Amen. I don't transpile to JS anymore. If the client is IE (no updates for 7 years?) and doesn't feel like installing FF, Chrome, Edge, or whatever, then it is what it is. Modern static ESModule JS is quite good. I have several projects north of 30KSLOC written in modern JS. I'm not living in "undefined hell" because I use named-export ESModules, I check types all over, and I write quality tests. A little discipline…

>I check types all over

Which is something you rarely need to spend time on if you're using TypeScript.

Post reply on HN