Общо показвания

октомври 05, 2012

TypeSciprt vs. Closure Library/Compiler

This post will take a look at the user experience with the closure tools versus the experience with TypeScript.

This is part 3 of 3 parts post. Part 1 is here, part 2 is here.

Because there is a compiler involved and because everyone out there is speeding up on comparing TypeScript to Dart, Clojure, C# and whatever there is I wanted to point out one thing very important that no one seem to notice:

JavaScript is TypeScript. All valid JavaScript is valid TypeScript. This puts the new language way out of the niche of Dart, Coffee Script or whatever language is out there that compiles to JavaScript. The closest thing that there is IMO is Closure library + compiler.

I will elaborate a bit on that: Closure library is all valid JavaScript: it can work in the browser just as it is. Because you can put pure JavaScript in TypeScript same is at least in a fringe case valid for TypeScript. Most people compare the closure compiler to other option in simple optimization case: however the library and the compiler were created to be used in advanced mode, which mandates very special subset of JavaScript to be used in the source js files in order for the output to work as intended. That is: closure library is a subset of JavaScript while TypeScript is a superset of the language.

If you can remember a few years ago the closure tools and especially the library were received very badly in the JavaScript community: well established names in the community were on the fast track to reject it. I particularly remember the notes of the RaphaelJS creator on how bad the closure library was, how little the creators understand JavaScript working and so on, even for loops were used as example on how they should not be used. Of course today we all know that the library should never be used without advanced optimization and that making micro optimization on loop constructs where the loop body is 10000 slowed than the slower loop construct you can imagine is pretty stupid, but back in the days the big names of the open source JavaScript development movement were there to "explain it for us".

I mentioned this because today I see pretty much the same story: the well established names in the javaScript world (at least some of theme) were fast enough to give their verdict on the new language just because it does not coincide with their established work flow.

Well, a few years ago those people were wrong and even though closure tools were never  widely accepted or used, they remain one of the best in the business. No compiler or minifier can beat the closure compiler in advanced mode. Of course the requirement for the input remains and is clearly a big leap for any JavaScript developer, but the benefits are very clear and if small size is what you are looking for this is the place to go.

Lots and lots of big products have been built with other tools of course and they work well too. The thing is that the tools were offered for free and almost no one put enough effort to figure out how and when should it be used. The developers were angry that they have to write their code following specific patterns and the learning curve for the components that were ready to use was huge. It still can be for new comers. The main complain was the style and lack of expressiveness because of the limited number of allowed patterns.

Strangely today the same developers are limited more than ever: most of the MVC frameworks are very opinionated about the code style and patterns that can be used, also most are not interchangeable, if you start with one product it is not such an easy task to switch to another, not really. So it is basically the same thing, I for example have never used AngularJS. Today I wanted to try to make something with it, well... I had 2 hours free time. Guess what - I could not complete anything in two hours. Maybe I am a slow learner, maybe it is not for me, whatever it is, the thing is you have to give it time.

Now back on TypeScript. Because of the automatic type inferring and because it does not actually contains any code/library the learning curve is very little, epsecially if you have already dealt with module patterns, inheritance, classes in JavaScript, public/private/protected methods and types. I will translate that for you:

If you have used closure tools before, TypeScript will be very refreshing and intuitive tool for you.

Yes, it does not provide the utilities closure has, yes, it cannot strip unused code, but it seems that the community is not interested in the later, even advanced projects like uglifyJS is not aiming to clear unused members because "it is not safe" for every type of code style. Yes, it is not. But is very beneficial. Anyways, unlimited by the patterns of closure library and compiler but still having static types and easy to follow annotations, having interfaces that can be checked at compile time, having sort of 'exports' (defined in the case of TypeScript) is very familiar to any closure developer.

Like in closure tools, you have to go through a build step before you can check your changes in the browser. In the case of closure tools, this is only when you change a namespace or require a new one, you need to recalculate the dependencies. In the case of TypeScript it is true even if you change a single letter, because the file that is loaded in the browser is not the one you are editing. I believe it will not take long for this to be overcomes like it was for closure with tools like closure-script and plovr.

Unlike closure, you have source maps that work right now, not that you will needed it much, unless you are using the TypeScript preferred module pattern, because the generated JavaScript matches very closely the source.

Unlike closure the generated code is not obfuscated nor minified. However there are plenty of tools that will do that for you. Unfortunately the generated code is not compatible with the closure compiler in advanced mode and you will always need to load the full of your libraries if you happen to create them with TypeScript. The good news is that modern JS engines tend to not construct everything in the memory, there is something called lazy parsing, which I do not pretend to understand very well, but basically it says that if a part of your code is never used, it is never interpreted as well, except the first time when checking for code validity. Maybe this will solve some of the issues with downloading several megabytes of code and the caching will solve the rest? I have no idea, but the thing is that we see almost then megabytes of scripts being now part of a single application. The fact the developers tend to use patterns that are easy on the eyes and skills but hog on system memory is entirely different problem.

I find it easier to express complex constructs in TypeScript than in Closure, however the small number of people already interested in the language pointed out that it lacks some important types (for promises, deferred etc.) I believe those will be resolved in the next few months.

The language is still in Alpha! You have to know that. Also it tried to follow ES6, which probably means that if it changes the language might change as well. But it is a fun toy as well, especially if your mind set is polluted by the closure tools and you are constantly thinking about types and interfaces and static methods of classes.

So the verdict in my case (me being not really an acknowledged expert, but still with years of experience in large scale projects) is that TypeScript looks very promising and I will definitely enjoy working with it. Hopefully there will be a standard DOM library soon and hopefully widget library later as well. I also hope that it will be possible to construct a compiler that will be able to strip unused symbols to make it possible to developer large and well featured libraries without fighting for every byte.

A few words about the compiler and auto completion in other editors: last night post established that the completion and compilation can work entirely in the browser and this is true: open the play ground app and disconnect from the internet - everything will continue working: the completion service is available in the browser offline simply interpreting your code and using the main definition file (lib.d.ts). This really means it can be accomplished in IDEs like Cloud9 which already work in the browser anyway. Please please please do something about it, because I really don't like VisualStudio2012 and I dont even own a Window machine.

Няма коментари: