Live data from Hacker News

Why does TypeScript have be the answer to anything?

hanselman.com

71–80 of 82 posts

Re: Why does TypeScript have be the answer to anything?

#71
post #41

Earlier quoted context omitted.

Go to function definition, refacor/rename, find references, view object / class hierarchy, and so on. Why not have all this work 100% of the time? Tooling makes your life so much easier. I don't understand why people would resist optional typing.

I'm not saying that tooling isn't nice. On the contrary. I'm asking why can't we have tooling even with dynamic types.

Because there is no type. It's dynamic. You can't figure out what the type is unless you run the code.

def do_something(thing_a, thing_b): ...

What's the type of thing_a or thing_b?

There is none. There isn't even a type globally. thing_a and thing_b acquire new types at every call instance. This basically screws you for all useful auto-complete information.

You can't even do proper go-to-definition because of things like getattr.

Re: Why does TypeScript have be the answer to anything?

#72
post #68

Seems like a troll article to me. Of course people are comparing TypeScript to Dart. They do the same freaking thing-- provide you with a different way to write code to run in the browser. Then he presents the metaphysical distinction between "building on JS" (good) versus "interop with JS" (bad). What's the difference? Neither language is JS. If something breaks, you're still going to be debugging code that isn't th…

> What's the difference?

One lets you take existing JS-code and make use of new language features there. The other "just" lets you call existing JS-code.

I'd guess one is clearly better than the other when it comes to dealing with existing JS-code* . (While the other is clearly preferable to the one when it comes to making the language you want to make.)

* It still obviously depends a lot on the language. Like, how well TS-code works together with plain JS-code (how much do you get out of adding some type annotations here and there while leaving most of the JS-code untouched, etc.).

Re: Why does TypeScript have be the answer to anything?

#73
post #72
post #68

Seems like a troll article to me. Of course people are comparing TypeScript to Dart. They do the same freaking thing-- provide you with a different way to write code to run in the browser. Then he presents the metaphysical distinction between "building on JS" (good) versus "interop with JS" (bad). What's the difference? Neither language is JS. If something breaks, you're still going to be debugging code that isn't th…

> What's the difference? One lets you take existing JS-code and make use of new language features there. The other "just" lets you call existing JS-code. I'd guess one is clearly better than the other when it comes to dealing with existing JS-code* . (While the other is clearly preferable to the one when it comes to making the language you want to make.) * It still obviously depends a lot on the language. Like, how w…

OK. So there is a path to converting JS to typescript without rewriting the whole thing. Thanks for the additional information.

Re: Why does TypeScript have be the answer to anything?

#74
post #41

Earlier quoted context omitted.

I'm not saying that tooling isn't nice. On the contrary. I'm asking why can't we have tooling even with dynamic types.

Because there is no type. It's dynamic. You can't figure out what the type is unless you run the code. def do_something(thing_a, thing_b): ... What's the type of thing_a or thing_b? There is none. There isn't even a type globally. thing_a and thing_b acquire new types at every call instance. This basically screws you for all useful auto-complete information. You can't even do proper go-to-definition because of things…

Yes, there most certainly is a type. It's dynamic, but not nonexistent. Now, of course you don't know the type for sure unless you run the code. I said so at the start. But I'm saying, can't you do a pretty good job in most cases? In this case, you could go to all places where do_something is called and see what objects are being passed in.

Yes, maybe there are situations where dozens of different types are passed in by different calls, or where we're building a library and we don't have any calls to do_something in our codebase, and cases where everything is obfuscated by one means or another. But depending on style I bet there are lots of cases where it works out ok.

Re: Why does TypeScript have be the answer to anything?

#75
post #55

The Typescript syntax looks shockingly like Adobe's ActionScript. Next up, Adobe releases an ActionScript to Javascript cross compiler?

This guy agrees with you (and so do I btw): http://blog.blakebarrett.net/2012/10/typescript-vs-actionscr...

And yes, they're all variants of ECMAScript. It's a mess!

Re: Why does TypeScript have be the answer to anything?

#76
post #73
post #72

Earlier quoted context omitted.

> What's the difference? One lets you take existing JS-code and make use of new language features there. The other "just" lets you call existing JS-code. I'd guess one is clearly better than the other when it comes to dealing with existing JS-code* . (While the other is clearly preferable to the one when it comes to making the language you want to make.) * It still obviously depends a lot on the language. Like, how w…

OK. So there is a path to converting JS to typescript without rewriting the whole thing. Thanks for the additional information.

Mostly the approach that personally makes TS interesting to myself is that typescript is building on top of javascript. You don't need to convert javascript to typescript because it already is typescript. Typescript simply extends the language. Dart or coffeescript on the other hand essentially creates an entirely new language that is simply compiled down to javascript.

Re: Why does TypeScript have be the answer to anything?

#77

The way I see it: 1. TypeScript is an answer to the poor state of JavaScript development today and an attempt to get more structure into it. There are other answers as well, and it can be discussed on properties of each of them, but they are competing in the same domain. 2. Since state of JavaScript is as it is, it is obvious that there is a lot of potential benefit in being a leader of the technology in that domain.…

Poor state of JavaScript development? By what measure? I've been doing "application-scale" development using JavaScript for 5 years... Not once did I think "gee my development process would be better if I had rigid typing." The notion is laughable. The lack of rigid typing and classes is by design. This is a feature not a bug. I honestly wonder about a programmer's understanding of JavaScript if they say things like…

I don't think of lack of strong typing or OO features as a bug either. I think Typescript's approach of optional features added to javascript provides even more flexibility. You can choose specifically if you want strong typing or not, or you can choose to use classes if you think it's the best approach for the current project. I don't think typescript is trying to remove the options that javascript already has, otherwise they would have gone the way of coffeescript or dart. Typescript, to use the common metaphor, simply extends your toolbelt to let you pick what you want for what you need.

Re: Why does TypeScript have be the answer to anything?

#78
post #69

I think google missed big time on Dart, and something like TypeScript is what they should have done. I really find it hard to come up with bad things to say about Microsoft's move, it's a mental cognitive dissonance, but I have to admit, they are doing something very right. 1) it's just JavaScript - winning some CoffeeScript fans 2) regular JavaScript is valid, (just like SCSS vs SASS) 3) it has day 1 interop with va…

I think you answered your own question. Google wanted a fundamentally different language, not just JS with some extra features thrown in. As to what will win out in the end-- I have no idea.

Google seem to like inventing things, they have people who create languages for a living (some of the creators of Java, that some of them are probably behind Dart) and they did some pretty amazing things, Go is a great language, I'm sure Dart will have a fan base, and who knows, it might catch up (in 2004 no one thought Ruby will be that popular, right?) Google went for their vision, Microsoft went for the practical.

Re: Why does TypeScript have be the answer to anything?

#79

Earlier quoted context omitted.

The JSDoc system gets in the way too much, how for instance do you type variables which is something like: /** @type {myType} */ var thing = new myType( ); It gets way to verbose when compared to typescript which is something like: var thing : myType = new myType( );

Actually that's not quite accurate. The Closure Compiler doesn't need you to tell it that `thing` is a myType, it knows that, asuming myType is defined in your compiled code, or you provide an extern specifying what myType means. And I might be wrong about that last bit even; the compiler may always know that `new Foo` returns a {Foo} regardless of context ... I would have to check the compiler source to be certain.…

The benefit of typing javascript is for the developer and not the compiler, therefore telling closure compiler that a variable is a type is to decrease the chance of mistakes. Closure compiler also is buggy and isn't as smart as we would like to think it is, sometimes you have to prod it into the right direction. It was a simplified example, something better would be:

  /** @type {myType} */ var thing = function_that_returns_a_myType( );
The point is using comments for typing a language is messy and takes up far more space than required.

Re: Why does TypeScript have be the answer to anything?

#80

I think google missed big time on Dart, and something like TypeScript is what they should have done. I really find it hard to come up with bad things to say about Microsoft's move, it's a mental cognitive dissonance, but I have to admit, they are doing something very right. 1) it's just JavaScript - winning some CoffeeScript fans 2) regular JavaScript is valid, (just like SCSS vs SASS) 3) it has day 1 interop with va…

Don't forget source map support, that is a huge plus to have from day one.
Post reply on HN