Those of you coming from server side programming on strongly typed languages may have been appalled when initially moving over to browser based development in the past. Anyone remember javascript debugging during the reign of IE6?
I’m happy to say, those days are behind us. In parallel with the improvement in client side runtimes thanks to things like Google’s V8 engine, the IDE support is now also up to scratch.
shweeeeet….
Case in point – Webstorm 6 from JetBrains is one impressive package.
I gave it a whirl to see how well Typescript and Dart integrate into the IDE (not bad at all).
Here i am remotely debugging a page containing a Typescript raytracer and the Dart balistic clock with Javascript glue logic (count em – three programming languages natively debugged on the one page) :
Typescript and Dart are two new languages (from Microsoft and Google respectively) able to be compiled into and integrated with Javascript, though with the advantage of type safety – same as languages such as Java or C# (though in Dart its optional). This pushes more errors to the compilation rather than runtime phase of development. Since variables must be explictly declared and to be of a particular type, misspelled references are always compilation errors. Also type assignments are rigorously enforced. A variable is defined as for example a string, and if you try and assign anything else to it, that is also an error. Since the compiler has more precise information about the code, refactoring ability is far superior (and always will be) to fully dynamic languages. These features become real advantages (there will always be ongoing debate about this) when the codebase grows beyond a certain point. The code necessary to support the GUI in a HTML5 app normally is quite manageable. It’s when ENTIRE applications and libraries start being ported (tens to hundreds of thousands of lines of code or more) that type safety becomes a godsend (imagine for example porting a realtime derivatives analysis and pricing engine to the client side). Judging from the action in this space, many groups are reaching the codebase size where maintaining the javascript is becoming onerous. That’s why you’re now seeing these alternatives come out of the woodwork. Whereas in the past the runtime would have fallen into a heap way before your LOCs piled up, thats no longer the case.
Typescript – ahhhhhh….. type safety
Dart can actually run within a custom virtual machine that must be installed in the browser alongside the javascript engine, and although they’ve made a slick solution (its written by the same guy that did V8, Lars Bak, and does things like compilation cacheing for ultra fast startup), I don’t fancy Google has a chance in hell of convincing any other vendor to adopt it (competitors are already nervous about Google’s market power and they don’t want to help them get more – Google is the ‘new’ Microsoft – I’m sure you’ve heard that thrown about). The alternative (though less performant) Dart deployment option, like Typescript, is an intermediate compilation to Javascript and execution via the existing Javascript engine. I expect where Dart is used, in pretty much all cases, it will be used in this way.
So, in choosing to adopt the benefits of these languages, the hassle is the intermediate compilation step that you have to go though to make use of them – something you don’t have to worry about if sticking to vanilla JS.
Of course you could knock something together yourself, but your time’s better spent solving your own specific problems, which is why IDEs were invented in the first place.
Step in Webstorm. Webstorm’s the client side development bits cleaved out and built on the same foundation base as JetBrain’s award winning IntelliJ Java IDE. Eventually all these goodies will migrate to a future version of IntelliJ. But if you’re not going to do any development in things like Java, don’t waste your money.
Webstorm’s done an awesome job not just on the Javascript side, but they’ve put a lot of effort into making the alternative languages that run on top of JS (Coffeescript / Typescript / Dart etc) first class citizens on the platform. You have to install the various SDK’s from the language vendors, but the IDE takes it from there.
You can then run and interoperate all these languages together inside the one application. So an application built with components written in each language can co-exist in the same app (though an external library you do not intend to modify would best be precompiled into Javascript and imported like any other Javascript lib).
Syntax support for the various languages is supported in the editor, as you would expect. But it goes further than that.
Using something like Typescript, you get a strongly typed language – far more errors will surface at compile time, similar to coding in C#. Various file watchers can be associated with file suffixes in the IDE, to automatically recompile the changed files whenever they are modified. So the background processing to support these JS alternatives is more or less transparent. A mapping file is also maintained which associates what part of the 3rd party source is associated with the compiled Javascript. Kind of like the debug info compiled into object code from C. This is obviously used for:
DEBUGGING!
Again – very impressive. Debugging on browser resident code is achieved through the installation of a plugin supplied by Webstorm which hooks into the execution chain of the Javascript runtime in-situ on the browser (it’s the same idea as remote Java app debugging where you hook into an agent running on the JVM). Chrome and Firefox are currently supported. The browser then calls back into an IDE listener and co-ordinates debugging actions. The mapping file Webstorm maintains against the polyglot source code allows you to specify breakpoints in the alternative language. This is converted under the covers to a breakpoint at the corresponding javascript point in the browser. But you don’t have to worry about that – all you see is the code halted, and the values of the various scoped variables in the language of the file you put the breakpoint in, regardless of whether it’s Typescript, Dart, or Javascript. It Just Works(tm)
There are a few ways to debug – locally, remotely against an independent browser as outlined above, against a node.js script. Pretty much all bases are covered.
You can also hook up unit tests against all your various flavours of code, optionally to be run automatically whenever you alter the underlying code.
Great stuff! It’s great to see the client side on par with server side development. If we’re going to move to client side development, these more powerful tools are a necessity for non trivial projects.
Hats off to Jetbrains on their awesome Webstorm 6 release. If you are doing client side or node.js development in a team environment, I cannot see how you couldn’t justify the current $29 for a personal license.
rudi…