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

31–40 of 115 posts

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

#31

Post by francis36012 »

tuckerconnelly wrote: post #14
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…

I feel the exact same. Reminds me too of Nassim Taleb's idea that, if something as already existed X years, it's likely to exist another X years. I'm skeptical of the staying power of these transpilers.

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

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

#32

Post by mikewhy »

jakelazaroff wrote: post #27
Andrex wrote: post #23

Earlier quoted context omitted.

Enforce shared ESLint rules on commit, and use Airbnb+React with most of the defaults set.

How would that catch a misspelled prop name?

You would end up defining PropTypes, and ESLint is capable of keeping you in check there.

It's much worse than just using TypeScript (only at runtime, PropTypes aren't that useful anywhere else, PropType syntax doesn't match Flow, TS, or jsdoc, ESLint can't check any PropTypes you spread in), but it can get you by in a pinch.

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

#33

Post by csours »

mikewhy wrote: post #16
MBCook wrote: post #3

What is ‘deno code’?

As mentioned, Deno is the new project from the creator of NodeJS. Here, as far as I can tell, "Deno code" specifically related to the code shipped to the developer / user using Deno, the compiler / runtime.

deno

de no

no de

node

heh.

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

#34

Post by ngerrity »

jakelazaroff wrote: post #27
Andrex wrote: post #23

Earlier quoted context omitted.

Enforce shared ESLint rules on commit, and use Airbnb+React with most of the defaults set.

How would that catch a misspelled prop name?

linting wouldn't, but if you're writing unit tests, that kind of problem would be caught pretty quickly.

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

#35

Post by mikewhy »

ngerrity wrote: post #34
jakelazaroff wrote: post #27

Earlier quoted context omitted.

How would that catch a misspelled prop name?

linting wouldn't, but if you're writing unit tests, that kind of problem would be caught pretty quickly.

This also works in TypeScript's favor. Meaning you can skip writing tests that simply check you're giving the correct props.

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

#36

Post by untog »

fearingreprisal wrote: post #28
hn_throwaway_99 wrote: post #24

Earlier quoted context omitted.

Your comment is somewhat incomprehensible, because this article is not about building end user applications in Typescript. It's about building the container itself in Typescript. I switched to Node from Java a couple years ago, and to Typescript within the past year, and I have never been on a team that has had this level of productivity.

What part of it couldn't you comprehend? I understand what the article is saying. I'm talking about the dysfunctional Node.js ecosystem, which includes Typescript. In response to your personal experience, I'll share my own: I switched from C++ to Java, to .net, to Node.js, to Typescript. Working on Node/TS I have never been on a team that wastes so much time fixing silly problems that a better language would simply n…

> I'm talking about the dysfunctional Node.js ecosystem, which includes Typescript.

Deno is, by definition, not Node.js. Typescript can live outside of Node (like when it's compiled for and runs in the browser). So I think you're getting downvotes because it reads like a generic rant about the same things we've already heard about in a context where it doesn't apply. I'm not going to argue with the notion that Node has many poorly written community packages, it does, but this core piece of Deno functionality does not use any.

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

#37

Post by lukevp »

Agent766 wrote: post #17
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…

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, assert types on everything you can, don't use !, learn about union types.

Hit me up in the e-mail in my profile if you want to discuss this further, would be happy to help and discuss my reasoning further. I've been doing a LOT of TS code recently on all the major target platforms for React - browser, electron, and react-native. I manage a team who's built several applications now and we use TS for everything, including an automatically-generated TS api interface that exposes types from our C# REST backend using swagger directly to the client code.

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

#38

Post by mikewhy »

hn_throwaway_99 wrote: post #26
dfabulich wrote: post #6

JS engines should be able to ignore TS annotations, out of the box. https://github.com/samuelgoto/proposal-pluggable-types

FWIW Flow actually let you write type annotations as comments so that the code was syntactically valid JavaScript. I'm not sure if TS ever had something like this. https://flow.org/en/docs/types/comments

For a while, TypeScript has been able to check types using JSDoc. Since 2.3 I think, back in 2017.

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

#39

Post by jeffmcmahan »

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…

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 goes a long way.

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

#40

Post by jdxcode »

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…

Do you use Babel to polyfill JS? Minify? Concatenate? You’re transpiling. And not much more than TS. There is very little logic change that TS does and most of it is essentially the same as what Babel would do for polyfill reasons.
Post reply on HN