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

април 14, 2014

My opinion on StackOverflow

StackOverflow is a strange place.


On one hand - it has lots of information you can directly access (via Google search) if you are just stepping into a technology (be it a language, a framework or what not).


On the other hand the moment you have a real problem (so not just being lazy to read the docs or test it yourself) so end up voice in the desert. No one even tries.


And then there is the 'reputation bullshit'.


Let me ask this: If I have a question (very clear one - can I trigger file download from custom made menu in Drive) and the only person who answers does not really answer but instead starts to explain to me how the other APIs work (Like the UI api and how to put a link on it and wait for my users to click on it, mind you, completely re-imagining the workflow - something I can do on my own) my reaction was a downvote. Which provoked several downvotes from him apparently and probably some of hif fan club. After a few more sharp messages the guy finally gave me an answer (at which point I no longer trusted his answers btw). But in the meantime I have lost 7 points and he has lost 3.


So to recap - voting someone DOES NOT directly correlate with his knowledge nor his helpfulness. It is simply an emotional response to user's desired to a) be noticed and b) be always correct.


I myself have answered lots of stupid questions in SO. Mainly related to TypeScript before I got bored of it. And NONE of my hard questions have been answered. They still sit there, more than a year after I have posted those.


If you are wondering: Question 1, Question 2.

Now, I am not saying SO is bad - it is a good place to fast-track on a new problem/technology, but once you get to a certain depth you get nowhere with SO. Which is sad. And makes SO less and less useful the more you gain competence on the area. Where should one go after that? I have no idea...

dart and performance (a test journy in game land)

I have been playing with Dart and StageXL for 10 days now and I feel like there are thoughts to be shared. Part of this post is also an update to a thread in the StageXL group

The game is really simple clone of the flappy bird. The main idea is that the gameplay should be easy to implement and understandable in order to allow me to concentrate on the internals of the game and the rendering engine instead of toying too much with the game itself.

At one point I have noticed that the way the original game detects the collision of the bird on the trees is a naive one and often gives false negatives. I went on reading about what is possible and present currently in Dart and StageXL in this regard. Turns out only very basic approach is available internally as StageXL is geared as animation library and not as a game development framework. Never the less this allowed me to play a bit more with the language itself.

For collision detection I have utilized the following approach:

  1. Using the DisplayObject.hitTestObject find element(s) that are potentially colliding (in the test game I developed it could be only one out of ~ 10).
  2. Determine the rectangle where the transformed protagonist will fit.
  3. Using detached canvas element, clear it and draw the transformed image of the protagonist.
  4. Using detached canvas element, clear it and draw the potentially colliding element. 
  5. The 2 canvases used are just big enough to contain the protagonist image.
  6. Compare the non-alpha pixels of the protagonist canvas to the colliding element canvas and there is a pixel where alpha is greater than 0 we want to return true (i.e. there is a collision).

Here are the results of this little experiment.

On PC and DartVM this runs so smooth, one would think why people are not using it all the time. The average time to run the code per frame with complete pixel accurate collision is ~0.35ms (with time limit of ~16ms this is pretty good I think).

Compiled to JS it runs at about twice as slow, the frame taking about 0.78ms still pretty good. This is kind of strange since the code is mainly touching webGL, canvas and arithmetics. Canvas and webGL are DOM interfaces and thus there should be no difference, so the only possible place of optimization / speed is the arithmetics (at least this is what I initially thought). I am not an expert in VMs, but having a VM that can run at least twice as fast the calculations is awesome!

However the problems with the 'compile to js' approach start to show as early as here: taking a look at the memory debug panel one could notice a very different pattern in JS world. The game has two different modes: off-game mode where a very simple animation is performed and on-game mode where in addition to the very simple sprite animation of the 'protagonist' obstacles are animated as well as collision detection is performed at each frame.

Here are the images.
DartVM

V8 - Chrome desktop

Notice a difference? Again - the code is only using a single canvas element with 3d context (webGL) to draw the animation on it and internally StageXL is using detached canvases and lots of calculations and canvas transformations. First of all - before the snapshot is taken the memory is force cleaned. Then for the test I let the off-game animation run for a while and then I play a little bit and then I leave it alone again.

On top of using around 4 times more memory (JS VM versus DartVM), JS also shows significant difference in memory allocation patterns when more code paths are executed per frame compared to DartVM. For example in the first image it is impossible to distinguish when I am playing the game and when not, while in the second image taken from JS land it is pretty much very clear - the climbs are much more steeper when the more complex code path is executed. Notice the change in steepness around second 33 in the second picture - this is where I killed my protagonist and the complex animation path is discarded. Notice also the enormous difference in memory allocation - going from 7.2MB up to 10MB in 40 seconds, while in DartVM we went from 1.8MB to 2.9MB in 5 minutes. Actually I had to wait for the garbage collection event to happen in DartVM just to see if it will ever happen, this is why the screenshot of the DartVM is encompassing such a long time period. For a moment there I thought it was broken - how come no GC event....

One negative thing about Dartium - when in debug mode (console open and recording) the performance on the screen was worse and noticeably janky. Turn off dev console and you get perfectly smooth animations.

The above summarized data about the performance and memory footprint were all taken on a core i3 @ 3.3GHz with 4GB onboard memory and a dedicated video card Nvidia. This is all well and nice, but the target platform is actually phones and tablets. It was time to test this on those devices.

I started with nexus 7 as easier to approach (no need to find a Mac computer just to debug some web stuff ha!). The results are pretty sad.

The memory consumption is pretty much identical to what we get in the desktop chrome (not surprising).

V8 - Chrome mobile

You can again easily see when the game is on and when not. Also the memory utilized is in the same range.
A very significant difference is however noticed in the frames timing. While on i3 CPU it takes under a millisecond to complete the code paths in the RAF, here it takes about 5ms on average, peaking at ~9ms!! This is so much more than what we had on the PC. Also the composite time is very different (although the canvas size is kept the same for measurement purposes - 480px x 640px) - ~2.5ms versus 0.5ms on PC. Strangely the time reported for compositing in Dartium is reported to be 0.2ms... (doesn't really make sense here...).

Even with those measurements the game should have been pretty good on the Nexus 7 device. But it is not. Well, remember the memory allocation patterns? This is the worse enemy of any game - having too much garbage. Guess the time for garbage collection events on Nexus 7.... ~80ms on GC cycle!!!! This is killing my game (and possibly will kill yours)!

Before following the logical steps to attempt to alter my code to lower the memory allocations and recollection I wanted to know which are the places where most of the CPU cycles are going. From the above tests I already knew that compositing the scene on Nexus 7 was taking ~3ms, which leaves me with ~13ms time to handle all the game logic. I have also tested with LG phone that claims to have the same hardware specs as the Nexus 7 device. Turns out the JS time is almost the same, but compositing time is 4.2ms. The screen is smaller and I expected the compositing time to be shorter, but instead it is longer, leaving the game in a pretty bad state: that is even in the time where no GC events occur the frame rate is below 60.

Back on my mission to understand performance implications of dart2js code I used nexus 7 to measure where is the CPU time spent.

Surprise - surprise! drawImage was taking 50% of the CPU. This is strange, I would have expected this to be a fast operation, considering the fact that the canvas is detached from the document. Anyways, what I was more surprised about was that 14.30% was spent in the comparison of pixel data of my two hidden canvases, but the actual comparison was only 7%, the other 7.3 was spent in 'convertnativeToDart_ImageData' - guessing from the name it converts the native ImageData object to Dart list of integers. Transforming the canvas is also 7.14% of the total time plus the clearing of the canvas. As a whole the slowest is the drawing of the image data. I believe I have put together the best practices (draw on a full pixel value, do not attach the canvas to the DOM), but still the combination of those actions take ~10ms, with a compositing taking ~3 the game is on the verge of not being playable.

Clearly using a different approach for detecting collision will reduce the amount of time (since we can avoid the most expensive operation - i.e. clearing the canvas and drawing on it).

More interestingly - using profiling from Dartium was not possible. The window.console.profile() call did nothing there. I am not sure if this is a bug or simply it does not work this way with DartVM, but it would have been interesting to see.

Going back to actual search for solution I decided to rework the code and instead of Dart idiomatic code to write what is known to work best in JS land. For more details on how one is supposed to write code in Dart please refer to this article.

One of the things I liked the most was the lexical scoping, combined with the lack of necessity to constantly write 'this' leads to lots of closures, trashing instances in methods and so on - the code becomes really terse and easy to understand and follow. Now, judging from the benchmarks DartVM performs around 2 times better than V8. Well, I have no idea how those benchmarks work and what they do compare, but the facts are like this: If you write your code in the Dart idiomatic way the code works perfectly fine and really fast in DartVM. This includes creating and trashing a lots and lots and lots of instances of small classes in a single stack (i.e. in one tick going deeper), using a lots of closures (think List..forEach()and List..forEach((_) => [_.a, _.b].map()) etc) and dumb objects, no local variables or lots of local variables, deep object nesting (o.o.o.o.o.o.o for example) and so on and so on - things that for years have been condemned and considered a no-no in JavaScript when performance is number one consideration. And to tell you more - i feels GOOD! Not having to write 'this', creating instances all over the place to make your code more readable and understandable (as opposite of creating cache properties all over the place and accessing it in bizarre manners just to avoid allocations to be cleaned later by the GC). Almost like a dream....

But it comes at a price. The dart2js compiler aims to produce code that is as close to the original dart code and its idioms, so basically if you use closures and forEach etc they end up in your code. Of course tree shaking is performed, but I do not see a lot of code rewrite being done, even less code optimization. It is a grey area (means it is not clear who should be optimizing the code in this case, the VM or the compiler. We know that in Google both are employed in different projects (for example GWT produces code that is highly optimised per browser, while Closure compiler produces code that is optimized for size and can potentially lead to more ineffective code when it is executed in V8 (actually there are several bugs submitted about this - function in-lining leading to calls that are de-optimized or cannot be optimized at all)).

When we write in JavaScript it is our responsibility to know all the catches and tweaks and quirks of the underlying VM in order to make most of the hardware and software capabilities. This is also true for transpiled languages (like typescript and coffee-script) but how should we handle this in Dart? Dart has its own VM and from what I have seen already it is optimizing all those 'dart idioms' very well and even with them it outperforms V8. But then the code needs to be compiled to JS and this is where I feel like the authors of the compiler fail us: yes the produced code works in all browsers, but the speed is not what we see from the benchmarks, the performance is 4 and more times worse than that of DartVM. So basically what I said before that Dart is more capable of what we expect - I lied - it is what it is, around twice as fast as V8, but the code dart produces for V8 is far from excellent in regards of memory usage and raw CPU performance. Seasoned JS developers know how to write code that is both memory efficient and performant (and those often mean the same due to those GC pauses), but then again those same developers are hard to find and even harder to make them do dull projects.

Because of the structure of Dart I assumed that it would be much more easy to produce more 'static' JavaScript code than to analyse a whole application and try to optimize it (à la closure compiler). I have been imagining some frivolity when rewriting the Dart code to JS such as turning forEach into for loops, creating bound and cached instances for often run closures etc etc, - things that we know to speed up and lower memory variance in large applications. Instead the code is preserved as close to the original as possible and thus it is again responsibility of the developer to write the same ugly but high performance code if the target platforms is known to be JS.

So what I did to mitigate things: first - remove all closures (so no forEach, no map etc). Second - get rid of all in-method created object instances (mainly Matrix and Rectangle instances for calculations). Instead create 'cache' instances and tie them to the main object (the one where the methods are executed). So now instead of creating several matrices only one instance is used and is mutated several time and reused. Same goes for the rectangles. Third - get rid of local variables, instead use a List instance as cache and put every number needed in there.

Result: the code got as ugly as any 'hand optimized' JavaScript you can see in my repository. In the often called methods there is no object creation or freeing whatsoever, nor variable (well I am not sure about the numbers, in JS those are primitive values, but in Dart those are Objects, so I am not sure if this optimization is really worth it). Memory wise I got this: 7.8 MB going up to 10.2 and back down. So now the logically same code executes with much less variance in heap allocation, which means the GC pauses are shorter and less often. Indeed the game play experience improved and GC time went down to ~30ms in the worse cases. This however is only my code and not the library code (StageXL). While the library is great (I could honestly said I wouldn't be doing this test if it was not for StageXL, so kudos to Bernhard for all his answers to my stupid questions) there are some (well - a lot) of places there the code is written directly in Dart idioms (so would run great in DartVM but not so great in V8). Those I do not intent to try to optimize out and there is no point in it: the point was to see if applying JavaScript idioms for fast code would benefit an application built in Dart and run as JavaScript.

Well the answer is (sadly) - YES.

My assumption is that this would not matter in more static web apps or apps using other means to animate, but for games, while providing great library and excellent tooling as a whole Dart hides too many underwater rocks. You have to already be a JS ninja to write Dart code that will perform best when compiled to JS, which basically nulls out the benefits of Dart IMO. Dart promised to get us rid from JS. And yet we are going back there the moment we need a bit more performance.

I should finish with a positive note: all this will be gone once DartVM is available as  a built-in Chrome option in stable. At the penetration rate of the new stable version to the users if would be a week after that release and everyone will have it. It is another question how will we deploy pure dart code to the users (my project for example uses ~500 dart files, imagine downloading those to the client...). But it could happen and then one will be truly liberated from the JS. But what about other browsers? Mozilla's ex CTO/CEO is directly opposing it, while Microsoft and especially Apple have financial interest of hindering the adoption of Dart. So it is not purely technical problems after all. Anyway, with Dart support in chrome one would have a large user base (Android + ChromeOS devices + all chrome installs) and in the beginning I think it is enough to incline the developers to explore it more as a platform and less as a compilation mid-stage for JS. Just imagine what you could write with those extra CPU cycles...

Ah, the dream..

март 03, 2014

GWT in Dart

I had no idea that this is even existing, but...!

Behold: http://dartwebtoolkit.com/

Okay, enough pathos. The thing is I always wanted to use GWT for a project (or several ones), but my knowledge of Java is about a book long and one that is for the first year of CS bachelor degree. And the book was a bad one!

It is understandable that I wanted to try GWT, after all it provided type system, safety, performance, developer productivity and is backed up by the best web app producing company out there. But this was not incentive enough for me to learn Java. Besides HTML and Java do not mix that well despite what you might have heard.

GTW was partially ported to Python and I have played around with that version of it, however never got to a working large scale application, mostly it was toy projects, jut to get a taste of the tool. As you can imagine the tooling around Python is not as good as the one around Java.

That and other factors led me to Closure tools.  After all it was used to build the flagman application for Google. t is indeed a great tool and anyone stating otherwise is simply ignorant. This is not the place to enumerate the benefits and advantages one gets with the project components. However they still lack something I find to be important for a productive developer: good tooling and IDE integration. There are several projects out there, some free and some at a steep price, but none of them solves the problem (and to be frank the premium ones are a rip off and worse than the free alternatives).

And then came Dart. If you have not watched one of the tens of videos introducing the language and the IDE go and do it know. You have no real reason to not do it, especially now that youtube supports playing the videos at twice the speed without loss of audio quality and without higher pitch of the voices. 30 or so minutes worth it!

Unfortunately Dart did not came with a sophisticated bunch of elements ready to be used in a large scale application. It came with Web UI, which was then deprecated and inherited by Polymer, which is powerful and new and cool, but far from ready for production IMO (it lags behind the JS implementation and has many bugs).

Little did I know that someone somewhere was thinking about it and working hard to implement the GWT set of components in Dart! It was just today that I have learned about the effort and the demo applications look great! Go on and take a look.

To sum it up - now you have powerful set of web tool-kit coupled with easy to learn yet robust optionally typed language with excellent IDE support.  If you are trying to build an application with lots of widgets that are more typical for the desktop application look and in the same time learn a new awesome language look no further!

февруари 19, 2014

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....

януари 29, 2014

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.

януари 24, 2014

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.




декември 29, 2013

The problem with on-line apps

Okay, I have to admin on-line web apps are absolutely great. You can use any computer and if you remember your password you can use the tool from anywhere in the world, you don't have to bring your own laptop, you don't have to worry about backups and disk failures and you are always using the latest and greatest version of the software. Isn't it great!


Well, it is great for as long as it lasts....


One after another companies and start-up fail or are being bought and/or merges with another (mostly commercial) product and with a little to no notice are being closed down. And it happens very often, more often than you might imagine.

Lets take Google reader for example. What a great service it was. And it closed down, regardless of the protests, regardless of the on-line groups opposing it. Vuru - financials service also closes now with only a month notice. Half of the applications I have ever installed in Chrome do no longer exist. Half! And the other half are giants like Facebook, Google mail etc. And even they can decide to close down at any given moment. As soon as they decide that it is no longer relevant or profitable there is nothing from stopping the company from closing down the doors and windows and there is no way you can argue with that.

So what does that mean for you? Lets imagine this: You have worked for several days, maybe even weeks creating the ultimate application in Google Spreadsheets. It is NOT portable, because you used all the excellent services provided in the scripting environment so basically your sheets are useless outside of  this company's environment.

But Google is almighty and great, they will not close down. Oh but they will, sooner or later they will shut down services that are not profitable for them. And then what?

I will tell you what - you re on your own. Currently there is no way to write those scripts portable so that they will work with any other known environment. I have data collection and analysis tool written for Google spreadsheet application spawning 24 files. It is working very well indeed and it is hosted for free for me etc. But what will happen when Google decides that the new - improved by the way - spreadsheet application drops some of the services support. Like they actually did? Can you stay on an older version so all your stuff will continue to work? No! Can you take your application elsewhere. No! Can you do something about it? No.....

So next time you agree to fully rely on a free or paid on-line web application remember this - you have absolutely no control over your data. And even if this is not a problem for you think this: you have absolutely no control over the software. And if this is also not bothering you - you have no control on the availability of this software. It can disappear  in just an instance!

I for one am thinking about it. The problem is this: 6-7 years ago when Google started this "the web is the platform" bullshit it sounded like the end of an era - every one can put their application on-line and reach any user on any device and perform outstandingly business-wise. Yeah... and now every and each one of those excellent performers hold you in a grip firmer than any of those other before them. Yes, I am talking Microsoft. The "evil" they was / are, they would NEVER make you loose your application. You had a choice. Stay with the older version and protect yourself the ways you can (Intranet, firewalls, whatever) or upgrade and pay anew once again becoming master of your applications. Now this choice is gone and you are completely at the mercy of those companies. Think about that. You do not own anything. Your data, your software or its availability. You control nothing and have no rights.

So congratulations to you all on-line service and apps users. You have been schemed out of your digital hold o things. What will happen next? Who knows. But the next time someone starts to praise to me the advantages of the cloud and web apps I might just kick him hard.

декември 27, 2013

Rss for personal use

After Google reader have been shut down in July I migrated first to Feedly and ten to InoReader.

Ino is very good if you can get used to some limitations.

Lately I have been reading more and more on privacy concerns and it turned out that all those on-line services have one or more issues when it comes to your privacy. Basically they can do whatever they want with the statistical data collected based on your usage and interests under one form on another.

I can understand why for some people this is not a big concern, however there are also people who strongly disagree with this policy.

I tend to be neutral on it, but just for the sake of the argument I decided to try and go on the other side and see if I can set up a local solution for RSS reading.

Now, it is clear to me that large percentage of the younger population prefer to get their news pre-filtered by their peers (via facebook, tweeter and g+ for example), but I still have several very different interest and no particular person(s) to count on for providing me enough information on all topics that might interest me, so I use RSS news feeds daily.

Quick look up for free Linux solutions for RSS reading reveal that most of those are console based and are not very useful if your feeds contain lots of media (pictures, embedded audio and/or videos) so I decided to go with liferea.

Now, one interesting aspect of liferea is that it can sync with those on-line services you know already (like Feedly and InoReader). However the objective is to be independent of those.

So what you do is basically export your feed list from the service provider and import it in liferea.

Liferea keeps all its data in .liferea_1.8 in your home directory so it is easy to set this up as a symlink and actually use portable media to store your data and take with you. Note that you should actually use fast flash drive as the low end devices are too slow and will result in bad user experience is used.

I think same could be done for your .firefox folder. Even thou Mozilla says it protects your data and encrypts it, Google definitely does look at your usage. Chrome is a very good browser, but I do not feel comfortable using it for my day to day browsing so I use it primarily for development.

As a developer I like the idea for the open web, but as a business trained mind I can clearly understand that those "free" services has to operate on something and that 99% of the users do not actually pay for the premium features so it is very hard to stay afloat with only free riding users so it is only natural to try and capitalize on the user statistics. This is why I think that most services must be pay-walled. If you pay you have the right to demand conditions. If you do not want to pay just use other personal solutions. Free services should die.

And if this means RSS might die, so be it.

декември 11, 2013

Component goodness (Polymer) - (with update on readiness)

After several months of active development I think Polymer deserves another trial / deep look.

My initial reactions to it was negative due to several assumptions I had:
  • there is no way to compile down to one file
  • there is no 'global compile-time checking'
It seems my first objection is now being addressed and there will be a way to compile down all the imports and links into one single file, which is great. The second one is hard to explain if you are not used to Dart or Closure ways of doing things, but basically they make compile time graph of all your calls and compile an AST of your application and operate on it (checks, asserts, rewrites etc). The thing is that you should not really need that if you use the declarative approach to build your application, which is what Polymer assumes you are trying to do.

So how do we do this?

First go get the code. I used c9.io workspace, but if you have a Linux/MacOSX machine you can do this locally. I tried all the methods: zip archive, git pull and bower - all of them work, but some of the examples need path tweaking to find the files. Also you might need to add both polymer.js and platform.js if non-minified version is used (bower and git).

I find that one of the most interesting tests one can do with a new technology is to try and build something complex that you have already built with another technology. Then compare the result, the experience and the speed of development between the two approaches.

My intent is to use Longa as a product developed with Closure tools and to try to re-create it with Polymer.

Longa is a large product (~2MB unprocessed JS and templates). Compiled with closure compiler it is boiled down to 115KB (JS plus the templates) and is further compressed by the server to 30KB, which makes a reasonable download size for a mobile web application. 

The HTML cannot be compiled down (names matter, its not like JavaScript), thus the savings should be coming from a more compact expression forms. 

For now I have re-created only a single channel record and I could say I am already impressed with what the platform is capable of doing without actually me needing to write any code at all. Of course there is much to be done and even more to be desired.

For example the styling of two shadowed elements do not work as I was expecting (in the context of a single polymer element and the elements are regular ones - a div and an image tag). Maybe it is a bug, maybe I am missing something, but still it is kind of a hurdle for a new comer, regardless of how many tutorials are out there, pretty much all of them concentrate their efforts on the area of isolating the styles from the outside world and not on how they work internally.

One of the most interesting things I notices was the fact that you can bind the styling of an element and mix it with an expression, so an element can calculate style values based on properties and arithmetics. For example:

#selector { height: {{height+20}}px; }

is a valid style inside the template of an element!

Another interesting factor is the abstraction of complex routines into elements. For example ajax calls are hidden in an element and you can listen on that element or any of its parents and use it as a regular element (just like the select or change events in native controls).

All in all it is at least an interesting toy. I am not sure how fast the browsers will get to the point where all this will work without hacks or shims, but at least for a certain class of applications it will be a nice fresh breath out of the JS insanity we have been living with for the last 10 years. 

As a conclusion: even if your code is very complex (for example something like a drawing board or document viewer) you can at least try and ship it as a web component so others can use it in the simplest form possible, by just import it and use it as a tag in their markup. I for one will try that!


Update (12/16/2013): Turns out most of the things do not work in FF/Mobile Safari, especially the styling. Some style rules do not work in Chrome even with no apparent reason. For example rule like this:

padding-left: 4px;

does not work but this one does:

padding: 0 0 0 4px;

I guess there are still lots of bugs and features missing, but clearly if you want to just tap your fingers into the power of the web components now is a suitable time. However if you want to go to full blown large apps you should definitely wait at least a few months! 

ноември 09, 2013

HP Chromebook 11 - developer's review.

Ever since the inception of the Chromebook project I have been a huge fan.

I envied the attendees who got the cr48 one. Then I was furious that the Samsung ARM one was not available (or any of the other ones as a matter of fact) in my country. I have travelled, but never got the chance to see one or wait long enough for a deliver on any given place.

Finally few weeks ago when the new HP Chromebooks have been announced I decided it is time to purchase one of those.

A little bit about my love-hate history with the 'new laptop' purchases.

I have an old Thinkpad X61s. Purchased 6 years ago when it was brand new it costed a lot! Really big money for the time. But I loved it. I has always been running with Linux and even thou I had to manually install a script every time I reinstall (every 18 months or so) it worked great.

A year and a half back I realised it was maybe the time to upgrade. So I went hunting for a new laptop.

This is the place to say that I do web development for living. Mainly front-end development (CSS, HTML, JavaScript). Modern front end development also requires you to run Node js, Java, GNU Make, Bash, Python and a series of other more obscure tools. They are not part of the final product but greatly reduce the work load and provide assistance which is invaluable for modern development practices. Linux fits here in the middle. Lots of tools work best with OSX, like Casper etc, but is much better than Windows.

Naturally I went first with Thinkpad again - Edge 340 (or something like that, sorry don't really remember the numbering - core i5, 4GB, 120GB HDD, 11 inches wide, glossy display, built in camera). Well the problem with that laptop was it was way too hot to tolerate on my lap. And the fan never ever stopped even on Windows, let alone on Linux. So I returned it.

Then the next choice was Apple - MacBook Air 11 inches. I have to say it was a very well built machine. It only goes hot when watching flash videos in full screen. And then there was OSX. Well, there is the menu bar always on top - stealing precious 25 pixels from a very short 768 pixels. And then there was Chrome not being able to make plugins go full screen (so when you go to apple trailers you have to watch them as small as they come). And then there was the fact that lots of tools had to be managed/installed from different sources manually. At least in Linux there is one general command to manage all software. I have been with it for 2 weeks and then I returned it. Some say I should have given it more time. Sometimes I think that too, but then I remember what I had to put up with all the time for the smallest things and I do not intend to to back to OSX any time soon.

To sum up I am a web developer who is fed up with badly designed hardware and software that was not fitting my expectations.

And then there was ChromeOS. I decided to try and live off the Chrome browser (on Linux) for a month and see how it goes.

I uploaded my pictures to G+ and my videos to YouTube, my pdf and manuals to Drive and my docs and spreadsheets to Docs. My music did not fit in anywhere, but I was listening more and more off my phone so it was not such a big deal. I moved my development environment to Cloud9 and what I was not able to move there I accessed 'live' with sftp mounts. (Well I was not aware that sftp mounts are not allowed in ChromeOS which sucks).

The experiment went for like a month and I was sure I can live with the Chrome browser. I still have my work PC at the office if I needed to test Firefox or IE compatibility.

I was thinking a lot which Chromebook to purchase. At the end I just wanted a silent machine and the one without a fan seemed just the right choice. I was aware that it might get slow with more than 5 - 6 tabs, but it was okay, I just need to make some adjustments to my browsing - that's what I told myself.

So I went and purchased the HP Chromebook 11 - ARM.

First I needed to wait for the availability. Then I needed to wait for the delivery. Then for the delivery from UK to Bulgaria. It costed me almost as much as a regular netbook (around 300 Euro). But it finally got here.

I had to wait (a lot) for the initial update, but after that it was fine. For viewing my email and G+.

And then I tried watching a movie from my thumb drive. H264 (480p) plays just fine. Excellent actually. Xvid is really bad (read SLOWWW). I haven't tried anything else yet, but I think h264 is okay. For now.

And this morning the shit hit the fan. I like to watch tech videos on YouTube at 1.5 speed. So naturally I went and enabled html5 player. And then it stopped working. Like at ALL! I was no more able to rewind in the videos. If I do it stops playing and it never comes back. Even after refresh. Even after restart. So I go back and opt out of the html5. But guess what - even if it says you are served the flash player you still get the html5 one. Even after clearing all caches. Even after resetting the browser. Even after deleting all the cookies. Even after powerwash. Even in incognito mode. Even in guest mode. So basically you are stuck with html5 play back which is terrible on this laptop.

After advice from G+ community I installed an extension that half resolved the problem. Now the video starts loading and then the extension kicks in and reloads the video this time with the flash player. Great! So after pushing for years now for html5 it does not work on the machine that they have designed? The big shots have more important things to do I guess.

So I went about my day and logged in c9 to do some work. Yeah, not so fast! c9 uses socket to communicate. And the HP11 decided to drop the connection every few minutes. Even when on the same network with the Thinkpad which never drops it. Even when left alone in the network with the router. Even after powerwash. Ha! So basically the terminal restarts every few minutes. And youtube videos stop every few minutes. And it is not the network and it is not the router. So it IS the HP11.

At this point I doubt that it could be used for anything more than to rant about it on the Internet. That one is does great. It is actually so bad that half of my spreadsheets do not work (actually they do, but after one makes a change it starts auto save and no new changes are reflected in the UI until a successful save and the saves take 1-2 minutes. Yes, MINUTES!

This reminds me of a toy that is sold currently - an imitation of a laptop which plays some music and displays some text to teach the kid the alphabet. Anyone looking to buy such a toy please feel free to contact me - I have one for sale and as a bonus you can also (try to) watch your porn on it.

In the scale from 1 to 10, 10 being the best laptop, HP11 is a 2. One point for being completely cool. Half point for being shiny good looking and half for the good display. Everything else about it is grossly unbearable and should never ever be sold to customers.

Important notice: It is NOT the software. I have lived with Chrome-only environment for the last month and everything was great. But it is great when run on a normal hardware. When run on something like the HP11 where the wifi is unreliable and youtube seem to be hated it turns into a nightmare. Developing in the cloud is absolutely impossible (if you want to stay sane). And you can never install anything locally, remember?

So two options left: sell it or try to run Ubuntu on it. About that - only 4 GB left free. How come from 16GB? What do those people put on this machine? I have Linux installs with 10GB only root filesystem and with all possible software (including build tool-chains, java, gimp, open office and lots and lots of other software it never goes beyond 7GB. How come ChromeOS already ate 12 GB?!?!? Its a mystery!!

When I get back to the city I will try it again. And if it fails me again I will just sell it. Too expensive to return it.

I have no problem parting with it. The problem is what will I get instead of it. I cannot live with Windows. And I certainly do not want OSX. But Linux is becoming weaker and weaker with every year. ChromeOS seemed like a nice fit, but evidently that still need to figure out the hardware policies. Because I am not paying 1300 USD nor putting up with a half usable laptop.