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

Deno will stop using TypeScript

startfunction.com

Post reply on HN
Print view View original

251–260 of 359 posts

Re: Deno will stop using TypeScript

#251

Post by electrotype »

burtonator wrote: post #78

I've migrated to Typescript and have been using it for about 2 years now. Maybe 1.5... TS is the best language I've used. It supports frontend and backend and strict typing and it's scalable so I can refactor and know that my code still works. The one thing its not good at is ML where Python is better but that's mostly because Python has better library support (not language design). Here's the deal. When dealing with…

I'm wondering about "--watch" too... My projects are compiled in the background, like pretty much instantly. The only time I wait is when I restart the applications.

But I suppose they are aware of this flag.

Re: Deno will stop using TypeScript

#252

Post by hakcermani »

emptysea wrote: post #32
hakcermani wrote: post #21

Was using JS for about 6 yrs now and decided will start using TS for a new Node.js project. Admitted it has its warts ... hit my first bottleneck rightaway when parsing the request query param. TS Express bindings declare it as string | string[] | ParsedQs | ParsedQs[]. Ok extract it 'as' string and move on. But I find as I am using it more and more it is getting better (or I am getting more disciplined!) .. maybe I…

just a heads up, casting `as string` isn't safe since the request param could turn out to be an array. If the request ends up with the query param as an array, there isn't a runtime to validate the cast and now the variable is typed as `string` but is actually `string[]`. I think a safer approach is to use a validation library or refine the type with an if stmt and returning an error when it isn't a string. I use the…

Thanks for the headsup. I did realize that. It was a specific case of pulling a username from the query .. checking out the library ..

Re: Deno will stop using TypeScript

#253

Post by jondubois »

stickfigure wrote: post #123
orangecat wrote: post #89

Earlier quoted context omitted.

You don't have to write as many tests when you use static typing, because your method contracts are solid. People often say this, and I don't get it. What JS tests are you writing that become unnecessary in TypeScript? I've used a fair amount of TypeScript and plain JS, and end up with similar amounts of tests for each. With JS, I almost never want to verify only that a value is of a specific type; I want to look at…

Let's say you have a method that takes a thing : function doSomething(thing) { ... } How many different possible representations of a 'thing' do you have? A json object? A class object with behaviors? A database id? Some sort of natural key like a SKU? A URL? Is it a metric or imperial thing? You need integration-level tests around every method call to ensure that caller and callee agree what kind of 'thing' represen…

>> How many different possible representations of a 'thing' do you have? A json object?

Why would you design a function in such a way that one of the arguments can represent so many different things? The problem here has nothing to do with testing. The problem is that the function itself is poorly designed.

If anything, the difficulty of writing a test for such a function would in itself be an indication that the function needs a refactoring.

Re: Deno will stop using TypeScript

#254

Post by emptysea »

mirekrusin wrote: post #249
emptysea wrote: post #226

Earlier quoted context omitted.

typescript also supports type checking js code: https://www.typescriptlang.org/docs/handbook/type-checking-j... I've found this very useful for gradually migrating a node.js project to a more maintainable state. Types also mean autocomplete works! Additionally since it's typescript we can download the `@types/` packages for our dependencies and get type checking for those as well.

You can't do too many things with jsdoc, can you? Ie. generics are not supported or basic things like importing types from other file, right? Ergonomy/verbosity/look and feel of those types in jsdoc is a bit poor IMHO as well. It's absolutely not the same thing. With flow you get the whole flow, with jsdoc it seems some scraps of typechecking. Am I wrong?

Generics are supported via `@template` https://www.typescriptlang.org/docs/handbook/type-checking-j...

types can be imported either explicitly via `require()` or via the `@type {import("foo").Bar}`

There are definitely some limitations and caveats, like `Object` being aliased to `any` (I think this is being changed in a new version), but it's still way better than untyped JS, and having typescript integration is nice since our devs are already using typescript in other places.

Can even using things like https://github.com/typescript-eslint/typescript-eslint

Flow is both more advanced and faster than Typescript, but the community isn't as large, so Typescript continues to gain marketshare

Re: Deno will stop using TypeScript

#256

Post by inimino »

WClayFerguson wrote: post #246
inimino wrote: post #192

Earlier quoted context omitted.

Spoken like someone who's never solved problems with medium-to-large scale JS projects... criticising people who have.

Here's a pretty sizable project I wrote in pure TypeScript: https://github.com/Clay-Ferguson/quantizr I have 5 years experience in TS and 20 in JS. Trust me, if you don't yet understand the value of type-safety, it's only because you haven't lived long enough yet.

I do understand the value, thanks mostly to Haskell. I also know that (language- or tool-enforced) type safety and type discipline are separable concerns. I also understand when the former gets in the way, thanks to JS, TS, Rust, Lisp, and projects large and small, slow and then fast, fast and then slow, slow and then slow, and fast and then fast.

Re: Deno will stop using TypeScript

#257

Post by kbenson »

hombre_fatal wrote: post #221
kbenson wrote: post #130

Earlier quoted context omitted.

The only really unique thing JS is bringing to the table is that it also has a privileged position in the front end. Your list of benefits it provides boils down to stuff multiple large languages all have, and the one thing that means you can learn just JS. GP comment was presented somewhat snarkily, but I'm not sure they're all that wrong.

Yikes to see people assume so little about others. Why not ask people why they use Node instead of assuming the worst about them? You don't think JS is obviously unique for its ubiquitous Promise, async/await, + async-everything abstraction. You tend to only get that in other languages (Rust, Python, Ruby) by limiting yourself to a fraction of the ecosystem. Btw, what's lazy is making convenient uncharitable assumpti…

I'm not entirely sure what you think I was saying. You refer to me assuming and being uncharitable in those assumptions, but I was responding to a specific list of items pointed out, and my own experience. I think you're actually assuming quite a bit about my comment.

> You don't think JS is obviously unique for its ubiquitous Promise, async/await, + async-everything abstraction. You tend to only get that in other languages (Rust, Python, Ruby) by limiting yourself to a fraction of the ecosystem.

A fraction like nodejs or whatever subset of NPM you decide to use?

Core JS is what you get in a browser. That includes async/await, but it's hardly ubiquitous in usage in the core.

The main distinction JS has over Perl, Python, Ruby etc is that it's in the browser, so you can assume almost everyone has it and it's accessible in some manner if they access a web property you are responsible for.

Re: Deno will stop using TypeScript

#258

Post by dbnoch »

I felt like the article and associated google doc were fishing for reasons to remove TS until ry finally mentioned "typescript provides an extra 500 lines and the namespaces make the code harder to reason with (V8 ingests these files directly)". IMO that was the only solid reason for the change.

Re: Deno will stop using TypeScript

#259

Post by mirekrusin »

emptysea wrote: post #254
mirekrusin wrote: post #249

Earlier quoted context omitted.

You can't do too many things with jsdoc, can you? Ie. generics are not supported or basic things like importing types from other file, right? Ergonomy/verbosity/look and feel of those types in jsdoc is a bit poor IMHO as well. It's absolutely not the same thing. With flow you get the whole flow, with jsdoc it seems some scraps of typechecking. Am I wrong?

Generics are supported via `@template` https://www.typescriptlang.org/docs/handbook/type-checking-j... types can be imported either explicitly via `require()` or via the `@type {import("foo").Bar}` There are definitely some limitations and caveats, like `Object` being aliased to `any` (I think this is being changed in a new version), but it's still way better than untyped JS, and having typescript integration is nice…

If it supports many constructs, why they don't switch to using it in deno?

Re: Deno will stop using TypeScript

#260

Post by dbnoch »

snek wrote: post #224
inimino wrote: post #179

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…

Gotta appreciate the part implying that anyone who finds this document amusing is a "novice" programmer.

I thought the "novice" programmer remark was a pretty cringe-worthy comment.

The original reasons listed by Deno for removing TS had the undertones of "senior engineer who hates certain tech because they didn't use it right". Naturally, their response was to say "you probably don't understand cause you're a novice".

Post reply on HN