Design Doc: Use JavaScript instead of TypeScript for internal Deno Code • Hacker News Board

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

#111

Post by joquarky » Wed, Jun 10, 2020, 3:34 PM UTC

biomene wrote: post #87

pkukkapalli wrote: post #43

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…

Came here to upvote typescript with jsdocs too. We use it in our project and it’s been really helpful. No overhead and you get the nice dev experience of typed code. Been doing it for 2 years, have yet to encounter a situation that would be solved by using ts compilation.

I much prefer JS+JSDoc over Typescript when writing my own code. Typescript makes me feel overly constrained.

Also, I've been doing web dev for 25+ years now and I don't like the trend backward to waiting for code to "compile".

Although if you're going to have to compile, Svelte looks like a nice middle-ground.

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

#112

Post by jeffmcmahan » Wed, Jun 10, 2020, 3:53 PM UTC

fardelian wrote: post #109

jeffmcmahan wrote: post #39

Earlier quoted context omitted.

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.

That's true. But with TS I have to declare types, import typings, maintain a build process to run the TS compiler, and so on. Moreover, static typing comes with added tediousness, and I personally feel that it's not worth the freight.

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

#113

Post by jaaames » Thu, Jun 11, 2020, 4:18 AM UTC

MaxLeiter wrote: post #107

lukevp wrote: post #37

Earlier quoted context omitted.

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?

He's referring to https://www.typescriptlang.org/docs/handbook/release-notes/t... rather than boolean coercion.

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

#114

Post by hootbootscoot » Sun, Jun 14, 2020, 5:08 PM UTC

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

Hmmm, I have more than one current project in pure ES5, as terrible as it is. I have one polyfill file with stuff like Object.keys and things that organically accumulated over time, and should probably be cleaned of obsolete nonsense but it's 6k LOC, and otherwise I need to remind myself to use my XHR abstraction, as I automatically still type stuff like "if xhr.readyState == 4 && xhr.status = 200" like a doofus... such is life in wart-land.

I will be happy when I leave wart-land, but only when I really leave wart-land, not when it's just "lipstick on the wart"-land.

Types and classes sound nice, but only if they really exist, and not as mere compiler advice. A type is really a memory shape/size/structure in compiled languages.

Ok, having said all of this heretical nonsense...

(and yes, I've used React, Vue, etc. I tend to like Mithril best, and avoid JSX as I've no problem with hyperscript, and have even made my own lousy reactive hyperscript that I don't use (lol) in favor of Mithril)

... i DO have to say that Typescript seems like a nice/useful tool for teams, were transpiling to be accepted for the project needs, after weighing the costs/needs. I am recently rather fascinated by Svelte, and I'm mostly trying to break things and see what generated code looks like, etc. I'll admit that ES3 get's a bit useless, hence the polyfill. Minified JS with single-letter variables is usually a hoot to read.

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

#115

Post by hootbootscoot » Sun, Jun 14, 2020, 5:13 PM UTC

Dragory wrote: post #93

capableweb wrote: post #79

Earlier quoted context omitted.

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

ES6 is plain old JavaScript. I think the parent commenter's point was that even when you're writing plain JS, if you target browsers (and old browsers specifically) or e.g. a large range of Node.js versions, you often still need to transpile it. This naturally doesn't apply if you target a specific runtime version (e.g. a specific Node.js version). That being said, the commenter above them could've also been referrin…

ES6 implies transpiling, or polyfilling, IF you want to support most browsers still currently used.

It seemed to me that the author was describing the (somewhat common?) practice of writing client code directly in ES5 and perhaps polyfilling any missing features for any targeted browsers that required specific fills.

I, personally, find ES6 to be ugly and requires me to pretend all sorts of things that are not true for the targeted runtime. It's like a whole fake world, so I'll prefer to avoid it unless there's some obvious reason to use it, as in an existing front-end build toolchain and a spec to use ES6, etc. Greenfield? I guess Svelte and such will use it, but if Typescripting, then one will just write Typescript, right?