Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

docs.google.com

Post reply on HN
Print view View original

71–80 of 115 posts

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

#71

Post by curryst »

speedgoose wrote: post #67
Agent766 wrote: post #17

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?

Instead of writing types, you write tests.

You need rigorous tests though. At some point you end up with a hacked on version of typing. I appreciate that Typescript will tell me "this value might be null, and that function doesn't handle null" rather than writing a bunch of runtime checks to make sure the value isn't something invalid, and then writing tests to make sure those work.

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

#72

Post by mbrock »

giantDinosaur wrote: post #63
searchableguy wrote: post #54

Earlier quoted context omitted.

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…

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

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

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

#73

Post by rictic »

cutler wrote: post #68
tanilama wrote: post #19

Earlier quoted context omitted.

Typescript helps you to avoid most obvious bugs(wrong classes, non-existent properties, basically to escape the undefined hell) that is the point of it, which I really like and find enormously helpful for medium-size JS project (10k-50k LoC) Also I don't think the transpiler argument holds in today's JS ecosystem. Everything is transpiled. Unless you are developing in barebone ES5 syntax and avoid babel as a whole, t…

Why? ES6 has been widely supported for quite some time now.

IE11, unfortunately, isn't _quite_ dead yet, and ES6 is definitely not the last word in useful JS language features.

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

#74

Post by nickbauman »

temporallobe wrote: post #13

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…

The problem with this argument is you're already compiling your JavaScript to JavaScript anyway. You already can't paste ES6 into the JS console. And don't even start if you're using JSX. I think the opposite: nobody should write JavaScript. You should write in any other language than JavaScript, there are hundreds to choose from. https://github.com/jashkenas/coffeescript/wiki/List-of-langu...

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

#75

Post by dragonwriter »

cutler wrote: post #68
tanilama wrote: post #19

Earlier quoted context omitted.

Typescript helps you to avoid most obvious bugs(wrong classes, non-existent properties, basically to escape the undefined hell) that is the point of it, which I really like and find enormously helpful for medium-size JS project (10k-50k LoC) Also I don't think the transpiler argument holds in today's JS ecosystem. Everything is transpiled. Unless you are developing in barebone ES5 syntax and avoid babel as a whole, t…

Why? ES6 has been widely supported for quite some time now.

> ES6 has been widely supported for quite some time now.

ES6/2015, sure; ES2021, though...

For the latest useful JS features, you need a compiler, whether it's TypeScript or Babel or...

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

#76

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

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

#77

Post by davnicwil »

mcintyre1994 wrote: post #76

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…

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.

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

#78

Post by jamesgeck0 »

cutler wrote: post #68
tanilama wrote: post #19

Earlier quoted context omitted.

Typescript helps you to avoid most obvious bugs(wrong classes, non-existent properties, basically to escape the undefined hell) that is the point of it, which I really like and find enormously helpful for medium-size JS project (10k-50k LoC) Also I don't think the transpiler argument holds in today's JS ecosystem. Everything is transpiled. Unless you are developing in barebone ES5 syntax and avoid babel as a whole, t…

Why? ES6 has been widely supported for quite some time now.

If you target browsers that are installed by default on operating systems that are still receiving security updates, you have to support Windows 8.1 and thus IE 11 for another two and a half years, alas.

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

#79

Post by capableweb »

nickbauman wrote: post #74
temporallobe wrote: post #13

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…

The problem with this argument is you're already compiling your JavaScript to JavaScript anyway. You already can't paste ES6 into the JS console. And don't even start if you're using JSX. I think the opposite: nobody should write JavaScript. You should write in any other language than JavaScript, there are hundreds to choose from. https://github.com/jashkenas/coffeescript/wiki/List-of-langu...

The problem with your argument here is that you're assuming that the person you're replying to is using ES6 and/or JSX when they outright said they prefer just using "plain old JavaScript" which is neither of those things, so you're bypassing their argument fully.

Their point seem to be that no matter what language you prefer to be compiled to JS, in ends up being JS anyway so you might as well write JS directly, because of the reasons provided in the last post. I don't agree with them (ClojureScript is the language of choice for me), but you're not arguing with good faith here.

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

#80

Post by dragonwriter »

nickbauman wrote: post #74
temporallobe wrote: post #13

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…

The problem with this argument is you're already compiling your JavaScript to JavaScript anyway. You already can't paste ES6 into the JS console. And don't even start if you're using JSX. I think the opposite: nobody should write JavaScript. You should write in any other language than JavaScript, there are hundreds to choose from. https://github.com/jashkenas/coffeescript/wiki/List-of-langu...

> The problem with this argument is you're already compiling your JavaScript to JavaScript anyway. You already can't paste ES6 into the JS console.

What runtime are you using that you can't run ES6/2015 natively in the console?

Post reply on HN