The point was nt about Hejlsberg promoting TypeScript but more about his points on JavaScript.

When you look at companies writing web apps at a really big scale(Google, Microsoft, Facebook) you will see they have something on top of JavaScript. Dont you think there is a reason why they do so ?

Now dont get me wrong Ext JS is great and i love what Sencha has been doing with it. Still Ext JS dont fix the JavaScript problem

1) Now well you still can work with the console inside an IDE.

2) There are things JsLint cant find. Simply because of the nature of JavaScript (or any dynamic typed language).

var request = new XMLHttpRequest();
......
if(request.readystate == 4){
console.log("Hello, World");
}
That s legal is JavaScript but doest not what i want. And i can only find it out at runtime. Which is pretty bad.

3) Then you know this is nightmare. You definitely miss a lot of things that a statical type language will you.Try to refactor a simple method accross classes in JavaScript.

4) For you maybe. For me not. Having to build teams it s a pain to find people fluent in JavaScript.

Programming languages are tools. One should use what makes more sense for her.
But we definitely need something better then the current state of JS

And my point was that Hejlsberg's thoughts on JavaScript are no more valid than any other developer's. Most people on this forum develop software professionally and have an equally valid opinion.

Like any language, there are negative aspects of JavaScript. Fortunately, Ext JS has stepped in and filled many of those voids. I can start pointing at things like C and how easy it is to fail to terminate a string and allow buffer overflows. Pointing out arbitrary issues is meaningless. I spend very little time, if any, hunting down minor issues like the one you pointed out (or type errors for that matter). There is no perfect language, nor is there one that fits all cases. I have written and maintained large-scale applications with Ext JS and I am quite pleased with its current state. Could JavaScript be improved upon? Of course, just like any language.

" Most people on this forum develop software professionally and have an equally valid opinion."

I agree wih that. But when the top web companies in the wordld dont write their big apps directly in JS then maybe one should thing there is something fundamently wrong with the language somewhere.

"Pointing out arbitrary issues is meaningless."

This is not an arbitrary issue. But it s core to the JavaScript language.
In JavaScript you can basically do anything at anytime. And the language wont let u catch that before runtime. Which is absolutely bad. Failing to terminate a string in C is an error and there are tools that will help you detect that. My previous example is not an error in JavaScript but is fundamentaly wrong and no library even ExtJS can help you fix that.

I m not going against ExtJS. I love the library and i like what Sencha is doing. But the problem is in the language itself and that Sencha cant fix. So if there is a chance to add the ability to catch more errors before actually running the code i think Sencha should consider it as a high priority instead of saying "Simply write right JavaScript".

But it s core to the JavaScript language.
In JavaScript you can basically do anything at anytime. And the language wont let u catch that before runtime. Which is absolutely bad.

Except the big issues are all related to thrashing the DOM, and TypeScript does not solve that in any way. The DOM is simply not an API you want to write large systems directly on top of. That's why you need solutions like GWT or ExtJS that abstract the DOM, and that's why all the major players use frameworks to abstract away the low-level browser.

ExtJS adds these things to plain JavaScript: DOM abstraction and lifecycle management, namespacing, encapsulation, UI controls. TypeScript adds strict typing, namespacing and encapsulation. In short, TypeScript is only part of the solution, and the only thing it adds that ExtJS doesn't have is strict typing.

Static compilation is a red herring when it comes to code quality. You can do static validation of javascript code, you just can't verify that the types you're calling are accurate. You can however check for things like accidentally creating global variables, calling non-existent methods, mistyping a variable name, and so on. I rely heavily on PHPStorm's static validation for JavaScript (and PHP), and you can easily integrate tools like jshint or jslint with whatever build infrastructure you have to prevent stupid bugs from shipping (or get really fancy and use something like Sonar).

The thing that strict typing + static compilation gets you is that when you call an API you have a build-time guarantee that you're passing it the right type of data and getting the right type of data back. That is a useful thing to have, especially at large scale, but I've found that the only place I really need this is in my web services boundary between the client and server, not inside the ExtJS codebase itself. I've also found that it's not enough, because I don't want to just say "this is a number", but "this is a number between 1 and 5". Java doesn't let you do that, TypeScript does not let you do that. There are languages that do, but they're not popular. So in the end you're still checking your data at run-time to see it is correct, and that means all that static typing in the end doesn't buy you as much as it should.

"Static validation of a Dynamic language".
I think a lot people have written PhDs on that. Bottom line you cant static analyse a Dynamic language in an accurate. You can only guess. Why ? Well because the language is dynamic.

Also static analysis goes beyond type checking. In Java(Or any other static typed language) if i give you an interface. Your code wont compile until you meet the contract of that interface.
You can't do that in JavaScript.

Static analysis give you better tooling support. There is no way you can refactor a method in JS and have it updated everywhere it gets called. A JavaScript IDE can only guess.

I'm confused about what everyone is actually arguing about. Is anyone here actually saying that static typing and the other enhancements TypeScript includes is a bad thing? If not, then the point of the thread is still that having Sencha create an official ExtJS definition file for TypeScript would be very useful.

I'm confused about what everyone is actually arguing about. Is anyone here actually saying that static typing and the other enhancements TypeScript includes is a bad thing? If not, then the point of the thread is still that having Sencha create an official ExtJS definition file for TypeScript would be very useful.

I think everyone agrees that having support for TypeScript in combination with ExtJS would be a good thing.

The argument is about whether a static typing solution like TypeScript is essential for developing large systems with ExtJS.

I wrote in the beginning of this thread why I think TypeScript is a poor choice (which I am not going to get into again). I think now this discussion has evolved to whether JS is productive/maintanable/even worthy to be called a language or not.

Type checking is just like assertion checking but automated.
Just like unit test assertions they squeeze the code's assumptions until bugs pop out.
So type checking is gold. It's like getting tons of unit tests for free.

Until recently I worked on a 3,000,000 line app written mostly in C# + some C++ and smaller amounts of about 9 other languages. We found that by replacing most interfaces that used dynamic typing with type safe wrappers our bug rate dropped significantly . e.g We generated type safe wrappers for all stored proc calls.

So here's an interesting 'experiment' you might like to try out on your large ExtJS app ...

1. Build or get a typescript type definition for your version of ExtJS
2. Recompile your large app using typescript
3. See how many *new* bugs pop out.