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