Shared publicly  - 
 
Microsoft's TypeScript may be the best of the many JavaScript front ends. It seems to generate the most attractive code. And I think it should take pressure off of the ECMAScript Standard for new features like type declarations and classes. Anders has shown that these can be provided nicely by a preprocessor, so there is no need to change the underlying language.

I think that JavaScript's loose typing is one of its best features and that type checking is way overrated. TypeScript adds sweetness, but at a price. It is not a price I am willing to pay.
185
81
Larry Trutter's profile photoAaron Frost's profile photoChristopher Done's profile photoLucas Gabriel Sánchez's profile photo
93 comments
 
Interesting to see that +Douglas Crockford likes the effort. Many observers commenting today -- for instance, +Miguel de Icaza -- were dismayed that the developer's story is good only inside the Microsoft universe due to things like lack of Intellisense.
 
Does the price you are referring to include other factors besides the strict typing?  If so, could you please elaborate?  It occurs to me that using SoftTyping could remove the JavaScript developer too far from the guts of the language; thereby leading to a lesser understanding of the language, like ignorance of prototypal inheritance.
 
The compiler is open source, so what's to stop WebStorm from integrating their own? Strong Typing is a lifesaver on large projects.

It's a miracle some of these larger javascript classes even run, hundred of files/classes, not a single one checked by the compiler, somehow works but it's scary and extremely brittle... for the sake of sanity, having the compiler tell me everything is at least talking to eachother correctly is a huge lifesaver.  Not to mention you can find obvious bugs immediately, not waiting until the code is executed (or not executed) at runtime.
 
I hear people talk about their beloved Strict Typing.... and then when I read their code I find things like HashMap<Object, Object> or HashMap<String, Object>. Really? If this is how you use your strict typing... you would love JSON. So much easier. I agree with +Douglas Crockford. Loose typing a strength, not a weakness. 
 
+Shawn Blais, don't forget that in lieu of strong typing, tools like JSHint and JSLint perform part of that development-time checking, though it's not as strong as strong typing per se.
 
So the occasional use of a hash map invalidates the advantage of strong typing across a hundred-thousand lines of code? Give me a break. It saves hours/days/weeks of deveoper productivity, scaling up higher and higher as the projects get bigger and longer.

There is a very real limit to the 'responsible' size of a code base that is using loose typing. At a certain point it just becomes a pile of Shit flavored Spaghetti.
 
+James Raden Sure, thats cool. I just don't get this argument that somehow loose typing is advantageous  Sure, when you're scripting, small scripts, then a scripting language is perfect. Fast, flexible, easy.

In a big fat codebase, that has multiple dev's, and a multiyear lifespan, it's no contest. It's  literally ludicrous to contend that Strong typing is not a huge win because of what it enables the compiler/IDE to do.

Refactoring support is hugely important. Fact is, refactoring does not get done on JS projects cause it's too scary. This is part of what leads to these horribly gross codebasews.

Trustworthy code hinting is another huge win within a big code base, you don't have time or ability to memorize every member name in every class.

Touching the entire code base doing sanity checks across the board, is another massive time saver.
 
+Shawn Blais Unit testing is what gives me confidence in refactoring, not compilation time checking.  Refactoring happens all the time on JavaScript projects, especially those that employ unit testing.
 
+Shawn Blais, I believe the opposite to be true. We have had huge wins moving most of our code to the client, using the back-end for REST and Security mainly. Our server costs are 1/5th of what they were. App stability is through the roof. I don't doubt that you have had success with your Strictly Typed projects. I am pointing out that people are having huge wins every day with front-end, JavaScript based apps. 
 
Just so we're comparing apples to apples, you're building complex web-Applications? Or websites? 
 
Complex apps. Enterprise apps. Used daily by the 50,000 service people that are here at the org. 
 
Fair enough, but I can't phathom it being enjpyable/maintainable. How do you guys test your code base? Tons and tons of unit tests?

It's interesting that the maker of the largest scale web apps, Google, is the one pushing hardest for a solution to this problem. I'd tend to think that their experience has taught them something, rather than 'there is no problem' which is the narrative here.

At least MS is now admitting there's a problem as well.

That really just leaves Apple pretending that the web is fine for building applications on. But, IMO, Apple knows better, they just don't care, it doesn't serve them to have the web actually be a capable App Deployment platform.
 
+Addy Osmani has written some good stuff about managing large scale JavaScript applications, though I haven't had to write one as large as what he's talking about. My apps have a few thousand LOC of JavaScript, not tens or hundreds of thousands. He was hired by Google only in the last few months; most of this writings on JavaScript predate this.
 
Thanks James, tons of good stuff there indeed :) 
 
Google is also the author of one of the most popular JS compilers today, Closure. Additionally, they just released an amazing new JS library that is making huge waves. Further, they have lent out members of their staff to jQuery and to the TC39, which forms the modern standards of ECMAScript. The problems that you are referring to are all tacklable. MS and Apple have also lent time and money to the TC39. 

You test Open Web apps the same way you test ServerSide apps. Unit Tests, Integrations Tests (manual and automated), and acceptance tests. 
 
What's the amazing new JS library? Their Closure library?
 
I'm not sure what any of that has to do with Google's position that Strong typing on the web is a valuable tool that needs to exist. Google contributes to all things Web, it's their lifeblood, these initiatives don't somehow cancel eachother out.
 
I agree. They don't cancel each out. They are both valid ;-) I was merely countering your point that we should all follow Google and avoid JS. Google doesn't avoid JS. Gmail, one of the most used apps on the planet is a JS app. That is all i was saying. Just correcting the leap you made the Google had somehow abandoned JS. If anything is true, it is the opposite. 
 
ha, I nevevr made that leap! I'm simply trying to get a general agreement that there is SOME value in strong typing. But apparently, judging by the +1's going around, I'm just crazy :p
 
I'm a big fan of strong typing, but others are not and I can see the arguments on the other side.
 
In my opinion you're all right.

SoftTyping appears to be what we in the Lisp-like languages call optional static typing.  See for example, http://opendylan.org/books/drm/Language_Overview .  Common Lisp also has optional static typing.  It has its limits though...you won't get  as much static checking as in a language like, say, Go or ML.

I want my language to support both modes of programming because they're both useful in their own ways.  Everyone understands that there are times when static typing can catch bugs before they manifest.  It's a bit harder to convince people that dynamic typing is so useful, but I agree that testing plays a big part.  There are costs to maintaining all the type annotations in statically typed code.  IDEs can help there, but IMO the type annotations often make the code more difficult to read.

I've seen just as much, if not more, crap code written in statically typed languages as I have in dynamically typed languages, so I don't think it's legitimate to attack JavaScript on that front.

Side note: There's massive confusion in the industry about terms used to describe type systems.  I'm assuming when you guys say strong/strict vs weak/loose you actually mean static (compiler) vs dynamic (runtime) type checking because that's what the context seems to imply.  Correct me if I'm wrong because I'm not a JavaScript expert.  Some of what JavaScript does strikes me as scarily weakly typed (e.g., '0' == false) so maybe you really did mean weak/loose.
 
People like static typing so they can grab some coffee or take a smoke break.

I'm not really against it as long as its done on someone else's CPU cycles.
 
I must confess I don't see the point of TypeScript.

My opinion is that many of the features TypeScript is bragging about are already slated for ECMAScript 6. As long as we're experimenting with a new language, why not create a spec-compliant implementation of ES 6 that compiles back to a polyfilled ES5 compatible with today's browsers?

I don't think we need strong typing at the language level. I'm OK with optional static typing, but I would consider it an anti-pattern for most purposes. I think we certainly need type validation at the object level for persistence and interoperability, but you can already get that (if you need it) with json-schema. It's an IETF draft in version 4, coming along nicely. http://json-schema.org/

+Frederik Krautwald I disagree with Angular's approach of adding data-binding to the DOM. Templates should be completely unaware of the data models that use them. I prefer declarative bindings that are independent of the DOM. For example, backbone.stickit http://buff.ly/NzWoAH

+Shawn Blais 
"Fact is, refactoring does not get done on JS projects cause it's too scary."

Not true. I have worked on many large JavaScript applications, and I have never seen one that did not have regular, frequent refactoring. I'm sure they exist, but not where there are competent JavaScript developers leading the charge. The comment about unit testing is spot on, whether you're using loose typing or not. I would add that modularity is your biggest friend when it comes to refactoring. Typing has virtually nothing to do with it.

For more on writing large JavaScript applications and how to write modular code that is easy to refactor, check out my upcoming book, "Programming JavaScript Applications" on O'Reilly.
 
HA, hey I'm working on a large project now and we're scared to refactor the C# code!
 
+Eric Elliott Thanks for the heads-up on backbone stickit -- looking forward looking into it, I was also thinking along the same lines regarding AngularJS. However, their short code approach to common HTML shortcomings can seem extremely appealing.

[edit] Purchased the early release of your book. ;)
 
I just don't like how Dart, TypeScript, GWT, etc. all put too much emphasis on inheritance and try to make the JS inheritance look like Java.
 
+Jack Donohue , obviously you haven't used Smalltalk. How many times did I personally run into dynamic typing issue in Smalltalk? Zero. Static typing introduces a higher degree of complexity that many people are unable to get their heads around, for example: dependency injection. Dynamic typing in JavaScript hasn't been an issue for me so far.
 
Now that's a ringing endorsement! +Douglas Crockford, just wondering: Do you think you might have missed an opportunity not writing a js front end yourself? All of the good stuff from JS: The Good Parts, implemented in a js front end and written way back when - that would have been quite something.
 
+Kinley Dorji Does JSLint not count?

+Jack Donohue Disbelieve if you like. I grew up with strict types. When I learned JavaScript it was like my hands had been tied all my life and I never realized it. I don't miss strong types at all. They get in the way more often than they help.

You have a false sense of security with strong typing, but it doesn't buy you as much as you think. A bike is a good analogy. Training wheels make you feel secure but they also limit your speed and prevent you from banking in the turns.

JavaScript took the training wheels off.

I feel the same way about classes. They're obnoxiously cumbersome and don't belong in JS.
 
+Eric Elliott Certainly JSLint counts. :) I was just thinking about the extra yards covered by the likes of CoffeeScript, ClojureScript and TypeScript, etc. in making just that desirable subset of Javascript readily available to the user.
 
I understand the sentiment on both sides of the table. Running free with dynamic objects is great for smaller projects with smaller teams and very productive when a developer's code is accounted for by its author or by highly proficient teammates. Formalities likely include unit tests where the test writer identified the programmatic requirements himself and implements the running solution code himself. But in a more structured organization and/or project, where the solution gets fragmented into disparate components and perhaps business objects are more likely to be defined with written specifications than with unit tests, using a classical language with compile-time type checking is a huge boost in software quality, which delivers productivity ROI in the long haul, as fewer out of band defects must be accounted for. In such environments, it's really not about you and your productivity, it's about the bigger picture and the guarantee of consistency.
 
I don't know how soft typing can be a bad thing... it's optional... use it/don't use it. Personally, I find that dynamic typing is awesome early on when things are still getting fleshed out, but when you have a substantial codebase and want to refactor (e.g. a parameter here while adhering to patterns like 1st param being an error, last parameter is the callback) having some level of type checking is invaluable.

I don't buy the argument that "that's what unit tests are for," why should I have to write a unit test for something that a compiler would normally pick up for me.

That said, I'm not a fan that they've brought across of the function short cuts/lambda expressions.
Example:
var array = [1, 2, 3, 4];
var sum = array.reduce((previous: number, current: number) => previous + current, 0);

The difference for me is that optional soft typing adds value and feels like a natural extension of JavaScript... Lambda seems completely foreign
 
+Milo Sredkov , I don't encounter "Message not understood" often. Sometimes, I even use it as a starting point to define a new method while in the debugger. ;-)
 
+Jack Donohue There's a lot of FUD about static typing, probably due to Java and C++’s treatment of it. Honestly, I simply do not believe people who claim not to have runtime errors that could've been caught statically when maintaining large systems. Maybe they could put their money where their mouth is, and show an unfiltered list of all exceptions thrown in staging and production, but, you know, they are not into being explicit about anything… I also have no idea where this “good for rapid prototyping” claim comes from. Either your code is right and it will work, or it's not.
 
One should have used both statically typed and dynamic languages extensively to come to a conclusion as to what works for their thinking style and coding skills, if you will. What's more, dynamic languages themselves often take different paths in relation to typing: Ruby is strongly typed, Javascript is loosely typed.
Having had extensive formal education mostly in statically typed languages, and professional experience mostly in dynamic languages, I rarely run into situations where bugs are type-related. And that is regardless of the project size.
I am in favor of dynamic languages unless the situation calls for better performance or due to any other tangible reason. Usually due to the tendency among dynamic languages toward less syntactic overhead, less ceremony, more syntactic sugar and more space to focus on describing the problem as opposed to satisfying the language's infrastructure. What I can suggest is, be pragmatic and write tests. To prove the correctness of our code, we are probably better off relying on our tests, and not on the language's features.
 
I think it's really sad that the static vs dynamic debate is so polarized.

There are certainly benefits on both sides. The last project I worked on was a fast growing coffeescript app, and there were times I wished I had automated refactoring tools that are common for statically typed languages. Unit tests allowed us to safely refactor, but it's still a more manual and time consuming process.

On the other hand, I think working with dynamically typed languages is much more enjoyable, mostly because the code tends to focus much more on the problem domain and less on ceremony. It's easy to dismiss this, because it's much harder to measure the gains as opposed to automated refactoring, but I think it's much more important.
 
+Anton Djurasaj Well, writing tests is orthogonal to static checking. Static checks detect bugs we don't care about and universally rules them out. The kind of bugs that static checks can't detect are the only kind that I want to deal with. If you are diligent enough to be writing tests and care about code quality, then (1) why do you not want static checks? — if your code is such high quality you will have very few static errors “getting in your way” and (2) if you are motivated to write tests then you understand the human is flawed and that you need all the help you can get, which includes any static checks available. Unit testing, property testing and static proving are all complimentary tools to prevent bugs, help you develop (refactor, complete, etc.) and any modern language should offer them. Regarding “syntactic overhead”, you're clearly thinking of Java and C++ and such languages that require type signatures. Regarding syntactic sugar, I don't know what that has to do with anything; it seems you think dynamic features (not just dynamic typing but also dynamic binding, unsafe reflection, etc.) are somehow related to completely separate features such as convenient syntax.
 
+Jon Davis I have spent years working on large code bases with teams of JavaScript developers. We do encounter many different classes of bugs, but calling functions with the wrong parameter type just doesn't happen much, because if you did that, the code would never work in the first place. If you're running with TDD and you exercise all the code you write, the class of bugs you describe rarely comes up.

But my biggest gripe about type checking is that type flexibility Can actually be a huge advantage. Flexible, type-agnostic, generic API's can aid developer usability and code re-use, and that's a big win for large teams. Take the generic string / array methods for instance.

In any environment, if you're not writing unit tests, you're doing it wrong.

+Soc Sieng JS has always had lambdas. ES 6 is bringing us lambda shortcuts. They are completely natural in JS and completely necessary.

+Anton Djurasaj has it spot on.
 
+Christopher Done Well said, but I think you over-estimate the importance of static checks vs the gains in code readability, simplicity, and flexibility that come with loose typing.
 
+Christopher Done Yes, tests and static checking are two different things. I should have been clearer regarding the intent to extend the discussion into areas other than static checking per se. When available, I surely use it. To make it clear, I am definitely not against static checking. But, I will not make a language choice based on a feature, but rather based on a problem at hand.
On the whole, the culture around dynamic languages tends to be more focused on the things that I mentioned. Which I find more suitable for the majority of use-cases that I have to deal with. My point is that the ongoing debate is almost entirely experiential in nature and sometimes puts ideology before context. On a case-by-case basis, I am confident that we would find problems that are better solved in one paradigm over the other.
Like +Eric Elliott implied above, exercising your code as part of TDD (or BDD) is often times enough to prevent bugs. I agree, static checking puts another layer of protection, but often times at the expense of type flexibility. There are definite pros and cons to both. I guess TypeScript is an attempt to relieve you of the burden of choice beforehand. Discipline is the key.
 
+Carl Gay I think you're spot on. If you've tried to write a largish-scale JS application, you'll know that unit/integration tests are a must, especially when dealing with services and templating and all that jazz. There is a place for both in Javascript and I like that TypeScript gives you that flexibility. For example, in a helper function, you'll probably always want to type your parameters. But in a factory-type function, maybe you do want to play loosey-goosey and just write tests around it to ensure it doesn't break when you change something somewhere else.

There's power in both, I guess is what I'm trying to get at, and it's up to the developer to know how to wield them.
 
Looking through a 3rd party library in a strongly typed language is much easier than looking through a library in a dynamic language like JS.  With JS, good documentation is pretty much required.
 
+Eric Elliott I think you're still thinking about Java and C++. In Haskell, I don't write any types unless I want to, for documentation purposes, which makes it more readable. I think you underestimate the power of static checks which permeate your entire codebase and add information that you and other people can use. Just relying on unit tests is great when your problem domain is easily testable, but in a general sense it's rather risky. I don't know what kind of tests you write, and I would like to see some nontrivial codebases you have written so I can see, but I find it hard to write unit tests for nontrivial code. In the same way, Haskell's type system goes a long way to eradicating exceptions, security problems, confusion of e.g. a user id with a order id, etc. (giving you time to just think about the problem domain, less need for unit tests), but again, relying on it alone is risky. It is a completely false dichotomy to choose one or the other, it should be both, in varying degrees, in my opinion.
 
+Christopher Done This is a little off topic, but generally if the problem domain is too complex to be easily tested, it should be broken down until unit tests can easily bite it off. There are test situations that require coordination between components. Those should be covered by integration tests, instead.

Generally I am opposed to monolithic application structures at all. A complex app should be made up of lots of small, independently testable components, and static checks "throughout the codebase" starts to sound like a much different problem. Each module can literally be treated like it's own codebase, and the only tight happens between modules and the app sandbox, or modules and submodules.

I am not against optional strict types in JavaScript. I just think they'll be misused a lot because of all the FUD that strong type supporters like to sling at loosely typed languages. I think that would be a step backwards for JavaScript.
 
+Evan Larsen I think that is your preference. Many of us prefer to read a non-static typing. Just like some dinosaurs still prefer XML to JSON, it is a preference. 
 
+Eric Elliott What are some examples of open source codebases written with this approach? A nontrivial system which is split up into components and unit tested, with no static checks. Frankly I just don't believe that people write such fine-grained tests outside high assurance systems, and for things other than parsers/generators which are easy to test. What about UIs, network applications, filesystem operations, etc.? What are the (presumably many, esp. in JS) projects out there that are classic examples that do this?
 
Great post. I love JS but TS and Dart do interest me a lot, optional typing is best of both worlds for me. The biggest advantage I see isn't the compile time checking, its the self-documenting aspect that I miss most when working with a dynamic language and looks like some of these newer languages give me it without forcing me into the straight jacket of always specifying full typing.

+Shawn Blais Having used both approaches there's definitely nothing at all wrong with dynamic languages and they don't necessitate the issues you are describing. Good discipline is needed but it always is anyway.
 
I haven't used a mixed type language. Seems like an anti-pattern. Sometimes types... other times no types. It might feel nice... but it seems like it would be more confusing. 

Again, I have never used a language that does this, so it might not be as bad as it seems. 
 
+christopher done I'm not aware of any large open source JavaScript apps to list as examples, but I know they're doing modular, unit tested JS over at BandPage (many tens of thousands of lines of JS), here at Tout (I recently came on board to lead the charge), and other places. This is an emerging trend in the JS community. Just because you're not aware of it does not mean it doesn't exist.
 
Seems to me that you can have your cake and eat it too - as Typescript allows "untyped" variables - it eats every Javascript you throw at it.

I have started playing with it and I have to say that the added development time saving thanks to better tool integration is a benefit - I usually do not have any issues with Javascript when I develop the code - but when you come to something that was written a long time ago in a really big system - you run into issues, especially if it was not you who wrote that code. That's when static typing helps to save your rear-end. I believe I will be using TypeScript going forward for some projects - but will keep untyped variables where they make sense.
 
Everyone is free to use whatever they like.  But to me, adding type-checking to JavaScript is like adding a schema manager to MongoDB.
 
+Ganbold Ganbat if anything is true, it is the opposite. Google, in addition to GWT and Dart, is the author of Closure and AngularJS, two of the greatest JS platforms today. You too a leap from reality when you claimed that Google is "giving up on" JavaScript. They are actively involved in both of the libs I mentioned, and they are actively participating in TC39, and are internally building Traceur-Compile (a lib that will be integrated with very many build processes around the planet). Perhaps only Mozilla is more invested in the success of JavaScript than Google, but even that is a stretch. Try another example, cause you just failed with this one. :(
 
+Aaron Frost Well, Google made Closure which implements a static type system for JS and I know a couple devs who work on GMail and everything is annotated and type checked. They have compilation servers that just sit re-compiling developers' builds all day. I use Closure myself for this reason. So +Ganbold Ganbat's example is perfect. JS alone has proved insufficient for large scale development by excellent professionals. TypeScript basically solidifies the lessons learned from that project into convenient syntax.
 
+Christopher Done Closure has what is know as "Strong Typing" not "Static Typing" like you claim. It is a middle of the road solution that many think is an anti-pattern in itself. So, I disagree again. 

+Ganbold Ganbat JS is supported on App Engine, on the front-end ;) As for back end, who knows. They don't have any interest in the NodeJS project. They gave away V8 so that things like this could happen. Thats right, they built the most powerful JS engine around, and then gave it away, so that people could do awesome things with it (like node). Hardly the behavior of a company that wants to EOL the language. As for AngularJS, Google regularly has Hangouts on the topic, they had sessions on AngularJS at GoogleIO2012. They just introduced an extremely powerful front-end dev tool for JS?CoffeeScript developers called Yeoman. It make use of some of the most popular tools around for front-end (read: JavaScript) development. For you to make the leap that they are somehow moving away from JS still makes me laugh, since they have given no indication that this is the case, and have only ever fought to make it better. 
 
To those commenting on value of static typing in 'large apps' , I'd like to refer you to this quote from Justin Meyer:

"The secret to building large apps is never build large apps. Break your applications into small pieces. Then, assemble those testable, bite-sized pieces into your big application"

The problems that static typing solves, and the problems faced in large applications are orthogonal.
 
+Tim Oxley The key word in your quote is “assemble”. How do you think you assemble those parts together?
 
+Aaron Frost Well, it's a flavor of “strong typing”. It's not exactly the best they could have come up with. But nevertheless, the type checking (and other checking) is determined statically. Did you even try it?
 
+Gregor Elke True, TypeScript won't prevent this kind of error, unfortunately. However, Haskell, F# and other languages can handle this kind of bug without throwing errors at the user, the error would be thrown at the programmer, during compilation. Static typing can save you from null/undefined errors, but TypeScript's type system can't.
 
+Gregor Elke There are no null pointer exceptions in Haskell, there is no implicit "null" in every value. I don't think I have to explain what we win. At any rate, as I said, TypeScript's type system is a start. Your attitude is the usual throwing the baby out with the bath water this-system-doesn't-solve-all-my-problems-so-let's-not-bother-using-it.
 
I think the pot just call the kettle black
 
At the core, static typing is nothing but compile-time enforced documentation.

I fail to see how this is a bad thing; if you want to go dynamic just stick everything into objects and cast it to whatever you expect it to be. That's "kinda" what dynamic languages do anyways.
 
+Martin Egri Good point, some people tend to view static typing as extra labour (and uglyfying of the code) in exchange for having to write fewer unit tests, but the important thing is that types are a very nice tool for understanding and reasoning about the code.
 
+Aaron Frost Please explain how that is the pot calling the kettle black. If such non-sequitor is how you choose to end the discussion because it has gone out of your scope of expertise then just say so.
 
I can't see anything in TypeScript that enforces type checking? The ANY type is there if you don't care what a parameter is.

Strange thing to pick of all the TypeScript features anyway. As a newbie to JavaScript I was constantly shaking my head at the weird constructs you have to manually put together to make it work properly. These don't add value and make the code less readable.

JS Namespaces? Oh, define an object that's defined if it's not defined, but returned if it is defined. It's a hack, admit it.

Closures? Great: but it's a 'class' in all but name. So here is a 'class' in TypeScript, inside a namespace:

------------------------------------------------
module MyApp.MyNamespace {
 export class MyClass { 
 }  
}
------------------------------------------------
That's two lines of code. What JavaScript does this compile to?
--------------------------------------------------
var MyApp;
(function (MyApp) {
    (function (MyNamespace) {
        var MyClass = (function () {
            function MyClass() { }
            return MyClass;
        })();
        MyNamespace.MyClass = MyClass;       
    })(MyApp.MyNamespace || (MyApp.MyNamespace = {}));
    var MyNamespace = MyApp.MyNamespace;
})(MyApp || (MyApp = {}));
------------------------------------------------

Please explain how the raw JavaScript is better. I'd love to hear that explanation.
 
+Howard Richards classes and modules are making their way into ES6 already. In fact, the syntax you're using is inspired by those features. What confuses me about Typescript is why they give it a new name at all. Why don't they call it an experimental pre processor that gives you access to possible future JS features today? The risk of using a non standard version of Javascript seems about the same, anyway.
 
I agree with +Eric Elliott. Further, if you are going to chose a language that transpiles to JavaScript... I think that Dart is a better language. The syntax is not difficult to adjust to. Very similar to JS and Java. However, Dart is an actual language. It isn't just a transpiled load of bullocks. It has it's own VM and it has the possibility of running one day native in a browser. So... having a one language solution on both front-end and back-end is a win. When developers have to context switch back and forth from languages when doing their client and server code, they lose productivity. Something like JaveScript + NodeJS or Dart + Dart help reduce that kind of productivity decrease. 

Neither Dart or TypeScript are going to get you completely accurate type compiling since it is optional at different levels in both languages, so I say chose the one that makes the most sense. Otherwise, stay true and do it in JS. 
 
I disagree with +Douglas Crockford on the "price" of type checking. The only "price" I have ever paid in writing code in a strongly typed language is a few extra keystrokes here and there. Period. That's it.

And don't let people fool you into thinking JavaScript is "just missing some good tooling". If that were true, it would have happened by now. Seriously, it would have. JavaScript is used by a LOT of people and has been around for a LONG time. The human race is smart enough as a collective to solve problems like this when they're possible to solve. The reason we don't have decent javascript tooling (at the same level as the tooling we have for, say C# or other strongly typed languages), is that it is fundamentally impossible without some form of type annotations.

In fact, the only good javascript tooling that has come close to what I've seen for C# for example, has made use of type annotations in comments, like closure. I don't see that as being ANY DIFFERENT fundamentally from efforts like TypeScript. You've just moved your type annotations out of the language syntax and into the comments. No functional difference between the two approaches. In my opinion, having them in the language syntax is more readable than having them in a comment. In fact, you're really just defining a new language, which is a superset of JavaScript with a cumbersome type annotation syntax.

The thing that gets lost in these conversations is that most javascript code in the real world is strongly typed. That's an outrageous claim. Let me explain: When you write a function with some arguments - your function code often has expectations about what those arguments ARE. Your code may not work correctly if you pass a Number. Those expectations are part of the "contract" of that function.  Even if your object dynamically iterates through the fields of any type of Object, your contract is still "give me an object, which implicitly is a thing that I can iterate over all the fields of". Any time you take an argument, return an object or a function, or interact in any way with any other component of the system, you do so through an interface. With JavaScript, the interface is implied (unless you use a tool like Closure). With TypeScript or any strongly typed language, it's explicit and statically verifiable. 
 
LOL +Jeremy Bell!!! Among the many leaps you make is your claim that it only take "a few extra keystrokes here and there" to implement the same kind of typing between JS and C#. I literally laughed audibly (LLA? because LOL doesn't mean what it used to) when I read that. Having spent significant time in both, I would like to point out that it isn't a keystroke here and there, it is hundreds of boilerplate lines of code here, and hundreds of lines of it there... AND a few dozen extra class files here, and a few dozen extra class files there. Many JS people have experienced both sides of the game, and have opted for a simpler JS solution. Those who favor intense class systems arrive on the scene and try to turn JS into something they are familiar with, rather than learn it. The latest of which is TypeScript. MS particularly has gotten devs so used to tooling that they can't function without it. I can tell you that it is possible to program without an IDE telling you how to do it. Yes, even on "large apps". TypeScript is an effort of MS to try and stay relevant in the age of the Open Web. Perhaps they aren't in denial anymore and are trying to maintain relevance. How can they keep making licensing money for IDE's if no one has a need for an IDE like theirs?

And too the point of large apps, even large apps need to be broken out into pieces, pieces that aggregate into the full app. Those pieces are EASILY maintainable, no matter the language that you are using. If they aren't, then you are doing it wrong. You show me an app with so many pieces that it isn't manageable, and I will show an app that needs to become modular. 

Ultimately, I think that there may be an easier way for me to say what I am thinking. JavaScript is not Java, and it isn't just for Scripting. I think that people hear both parts of it's name and draw bad conclusions. The "Java" piece doesn't mean that it was intended to be Java in the browser. JS is guilty by association here, not by implementation. It simply means that Sun paid Netscape money at the right time, and got their brand on it. That is why many people (like +Douglas Crockford) refer to it by name as ECMAScript, cause it takes that name-confusing away of it. The other part of the name is Script, which implies that it is a simple scripting language, which as we now know could not be further from the truth. With the growing list of WebAPIs, which list increases almost daily, there is much more of an education to be had around JS. People who show up and expect to understand it with a few insincere hours of reading are only fooling themselves. JavaScript is a first class language. It is unique, and is that way on purpose. 

In the latest ES6 release they are considering adding Classes to the spec. This is scary to me. This is also what TypeScript is trying to do. I can already imagine the day when we see "AbstractGenericObjectToObjectHorriblenessMappingServiceImpl.js".If you are on a project that ends up with a class names like this.... you failed. 
 
+Gregor Elke You don't have to ensure in code via code checks the parts of the contracts you specify with a static type system, the compiler ensures it for you.

+Aaron Frost It's true that classes and inheritance have been way overused in the Java and .NET  worlds. Being forced to put everything into classes is silly, it is a good thing that people (even former die hard OO fans) nowadays tend to realize this isn't always the best thing to do. It may be that static typing helped making this over-engineering practical/possible/easy and therefore in a (very) weak sense was "responsible" for it because it enabled it, but to conclude from this that static typing is inherently bad is wrong. (One cannot convincingly argue that static typing itself is bad with only knowledge of C# and Java, these languages wouldn't even have represented state of the art in static typing during the 70's, much less today.)
 But even small wins for static typing, like being immediately able to tell whether a given argument to a function is supposed to be  a string or a number or an object (and if the latter, what assumptions are being made of the object), is to me extremly valuable. In fact it's impossible for me to understand why anyone can argue why it is a bad thing to be forced to tell a little about what kinds of arguments are expected, except in the tiny minority of cases where you actually don't want to put any constraints on a given argument at all because it really isn't "used" inside the function, only passed on somewhere else or wrapped into something else in a well-defined way.
Aaron, I agree that if you are on a project with a class named AbstractGenericObjectToObjectHorriblenessMappingServiceImpl, you "failed". But would you agree with me that if you are on a project with code like this (pasted in from a  project on GitHub), you similarly "failed"?

function createConnection(/* [port, host, options] */) {
  var options = {};

  if (typeof arguments[0] === 'object') {
    options = arguments[0];
  } else if (typeof arguments[1] === 'object') {
    options = arguments[1];
    options.port = arguments[0];
  } else if (typeof arguments[2] === 'object') {
    options = arguments[2];
    options.port = arguments[0];
    options.host = arguments[1];
  } else {
    if (typeof arguments[0] === 'number') {
      options.port = arguments[0];
    }
    if (typeof arguments[1] === 'string') {
      options.host = arguments[1];
    }
  }
  return tls.connect(options);
}

To my "static" eyes, this code is very scary crap and shouldn't belong anywhere at all, especially not in code meant to be used by many. I hope it is just as bad to "dynamic" eyes! :)
 
+Jarle Stabell, the koolaid is in my veins. 

I can see that this looks scary to "static eyes". However, it is from a code Nodejs library. The fact that core Nodejs looks like this, it makes it much easier for someone to use. This kind of checking is how JS deals with not having method overloading. So... for this type of parameter scrubbing... I could go either way. I like that in languages like Java you can method-overload to assimilate different signatures. In JS, you do it like this. I like both ways. Both are readable to me. I wouldn't pick JS's over Java's. 

Also, I will add that this kind of code exists for library authors... not for library users. If nothing is offlimits, and we can attack library writers... then this conversation quickly turns into finger pointing. However, JS encourages a simplistic approach. Java (and C#) appears, to me, to encourage an extremely generic and abstracted approach, which is the same as saying while(true) boilerplate++; It get's to be so abstracted that it quickly loses any intuitivity (if such a thing exists). You can only Ctrl+click through so many libs before you just forget where you are even at anymore. (sorry that I keep picking Java and C#, they are just two of the most prominent OO langs around)

I am sure that there are some truths to what we are both saying... however, as with many other things in the world, it appears that there is a lot of preference here to consider. Preference == opinion. I think that we just have different opinions. No harm there. Just good debates ;-)
 
+Jarle Stabell, very well-said. I disagree with fundamentalism in just about every realm of life -- the purists who think that no type declarations are ever good are just plain mistaken, in my opinion. I think the best of both worlds is probably in the middle. Witness C# adding dynamics and JavaScript adding type declarations via TypeScript (and other, similar ventures). Those modifications are in a direction away from fundamentalism and toward moderation, thus strengthening both languages and extending their usefulness.
 
+James Raden Yeah, you have to be very specific about that or the pedantic-police will shake their blogs at you angrily.
 
+Aaron Frost Even if you are correct about the true amount of extra keystrokes and infrastructure that type systems require (which is not always the case, but I'll grant that it CAN be true), that doesn't change the fundamental problem with weakly typed languages in general. Which is, no matter how "dynamic" you think your code is when you write javascript or ruby or python code, your code is never truly dynamic - software components have to talk to each other. In order to do that, they have to have an agreed upon protocol in which they can talk - a "contract", if you will (type systems are only a subset of the full set of potentially verifiable software component contracts). 

This fundamental property of software is true no matter what programming language or level of abstraction you choose to deal with, so in my eyes the only thing you've saved yourself going from a language that statically verifies whatever form of contracts it knows how to explicitly express to a language that can barely even express a contract let alone verify it (and even then, what you see is often a lie) is a few keystrokes. Period.

What you lose is a great deal more valuable - tooling, statically verified contracts, and 10 times as much time wasted tracking down bugs that would have never existed otherwise.

Now, about those keystrokes and interfaces and scaffolding everyone seems to like to complain about - I would point you all to the following programming languages, which have statically verified type systems, and yet code written in these languages often rivals or more often exceeds javascript in terms of code terseness: Scala, F#, Haskell (haskell in particular). I would also point to TypeScript and Go as languages which support a form of statically verifiable "duck typing", in which the barrier to defining interfaces and implementing them is greatly reduced compared to languages like C# and Java. Look these languages up and try them out. Even if you never use them again, you'll still be a better programmer for having done it.

If you are being hampered by your language's type system, odds are it's because your language's type system isn't sophisticated enough to express your domain in a succinct and elegant way, or maybe it just doesn't have a sophisticated type inference engine or it's missing some sugary syntax that makes your code more readable. Either way, no matter what runtime you are targeting (even javascript), there are language options - use them! (or learn what they are, at the very least) :)
 
The "free book" is a copy of the PDF language specification.
 
Yes, you are right.

I'm sorry for my description to bring you the inconvenience.

I am a shareware author (not a writer), all e-books on my website are
convert and build by my shareware(HeroNote <http://www.heronote.com>).

In the future, I will add some tutorial or class library reference in this
ebook.
 
Most Javascript developers spend a crazy amount of time creating fairly small projects with tons of unit tests just to make small libraries and simple applications run. And just look at the evidently slow pace of refactoring on the fairly simple Javascript projects on Github. Who can in their right mind fail to see how poorly they evolve after reaching a certain size. 
 
I think the loose typing is one of JavaScript's worse features. Surely the benefit of picking up type errors when you compile outweighs the slender benefit of variable conversion. And functions for everything? JavaScript developers really seem a dogmatic bunch. JavaScript has won the war of the browser languages - more because the giants of the industry couldn't agree on a solution - but that doesn't mean a more structured approach isn't more productive. I can knock up some pretty complicated UI applications in Java and C# in minutes but in JavaScript it takes far more time.
 
I Goggled this "douglas crockford typescript" and got here. I am evaluating TypeScript right now and wanted an opinion. thanks +Douglas Crockford 
 
I don't like how the use of typing (a tool with context-dependent applicability) is treated as a matter of taste.

Context dictates, taste should not.