Why does TypeScript have be the answer to anything?(hanselman.com) |
Why does TypeScript have be the answer to anything?(hanselman.com) |
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.
Yeah, this was kind of an odd non sequitur that didn't go anywhere. I half-expected the article to actually give an illustration from computing history.
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.
At a high-level, though, and in the case where browsers are the target platform, those aspects are largely implementation details.
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 vanila JS (Dart just started, and until it has it, it's just a play-with language)
4) TypeScript support for most popular editors (Dart has mostly Eclipse I think, TypeScript has support for everything but eclipse, but an eclipse plugin is just a matter of time probably)
5) TypeScript has a bit more chance becoming a standard, (future ECMASCript 6?)
Well played Microsoft, didn't see it coming...
VS 2012 is actually nice, still I would probably wait for an Eclipse plugin (I'm sure someone out there is already working on it) but this is for me a big reason not to start learning Dart
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. Regarding that, it is kind of answer to forces that are trying to ensure domination in that domain for the future.
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.
Do you mean sell as in for money? Or sell as in get people to adopt? Under an Apache license, I doubt it's the former. Although they could sell the Visual Studio tooling.
I highly doubt that they created TypeScript to try to sell more copies of Visual Studio. I mean TypeScript is under the Apache 2.0 License so I don't see what would stop other IDEs (like JetBrain's WebStorm/PHPStorm/RubyMine/etc...) from integrating TypeScript into them (and I really hope they do soon).
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.
When people argue for static types (whether optional as in TypeScript or mandatory), one of the main reasons is "tooling". Why?
I know that writing a "go to definition" function for your IDE is impossible to do 100% correctly, when types are dynamic. But I would've thought it'd be pretty easy to do a 99% implementation, which rarely fails if you don't deliberately write code to fool it. Right?
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')) {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.
And yes, they're all variants of ECMAScript. It's a mess!
A build step is already a reality for many people writing JS today.
Even so, a build step can be a single keypress, so its no big deal.
Edit: I'm currently using Chirpy to compress and unify all my JavaScript, anyway. So this isn't even really a concern.
And you can use plovr to recompile on every reload (takes 5-10s) if you need these warnings in your workflow at every step.
With good tools (IDE and build automation) coupled with continuous integration/deployment, this doesn't have to feel like a tax.
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 the code you wrote-- it's generated code.
I feel no better informed after reading this article than before. Will someone please do a straightforward comparison between Dart, TypeScript, and CoffeeScript? It might be kind of hard because as far as I can see, TypeScript does not build on Linux.
P.S. Is "it doesn't even use the JS numeric type" supposed to be a put-down of Dart? I always thought the JS numeric type was a big mistake. Who would want to be forced to use floats for everything? Inaccurate and slow-- two great tastes that taste great together.
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.).
I've worked on large code bases in several languages and JS has to got to be one of the worst when it comes to code quality due to the flexibility. It's always an awful experience trying to refactor a large portion of JS since it's difficult to even find where objects are being used. I'd take AS3 over JS anytime of the day since it allows me to specify types (though optional) and if I do the tooling is able to do a lot of the static analysis that is important in large projects. TypeScript still gives you plain old JS while allowing you to specify some extra information in order to facilitate development. It's actually new developers that aren't aware of these things and love JS from what I've seen. They haven't worked on large code bases and love the flexibility of JS. When you actually are trying to create proper abstractions in order to architect your code, you need visibility modifiers, you need interfaces, and you need types.
The idea that (optional) strict typing and (optional) well-defined OO practices would only work to act as a "safety net" for new developers is, quite frankly, ludicrous. Static typing is the bedrock of static analysis and if you can't see the value in static analysis, take a read here - http://www.altdevblogaday.com/2011/12/24/static-code-analysi...
You're welcome to keep doing things the hard way. You will certainly be enabled to do so since Javascript is not going anywhere. But easy-to-use Javascript-compatible languages with powerful, precise and accessible features are the future, IMO. I don't think I'm alone in that sentiment given the recently budding interest in this arena.
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 "JS lacks classes!" - I'm not sure they understand JavaScript.
This is a type, not a class, taken from a Closure Compiler docs annotation example:
/**
* Enum for tri-state values.
* @enum {number}
*/
project.TriState = {
TRUE: 1,
FALSE: -1,
MAYBE: 0
};
/**
* Do something...
*
* @param state {project.TriState} The state ...
*/
function doSomething(state) {
The classes in TypeScript are a formalisation of a very common design pattern in Javascript, so obviously people do think it's useful. TypeScript takes the common practice and makes it more succinct. (Other than inheritance, which does seem a little un-JSy)
I've worked on a couple of these applications, they almost always end up having some fake-class system that provides mechanisms for encapsulation, code sharing, and namespacing. There's often almost a hundred of these fake classes defined with thousands of instances living in memory. I grant you that you can use things like the module pattern to accomplish those requirements -- in fact, if you couldn't, then I wouldn't be here talking about it because I'd be writing Java applets instead. But the lack of having static typing to catch simple errors and enabling basic refactoring tools (like renaming something without having to use a regular expression which took 2 hours to "perfect", or simply switching argument orders, etc) was the absolute worst. I've spent countless hours debugging problems that occurred because something like a string was accidentally passed when an array was expected, and only having the actual runtime error occur 50 function calls later because something like "cat"[0] was working fine up to that point. Static typing would have caught that before I even ran the app.
Anyway, these types of apps perhaps aren't as common as websites, but they exist and therefore there is a need for statically typed languages for the browser.
This ought to be a classic case of "worse is better", which is why I'm surprised to see that people seem to shy away from it.
Tooling makes your life so much easier. I don't understand why people would resist optional typing.
(I actually also came to say, damn, y'all, IDE support is awesome, and it's here for dynamic languages. Go-to-declaration alone is lifechanging, since it's usually faster to jump into a library call with ctrl-B than to check the docs. Live error highlighting alone is worth it. Just give JetBrains whatever they ask for.)
TypeScript language service is developed in TypeScript. This is how they can host these type of function on the browser. It's all just JavaScript
Check out this screenshot from the playground http://i.imgur.com/H2rqD.png
/** @type {myType} */ var thing = new myType( );
var thing : myType = new myType( );Also, I think that the first example is more likely to be written as follows (in the case where type data cannot be inferred):
/**
* Description of the variable.
*
* @type {my.UnionType}
*/
var foo = { ... };
/** @type {myType} */ var thing = function_that_returns_a_myType( );
Unless you are performing integration tests, there is no reason to compile each time. Doing that is just the legacy of limited build systems.
There are plenty of people who actively have build steps for web development: SASS, Less, CoffeeScript, CSS.
print "Which do you like better: cars or trees?
let a = AskUserForInput()
var b
if a=="cars" then
b = new Car()
elseif a=="trees" then
b = new Tree()
endif
b.DriveOnExpressway()
While that's a contrived and simplistic example (that you probably could somewhat easily detect with tooling/analysis) think about a language like Javascript where there are no classes and you may be adding or modifying a bunch of an object's methods at runtime. At coding time, the tooling doesn't even know if foo has a .bar() function, much less which .bar() function, much less if the particular .bar() function that foo may have is being called with acceptable parameters.
edit: even my pseudocode is buggy ;-)
Basically it will complain if neither Car or Tree have a DriveOnExpressway method, but it's fine if one of them does -- the warning goes away if I uncomment the method. So there's ways to fall through the safety net, but lots of things it will catch.
(In Javascript, it's looser -- it only flags a potential problem if "DriveOnExpressway" isn't defined at all in the file.)
But a tool like "go to definition" would work fine, wouldn't it? Maybe you would need a heuristic that guesses what are the possible types b could have, and detects that Tree doesn't have DriveOnExpressway, so it takes you straight to the definition in Car. Certainly, there are more complicated cases where guessing b's type is harder or impossible. I'm not denying that.
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.
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.
I admit there are cases (refactoring is an example) where if you don't trust the tool 100% you won't use it. But many tools are not like that.
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...