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

101–110 of 194 posts

Re: I Was Wrong About TypeScript

#101

Post by swax »

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?

A major benefit is the ability to quickly understand code you didn't write because you have the ability to 'go to definition' or 'find all references' which works across multiple files. On top of that once you understand the code and need to modify it you can quickly refactor across multiple files instantly and with a high degree of confidence.

Types are not a substitute for tests, but they eliminate an entire class of bugs that are screened out at compile time. That way you can focus your tests on functionality and not silly mistakes.

Re: I Was Wrong About TypeScript

#102

Post by seanwilson »

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…

> But doesn't Typescript compile to JS, thus there's actually no type-checking at runtime?

Sure, but that's what happens in every other language e.g. C's type system will enforce certain properties for you but when you compile to machine code the machine code is not checking those properties at runtime. If you know the compiler is correct you don't have to worry.

Nobody is saying you should stop writing tests but a good type system will mean you have to write less tests because the type system will do some of the checking for you in a more robust way.

Re: I Was Wrong About TypeScript

#103

Post by swax »

k__ wrote: post #85
calebegg wrote: post #81

Earlier quoted context omitted.

No, I think solomatov is saying you can always use the 'any' type built-in to TypeScript. You can always do: declare var fancyNewLib: any; fancyNewLib('hello'); fancyNewLib.someCoolFeature = 3; You don't get any suggestions or typechecking (obviously), but you're no worse off than just using JS in that sense. And you can easily replace your 'declare' with the actual // tag when you find it or make it, and clean up an…

Ah, yes, that's what I'm doing most of the time. But like you said it's no better than using JS directly, haha.

Just changing the file extension from js to ts will often bring out bugs in your code. The type inference will often catch things. Functions that are declared multiple types or that have duplicate parameters, and a lot of other stuff will be caught.

Re: I Was Wrong About TypeScript

#104

Post by swax »

mikerichards wrote: post #50
Waterluvian wrote: post #26

I just can't justify writing my team's code base in typescript. I don't want to make that move, setting us down a very specific path. I don't want to add another layer of training to develop on our codebase, but mainly, I just don't have the confidence that it's a right or wrong choice, and its a big choice. But I get a sense that it would be great to try for smaller, disposable projects as that's limited risk. Does…

I wrote in a previous post that I enjoy working with Typescript and overall it's a win for our team, but these days I sometimes wonder how much of a win over es6/7. I've found the biggest headache is getting all the *.d.ts files setup right and setting up your own types can sometimes be a pain, but as I mentioned it's pretty opt-in.

ES6/7 doesn't have static type checking.

Re: I Was Wrong About TypeScript

#105

Post by jestar_jokin »

dandare wrote: post #23

I find it funny - the first language I learned was ActionScript 3 (built on ECMA 4 proposal) and I become a Flash developer aka laughing stock. I remember I had very rough time transitioning to JavaScript because it felt like a stone age compared to ActionScript 3. Then came TS and saved me and dare I say the whole web.

You should also have a look at Haxe, which comes from an ActionScript-inspired syntax, and compiles to JS (and a whole bunch of other languages, including ActionScript). It has even better language features than TypeScript (gotta love compile-time macros), although TypeScript has the benefit of adding features in an attempt to describe existing JavaScript code using types, so the interop with JS libs is easier.

Re: I Was Wrong About TypeScript

#106

Post by Dr_tldr »

seanwilson wrote: post #102
Dr_tldr wrote: post #96

Earlier quoted context omitted.

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…

> But doesn't Typescript compile to JS, thus there's actually no type-checking at runtime? Sure, but that's what happens in every other language e.g. C's type system will enforce certain properties for you but when you compile to machine code the machine code is not checking those properties at runtime. If you know the compiler is correct you don't have to worry. Nobody is saying you should stop writing tests but a g…

Q: What is a concrete advantage of Typescript?

A: C's type system is very useful for data validation.

Please read at least one sentence before writing a response next time.

Re: I Was Wrong About TypeScript

#107

Post by DanRosenwasser »

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…

Hey, I work on the TypeScript team. I hope you'll reconsider, and maybe you can fill me in on the issues you ran into.

Your .js files should typically be relative to each other, so unless you're using absolute paths (which you usually shouldn't!), this hasn't been a problem for other users. Is there something that I'm missing?

Re: I Was Wrong About TypeScript

#108

Post by int_19h »

pygy_ wrote: post #40
dandare wrote: post #23

I find it funny - the first language I learned was ActionScript 3 (built on ECMA 4 proposal) and I become a Flash developer aka laughing stock. I remember I had very rough time transitioning to JavaScript because it felt like a stone age compared to ActionScript 3. Then came TS and saved me and dare I say the whole web.

Did you know that Microsoft was part of the cabal against ES4, proposing a competing and very modest ES3.1 which became ES5?

MS was on both sides of it. Remember JS.NET? It was veey ES4'ish (for early definitions of ES4, anyway).

Re: I Was Wrong About TypeScript

#109

Post by jestar_jokin »

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 don't know exactly what your code looks like, but a major reason for using Dependency Injection, like AngularJS does, is to allow your tests to "mock" the injected services. Then, you verify the behaviour (but not the implementation), by checking that each mock is invoked with the expected arguments, and set it to return a particular value.

On the server side, I've used TypeMoq, which is pretty nice. I have only used it to mock imported modules; for AngularJS 1, you'd need to invoke the "inject" service, to insert your mocks into the controller.

Further reading:

https://en.wikipedia.org/wiki/Mock_object

Re: I Was Wrong About TypeScript

#110

Post by ENGNR »

daxfohl wrote: post #55
bdcravens wrote: post #6

Ashamedly at one point I was on the anti-Angular 2 bandwagon due to Typescript, because Microsoft. When I started learning Angular 2 myself I've found I actually enjoyed working with Typescript, for many reasons. (confidence that my code wasn't a ball of mystery before it ran, using inline templates, succinctness of annotations, etc) At the same time, you're gonna need to use some preexisting libraries, and run into…

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

Angular blew a loooooot of my trust in Google, who in the past always put out the highest quality stuff. I built an entire app in the damn thing only to realize as it got bigger that it wouldn't scale. Sure you can use less HTML templates, but that's the whole point so that it's easier for designers to approach / fix.

Sure I should have checked it out but the documentation didn't exactly highlight it (at the time anyway), and with the services, controllers, testability, etc it just looked like they'd thought it all through.

Frankly after finding React there's no way I'm giving NG2 even a look in.

Post reply on HN