1. #91
    Sencha Premium Member
    Join Date
    Feb 2012
    Location
    Raleigh, NC
    Posts
    417
    Vote Rating
    134
    brian428 is a name known to all brian428 is a name known to all brian428 is a name known to all brian428 is a name known to all brian428 is a name known to all brian428 is a name known to all

      0  

    Default


    Quote Originally Posted by joeri View Post
    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.
    As I said earlier, it's obviously not "essential", because people are building large systems with ExtJS right now. But there's no doubt that compile-time type checking is a great way to catch a wide range of errors. It's not a silver bullet but it eliminates a huge set of potential errors.

    That said, compiler errors are only part of the benefit. The other huge area where this would help is around tooling/IDE support. Sencha's done some cool things with their Eclipse plugin, no doubt. But anyone who's worked with Java or Groovy using IDEA or Eclipse, or C# using Visual Studio, knows that Sencha's plugin is barely scratching the surface of what is possible. And all of that power is predicated upon some kind of type inference.

    It also doesn't help that for reasons I'm still unable to fathom, Sencha is limiting the ability to buy their Eclipse plugin. But that's a completely different topic/rant.

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

      0  

    Default


    Like this story from the TFS guys:

    http://blogs.msdn.com/b/bharry/archi...on-in-tfs.aspx
    Exactly ! QED. Now it's your turn.

  3. #93
    Sencha User
    Join Date
    Dec 2007
    Posts
    168
    Vote Rating
    4
    SeaSharp2 is on a distinguished road

      0  

    Default


    Quote Originally Posted by joeri View Post
    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 odd thing about this post is that change a few words and it sounds like an argument promoting the benefits of TypeScript.

    Few JS programmers today will have strung together an advanced JavaScript development workflow as described by joeri and now looking forward what makes more sense, TypeScript or an assortment of code validators mentioned above.

    Joeri I do not get your hostility to TypeScript. The custodians of JavaScript have been working for 5 years to define the next version of JavaScript and TypeScript is an early manifestation of nextGen JavaScript albeit one that compiles down to present day JavaScript.

    Looking more broadly at the debate, GWT, CoffeeScript, TypeScript, ScriptSharp, Dart and tha big eBay project are all strong indicators that loads of smart people reckon there is a problem with JavaScript that needs to be solved.

    Consider CoffeeScript, from nothing to the 15th most popular language on GitHub in 2 years with no big company backing. The success of CoffeeScript is based on a groundswell of adoption by ordinary programmers who believe there is a problem with JavaScript that needs to be fixed.

  4. #94
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    36,620
    Vote Rating
    817
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    Errors during "compilation" makes me think that you could do something with Sencha Cmd. You can add plugins to do JSLint/JSHint to get the bulk of it and maybe even do extra stuff.
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  5. #95
    Sencha User
    Join Date
    Dec 2007
    Posts
    168
    Vote Rating
    4
    SeaSharp2 is on a distinguished road

      0  

    Default


    Quote Originally Posted by Tim Toady View Post
    ... I don't think that a compiled language would save me much time here. In fact, it would probably cost me more time if I was working with a compiled language since I would have to compile every time I wrote a minor change.
    Obviously you have not programmed with a compiled language for a long time, things have moved on and we no longer submit a deck of punched cards to the mainframe operators.

    My largest TypeScript project generates about 5000 lines of JavaScript minus white space. A full compilation takes about 3 seconds and much less for single file compile-on-save updates. Compilation takes less time than refreshing a browser for a new test cycle.

    A modern IDE also implements continuous background compilation in addition to a manual formal compile step. The moment I write a bad line of TypeScript the background compiler warns me with a red underline squiggle.

  6. #96
    Sencha Premium Member
    Join Date
    Feb 2012
    Location
    Raleigh, NC
    Posts
    417
    Vote Rating
    134
    brian428 is a name known to all brian428 is a name known to all brian428 is a name known to all brian428 is a name known to all brian428 is a name known to all brian428 is a name known to all

      1  

    Default


    Quote Originally Posted by mitchellsimoens View Post
    Errors during "compilation" makes me think that you could do something with Sencha Cmd. You can add plugins to do JSLint/JSHint to get the bulk of it and maybe even do extra stuff.
    It might be partly possible, but it will still require parsing type information in comments, which is an approach that has numerous problems. JSLint validation is always nice, which is why I currently use CoffeeScript, since everything it generates passes JSLint in addition to as many compile-time checks as it can reasonably do.

    Beyond that, it seems like a TypeScript definition file is really, really low-hanging fruit. Creating one would be far easier than modifying Cmd. And with the definition file, you immediately open tons of capabilities in IDEs that support TypeScript (namely IDEA and Visual Studio). In other words, it would sure seem a lot simpler to take a few days and create a definition file, than take weeks or months to update Cmd.

  7. #97
    Sencha User Tim Toady's Avatar
    Join Date
    Feb 2010
    Location
    Pennsylvania
    Posts
    536
    Vote Rating
    70
    Tim Toady is a jewel in the rough Tim Toady is a jewel in the rough Tim Toady is a jewel in the rough Tim Toady is a jewel in the rough

      0  

    Default


    Quote Originally Posted by SeaSharp2 View Post
    Obviously you have not programmed with a compiled language for a long time, things have moved on and we no longer submit a deck of punched cards to the mainframe operators.

    My largest TypeScript project generates about 5000 lines of JavaScript minus white space. A full compilation takes about 3 seconds and much less for single file compile-on-save updates. Compilation takes less time than refreshing a browser for a new test cycle.

    A modern IDE also implements continuous background compilation in addition to a manual formal compile step. The moment I write a bad line of TypeScript the background compiler warns me with a red underline squiggle.
    The back-end of the application I build daily can easily take 15+ minutes. I must have been under a rock to not realize it actually compiles in 3 seconds now.

    Regardless, the fact of the matter is that any time spent compiling is time that is taken every time I want to make a change. Don't get me wrong. Compiling brings plenty of benefits. There are benefits to both systems. But for me, I know it would cost me more time compiling than finding the few extra little things jshint doesn't tell me. I spend very little time tracking those down.

  8. #98
    Sencha Premium Member
    Join Date
    Feb 2012
    Location
    Raleigh, NC
    Posts
    417
    Vote Rating
    134
    brian428 is a name known to all brian428 is a name known to all brian428 is a name known to all brian428 is a name known to all brian428 is a name known to all brian428 is a name known to all

      0  

    Default


    Quote Originally Posted by Tim Toady View Post
    Regardless, the fact of the matter is that any time spent compiling is time that is taken every time I want to make a change.
    Modern IDEs compile individual files that have changed, immediately when you make the change. So unless you're compiling a 10,000 line file, it's virtually instantaneous. You don't even notice it, until the IDE starts highlighting errors.

    Quote Originally Posted by Tim Toady View Post
    But for me, I know it would cost me more time compiling than finding the few extra little things jshint doesn't tell me. I spend very little time tracking those down.
    Again, if the IDE is doing it's job correctly, there is no discernible time cost involved. And robust type inference means you don't need to create and maintain jshint comments all over your code.

  9. #99
    Ext JS Premium Member
    Join Date
    Aug 2007
    Location
    Antwerp, Belgium
    Posts
    555
    Vote Rating
    27
    joeri has a spectacular aura about joeri has a spectacular aura about joeri has a spectacular aura about

      0  

    Default


    Quote Originally Posted by SeaSharp2 View Post
    Joeri I do not get your hostility to TypeScript. The custodians of JavaScript have been working for 5 years to define the next version of JavaScript and TypeScript is an early manifestation of nextGen JavaScript albeit one that compiles down to present day JavaScript.
    I had a hostility to the claim that JavaScript is unsuitable for large-scale development, not to TypeScript.

    Now, if you ask my opinion about TypeScript itself, I see it as an experiment of where JavaScript could (and probably should) go, but not as the future of browser-side computing. I think the ability to do view source (or f12) and to modify code in the browser without having to use a huge lumbering IDE is an important ability which shouldn't be lost, even in large-scale systems. From that perspective I think it's instrumental that JavaScript itself evolves to include strict typing, without requiring compilation (except to support legacy browsers).

    So, what I would like in JavaScript is better abilities to do static validation of code, and optional typing can be a useful part of that, but without a mandatory compilation step. I've done plenty of development in compiled systems over the years and I never liked the compile step, even when I was writing a compiler

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

      0  

    Default


    Typescript is just part of a large suite of goodies that Javascript devs enjoy in Visual Studio. If you're just coding in Eclipse you'll probably don't know what you're missing. I've spent several years working in several versions of Eclipse but for my latest JS projects I found that VS.NET 2012 was overwhelmingly better. (I even spent last week at a Sencha Touch course doing time in Juno Eclipse & Aptana). I've not look at IDEA but also heard good things.

    VS.NET 2012 Javascript Editor ... (demo video)
    http://www.asp.net/vnext/overview/vi...ascript-editor

    You also get these free plugin features that just start with typescript support ...
    http://visualstudiogallery.msdn.microsoft.com/07d54d12-7133-4e15-becb-6f451ea3bea6

    Most VS users also buy the Resharper plugin that adds heaps more goodies ... and specifically some useful JS refactoring. The addition of typescript will inevitably grow this feature set much further as they leverage the type metadata.

    http://blogs.jetbrains.com/dotnet/tag/javascript/

    So the point is ... that a large percentage of Sencha developers will not choose Eclipse and will inevitably be hanging out for Sencha supported typescript and may even consider other JS frameworks rather that abandon their favorite IDE.

    I would also suggest that the Sencha team consider packaging their SDKs as a NuGet autoinstaller. Many .NET devs start exploring web tools by downloading these packages. Many more would discover Sencha if you shipped your GPL product in this format.