I Was Wrong About TypeScript • Hacker News Board

Re: I Was Wrong About TypeScript

#151

Post by wyager » Mon, Jun 06, 2016, 4:12 AM UTC

Dr_tldr wrote: post #96

wyager wrote: post #92

Earlier quoted context omitted.

Tests are weak evidence of the validity of a piece of data at runtime. Types are proof. The stronger your type system, the more you can prove.

But doesn't Typescript compile to JS, thus there's actually no type-checking at runtime? Certainly type checking can prove that it's the right type, but in my experience knowing that it's the right type but the wrong data is useless, I care if it's the exact data it's supposed to be. How does type checking protect you (or someone else) from inadvertently mutating a value without changing it type and causing problems…

The whole point of strongly statically typed languages is that the proofs are performed at compile time. Statically typed programs shouldn't change behaviour after type erasure.

Languages with strong enough type systems can statically guarantee that data is structured correctly at runtime. Stronger structural requirements require stronger type systems. Algebraic data types are sufficient for many common static structuring guarantees.

Re: I Was Wrong About TypeScript

#152

Post by robwormald » Mon, Jun 06, 2016, 4:14 AM UTC

ihsw wrote: post #129

solomatov wrote: post #117

Earlier quoted context omitted.

Could you give links about moving types to npm? Are there any issues in a tracker or a blog?

I don't know about moving all of the current typings to beneath an NPM org, but TypeScript can look for the `typings` field in a package's package.json file. https://github.com/ihsw/toxiproxy-node-client/blob/master/pa... An NPM package will be typed and you won't have to download typings separately. It may be improper to publish typings with your code instead of letting the user install them separately, but at that…

yep, this method works great for libraries authored in typescript (and/or those that take the time to provide external module-style typedef files), but the @typings would be for what tsd/typings does today (mostly ambient)

Re: I Was Wrong About TypeScript

#153

Post by danielearwicker » Mon, Jun 06, 2016, 4:15 AM UTC

ChicagoDave wrote: post #89

daxfohl wrote: post #55

Earlier quoted context omitted.

Ha, I'm on the anti-Angular2 bandwagon due to Angular1. I use React and Typescript and love it. Curious if you've tried React. Or Angular1 (TBH Angular1 was pretty great at the time, but after React I look back at those monstrous template files, ng-everything, plugins and workarounds, and only the bad memories surface).

The real decision re: NG2 v React is more about opinionated frameworks v non-opinionated frameworks. If you're by yourself and/or have tight control over all of your libraries, React is fine. If you're a bigger operation and need to trust the restrictions of the framework, NG2 is possibly a better choice.

Not sure how well this analysis explains Facebook's widespread use of React.

Re: I Was Wrong About TypeScript

#154

Post by danielearwicker » Mon, Jun 06, 2016, 4:18 AM UTC

k__ wrote: post #64

johnny_reilly wrote: post #63

Earlier quoted context omitted.

I can't go with that. Anders H is one of the most avuncular, helpful and accessible voices out there. Oh and his very verbs twinkle!

Well, I just saw a talk about TypeScript 2 and it felt to me that he was belittling JavaScript.

You may be traumatised if you ever hear Crockford talk about JavaScript!

Re: I Was Wrong About TypeScript

#155

Post by likeclockwork » Mon, Jun 06, 2016, 4:27 AM UTC

All the TypeScript fervor kind of passes me by because I simply don't want to structure my work around classes and 'ideal TypeScript' that I've seen looks a lot like Java or another class-oriented language.

Re: I Was Wrong About TypeScript

#156

Post by 235337 » Mon, Jun 06, 2016, 4:29 AM UTC

I signed up just to tell you that a slam dunk is not an easy shot. Its when the player jumps up and places "slams" the ball in the net rather then taking the shot from a distance. Its A) hard to get that close unobstructed and B) for most people hard to actually jump that high. Its almost a boastful move of skill to slam dunk the ball.

I'm actually no a sports person....

Re: I Was Wrong About TypeScript

#157

Post by spo81rty » Mon, Jun 06, 2016, 4:31 AM UTC

likeclockwork wrote: post #155

All the TypeScript fervor kind of passes me by because I simply don't want to structure my work around classes and 'ideal TypeScript' that I've seen looks a lot like Java or another class-oriented language.

You mean it looks too much like normal javascript?

Re: I Was Wrong About TypeScript

#158

Post by jondubois » Mon, Jun 06, 2016, 4:42 AM UTC

I'm not a huge fan of TypeScript (though I will admit that it's way more useful than CoffeeScript). My main issues with it are that: 1. The type definition files tend to get out of date. 2. The build step is time consuming for large apps. 3. It adds complexity to your app and opens it up to new kinds of errors (particularly during setup, different typescript versions...).

I prefer using plain JavaScript - When I need to find a definition for a function, I just do a text search for it in my IDE. Text search isn't as nice as intellisense for beginners but you get used to it pretty quickly and it's actually pretty efficient once you do.

I also like to read through the code a bit before using a function written by someone else, I find that just knowing the interface is often not enough - Often you want to know how specific edge cases are handled and it encourages you to fix bugs in other people's code instead of thinking "This class doesn't work, it's not my problem - I'll just hack a solution to work around it".

Re: I Was Wrong About TypeScript

#159

Post by nidu » Mon, Jun 06, 2016, 6:12 AM UTC

shuzchen wrote: post #59

samps wrote: post #45

Earlier quoted context omitted.

TypeScript 1.8 already has unions and custom type guards! You can use them today. Woohoo! (Looking forward to those non-nullable types, though.)

I was just about to complain how TS fails totally for typechecking backbone models or immutablejs datastructures: both situations where obj.get("foo") and obj.get("bar") return a particular type but there's no way of having TS handle that except defining them as any. But it turns out string literal types in 1.8 will make that work. And this was out since February! I should reevaluate TS for my omniscient project.

It could also benefit from constant propagation (iirc the term) where you could write obj.get(Item.name) and both get type check and stay refactoring friendly (though with cost of some more typing).

Re: I Was Wrong About TypeScript

#160

Post by DanRosenwasser » Mon, Jun 06, 2016, 6:46 AM UTC

batuhanicoz wrote: post #95

mikerichards wrote: post #52

Earlier quoted context omitted.

From a React newbies's perspective, the React community is much more in the es6 camp than Typescript. Many of the starter kits are in es6. It's not a huge deal. I actually write most of my front-end code these days in Aurelia, which is written in es6, but they actually have type annotations which Babel knows how to deal with. So basically the tooling can auto-generate the *.d.ts files for you. That said, Typescript n…

Shameless plug: When we've started switching to TypeScript and was looking for a good starter, we've couldn't find any that we've liked so we've created & open sourced our own. Maybe it can help people who are considering using TypeScript with React: https://github.com/barbar/vortigern

We also have an official doc on getting started with TypeScript, React, and Webpack if anyone's interested: https://www.typescriptlang.org/docs/handbook/react-&-webpack...