Dart (a revision at the end of 2014)

In this past year I have been using Dart on and off and then back on and then back off and I wrote a lot of articles about it (mostly critical but hey, this is who I am and this is who most people are - most people tend to emphasize negative impressions while the positive ones are accepted as 'the normalcy').

As with many other Google related things the often missed truth is that a lot of work and a lot of consideration has gone into the idea long before it became a project and still before we even have heard about it. 

Dart is not an exception. If you have been watching carefully the talks published that are related you will easily notice that even now, long after the language has reached 1.0 and have been publicized as 'stable' and 'ready to use' there are still things that are not clear and that different project members want things to be done in different ways and at the end of the day not everyone is happy with how things went. 

As a side note I think that Google should not force people to go to conferences because they (those forced people) tend to express their opinion on things in an agitated state and it makes a very very bad impression on the states of affair when an open source project is concerned especially if you are putting your neck up when advertising 'pro' it inside your company (or even worse when you are a start up or a young company and you need to make some technical decision that can cost you a lot in the short and long terms). I have seen at least 3 such videos - the first one I have talked about before and it concerns angular dart mostly. The last two I have seen only recently. One of them basically starts with 'I have picked the short straw so here I am to talk to you about dart ...'. and finishes with 'So here it was, I talked to you about those things that I know nothing about, do you have any questions?'. 

The second one I have in mind if given by Gilad Bracha and in it the negatives are less but still they creep in.

Why I mention this? Well, the thing is that when you go to present something on a conference (or wherever) you are expected to be enthusiastic about it, you do not go there to say bad things about what you are talking about, right? Even when it is really a stupid useless piece of moronic code that you have made in your free time and no one will ever never use (like some of the items presented at HTML5Conf, omg, I feel like this was the worse conference ever, full of really badly prepared presenters and full of really badly made software). But still those people talk like their thing is THE thing - it almost cures heart disease and cancer. They are enthusiastic and positive about it and even when almost everyone leave the room after 10 minutes of their presentation and there is this irritating guy in the front row who keeps interrupting and asking real questions that they have no real answers for they keep going explaining to everyone (who did not leave) that this is it - the next big thing.

Putting that on the side, the reality is as follows: it takes too much effort to write real world web application. Way too much. There is no standard toolkit. There is no usable / fast way of creating UI/UX. If you go for a framework you are basically stuck with it. We have seen time and again (now even Google acknowledges it) that Polymer is way too slow for real world usage, so this is a no-op for now, mastodon libraries were great once upon a time, but they are now crushed under their own weight - they are so big and so hard to write for that they simply cannot keep up with the evolving requirements of the UI/UX on the client side any longer. If you chose to go with that, you are basically stuck in the state of the art UI of year 2000.

But even if you close your eyes (for the mobile first etc UX) you still face a ton load of issues - incompatibilities in the libraries (have you seen projects where the UI is done in one library, the graphs in another, yet more dynamic things with another and so on and each of those provides its own way of doing things?), the minification (I know it is not a word, even the spell checker thinks it is not a word) and then the bloating (no mater how much you minify at the end you still push 600KB on the client on mobile connection and this is only the script, let alone the images and styles and then the live performance... oh my...).

So I think most people agree that web development is super complex today.

Where do you even start to learn if you are new to this? Do you start with simple scripts (news flash - it is not really helpful if you are then buried in half a million lines of code of an app)? Or do you start with a coach, who will have to explain exactly how browsers work today, how they fetch resources, what is blocking, what is not, when painting starts, what is re-layouting, what is the link between JS objects and DOM objects, why you should combine your read and writes to the DOM and so on and so on. Even a super intensive course on all the topics (and brace yourself, we have not even touched the SVG, canvas, webGL, audio processing, server side, noSQL DB etc yet!) would take weeks.

How much does it cost to train a new developer (not necessarily one without experience, but instead new to the client side/JS). JS is really not just the language. Its the DOM APIs as well. JS without it is not that bad, you can write simple apps in it and run them in node. And then on the other hand if you are classically trained in C++/Java JavaScript has so many underwater stones that you will be productive in... at least 6 months I dare to say. I mean really knowing what you are doing.

I have worked with people coming from back-end to the dark side (the front end): its not the event loop that trips them first: its the fact that you have multiple entry points to the same application. The fact that if you change the order of script tags things tend to break badly.  The fact that you are declaring things but some things are immediately executed while other are not and finally the fact that you cannot just do your work in a loop, you have to break things to smaller pieces because otherwise you kill the UX.

This and much more need to be learned before one developer can even start  (to let say port his ideas from the mental model he or she is used to on the back-end to the front-end coding arena).

Now about Dart.

They have got some things right, and mind you, those might seem like trivial things for seasoned JS developers, but are super important to people coming from other languages and from the back-end.

Single point of entry for your application: you cannot believe how much of a help that is! I have seen it with my eyes and now I am a believer. Well, this is nothing new, some frameworks/libraries have been doing this for a long time, but most do not provide any guidance about it. Now compare this to multiple 'onload' handlers and multiple immediately invoked function spread over tens of files. If you already know the internal design of the application it might not sound so bad, but usually you do not. And it is bad!

Built in libraries: I do not even know how to compare the dart (and most other languages) libraries with the way things work in the browser. I have worked with a young designer that has been learning JavaScript for some time now. He still does not get the order of execution of JavaScript libraries, well because the language does not provide a built in way to require another library and most do not even bother - lets assume a UI plugin for jQuery: it requires jquery, this is simple, but then again in the docs it requires another plugin, but instead of requiring it at use time it requires it at creation time (i.e. the required plugin needs to be present when the new plugin is registering with jqeury) - this is a hard dependency. Now imagine how many times I have been asked to resolve a "problem" that turns out to be incorrectly ordered script tags. You might say 'oh, but this is because the plugin is written in a stupid way' or even worse, you can say 'the guy is stupid, he should read the documentation'.  The truth is different: simply JS was not designed to handle this kind of usage - dependency tracking and handling was never part of the language and every one does it differently. I, for one, like how closure does it but this is just my opinion. I have used AMD as well. I also used simple script tags... but JS does not provide a standard way of doing this sort of things and while we as JS developers may be dazzled by its flexibility (to implement things that are missing) for new developers this is off-putting in immense ways. Yes, this problem is solve-able, but do we need to solve THIS problem - really? Yet we need to solve this with every new project and even worse in the middle of the project we often need to re-solve this because not all libraries comply with the solution we have chosen - be it browserify, amd, commonJS, closure library or whatever more solutions you can think about just because all of a sudden we require a new dependency that does not mach our dependency solution. Let alone the fact that libraries tend to solve this same problem in their own way, 99% incompatible with the rest of the world.... Well - Dart solved this for us! Once and for all. There are cases where this is not working perfectly (for example when we need to inter-operate with JS land in our app - we still need to manage those dependencies on our own. This is also why I am advocating on a rewrite where possible and doable within the project, because I want to get out of that JS grip and use modern tools for my projects. Even if I chose TypeScript (which I have done once) still the external libraries need to be loaded. And yes, I know about concatenation, guess what, order still maters!)

Fixed up DOM APIs: This is somewhat a double sword; on one hand it does simplify the DOM interaction (which means it makes it look more natural and close to the language as opposite to how JS handles this, but of course this is purely a fault of the committees and specs creators). On the other it does not always comes at zero price: I have written about that as well, for example in (maybe older) some version of Dart the image data arrays have been 'manually' converted to regular arrays in the generated JavaScript which had a really big penalty (mostly GC pauses but still CPU as well). This was of course a lack of consideration when it comes to the implementation of the dart2js process, I hope this was fixed, if not - it should be. Never the less the benefits of having a consistent API outweighs the edge cases when it comes at performance cost. Depending on your project you might need to consider what you are doing more carefully than usually. This is I think one of the weak sides of the html package - it makes things so easy that you sometimes forget that there are perfs that you need to account for. Again with an example - I have seen people I work with that had to 'translate' what jQuery is doing and then searching in google how to do it. This 'translation' work is terrible and I think no one should really do it! Consistent APIs for the win... also this is not only my point of view, lots of talks have been made where regrets have shared about how many APIs were designed without really looking at anything else in the list of DOM APIs and how different they look from one another.

Types: Types in combination with generics and the fact that those are optional makes the language approachable by a much larger audience imo: I know that the type information is completely ignored at run time, but if you are a 'typed' developer you don't care, you still consider it essential. Types in Dart are also somewhat not ideal (at least for me) for one single reason: I am so used on union types from closure/typescript that I basically want to make each and every method accept an union of several very different things: just an example - how about an union of string, Node and NodeList - this could be for example the content of an element. Also enumerations came only recently and are still experimental. But still the advantage you get from using types and more precisely the work of the analizer on it is simply fantastic! All of a sudden you can use a much larges code surface without actually knowing it or used it before because of the type inference and the inline help/completion you get. This frees your mind to be bothered much more with the aspects of your own code than with the API surface of the supporting libraries. It simply enables a JavaScript developer to 'know and do more with less'. I know it sounds like a cliche but it is the truth. Want to give it a try - simply try posting complex code to dart. First you will notice that a lot of the code in JS is 'tricks' (like turn this node list into a real array so iterating we can remove some of the items and then make a new iteration on the shortened list and many other such examples where we as developers are spending too much time solving inefficiencies in the language or APIs than actually working with our ideas). One other thing missing from dart types is the so called 'non-nullable' types. In typed variants of JS you can state that a value (especially function params) can never be null and then you safe on type checks, not so in Dart and because there is no such annotation the users of your code are allowed to submit null values as valid ones for every type and the type checker will not warn them, so you have to check the values for null... blah...



Not all is perfect in Dart either. As with many other languages and tools it has some darker sides. One of those is that it works well enough only in Dart Editor. While it is supported on sublime text for example, the support is very limited and does not provide the great experience you get when using the Dart editor. Also the attempt to bring the same productivity to the web for now does not provides what it was expected. The implementation (chrome dev editor) is really a crappy experience compared to more robust and seasoned applications. Even Vim performs better with polymer (because of how it can handle matching tags) than CDE. CDE implements git but only partially and only with some predicaments. It is supper slow compiling to JS (so if you have a large dart code base you can take small naps when you press the 'run' button before the result is shown in the browser). They have had some terrible performance issue with it comes to dart/js integration in the past (I am not 100% sure it is solved now). As such one of the largest user facing projects written in dart does not look so great and does not put dart in a nice place really. There is hope (at least in me) that this will change if DartVM is bundled with Chrome but this seem to not be coming soon...

Another pitfall is that pub does not allow un-publishing your packages. While this is done for a good reason, it makes it pretty much full of dead code. Even more is the number of 'crap' packages (just like in npm you can easily get 10 packages that should do the same, but 10 of them are useless of full of bugs and there is no real review process in place nor a way to know how many projects use it in production and which version). As the times goes the number of really good projects is not increasing with the rate of the badly constructed ones. Having this in mind can make some of us (adopters) cry out loud for the time of monolithic, carefully curated libraries. One stark example is closure library and often related projects (again usually coming out of google) - old code is preferably not removed but just deprecated, all tests are run, everything is tested and performance measured. This means that you need to do more work (reviewing the package and its performance on your own), but I guess this can be improved once more people start using dart (if this ever happens).

Another thing to consider is this: when dart first appeared it was twice as fast as JS and the gap between generated code and handwritten code was very small. One year later the things look a bit different:

DeltaBlue: Dart VM is almost back to the level it was in the beginning of 2014 (~5% improvement). Dart2js has not moved at all, but v8 is now much faster (starting the year around the 400 mark and now it is above 600).

FluidMotion: Dart VM improved by 2 points. dart2js has lost a bit, bit is very close to where v8 is, and v8 is on the same place it was in the start of 2014.

Havlak: it appeared somewhere in the middle of the year so no date prior to that, but v8 substantially beats the dart2js code on this test, as of the last month hand written js code  is closer to DartVM than dart2js is to v8. The really bad performance of dart2js is shame on this test - really! Both v8 and dartVM performance has been improved this year, while the dart2js has not moved at all.

Richards: somewhere at the end of 2013 dart2js and v8 got in parity and stuck that way for the whole year - no change there. DartVM got better at this test by about 10%.

Tracer: I bet this is the fave test of all Dart lovers - v8 got just a tiny amount better at it, but dart2js has always been faster, more at the end of the year than on its start. DartVM also made a great leap this year in this test.

Looking at those tests an interesting picture is forming: DartVM is no longer (if it ever was) twice as fast as v8 - it is now about 20 to 25 percent faster. V8 made some great progress in 2014. Note that this does NOT represent advances in other JSVM so if you have some free time on your hands please do this: compare JS code to dart generated js code in other browsers - please!

dart2js did not moved a lot in 2014 and IMO is still pretty much work in progress. One things I cannot get from those test is the flags used to compile JS from Dart: for example is it minified, is it type optimized, are the boundary checks preserved and so on. Would be interesting to turn on all possible optimizations and then try again. Why? Because Google has been doing type optimizations and in-lining and virtualization and what not to its JS code for almost a decade and using Dart it is possible to do the same. I wonder if it really makes the code run faster as they say. It is known that the closure compiler for example sometimes break hot functions (because of code in-lines basically breaking the compilation to native speed code in v8 because of type alteration or because the function becomes too large (larger function are not compiled)). This is what perf tests are for. There was a recent blog post describing ~14% increased speed in some code so I guess it is worth a try. For this to work however you need to be really diligent  about those type annotations, just like with closure compiler. Which basically excludes some (actually most) pub packages....

This all was about CPU performance, which is fine and well, we see that dart VM is advancing little by little and that v8 is still strong and catching up, dart2js has much to be desired. But what about the other type of performance - memory?

Oh, Memory! There is a really good explanation about why memory is much better topic to talk about when it comes to DartVM vs. V8. Ask Gilad Bracha.

The whole thing is really simple: Dart works differently and the internal representation of things require less memory, which on its own is a big win - remember the talk about static JS? The fact that for a garbage collected environment to work optimally (and fast!) you need to have ~8 times the RAM that your application requires at any given time. Then you can be sure that the GC will not interfere with performance while still doing its job. It is not only limited to JS, but it is important for JS because apps are getting bigger and bigger and bigger, JS heap sometimes is reaching for the gigabyte mark and yet most people do not have 8GB installed...

In the blog post about game development with dart and stageXL I have mentioned that the memory profile of the exactly same app run as Dart and JS generated code is very different, both in the way memory allocations are accumulating in the game loop (mostly fault of the dart2js transformation) and in the memory consumed as a whole. JS code was 3 to 4 more memory hungry and was making more and larger allocations and GC was running more often as a result. Back then I blamed dart2js for the whole things and also I was not sure  if DartVM was reporting the correct values, now that we have better tooling for dart it is proved - having a bigger app in dart is better than having it in js. This is why I really really hope that dart and chrome team can finally integrate and chrome starts to ship with DartVM by default.

Yes, I know that most people are not using chrome (which is not really true, around 50% are using chrome but this is a whole other story), but even for the sake of android this will be a big win both for devs and users: first of all android is usually more memory constrained (as well as those chromebooks!), also being faster means less CPU for the same tasks even if ti is only 20% less, it still can translate to an hour of battery life. But not only that - it will become easier to ship web apps with native feel like (UX). At HML5Conf there was a talk about why app stores should die. Well, they are not dying as far as I can see, but for some apps it is really bothering that you need the cordova wrap just to be accessible for the sake of the store. Google is making some great progress in that direction with recent changes (separating tabs in A5 and so on). I hope the whole cordova thing can go away in 2015 and capabilities are granted to https served apps without real installation (sort of like service worker).

Yes, most apps still need to serve to IE/opera/ff/safari. I for once need to continue to support those, but still, if at least on one platform things get much better the market will react, especially if great apps come out of it. If the users see the difference and feel the difference they will react. So hopefully 2015 will be the year. if not, next year is fine also, but not more... I am getting older after all:)

Happy new year to everyone and may all your dreams of virtual machines and fast code come true!

Riding the Polymer wave

Comparative analysis of the developer experience for creating a multi-screen, single page application complete with persistence, animations and rich client data management w/ filtering. 

This piece will describe the development process of the creation of a single page application that harness multiple rest resources to compile a cohesive user application with multiple views, data filtering and persistence using the Polymer library. The process is describes as direct comparison with the process of building very similar application using the closure library and tools collection. The analysis is made as an effort to point out the pros and cons of migration from closure tools and libraries to the modern Polymer project as framework/tool set for building such applications. 

The post is quite lengthy so if you are looking for a quick summary scroll down to the bottom of it.

I will start with some background information: I have been building large scale single page applications for the last 5 years. I have been using many different tools for that purpose for one reason or another (some of those being: project already have been started using a particular framework that is not playing really well with anything else, the project required really small footprint as it would be server many many times without caching, and other). Some of the tools I have been using extensively include: MooTool (archaic, I know), jQuery (ridiculous, I know!), GWT (Java, I know), Closure library and tools (templates, CSS pre-processing, compiler) (really really verbose, I know), TypeScript (just a toy, I know), Dart (not really what it is portrayed to be, I know) and other - on occasion.

From all of those, the most reliable one and most trustworthy thus far at least in my use cases was Closure. Google really put efforts into it. The main problem with Closure is that it was designed with several things in mind, that kind of trip over JavaScript developers coming from any other framework/library:

• designed to look and feel a lot like Java
• designed to be production useful explicitly only with the Closure compiler 
• designed to be compatible with old old old browsers
• designed for internal use primarily and thus lacking the polishing of the other competitors out there

From those probably the biggest obstacle one could have with Closure is the fact that it is designed to actually use types, while JavaScript is designed to not use those. This is also the fact why TypeScript is used mostly as a transpiler these days and much less as compiler - types are not something JavaScript developers want/need to deal with.

Assuming the developer has the time and willpower to learn about the basic ideas inside closure (so types, the fact that you actually have to be able to imagine everything the compiler will do to your code in order to write something that will work after compilation, the fact that you actually need to test both source and compiled versions) - those great ideas and the advantages they bring could become part of your daily coding routine.

However even if you become the master of imaginative compilation and you are able to write code without errors (coming from the compiler) - those will never mitigate the fact that to write closure compatible code you have to always be very very verbose. Actually you have to write so much boilerplate code that even Google attempted to come up with some shorthand versions (mostly I am talking about goog.scope). Those efforts are however nothing compared to the amount of code one need to write to get going. This includes the type information (obligatory - the compiler is still not so smart to infer all types from the code directly and probably will never be), the namespaces and the fact that you need to include all used namespaces in the beginning of your file. Also from my experience it is very much possible to often have slightly overlapping functionality just because the design of a super class does not allow for some particular alternations (a property being important for your subclass but it being private in the parent class etc - no, you cannot alter the source code and no, you cannot just access it - the compiler will scream at you and who knows at which point the compiled code will stop working just because you are accessing something that is marked as private and the compiler can remove it as it sees fit...).

Part I: The good

Polymer is a new library from Google, that attempts to provide opinionated but easy to use abstractions over the new Web Components standard. It promotes declarative syntax for creating and using custom elements that should be compatible with all modern browsers (this includes the last two versions of all 'ever green' browsers).

Polymer itself is consisting of a polyfill for the platform features that are missing in some browsers (actually the only browser that has implementation for all web components specs is Chrome) and then the 'opinion' on top of it (polymer itself) on how to utilize those features to create developer friendly, fast to develop and easy to use custom elements and web applications.

First of all - instead of JavaScript you are writing mostly HTML - tags, attributes and properties. What you would write as new namespace with instance properties now you write as an element (polymer element tag) and attributes on a prototype object.

Here comes the first new thing - in Closure we do not write primitive values (nor object types - like NEVER) on the prototype because it alters the hidden class of the instance if altered after the instantiate phase and thus potentially makes your code run slower. In Polymer it is encourages for readability reasons and to easier understand what is going on. You can still write all properties in the 'ready' method, but the polymer implementation encourages you to use the prototype object of the element to define those and they are used for type conversions (for example the attribute will always be written as string, but you can hint polymer that you actually want to use numbers and thus the string will be automatically converted to number). One can also argue that this saves memory, but unless you are creating thousands of elements this is not really important.

Being able to not really care for the type (i.e. if the correct type will be passed to the property as value etc) and instead hint the type and expect the system to convert it for you is really a great developer experience and removes burden from the developer while in the same time proves usefulness (if one binds the input value to a money conversion element there is no need for the developer to manually convert the string to a number). So +1 for Polymer for not caring about the types and another +1 for managing type conversion for you.

After you define your custom element you need to (for UI components at least) make some templates. In Closure this is done with the soy template language, which is not so bad per see, but is cumbersome to work with - it is not possible to render your template in the browser without a) having a consuming element/component and b) valid model if data is used in the template. More over the template cannot be used directly, you always have to compile it before you can see what it looks like. So basically you end up writing HTML like files, but you cannot preview them and you cannot use them without all the boilerplate code around it. You certainly cannot just visualize that particular template with ease - you need to setup a whole new view with imports and more code just to see what you have done. This forces a certain type of workflow that seem a bit unnatural - first the designers write the view as regular HTML and then you (the JavaScript developer) take that piece of HTML and strip it out and turn it into a template and you hope that you did not broke anything.

In polymer the template is just a regular HTML. Testing it is as simple as including your new element/components in any web page.  +1 for Polymer and easy to use and create templates.

Once you have a basic element (so some template structure and some properties to operate with) you might need some ready to use functionality - you need an import. Unfortunately here polymer and closure, while in totally different in technical perspective ways, operate very similarly from consuming point of view - you have to always include what you need in each and every of your custom elements/components. In closure you do not have to care about file paths so shifting files and directories around is much safer (in Polymer it was a nightmare to have to move some elements to a different directory mid-project - we needed to go and find all the places those were used and update them), but you cannot automatically retrieve needed libraries and elements. In polymer the preferred way to manage dependencies is bower. While it is very nice the installed elements are very volatile to path alterations and once you start it is hard to update those. In both cases however you have a lot to write!

• In closure - the whole namespace for each used element/utility
• In Polymer - the full path of every used component (and writing "bower_components" all the time is not fun!)

Because of that no +1 for Polymer in this area.

After all these steps you can potentially have a self-contained ready to be used, re-used and extended/augmented piece of code. As a whole the closure code will be 50% larger (mostly because of the type comments, but if you put comment on your polymer code it would be the same size). The main difference is that in Polymer you end up with a single file (or 3 files, depending on how you structure the component CSS and Script could be separate files, but I tend to keep everything together for more cohesive experience), in Closure you end up with at least 2 files (for UI components) - one with the scripting and logic and one with the markup. The markup of course can live with the markup of other components in a single file under a namespace which makes it even harder to separate your code and distribute it as a single element.

Polymer also provides utilities for documentation and demos of your work (again elements that automatically extract the code comments and construct html in the browser). To do the same with closure code you need jsdoc and templates and basically you are on your own there because the docs of closure library are generated internally by Google and the ones you can generate look and behave nothing like Google's - they are less usable and uglier.

Because of these not so important but kind of not unimportant reasons Polymer gets one more point.

Part II: The bad

Not all is roses in Polymer land either.

First thing one could notice is that because of component reuse and the ease of instantiation basically you are inclined to use lots and lots of elements that provide utilities and no UI. The most notable example for that being core-ajax. In a single view page you can have several core-ajax elements. In Closure land you usually have one 'Loader' class that takes care of all the communication to specific REST endpoints and when an error occurs you decide what to happen next. In Polymer each core-ajax element lives on its own and you might end up having 30+ such elements in your app. You can define error handlers on each of them or listen for core-error globally (on application level). The problem is that you end up with ajax request originating from pretty much anywhere in your application and it makes it harder to manage. Also it is pretty hard to limit what is happening when because you do not have central control over it. Of course you can write such, but it looks unnatural. As a side effect you can load pretty much all your request except one, but it will take time to notice that you failed in that one request.

Another catch you have to deal with is Shadow DOM's CSS rules. Once all browsers implement Shadow DOM it might be great (and it will be in theory) but today you end up with styling that is very volatile under the polyfil. The first time you start styling you are tempted to write rules that are automatically scoped (for example adding classes like '.padded' in several different elements with different values inside of it). Under native Shadow DOM it works fine, but under the polyfil you will get overlapping rules and definitely not what you expect. The main problem with that is that you actually develop in browser that has native Shadow DOM and you do not notice that there is a problem until much later (and of course you are developing with Chrome, right? If you use anything else for development this whole post is probably not for you anyway). Once you realise what is going on you end up writing all rules as if they were un-scoped (so ':host .padded' which defeats the purpose of Shadow DOM - even with Polymer you still have to think about your styles as global - not cool!

Next come RAF and timeouts: The documentation for polymer states: 'async is bound to animation frame'. Well it is, unless you specify timeout in which case setTimeout is used and you loose the RAF timing. To gain that back you end up with atrocities like this:

this.async(function() { this.async(function() { _doSomethingToTheUI() }), null, 500);

I know, it is not that bad, but still looks a bit unnatural. Also guess what if you need to cancel this delayed work... you need to handle the case where the first async is already executed but the second one is not... this makes async programming fun, doesn't it!

Another async related code - 'job' is working around a common pattern and is designed much better and actually reflects real pattern. The implementation for it (as in polymer dev) is actually a bit different than what is expressed in the docs, but still is a nice enough utility.

Next comes the scroll handling: in Chrome scroll events are synchronized to the RAF, but in all other browsers they are not. However guess how scroll events are handled in Polymer...

Same goes for touch events. I know that it is best to think forward, to innovate and blah blah blah, but when you are pressed to deliver working code for those old phones Polymer is not not your friend.

This is especially true when it comes to the animations: the design and the looks are really really great - for the first time you get a framework that allows you to implement very complex and very impressive transitions and animation with so little effort. They are amazing when demoed and when they work. Now try to run the exactly same code under Firefox... or under iOS safari.. Hero transitions do not work as expected, sliding transitions are braking the view completely in Safari... and in Internet Explorer ... there is a bug that prevents platform polyfil from loading... fun huh?

Basically polymer teams says that they support and want to support all major browsers, but the reality is that once you go beyond the simplest demos it only works reliably in Chrome. This is not so bad if you are targeting Chrome users, Chrome OS users and Android users with sort of new and fancy phones. Unfortunately most paying users are actually using iOS for mobile. In theory if your product is successful you should rewrite in Native for iOS for best user experience, but in reality complex polymer applications work ONLY on most modern phones. For example equal by complexity and code size apps when written with Closure work perfectly on iOS 7 on iPhone 4S and iPad 2, but when written with Polymer the app is completely unusable on iPhone 4s and barely running on iPad 2. On iPhone 5 it works in parity with desktop Firefox for example (i.e. there are delays here and there and some things are broken but most of the app is fine). Now compare this to the Chrome browser on the oldest Nexus 7 (also called original Nexus 7). It works perfectly smooth! Nexus 4 - butter smooth, Nexus 5 and Chrome - again buttery smooth experience, all animations look exactly as they should be, all transitions complete nicely and in sync...

I am sure Polymer team wants to support all major browsers, it is simply the fact that they don't. So does not your application. And this means you can be in big trouble with your manager...

When you debug your application in Chrome everything makes sense, you see the shadow root, you see where elements got inserted and so on. Try the same in Safari debugger... or in Firefox.. what you see is very very different from what you expect. This is again related to the fact that there is no native shadow DOM support. Apart from that other things seem to work just fine. The problem I have with those is that I cannot figure out where the slowness comes from, initially I believed it was a rough code path - someone somewhere was making something that was not really needed. However test after test after test proved to be 'accumulation' problem - if I isolate a component and nest it deep deep into lots of other components it still works fine. But when I start adding siblings on all levels the slowness accumulates progressively and an app with only 3 levels of nested animated pages with 4-10 siblings in each level results in apps that run only in Chrome, crawl on any other browser on Desktop and kill performance on mobile safari and old PCs.... There are some 'offenders' that are worse than others, but one after another they bring their 'slow' and it all results in intolerable application.

Once again - I am NOT sure what is going on there (mainly because debug tools on most other browsers are really years behind what we have in Chrome), also another 'nice' reason is that when you attach iOS device to debug web page on a Mac it auto-magically becomes 20 times slower. I do not kid you - the model observing digest all of a sudden runs for 25-28 milliseconds and the touch events take 50 ms to be processed.... close the debugged window and MAGIC - you again have something that looks like an app and not like still images... this terrible experience proves to me that Apple is strictly inhibiting any and all web advances they could think of and wants you to use their insane languages (I am sorry but Objective C looks like someone killed a dragon and used the body parts to compose a language).

Part III: The ugly

The ugly part is short: the ugly part is the controversion this whole Polymer thing creates: on one hand the managers want things to come into existence fast - the faster the better, and love to talk about things like 'time to market' etc. On the other hand they really really want to be able to tap into the paying market of Apple store. 

And indeed developing with Polymer will make you 10 to 20 times faster (depending on what you have been doing before that, I have been doing Closure and Polymer gave me a lot of speed). It makes so many things easier taking care of many things for you: type hinting, data binding, resource loading (hello, HTML imports) and ready to use components that are beautiful and usable (paper-elements). 

However as the 'bad' part explains there is a price to be payed and it is not really developer's choice to make: once you know what to expect it is not really something you would go and fix even if you are a 'javascript ninja' - it is just the way it works, it utilizes very new things that are simply not there in most browsers. Even if you are a ninja, you could fix this or that, but the amount of work you have to do is much much more than if you have just used something that is known to work already. Polymer is being worked on all the time. But Apple is not showing any interest in developing for those new standards and we know iOS is away from this new goodness. 

Conclusion

If you are lucky enough to be developing a Chrome packaged app or an Android only app - consider yourself really lucky, because you can jump right on top of Polymer and ride it like a champ. You can do crazy things like declarative data processing (yes, you describe the data processing and filtering as nested html elements and it works!!!), ultra cool lively animations and transitions and you can write truly reusable, configurable components that you can reuse from project to project regardless of the used library and/or framework - something we have not been able to do - never, until now. Even with closure components you were still bound to closure tool-chain. With polymer you can include (one day only) polymer and do not care who uses what else to construct custom elements that you might use.

If you are not one of the lucky you better watch out: Polymer is really fast to develop with and very gratifying up until the moment you start to test compatibility: forget about IE < 10, forget about complex apps on older phones, forget about really clean fluid animations on anything else than Chrome... at least for now. Polymer is said to be early preview and alpha and not ready for production. If you are like me, if you want to developer faster and more pleasantly Polymer might lure you in, but then you have to pay the price: days, even weeks after your application development is ready and stable you might still be fighting with Mobile Safari and Firefox and IE... and even if you are not actually fighting bugs in your own code you are still days away from releasing.. you have been warned!

Is Google intentionally making their products only for Chrome Browser?

Here is the deal: Google's web applications are the best of breed, exemplary model for modern, high efficiency, stable, constantly updated, usable pieces of software available today. Without their web apps the Chrome OS would be almost useless.

However I have notices a tendency in the recent development of their products that I do not like at all!

The tendency to lock features to their own browser. Many examples exists across many of their products: offline support (no, no, do not tell me it is because APIs are missing in other browsers, packaged apps are indeed possible only in Chrome, but AppCache and IndexedDB are available on all browsers!), features (like developing image editing feature as NaCl plugin instead of a web application might have been easier, but is surely NOT impossible to be done the other way around especially with the wide support for workers) and other.

I can freely assume that this is a business strategy (which is kind of counter intuitive for a company that has a slogan of 'do no evil'), but what is worse for the web platform as a whole is the fact that instead of advancing the open web features they advance locked in features that promote ease of use for the developers, but lack availability on anything else but their own browser. Many of the packaged applications (maybe not all of them of course) can very happily exist as offline applications with web standard technologies, but instead the developers of those applications decided to go with Chrome's closed ecosystem.

It is hard to promote the standards use in place of the ease of use, which has something to tell to the standard bodies, but this is a whole different story. What is more important is why is Google doing this? It is one thing to provide the best services and best products and willing to profit from that, but is completely different to lock in users, encouraging mono-culture on the user end.

I love Google's web products, I truly believe that they are the best I can use right now, but this is not the case with the Chrome browser. However I feel like I am missing something when I am using the web apps when I do so from another browser. Especially features it has been shown to be working and working well with standard and widely available web technology only (I am talking about the image editing features in G+ in this case). Also promoting a new "offline" capability in Google Sheets without mentioning that it only works in Chrome is kind of hypocritical. So basically it says: "We are releasing new and exciting features, but only for the users of Chrome, the others can suck it". 

Does remind me of another browser and another technological epoch....

The Dart language

Introduction

I have been using JavaScript for many years now as my primary language and most of the time I have been developing front-end rich applications. Not only applications with lots of data, but also with robust custom widgets/elements that are not native to the web (like scalable design views, video editor times lines etc).

When I first started writing those complex apps it was very very hard to compose such an app and make it run on all browsers. Now days when I have to quick fix something written years ago I see how custom objects have been sprinkled in IE only code and other terrible things.

Then came the libraries. jQuery, Mootools etc. They made it a bit easier.

And then there were the frameworks. Without them a lot of what is possible today would not have existed at all! I will not iterate over the problems of incompatible implementations etc, but the thing is even the best of the best of those frameworks and libraries had issues on their own and most importantly the developer needed to choose one and stick with it for the whole project basically, changing it requires learning a whole new world of class implementation and strategies for building an app.

The last thing to consider was the lack of comprehensive and useful tolling for the language as a whole and in particular for those enormous libraries/frameworks.

Alternative solutions

Meanwhile some of the shortcoming of the language (JavaScript) have been addressed by different organizations differently for a long time now (think GWT, Closure tools,  TypeScript etc). Some are targeted to the JavaScript community, some appeal to the developers community as a whole and try to attract interest from developers not traditionally writing for the web.

One of the earliest was GWT. It was targeted at Java developers who want to write web applications, but are not versed in HTML and JavaScript. Google used it internally and many companies outside of Google are also using it to build data driven apps. However the built-in widgets and utilities tend to be seen as obsolete and not attractive enough for the new markets and the new generation of users that are spoiled by the Apple inspired designs. The promise there is that you can write in the language you already know and you get for free the type safety and the rich tooling typically existing for type safe languages and for Java in particular. On top of that the tools were able to produce optimized code tailored for each target platform. GWT is still an excellent choice today as it continue to evolve and addresses some of the shortcomings raised by the extensive use of the tools and revolves around the evolution of the web as a platform. Mobile is also a big word in the newest history of the project, so if you already know Java and maybe you wish you could target several platforms at once (see keynotes from GTW create conf) this might be the best choice for you.

Closure tools are also a Google conceived product, later on open sourced. It consists of an extensive JavaScript library, a compiler written in Java and a template language that can be compiler to run both on the server and on the client side. The compiler is used to optimize and minify the JavaScript code, supports tree shaking (meaning eliminates dead code paths assuming it is provided with the full code for your application) and does some neat tricks like using the comments in your code to infer types for an abstract type system. Assuming all of your code is sprinkled with the needed comments the whole of your project can be type safe, bringing the benefits of the previous project (GWT) to the JavaScript world. However this comes at a cost - all of the JavaScript in your application must obey a stricter subset of the JavaScript language, mainly the classical pattern for inheritance can only be used and no constructor addressing should be done. Other than that you still write in JavaScript and you get type checking, type inference, safety and because of those - tree shaking and safe advanced rewrite and minification. If you are starting a new project and you expect the code size to be large or you would like to try and see what you can do when you have type safety throughout of your application you can count on this project. Check out the wiki page as well as it links to some helpful third party widgets and libraries that are compatible and highly efficient.

TypeScript came only recently and is produced by Microsoft. It was also open-sources. The approach there is different, inspired by the new features yet to be released for the JavaScript language and mixes it with some optional type information, basically becoming a superset of the JavaScript language. It allows reuse of existing JS code (unlike Closure), however the support for tooling and type safety and inference is only available for Visual Studio on Windows, which limits the usability for the developer community. Unlike Microsoft, Google has always targeted all platforms when providing tools for the developers. Never the less TypeScript, being young has yet to be used in very large scale projects, but in the mean time it is successfully used by several not-so-small ones. If you are looking for ways to reuse your code or a popular library, like jQuery, but get good tooling and you are okay with using Windows, TypeScript might be jut for you.

Dart - batteries included

The latest project, trying to address some of the shortcoming of JavaScript is Dart. Unlike the above mentioned projects it is targeted at all developers regardless of their background. This is because Dart is an entirely new language, mixing features from several other languages and trying to make sense of the web platform.

The language itself is okay, its functional (see functions as a first class citizen), but also has classes, single inheritance, mirroring support, isolates, mixins and some very nice sugar syntax for common use cases. As whole it looks familiar for Java as well as for JavaScript developers, probably for other as well.

Dart VM is a virtual machine for the dart language and can run dart scripts natively. For now it is not available in any stock browser and this tend to be the future at least for non-Chrome browsers. However it has been proven by many project already that it i possible to compile to very high efficiency JavaScript from other languages, so I would not worry if Dart VM will ever be adopted in stock browsers as far as it produces efficient JavaScript.And that turns to be the case as of recently.

The type system in Dart is optional and is really not used in runtime, not in the Dart VM (the virtual machine that runs Dart programs natively) nor in the compiled JavaScript version. The type system is actually there for the developer and for the tools around the language. First of all it is used by the Dart editor which gives you very rich real time information about your code, intelligent code completion, intelligent re-factoring and problem resolution and helpful information. This speeds up my programming at least 3 times compared to the closure tools where I need to look up type information myself while writing the code and only later when I run the compiler I can see if I have a type error. Because the types are optional and because of the excellent type inference you can often omit the type annotations in your code and still get very useful information and help from the editor. As a bonus you also get very efficient JavaScript.

The structure of the language itself is crafted in such a way as to allow high expressive power without sacrificing the safety. Because classes are supported in the language itself the problem with different class implementation that exists in JavaScript land is basically non-existing here. You can be sure that your code is compatible with the rest of the ecosystem and you would never again need to choose inheritance implementation etc.

Because of the type system in the editor and the tools around the language tree shaking is possible and performed every time you deploy, which means that you deploy only the code that you are actually using regardless of the size of the libraries your project utilizes / links to. This puts the constant chase for the smaller code size in a library to its end. Very similar effect you can get with GWT and Closure but not with TypeScript. The later translates directly to JavaScript and will not exclude anything from the compile, so you still need to think how to rectify that after the compile. This is not to say that there are no other method to achieve this (AppCache, server caching, even localStorage and Desktop apps (for Chrome only)), but if you are on a team that likes to make updates and improvements often this might be challenging. On the other hand you get the minimum possible code size for free from your tools if you decide to go that way.

Another interesting option is the ability to run on the server side and while the language is targeted mainly at the front-end developers, it is not impossible even today to share code between the front end and the back end, just like with JavaScript and Java. This seems to be a mandatory feature as of lately.

On top of that Dart has its package management system, similar to npm for JavaScript. There are hundreds of packages there already, but just like with npm the quality varies. One of the nice things still is that the language itself makes the packages compatible with each other, which is a great relief, unlike with NPM where each author decides on the structure and API exposition  to use. With the time, just like with NPM the bad projects will die out and the good once will grow. And as mentioned early growth is not a a problem with Dart as everything not used is excluded from the builds.

So who will be appealed by the language?

For once I can easily see Closure tools guys switching to Dart. They are already disciplined enough to use type safe code and dream of a shorter syntax and more expressive power and the amazing tooling will be an unexpected bonus for them.

I do not see Java developers running toward Dart right away, but with the right packages they might be tempted as well.

There seem to be two types of JavaScript developers: the ninjas will probably not be impressed by the language neither the tools, no matter that arguing on the implementation of the Promises and how we should create our objects is only possible in only two cases: either you are so passionate about the language you tend to be obsessed with the details or you have too much time on your hand. So those "ninja"s will not be impressed at all. Those are also what I call "the low level engineers", the tweakers and the experimenters. We need them in order to move the platform forward and I would say they are doing a great job at that. However they can be of little use in a small company or in a start up as their obsession with the language itself and the detail is often very time consuming.

The rest of the JavaScript developers are the guys like me, who have learned the language to a great deal, but wish there was compatibility at least to some extent in the ecosystem. Those guys write applications, not libraries (thou many of them, me including have written at least one library or a small framework just to get a good grip of the language).For them application level support in the used tools might be something very useful and unexpected considering the state of such support or more precisely the lack of it currently.

There are some great examples out there demonstrating the power of the language - things only a real JS master can do are easy and natural in Dart! Take a look at this for example: extending the regular Array object to count the access to its items. Try to do the same in JavaScript! Operator overriding is cool!

If you have not yet - please go and check out the one hour tutorial. You will be surprised how easy to understand and natural this language flows. If you are coming from Closure tools I bet you can understand and finish the exercise in less than 10 minutes and understand everything crystal clear! If you are coming from TypeScript the same should happen! If you are a regular JavaScript user you might wonder why those types, but fear not - you can add them later!

Of course there is still much to be desired. For example for me it is still unclear with what to replace closure templates for example. I see the community pushing strongly toward polymer and/or angular. Angular for me is just a toy and is more of an obstacle when it comes to very complex highly interactive widgets (image editing, design instrumentation etc - widgets that do not naturally link to a model of a strict JSON representation) and this is indeed what I have been doing a lot lately. Polymer might be better suited because it can encapsulate model handling that is not necessarily observer based and instead, but it is poorly supported in non-Chrome browsers. Even the demos on the dart site are not running on Firefox. Also there are bugs in the Polymer JavaScript implementation (basically styling issues - see my post dedicated to polymer. If and when polymer stabilize it would be a great addition to the dart ecosystem but for now I would really like to build complex apps with it but based on secure and fast templates like the ones used in closure, however I cannot find it.

Regardless of the hiccups and the fact that it is still evolving the goodness it brings is so tempting that I just might use it to build a real app!

You should try it definitely! If nothing else you will at least have a real opinion on it!

A colleague of mine has tried it too early (before 1.0) and was very disappointed. As application developers we should know when to try out a new technology. Let the ninjas handle the demo and beta versions! We want security, stability and robustness. I believe Dart is capable of provided all those and more!

Disclaimer: I am a front-end developer and have been doing this for 8 years. I use mainly JavaScript and HTML/XML/CSS as complementary tools/languages. I have been using in the past several other languages: Python, PHP, C, I have a working knowledge of Bash, TLC and other tools and instruments from Unix/Linux. By no mean is my opinions the ones of my employers nor that of a community, those are only mine.

12 reasons why I still prefer Firefox for my daily browsing

I am a web developer. It is more precise to say that I am a front-end web developer. This means that I need developer console each and every day.

For years now Chrome's development tools have been much much better for me as a developer than what is available in Firefox. So I use Chrome (mostly) for development.

However I also have personal needs when browsing as well as professional, not related to coding. In this case I love what Firefox has to offer.

Here are   reasons why I prefer Firefox over Chrome for my browsing:

Unlimited tabs open without noticeable slow down. This is important for me, especially when I read my news feed, I tend to open all interesting articles and read them after I am done with the list. Often this means 30+ tabs.

Configurable tab opening behavior. Chrome was not able or not willing to implement that for years: I want my tabs to open in the background without me having to use the middle mouse button. Why? Well because most products (apps) use shortcuts there days and I love them. Even in Google Plus you can press "v" to open the linked article and in Firefox it goes to load in the background while in Chrome the browser switches to the newly opened tab and I have to wait and stare first at the blank page and after a while at the half rendered page and after that maybe read the article, but usually switch back to the original opener tab. There are plugins that try to handle that, but none of them works correctly.

Much faster start up. One thing Firefox learned to do is to load only the pinned tabs and the one that is focused when restoring a browsing session. This means that I can close my browser at any time and go back to it as it was without having to wait like 5 minutes for it to become responsive. On top of that even without many tabs Chrome starts much slower, on a few years old computer (core 2 duo with 4 gigs of ram) Chrome starts too slow (mainly because it tries to read so many things from the disk I think). Once it starts it is okay, but this means I have to keep it preloaded all the time for it to be as responsive on start up as Firefox. No thanks.

Omnibox completion. This one suck big time in Chrome. At the beginning Firefox used two inputs - one for the address (address bar) and one for the search (search bar). However for many years now one can just remove the search bar and use the address bar to search Google (or any other set as default search engine address). On top of that it uses your bookmarks, your history and your recent searches and it learns to be much more of help than what Chrome does. Chrome for example almost never uses my bookmarks to help my with the typing, it is limited to only 5 entries and usually most of them are Google suggestions. On top of that there is no easy way (panel or otherwise) to search your bookmarks quickly. Chrome has those "apps" installed that are just links, but they are not configurable. For example I use InoReader, but their 'app' icon uses http. I want to use https for the service, but even if I add it as a bookmark Chrome never completes it for me. I have to navigate my bookmarks and find it. Way to frustrating.

Pinned tabs. In Firefox you cannot accidentally close a pinned tab. In Chrome pinned tabs are not really pinned, they are just visually reduced to be as large as the faveicon.

Expose like functionality for sessions. Okay this is really interesting. With this one Firefox allows me to have several filled with tabs views into the same browser window. I had 3 and kept them there for months before I had the time to read all of them and the browser remembered them. In chrome I am forces to bookmark those and mark them as "read it later". But those should not really be bookmarks. Note that this cannot be simulated with several Chrome windows, because I cannot close all windows at once easily.

Often used web sites: Chrome and Firefox have the ability to display thumbnails of your most often visited web sites. What Firefox allows you to do on top of that is to pin your favorites and thus have quick access to the ones you think are most useful and not the ones you really visit most often. This is to say the tool is versatile and you can use it as you like, not as someone has decided for you.

Superior plugins. At this point I have only one in mind but it works much much much better in Firefox than anything close to functionality in Chrome - ScrapBook. In Firefox the extension uses nice side panel, has search and most importantly - saves your documents at configurable location. For example in your Dropbox folder. Chrome variants use indexedDB and cannot sync between several computer in no usable way. And this tool has proven to be so useful that I simply cannot forgo it.

Better support for themes. You can make Firefox look like Chrome. You cannot make Chrome look like Firefox.

You can force sync. In Firefox the sync button is exposed and you can force the sync. In Chrome if you make a change right before you close the browser it might not be populated to the server. This is especially bad in relation to the fact that a bookmark has to be used to mark a web page for later reading (see above).

Last tab closed behavior: In Firefox when you close a tab and it happen to be your last tab the browser does not exit, instead a new tab replaces it. This is also configurable. The problem is that I am just closing a page, I do not have to pay attention if it is the last one in the window. This is very irritating especially when combined with the slow "fresh" start of the Chrome (see above).

AdBlock(+): This almost never work as intended on Chrome. Maybe it is developers problem, not necessarily a browser problem, but still as an end user it irritates me.


If I think hard enough I can come up with several other reasons, but I think this suffice to say that I am a bit on the 'advanced' user side. Chrome appeals much more to those that do not rely so much on their browser to comfort their browsing for whole days/nights. I know people that use it very happily, do not have even a single bookmark and most often do not even know which browser they are using. This is all fine as well and I know Firefox is not for everyone, neither is Chrome

What I miss from Chrome when using Firefox?

As much as I love Firefox there are aspects of Chrome that I like and miss when using Firefox. A list follows that describes the most missed features.

Open as window app. Using the 'app' icon you can configure a URL to open in a new window as a separate app. It is especially useful for apps that do not use popup windows and are examples of the so called fat clients or rich apps: Gmail, InoReader, Youtube (especially now that it does not reload the page) etc. The window manager picks up the face icon as application icon and you have somewhat more real application on your desktop.

Task manager: Sometimes while browsing I notice that my fan goes on and on at the highest speed. Chrome allows me to see the CPU.Mem usage of each separate tab. Well, this is not entirely true, it shows me tabs grouped by processes, which is not the same as being per tab but never the less it allows me to narrow down the offender. On top of that it can give useful information from developer's point of view.

Offline apps with escalated privileges. I do not use one in particular that cannot be implemented well with IndexedDB and AppCache (that is to require access to hardware outside of the standard web APIs) but still it is good to know that it is there if you need it.

Chrome makes features available faster than Firefox. Such example is Speech synthesis and recognition, File API etc, things Firefox users have to wait for much longer.

Chrome has more horse power when it comes to raw JS performance: For most apps JS runs smooth on both browsers, but computation intensive apps tend to be more responsive in Chrome. One such example is Google spreadsheet. I have spreadsheets with thousands of records and tens of sheets and thousands of formulas and those run around 20% faster on Chrome. I am not sure if it is because off the browser or because they were fine tuned for Chrome but it is the fact.

This is again not all, but what comes at the top of my head, the features I miss the most on my day to day browsing.

I am really pro-Firefox for several ideological reasons as well, but I am not too optimistic for its future. They as a company have dedicated too much effort in Firefox OS, a project that is born dead in my eyes. On the other hand Google uses Chrome to make it possible to create apps that run fully offline on the desktop and on the mobile (packaged apps) and eventually this will make them a leader as a target platform for development while Firefox will remain marginal "proof of concept" platform with no adoption outside the geek community and is essentially waste of time and money. I know that Mozilla is non-profit, but making useful things for the users is IMO more productive than to make a very limited-use OS.

Closure tools development in the cloud

I have been waiting for this for some time now!

Probably this happened some time ago, but I found out just today that it is now possible to use cloud9 ide on a complete shared environment, which means I have a terminal, python and java runtimes and I can finally develop using complete closure tools in the cloud! I just had to copy over my setup from a local folder to the hosted environment and it just worked.

Well not "just", because they run an older version of python (2.6), but it is pretty easy to overcome this.

The finding was part of my ongoing investigation for an article on using Chomebook as a primary laptop for the modern web developer. Of course my work flow is already skewed enough by my decade and a half living with GNU/Linux, but even I find it frustrating to constantly have to "update" and "distro-upgrade". The last piece missing will probably be the hardest to figure out, but I have one last trick up my sleeve.

If it all goes well and sound I would be buying my next laptop from Google. If not, well, I would be still buying a laptop with Chrome OS but it would be the cheapest one (Samsung S3) and will use it only for light reading.

Tip: I know that the Samsung can be used for development as well, because all the compilation and checks are run on the server, however because it has only 2GB of RAM it would be hard to open many "applications" on it and I am not sure how usable it would be for devs.