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

I Was Wrong About TypeScript

triplet.fi

Post reply on HN
Print view View original

131–140 of 194 posts

Re: I Was Wrong About TypeScript

#131

Post by daxfohl »

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…

> 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

Entirely possible people are comparing apples to oranges here. My experience is all based on structured data; e.g. User, Address, Order, Product, etc, and the relations between them. Data is generally static throughout the duration of the call; e.g. CRUD app.

It sounds like your experience is more with raw numbers and collections, and higher rates of entropy. In that case, I can see how types wouldn't add much value, and tests would be far more essential.

Re: I Was Wrong About TypeScript

#132

Post by lobster_johnson »

Tx3 wrote: post #9
burai wrote: post #3

Another good alternative is Facebook's flow. Rather than being a transpired language it works on top of JavaScript files. This two tools are amazing and it improves working with JavaScript to the point of never wanting to go back to not typed JavaScript

You're absolutely right. Flow seems to be a very good alternative. One thing I would like to add regarding the .js files, TypeScript 1.8 added a flag --allowJs which makes some sanity checks to the plain old .js files.

It sounds like --allowJs alleviates the need to create TypeScript definitions for everything? So if you have an existing project based entirely on JavaScript, you can gradually convert each file to .ts without having to do anything else?

Re: I Was Wrong About TypeScript

#133

Post by ihsw »

venuzr wrote: post #87

Are there any patterns / recommended practices for unit testing Typescript. I recently joined a project which uses Angular1 + Typescript and had to introduce unit testing to the code base and it has been painful. A lot of backend API calls (wrapped in services) are being (chained and) invoked in the constructor. Any initialization is being squashed into the constructor. This makes setup of karma tests extremely painf…

I have found Angular 1 to be an untestable hot mess, especially on projects with a lot of technical debt. This is largely unrelated to TypeScript (and probably unrelated to Angular 1's shortcomings too).

My only suggestion is start migrating to Angular 2 immediately.

Re: I Was Wrong About TypeScript

#134

Post by ihsw »

rymohr wrote: post #88
Tx3 wrote: post #38

Earlier quoted context omitted.

Rob is exactly right that you should use --outDir You should aim for deployment process where outDir would be in .gitignore and building of the JS files would happen on a build server.

If you use --outDir, wouldn't the .js files that import the transpiled .ts files need to point to outDir instead? This is the kind of stuff that makes the "incremental" adoption argument hard for me to swallow. If I can't rewrite a .js file to .ts without any further ripple effects within the project, then it's not truly incremental. I wrestled with this stuff last week and ultimately ended up going with flow since i…

The .js files don't import the transpiled .ts files -- the .ts files are written to import other .ts files using relative paths.

A.ts importing B.ts would be `import * as A from "./B"`, where the transpiled A.js file would import from `./B.js` rather than the original A.ts file.

Furthermore you can mix JS into your compilation process and the TS compiler will* accommodate you by compiling your JS alongside your TS code.[1]

* TypeScript 1.8

[1] https://github.com/Microsoft/TypeScript/issues/4792

Re: I Was Wrong About TypeScript

#135

Post by ihsw »

lloyd-christmas wrote: post #75

> I have written tests in TypeScript, compiled to JavaScript, and then used Mocha, for example, to run tests. I would like to hear your thoughts on this. We use ts-node to run our mocha tests without ever compiling: https://github.com/TypeStrong/ts-node

Another vote for ts-node running your tests, it makes things a lot simpler. Running tests directly instead of running compiled tests is faster and more reliable.

Re: I Was Wrong About TypeScript

#136

Post by ihsw »

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…

You are correct, there is no type-checking at runtime. Getting garbage data where you are expecting properly formed data will throw a nasty wrench in your application.

Thankfully this rarely happens.

Re: I Was Wrong About TypeScript

#137

Post by nojvek »

lobster_johnson wrote: post #132
Tx3 wrote: post #9

Earlier quoted context omitted.

You're absolutely right. Flow seems to be a very good alternative. One thing I would like to add regarding the .js files, TypeScript 1.8 added a flag --allowJs which makes some sanity checks to the plain old .js files.

It sounds like --allowJs alleviates the need to create TypeScript definitions for everything? So if you have an existing project based entirely on JavaScript, you can gradually convert each file to .ts without having to do anything else?

That is true. You slowly add more black typescript to a white js project as you go along and decide the shade of grey you want.

Re: I Was Wrong About TypeScript

#138

Post by nojvek »

daxfohl wrote: post #127
Dr_tldr wrote: post #91

It seems like people are trying to use types as a substitute for tests and a way to protect themselves from unintended mutations. But if you write tests already and use immutable data structures, what benefits does TS bring to people whose background isn't in strongly typed languages?

Refactoring. Say you want to make a 1:1 relation into a 1:* relation. You change your core data type from e.g. `type person{address:string}` to `type person{addresses:string[]}`, follow/fix all the red squiggly lines until it compiles, and generally you're done. OTOH with unit tests, you've got to find/fix not only your app code but the test code as well. You may forget some things because you overlook a function and…

The way I think about this is types is like writing tests for your code. Typescript will fail if the contracts don't match.

Re: I Was Wrong About TypeScript

#139

Post by shados »

choward wrote: post #70
virtualwhys wrote: post #29

Earlier quoted context omitted.

> As a Scala developer Interesting, choosing TypeScript over Scala.js; what does TS offer vs. working directly in Scala across the board?

I think the biggest advantage is that typescript emits code that is good JavaScript. This means if I decide to stop using typescript, I can just use the generated JavaScript. It also means that there transpiled file is smaller. Using scala.js for a small project wouldn't make sense if you cared about file size at all. It could be worth it more as your project grows, but your then you are that much more commited. Ther…

I'm always curious where that came from. TypeScript does not emit good JS. It's pretty garbage and not reasonably usable by humans. TS supports ES6 target, where it more or less just strips TS-specific features, but that's only useful if you target a very small subset of browsers and limit what you use.

Even "6to5" (previous name for Babel), which originally had as a design goal that it would emit good JS (and back then, it did!) quickly lost that when they tried to aim for spec correctness.

TypeScript actually punts on the standard in some cases (eg: TypeScript classes are not ES6 compliant) to generate more readable code, but it's still not "good" code and I certainly would never consider working with that.

Post reply on HN