1. #81
    Sencha Premium Member
    Join Date
    Oct 2009
    Location
    Germany
    Posts
    299
    Vote Rating
    62
    Ekambos is a jewel in the rough Ekambos is a jewel in the rough Ekambos is a jewel in the rough Ekambos is a jewel in the rough

      1  

    Default


    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

    Cheers

  2. #82
    Sencha User Tim Toady's Avatar
    Join Date
    Feb 2010
    Location
    Pennsylvania
    Posts
    548
    Vote Rating
    115
    Tim Toady is a name known to all Tim Toady is a name known to all Tim Toady is a name known to all Tim Toady is a name known to all Tim Toady is a name known to all Tim Toady is a name known to all

      1  

    Default


    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.

  3. #83
    Sencha Premium Member
    Join Date
    Oct 2009
    Location
    Germany
    Posts
    299
    Vote Rating
    62
    Ekambos is a jewel in the rough Ekambos is a jewel in the rough Ekambos is a jewel in the rough Ekambos is a jewel in the rough

      0  

    Default


    " 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. F
    ailing 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".

    Cheers



  4. #84
    Ext JS Premium Member
    Join Date
    Aug 2007
    Location
    Antwerp, Belgium
    Posts
    560
    Vote Rating
    36
    joeri has a spectacular aura about joeri has a spectacular aura about joeri has a spectacular aura about

      0  

    Default


    Quote Originally Posted by Ekambos View Post
    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.

  5. #85
    Sencha Premium Member
    Join Date
    Oct 2009
    Location
    Germany
    Posts
    299
    Vote Rating
    62
    Ekambos is a jewel in the rough Ekambos is a jewel in the rough Ekambos is a jewel in the rough Ekambos is a jewel in the rough

      0  

    Default


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


    This is an interesting read on the topic by Bruce Jonhson
    http://queue.acm.org/detail.cfm?id=1572457


    But again one should use the tools that makes more sense.
    We switched to GWT (and have been generating ExTJS code from Java and never) looked back.

    Cheers

  6. #86
    Sencha Premium Member
    Join Date
    Feb 2012
    Location
    Raleigh, NC
    Posts
    431
    Vote Rating
    183
    brian428 is a splendid one to behold brian428 is a splendid one to behold brian428 is a splendid one to behold brian428 is a splendid one to behold brian428 is a splendid one to behold brian428 is a splendid one to behold brian428 is a splendid one to behold

      0  

    Default


    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.

  7. #87
    Ext JS Premium Member
    Join Date
    Aug 2007
    Location
    Antwerp, Belgium
    Posts
    560
    Vote Rating
    36
    joeri has a spectacular aura about joeri has a spectacular aura about joeri has a spectacular aura about

      0  

    Default


    Quote Originally Posted by brian428 View Post
    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.

  8. #88
    Sencha User Tim Toady's Avatar
    Join Date
    Feb 2010
    Location
    Pennsylvania
    Posts
    548
    Vote Rating
    115
    Tim Toady is a name known to all Tim Toady is a name known to all Tim Toady is a name known to all Tim Toady is a name known to all Tim Toady is a name known to all Tim Toady is a name known to all

      0  

    Default


    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.

    Static typing is a good thing, but it is far from essential.

  9. #89
    Sencha Premium Member
    Join Date
    Oct 2012
    Location
    Brisbane, QLD, Australia
    Posts
    49
    Vote Rating
    3
    ampro is on a distinguished road

      0  

    Default


    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.

    My theory is that your team would soon become typescript converts .

  10. #90
    Sencha Premium Member
    Join Date
    Jul 2011
    Posts
    119
    Vote Rating
    5
    john76543 is on a distinguished road

      0  

    Default


    Quote Originally Posted by ampro View Post
    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.

    My theory is that your team would soon become typescript converts .
    Like this story from the TFS guys:

    http://blogs.msdn.com/b/bharry/archi...on-in-tfs.aspx

    Incidentally, a few ExtJS properties can be either a string or some kind of key/value dictionary (as an object). Is there a nice way to represent this in TypeScript?

    Just falling back on 'any' isn't very good.