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

Why does TypeScript have be the answer to anything?

hanselman.com

Post reply on HN
Print view View original

21–30 of 82 posts

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

#21

Post by apendleton »

mistercow wrote: post #10

>Dart interops with JavaScript...but it's not JS. It doesn't even use the JavaScript number type for example. What is meant by this? As far as I know, the only way that you can use Dart in any browser currently is by compiling it to JS, and when you do that it most certainly does use native JS numbers. In fact, the type check function it creates for numbers contains this line: if (!(typeof value === 'number')) {

The native Dart VM distinguishes between integers and floats for performance reasons, and (I think) lets you explicitly cast back and forth between them, and if, at some point, Chrome ships a Dart interpreter, developers will be able to take advantage of that. I assume this all gets turned into noops when it's translated to JS, so to some extent it's academic, but I think they were just trying to illustrate that Dart's innate notions of built-in types are different than JS's, and are kludged into JS types at compile time, whereas TS sits much closer to current JS environments.

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

#22

Post by oinksoft »

MatthewPhillips wrote: post #19
oinksoft wrote: post #17

Earlier quoted context omitted.

This is a moot point. The Closure Compiler supports dependency resolution so that you can unit test your code without building the full project. So, if I am testing foo.bar.Baz, I can create a file that only includes `base.js' and a goog.require('foo.bar.Baz'); call, and `base.js' will include all of its dependencies, in most cases fairly quickly. Unless you are performing integration tests, there is no reason to com…

Does goog.require() resolve at run time or compile time?

You're realistically only going to deploy a compiled script. The compiler supports goog.require/provide() without requiring any JS inputs, and core tools like closurebuilder.py (which has superseded calcdeps.py) build your dependency graph for you. The compiler uses the require/provide statements to ensure that all necessary symbols are indeed provided, and are only included once in the script.

For debugging purposes, `base.js' implements goog.require() in JavaScript. The implementation is naïve, it just turns foo.bar.Baz into foo/bar/Baz.js and tries to include it. This is good enough for running unit tests or fiddling around with experimental code, which are the two times you're going to use `base.js'.

http://code.google.com/p/closure-library/source/browse/trunk...

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

#23

Post by petegrif »

ivanjovanovic wrote: post #2

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

1. Well said.

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

#24

Post by scott_s »

mistercow wrote: post #10

>Dart interops with JavaScript...but it's not JS. It doesn't even use the JavaScript number type for example. What is meant by this? As far as I know, the only way that you can use Dart in any browser currently is by compiling it to JS, and when you do that it most certainly does use native JS numbers. In fact, the type check function it creates for numbers contains this line: if (!(typeof value === 'number')) {

He means that the semantics of Dart - including the data types provided by Dart - are different from JavaScript. This is in opposition to TypeScript, which is a superset of JavaScript, which means that it necessarily shares JavaScrips semantics.

If your example bothers you, consider that JavaScript just happens to be a target language for the Dart compiler. That is, it takes a program with Dart's semantics, and figures out how to map those to JavaScript semantics. That there is a mapping is not all that interesting, as such a mapping will exist from any Turing complete language to any other.

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

#25

Post by rbellio »

I've been testing it out and I like it so far. I personally don't enjoy writing JavaScript in text editors and the tools like PHPStorm, while being decent don't really give me the slick development environments that I've come to enjoy.

Since I do a lot of Windows and .NET web app development for my day job, I really enjoy the fact that Microsoft is putting a concerted effort into not only adding more support for JavaScript, but also for looking at the state of JavaScript and looking to improve the experience for people like me.

In Anders introduction to TypeScript, he mentions the gap between .NET development and JavaScript and hints that this is just the beginning of bridging that gap.

Rather than being a language that hides the underlying structure (a la ASP and ASP.NET) it is much closer to native JavaScript development. I'm really excited to see where this might go and have my fingers crossed that it only improves the state of JavaScript development.

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

#26

Post by bascule »

"What I like about TypeScript - so far - is that TypeScript’s static typing could enable better tooling with warning squiggles, easy statement completion, plus smart refactoring. You also get easy navigation around code, as well as find references, rename, and more."

RubyMine (by IntelliJ) can do all of that. Don't get me wrong, the refactoring support for statically typed languages is a lot better (e.g changing method signatures) but none of the examples he listed require one.

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

#27

Post by MatthewPhillips »

oinksoft wrote: post #22
MatthewPhillips wrote: post #19

Earlier quoted context omitted.

Does goog.require() resolve at run time or compile time?

You're realistically only going to deploy a compiled script. The compiler supports goog.require/provide() without requiring any JS inputs, and core tools like closurebuilder.py (which has superseded calcdeps.py) build your dependency graph for you. The compiler uses the require/provide statements to ensure that all necessary symbols are indeed provided, and are only included once in the script. For debugging purposes…

Yes, my question is whether goog.require() executes on the client's computer (in production) or whether Closure strips out those calls when you pass a special flag (as part of your deploy build). I personally don't want dependency resolution to happen at runtime in production.

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

#28

Post by krohrbaugh »

First of all, I'm glad Microsoft is getting involved in this space. They have a deep talent pool when it comes to language design and tooling and it'll be interesting to see where TypeScript goes.

Unfortunately, the arguments trying to draw some kind of monumental distinction between TypeScript, Dart and CoffeeScript are silly. They are all a response to the state of client-side development and are all applying essentially the same strategy (i.e., some syntax changes and a pre-compiler). It's great that TypeScript is a superset, which is what makes it pretty interesting to me, but it's still more similar to the other two than not.

Plus, what's so bad about being Microsoft's "answer" to something else? Windows was the response to Mac OS, Xbox was a response to PlayStation, .NET was the response to Java, ASP.NET AJAX was the response to Prototype (later abandoned for jQuery), ASP.NET MVC was the response to Rails, Entity Framework was the response to Hibernate/Active Record, NuGet was the response to Rubygems/npm. Each of these moved MSFT forward and several of them moved the industry forward. The ASP.NET team (of which Mr. Hanselman is a member) is doing a lot of great stuff inside MSFT, but a lot of is derivative. That's okay. It's largely the strategy MSFT has always followed, so why waste energy defending what has worked well in the past?

I agree with one point, however: It is disappointing when smart people display a profound ignorance of computing history.

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

#29

Post by TazeTSchnitzel »

krohrbaugh wrote: post #28

First of all, I'm glad Microsoft is getting involved in this space. They have a deep talent pool when it comes to language design and tooling and it'll be interesting to see where TypeScript goes. Unfortunately, the arguments trying to draw some kind of monumental distinction between TypeScript, Dart and CoffeeScript are silly. They are all a response to the state of client-side development and are all applying essen…

> essentially the same strategy (i.e., some syntax changes and a pre-compiler)

TypeScript and CoffeeScript, yes. Dart's a brand new C-like web language that is quite different, and has its own VM. Although, of course, you can still compile to JS. But unlike TypeScript and CoffeeScript, it isn't really an alternative syntax for JS, or annotations removed at compile-time.

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

#30

Post by oinksoft »

MatthewPhillips wrote: post #27
oinksoft wrote: post #22

Earlier quoted context omitted.

You're realistically only going to deploy a compiled script. The compiler supports goog.require/provide() without requiring any JS inputs, and core tools like closurebuilder.py (which has superseded calcdeps.py) build your dependency graph for you. The compiler uses the require/provide statements to ensure that all necessary symbols are indeed provided, and are only included once in the script. For debugging purposes…

Yes, my question is whether goog.require() executes on the client's computer (in production) or whether Closure strips out those calls when you pass a special flag (as part of your deploy build). I personally don't want dependency resolution to happen at runtime in production.

Erm ... like I said, it happens at compile-time. The library provides a runtime version for testing purposes. Sorry if I wasn't clear enough.
Post reply on HN