The real price of going ChromeOS all the way

Chromebooks to this school, chromebooks for that school...

It is being repeated over and over again, reviews are being written almost every week about a new chromebook (which is by the way exactly the same as the one from previous week, including chips, size, weight, battery life, keyboard, performance and so on), tons of user testimonials and praises are being liked and re-shared ... it is getting a bit old, isn't it?

Chromebooks are here to stay and with the new strategy to teach kids on them they are more than probable to remain part of the picture if not dominant.

However one important question is rarely if ever asked: what is the real price of using chromeOS as a replacement device (not as primary one, and not as a complimentary one, but as a sole keyboard equipped device)?

In the plethora of available devices like phones, tablets, TVs and now watches, one almost feel like there is no real need to have a PC or a tablet. Most people either already have one and use it in the rare cases where one of their other devices cannot do the job or buy new one(s) for one single reason: work!

But let's define how a laptop or a PC is used for work! If one's company is already embracing the cloud chances are they already use one or several services and pretty much all the office work can be done from a browser, thus chromeOS is capable of handling this. However there are several large classes or work related tasks that cannot be done without a specialized software: CAD/CAM, 3D production, Electrical and other type of engineering, and... software development. 

The last is possibly the most common use case. For years now companies are trying to create businesses that offer an online solution for those kind of work related tasks, but the adoption is slow and currently - very low. The concerns are numerous and come from different sides: security, speed, availability, reliability, management etc. The reality is that while those services are well intentioned and legit business ideas, the execution is often subpar and even if it is at good level with the user target the cost if overwhelmingly steeper compared to the cost of ownership. 

So how do things really stack together for a regular Joe developer for web? I will present a simple example - one that is of course based on experience (mine and those of friends of mine who have switched) and is by no means presentable as evidence, but I think it comes close to at least people in similar situation. 

So, Joe is working as a freelance developer, web stuff, JavaScript, PHP, some HTML and CSS. However from time to time he has to deal with Java, Python and other technologies. Joe knows that there are at least two possible solutions for his needs: a MacBook or a ChromeBook. The projected lifespan of the laptop would be 5 years.

MacBook:

Price (ownership): 1299$

External ssd disk (for backups): 199$

Text editor/IDE: 70-100$

ChromeBook:

Price (ownership): 199$-399$

Storage (auto-backups included by vendor): 2 years free, 1.99/mo for 3 years = 71.64$

IDE: 19.00/mo = 1440$

At this point we have to make some very important clarifications. The online IDE in the example is Cloud9, I personally find it to be the best for my needs and I have recommended it to my peers and this is possibly the reason why they use it as well. The pricing there is 'pay as you go' so basically it could be much cheaper than that, but it is worth noting that with the MacBook you get much more RAM and processing power than what you get on Cloud9 for almost the same amount of money. Also I have included an external disk for the MacBook case as one need to backup, we all know that, some of use learned it the hard way. With cloud storage this is being taken care of for us. 

I have not included other stuff like music or movies for several reasons: it is unclear to me how the cost of ownership compares to the cost of streaming, also I am not aware if purchased once the song becomes yours forever and can you copy it over unlimited times etc. I have also not included software like budgeting tools etc because I see lots of people migrating to online tools for this and not for other reason but being able to access their data from their mobile devices like phones and tablets. I would consider those expenses to be similar in both cases.

As seen from the above example if you are working as web developer the cost at the end of the period would be higher for the ChromeBook. That's okay if we apply some basic knowledge of finances and make sure the money spent in a period of time have different present value than the same amount if spent today, so lets keep it simple and say that those are almost equal (1).

Now let's consider a different price. I call it emotional price. People tend to love their stuff: gadgets are especially lover and Apple's products are at the top of loved possession. With a chromebook you simply do not care. I used to be proud of my computer - business class, slick, thin, wonderful. But on its own it is really nothing more than a way to show of as the components inside are doing the exactly same job as any other laptop. With the chromebook I really do not care. I know no one will notice it because it looks exactly the same as any other. Samsung attempted to make the chromebook look fancy and they failed. Being liberated from this emotional dependency and more over being unburdened with its security and safety was really something very new to me. 

Of course I try to keep it clean and working, but when my partner drops it do I freak out? Nope. Because I have no attachment to it. I know I can use another one, on the cheap end, and continue where I left of. Years ago Google put accent on that with the video ads for the first chromebook. Back then I did not even understood it. Now I do!

But wait, there is even another price - ecological. We all tend to say that because those devices are very cheap they are basically disposable. But in fact we do not use them as such. We use them as regular laptops, we tend to try to not throw them at walls and drop them, slip them in the bath full of water and so on, we don't care about them but we still use them as intended. So the projected life, while maybe not 5 years, is at least good 3 to 4 years. Of course Apple says that they do recycle and their laptops are indeed one of the best when it comes to energy efficiency. But think of this in a different angle: while your laptop sleeps for at least 14 hours every 24 hours, the cloud never sleeps. Which means that while you are not doing anything on it, someone else is using that processing power for something else. Cumulatively this reduces the material needed to satisfy everyone's computing needs globally. Think about the processor: yes, macbooks are really powerful, but how often do you load it at 100%, let alone load all the cores? Does it cumulate to more than 30 minutes daily? Now consider the cloud where you IDE is a virtualized machine and one single CPU is running yours and possible many more users. Electricity? If you run your MacBook at 100% load all the time it will not last 10 hours on battery, on the other hand cloud providers are in the rush to become greener and greener in ways we as individuals could not accomplish even if we wanted: cooling from the see, energy from the sun and wind etc. 

"But all the traffic I am making using those online apps, does that not require energy". Well yes, it does, but you are doing it anyways. Besides the amount of bytes to watch a movie online and to download it and watch it locally is the same. The amount of bytes you will exchange in a month of using an online IDE is lower than the amount of bytes you will exchnage to download a source locally and upgrade your IDE. 

Choosing a ChromeBook might be on par financially with buying a latest model MacBook, but the emotional and ecological costs are much lower in the case of ChromeBook.

And yes, it is certainly not for everyone, especially as a only device. But depending on your needs it could be reasonable choice and a more responsible one as well. 

Many years ago I have written about how you could be a responsible person in global planetary context and switch to Linux to keep the baby seal alive. Today I am saying this: be a responsible person and chose the greener alternative if you can!

Evaluating jsaction library.

From time to time one starts wondering how are the some bigger web applications written, what technology has been used and from the properties of the product attempt to make decision if such technology could be useful for one's workflow.

This week I decided to take a look at jsaction - somewhat small library used in the making of Google+. If you happen to not use G+ (and if you believe the Internets - the chances are you are not, unless you are a Google employee) the web app features fluid design and is very capable on mobile phone (under chrome) - works really great and stays responsive and fast even after using it for a while.

The library itself has an interesting proposition: separate the event registration from the event handling and in this way allow for some interesting situations:

• render server side and send content to be rendered as HTML
• send script that basically does nothing else but to queue events 
• additionally send 'handler' script that contains all the app logic 

As expected this results in HTML that is fast to load and works without waiting for the actual application logic to arrive over the wire. All handlers are registered on the body element and once the application logic is loaded the events are being replayed and dispatched to the designated handlers. 

The handlers themselves are described in the HTML directly via custom attribute (jsaction, thus the name of the library). The system is very similar to the event delegation pattern, but the actual handler code is determined from the html attribute instead of being declared in the code. This means that the handlers do not care much about where the event comes from in the DOM tree, which is kind of powerful.

The library supports custom events as well, unfortunately those cannot be declared in the HTML with the actual custom type of the event, instead the '_custom' type is always used and the actual type is hidden deep in the detail property of he event. In fact there is a global define flag that allows you to use the custom action name in the jsaction property: you can test it like this

var CLOSURE_UNCOMPILED_DEFINES = {
    'jsaction.EventContract.CUSTOM_EVENT_SUPPORT': true
}

Additionally the event's artificial propagation is stopped once a matching handler is found.

This poses and interesting limitation: you cannot use the same combination of event name and handler in a nested tree as the first match will stop the flow. This however can also be controller by a global flag, take a look at eventcontract.js

The library is small and does not contain any 'gotchas' as far as I can tell. Big part of the code is wrappers around IE and other specific cases (mouseenter/mouselave, mac specifics etc). Another big chunk is static description of the library specific syntax. 

In what case would it be useful? 

I could easily imagine pages where certain actions must be available on user input (a la jQuery 'sprinkling' magic) and you would like the application logic to be kept on only one place. In this scenario you would need code that 'finds' elements on the page and add handlers to them (usually in the form of $('whatever').bind(...)).

jsaction allows you to skip the last part and instead of imperatively bind the actual logic to specific elements that JS needs to find in the DOM, one can simply add a property to the needed elements that will automatically bind the correct elements to the correct actions and corresponding handler.

It is important to notice that the library requires closure library and closure compiler (the latter one is optional, but almost inescapable for production), but this is only an implementation detail. The idea of the library could be useful outside the scope of closure tools and reminisce of the inline handler definitions we used back in the 90s, only in this case we have the namespaces to separate the different controls and the custom events. 

In the context of larger apps I believe the concept is becoming too complex to handle as the JS developer and the template developer need to coordinate on what is exposed and where (as the controls can be separated into smaller containers and not necessarily being document level, this is the events are being listened for always on the body, but the resolution of handlers can be scoped to container element, allowing for 'widgets' like boundaries).

For smaller projects I think it could be very useful especially to decouple the application logic from the specific endpoints in the DOM from where it should be triggered. 

Conclusion

Is this library for me?

Probably not, unless you already have experience with closure tools and you do not want to go deeper in the UI frameworks forest and instead you need simple and clean solution to attach application logic to specific points in the view. Note that all default events are supported (so mouse, keyboard, touch) and you can make it as complicated as needed (G+ is using it, and it's not simple), but unless you really want to render mostly server side and not deal with finding elements or constructing DOM on the client or you have very fluid design and you cannot keep up with HTML changes in case you have a large project it might be beneficial to consider other options before electing to go with jsaction. 

RPC package generator for closure library / compiler

Update: published package and demo app.

Recently I have been using the rpc package for Dart, which in turn provides a very useful capability: it supports discovery document generation and stub file generation for consuming the API.

However my use case is a little bit different and Dart is not yet there when it comes to easy JS integration (i.e. consuming Dart code from external JS file).

My fronted is written entirely in JavaScript with closure library and closure compiler compatible style. Taking a note from the idea of automatically generated code I wanted to generate API specific rpc consuming package based on any discovery document, generated code to be 100% compatible with the compiler and the existing code in the library.

The effort took 3 days, but I am happy to say that it now works for what I have as a small test API. It is very possible that I missed something or there is an edge case I did not see, so apply cautiousness if you decide to use it.

What does it support?

On top of the standard expected things like DTO classes and rpc method implementations the following extras are included:

• integration with the xhr package (goog.labs.net.xhr) for clean promise based interface
• integration with the assertion library and checks on incoming data when goog.DEBUG is true
• dto instances that optionally extend a base class to support event emission when changed
• implements 'toJSON' in order to support easier serialization
• full type information preserved
• closure style guide rules are honored in the resulting code

The main idea was that I wanted the code to be as clean and as useful as if written by hand.

The produced file contains two packages namespaced after the API - one for the DTO classes and one for the rpc call. Resources are nested inside the rpc package.

The whole thing was designed as part of my pstj library. The code is here.

To run it with your project install all dependencies as described in the readme, then use this command:

node path/to/pstjlib/nodejs/discovery --uri http://some/discovery/endpoint --output-path path/to/store/rpc.js

As usual the code is closure compatible and can be run in the browser as well (see here).

I hope it could be useful to someone else as well.

List data optimizations experiment.

First and foremost it seems like a very important thing to tell that this test is entirely synthetic: it does not represent any significant information that you should consider when writing your applications. 

This said, if you are interested in the use case I will share it at the end of the post.

Last week I had a discussion with a colleague about memory, garbage collection and CPU utilization for list-like data structures - basically we wanted to check a theoretical postulate deducted from the knowledge about how JavaScript VM works and some assumptions about the speed it operates on different objects types.

The riddle was as follows: given a list of objects representing points on a drawing board, consider possible implementation as to achieve speed and low memory footprint.

Two competing ideas were considered initially: Plain JavaScript arrays and linked list implementation as JavaScript objects with 'next' property.

Additionally we wanted to see what is the overhead of having garbage collection involved, for that reason we have implemented four versions of the test code:

1. Using array, recreating the array at each pass and recreate the objects in the array each time.
2. Using linked list, recreating the items in the list each time and linking them, de-reference the head of the list when cleaning.
3. Using array but taking the items from a pool and returning them before de-referencing  the array on cleanup.
4. Using linked list and taking items from a pool and returning them before de-referencing the first item on the list.

To make it even more interesting we decided to implement the same thing in JavaScript and a language compiled to JavaScript, in our case Dart.

Then we had to come up with a value that is way out of the actual use case, but seemed like could be large enough to have a measurable performance implications. In our case we tried with 100BLN - however this simply crashed Chrome. After some experimentation we settles on 1MLN.

To simulate real world case we separated the creation and destruction of the data by binding it to buttons in the HTML,this was because we wanted to prevent any hidden optimization that could be performed if the scenario was run without pauses between or equal pauses. I am not aware if such optimization even exist, but I just wanted to be sure. Using setTimeout was not an option as I wanted to keep the code as clean as possible. Before running each test we were making a full refresh and force clean of memory, then we measured 6-10 creations and destruction and then we repeated the test and took the average time and memory of the execution.

The computer the test were run on is Intel(R) Core(TM) i5-3330 CPU @ 3.00GHz, 8GB mem, Fedora Linux (with all latest updates), Chrome 44.0.2403.130 in incognito window.

The results

## JavaScript

1) 210ms total time (75MB fluctuation)
2) 140ms total time (55MB fluctuation)
3) 70ms total time (23MB on 1 fold, 45MB on 2 folds)
4) 17ms total time (2K on 1 fold)

## Dart

1) 290ms total time (74MB fluctuation)
2) 130ms total time (56MB fluctuation)
3) 100ms total time (28MB on 1 fold, 55MB on 2 fold)
4) 29ms total time (1.5K fluctuation)

The first number of each measurement is the total time it took to execute the test function (i.e. without the handler of the click event of the button), the second one is the amount of memory the heap had to grow and subsequently clean for each run. Where 2 folds are used - the memory was cleaned every two runs, the first number is the amount it grew for single run. The last test does not trigger garbage collection for the small number of tests so it only grew.

As a side note: the time to clean things up in the case of a pool is almost the same as the time it takes to get items out of the pool, but it is not included in the total time as it happens asynchronously. 

Because we had feedback on the idea even before deciding to actually implement it I will share some of the feedback:

• arrays are very fast and you can use them everywhere, no need to optimize further
• garbage collection is very fast for new generation objects so you do not need pools
• arrays do not trigger garbage collection is you clean them with 'array.length = 0'
• iteration over arrays is as fast as accessing properties on an object so you do not need linked list

Because we were never involved in the process of optimizing for garbage collected languages, let alone V8 it was safe to assume that we might be wrong and any of the above statement are true.

The first test was no surprise: 1 million objects created and de-referenced on each run was expected to be memory costly.

What took us by surprise was that a list with 1 million items on it actually took  ~20MB of memory. Second test proved that having an array to contain all the items with such a big number of items was a significant overhead. At this stage we have also discovered that the 'array.length = 0' trick was no better than simply create a new array: arr = [].

There was simply no difference when comparing things in the context of 1 mln items.

The third test was interesting because it allowed us to limit the memory fluctuation using items from a pool and basically allowed us to measure much better how much memory the array actually consumes. The amount of memory used by the pool remains constant as it does not change the whole time. 

As you might notice the time of creating an array and crating objects is identical to the time of using only the objects (linked list) and only the array (when using pool). This was logical and expected.

The final test recreates destroys the linked list entirely from the pool. We made sure to clean the 'next' property correctly when returning items to the pool. At this point we almost made it to the point of making it into time for a RAF, but not entirely. The code will take longer on a lower specs computer of course. At this point I was really surprised, for some reason most people I talked about this with (me including) expect that adding an item to an array should not be so costly. 

I am almost sure that this is not the case for smaller arrays.

Potential use case

The reason I wanted to use the lowest memory solution was because of the context the data will be used in: drawing and animating on large canvas. I wanted to be sure that adding to the list and iterating over it is as efficient as possible as to avoid any pauses in the animation and drawing.

Dart 

The reason I wanted to implement the same test in Dart is that it is marketed as a solution for large scale applications that perform just as well as JavaScript and is scale-able and more suitable for large apps and teams. 

As one can see from the results there is a different between the two implementation, while I tried to follow the exact same semantics as close as possible. One difference that can be noticed in the dev tools is that the call stack is 3 levels deeper, however the measurement state that all those nested invocation have the same time share. I am not sure if this might be a good reason for the slower execution.

A side note for the Dart to JS compilation: it was done from the command line with the following transformation flags:

- $dart2js:

    checked: false

    minify: true

    commandLineOptions: ['--trust-type-annotations', '--trust-primitives']

To my knowledge this should produce the smallest, fasted code possible. 

Surely Dart VM could have beaten these results, but it is not in discussion anymore, JavaScript is the way to go.  What worries me a little bit is if dart code when transpiled to JS will ever run as fast 'native' JavaScript. Of course this test is totally superficial and should be taken with a ton of salt, but still, it is one of the simplest things to do in computing (working with lists). Is it possible that small, insignificant slow-downs here and there in Dart could make a whole large application slower than a similar one written in JS? This is for the Dart developers to answer.

Conclusion

Test are fun. We had a hypothesis and we wanted to see what will happen. We did. Should we always prefer linked list over arrays (where possible, as indexing is much slower as well as random access)? Of course not, arrays are great! 

But from time to time you might be in doubt how things work and if you correctly understand the execution of your code and the implication it has. In that case just write a test. Even if it is flowed, even if it is unrealistic - write a test and try to understand more about your target platform through it! 

Co-authored with LexMihaylov

Request Animation Frame for high performance applications

Disclaimer: This is a recent document I wrote for the technical blog run by a SaaS company operating in the USA. I got the permission to post here as well and this is what I am doing. 
Disclaimer 2: The code is based on the implementation of the same approach as found in the open source closure library.



As per recent publication on optimizing the drawing operations on a canvas element one of the recommendations is to use a single RAF instance and put your callbacks that should be working right before the next drawing to be done by the browser.

In a less demanding application a simplistic solution based on a queue should be sufficient to bundle the callbacks to run when the browser is ready to draw, this however does not solves the main bottleneck of the RAF approach in the first place: the callbacks might be causing a lot of layout requests and trashing without knowing about each other's internals and thus make the frame (the pre-drawing execution) much slower than it needs to be.

Another possible problem with the default approach (i.e. calling

function myCallback {

// potentially close over the variables in the current scope

requestAnimationFrame(myCallback);

}

inside the body of the callback) is the creation of closures on each execution. When multiple such occurrences are live in the application this might end up creating too much memory allocations every N-th frame and thus promoting the garbage collector run. This is a potential problem because several generations of callbacks have already been passed and the result is that generative garbage collection might not be effective enough and your application might end up spending > 40ms for middle sized apps in GC phase while inside a RAF callback. As expected this leads to a delay in the call for the next frame and user perceives this as frame being dropped.

To mitigate those pitfalls we can devise an approach that has the following characteristics:

• make it easy to schedule work for the next frame
• make it easy to only do work once per animation frame, even if more than one event fires that triggers the same work
• make it easy to separate and do work in two phases to avoid repeated style recalculations caused by interleaved reads and writes
• avoid closures creation per schedule operation

To achieve this we need to be able to:

• create the callback only once and call it without using closures
• create the callback in such a way as to allow ordered execution in two contexts: read from DOM and write to DOM for each callback

Because the callback is now separated in two phases we also need an object to represent 'read' state and to be passed to the 'write' state. For example we want to read the offsetHeight of an element and we want to perform some calculations with it. After that we might need to update the style / positioning of an element based on the performed calculations.

As already known the fastest way to perform a task is to not perform it at all. Same principle applies to animating with RAF: if you can avoid a job - avoid it. An extension to this principle is to use 'pre-calculation' - that is to use the time between the triggering of a new animated interaction and actually start the animation to pre calculate anything you might need as values while the animation is running. An example for this is pre calculating dragging thresholds that might trigger an action: instead of calculating the potential next threshold while performing the dragging you can pre-calculate all thresholds in the visible area and use them to compare values while animating the object the user is dragging.  This will also avoid more memory allocations while animation is being run. For example if you create an array of threshold values it is better than to create a new value after each threshold. Basically think of this code path as critical and make the code as static as possible: pre-allocate all memory you might need (i.e. new array with the exact length you expect to use in any calculation involved), pre-generate the actual animation code.

Now lets take a look at one possible implementation of such approach: https://gist.github.com/pstjvn/f0197e09381eb346160b

What we did is define a single function that will be available in the global scope and can be used to create callbacks for event handling that can be used as regular handlers for events and still work in sync with the browser's drawing operations.

Lets see an example:

var el = document.body;

var task = window.createTask({

 measure: function(ts, state) {

   // Record if the document is scrolled and how much.

   state.scrollTop = this.scrollTop;

 },

 mutate: function(ts, state) {

   if (state.scrollTop == 0) {

     // remove header shadow

     el.classList.remove('scrolled');

   } else {

     el.classList.add('scrolled');

     // add header shadow to indicate that there is scrolled content

   }

 }

}, el);

// Will ignore parameters passes.

el.addEventListener('scroll', task);

While contrived, this example demonstrates the power of this approach: a single function is created once for each RAF tasks and is reused as a regular event handler. Internally the work is synchronized with the browser drawing scheduler and layout trashing is prevented assuming you avoid mixing the measure and mutate operations and correctly separate them in the corresponding functions. Existing implementation do check your calls for correct use of only measuring in measure phase and only mutations in mutation phase, but ultimately it is developer's responsibility to use the tool as per its design.

What can be improved in this example? One might add new property to the state that keeps the last state and only assign classes when there is actually change. In this case this is neglectable as we know that modern browsers do avoid re-layouting when 'classList' is used and no change is detected, but might be a potential gain in other use cases.

An optional improvement in the implementation is to allow the creation of the task to also accept an instance that has a certain shape and thus avoid garbage while restructuring the state in the animations. For example:

function MyState() {

 this.scrollTop = 0;

 this.wasZeroPreviousTime = false;

}

Now one can create state instance when creating the task and have completely static task representation with state.

Conclusion

When developing large and highly interactive web application with JavaScript one might often be tempted to take the short road and write code in an intuitive way in order to accomplish programming tasks faster. JavaScript is notorious for allowing the developers enough flexibility to do just that. However flexibility often comes at a cost and while the code is valid and runs fast on your desktop computer, one need to consider the implications in mobile devices.

Finally, if you already have an application and you see performance penalties instead of blindly rewriting your code always measure and deduct where the potential for improvement is and only then start refactoring.

The approach presented in this article is a tool and not a complete solution for all your intensive animations, but is a good one and should be considered when applicable.

The confessions of a chromebook user

Here is the deal - I am sick with the Chromebook!

I know I will get flamed even after that first line, not because I have no right to be mad at those machines and not because they are perfect and I am wrong; from that first line it will be because of the new fan-boy bandwagon that has been rolling recently - the Chromebook / ChromeOS core fans.

It is understandable - after so many years in the grip of Microsoft and Windows, after so many years of Linux being the idiot child in the bunch, after so many OS disappearances (even today I have read about someone testing Solaris... what?). And then there is OSX as well, the brave saviour of us all that never was - on its latest incarnations OSX is so buggy that I often hear the once 'windows' branded joke - "it needs rocket fuel to run at normal speed" being repeated over and over again, now that 8GB of RAM is the minimum required to have installed if you want to browse the web in more than one tab or actually do some work on your computer. 

And there it is - the sunshine, the little gem that Google decided to gift to the world for unknown or at least unclear reasons: ChromeOS - a stripped down version of Linux that runs it's own graphics stack and has Chrome on top of it.

I can whine and whine for days about the issues with Linux and even more - months - for the stupidity collection labelled as OSX, but this is a post about ChromeOS.

I knew I was not going to get out of this without whining at the end, but there it was - cheap (okay okay - affordable) and promising to never bother me with updates, viruses, hardware incompatibilities etc. laptop...

What I did not expect was that even their own (Google) services will be impossibly slow to use on those machines in less than 1 year! And don't start with 'powerwash' or 'try in an incognito mode' - this is bull shit! I want to have adblock and still be able to use the damn site and I would NEVER use youtube if I have to watch an ad before each fucking video there!

Google+ is now so slow I can actually see the rerendering when new data is loaded. Spreadsheets - I can actually take a small nap when the initial load is going. Hangouts - I actually need to kill it from time to time because I consider half a gigabyte of RAM used by a chat service to be obscene!


Was this whole thing a plan to 'revive' the dying PC market? Or are we too stupid to not remember the rise and fall of the 'netbook'?

In any way ChromeOS might be gaining 10-20 points in some benchmarks now and then but those devs at google are making sure that each week the apps become more and more demanding even if they do not present new features (like for example using paper elements in drive - WTF!) - at the end of the full year of ownership you end up with an almost completely unusable device - its too slow to handle new apps, its unsellable (unless the buyer is a fanboy who does not care if the device can actually be used for something), its untweakable (at least with old windows laptops you can sell to linux nerds and they can use it but who would buy a device with 16GB or storage, its not 1999 any more - the last time I was able to sell a PC with only 4 GBs of storage).

So for 1/3 of the price you actually get 1/3 of the usable lifetime and 1/3 of the functionality of a regular laptop.

I guess one gets what one pais for.

So I have only me to blame for my stupidity. Once I had a thinkpad - latest business model, ultra portable (its funny how almost all laptops today are more portable than the then ultra portable) - I paid premium. I have made a mistake.

Now I have a chromebook - I have paid really small amount and again I made a mistake.

I guess Buddha was right - the true path is in the middle.

And if you are wondering - yes, I ave tried crouton - on paper it sounds great, have you tried it running for more than a day - all the storage is eaten by the swap created for it. ALL OF IT! It is a complete crap! Even if I leave o the background doing nothing it still eats up all the (oh so large) free space on the ssd.

Also I am sick of not being able to play AC3 sounds. I cannot chose what people send me.

If after all this you still consider buying a Chromebook as a second laptop ask yourself this: why do you need a second laptop? You get bored with the first one and you need something else to sit on your lap?

At least this is what I feel right now. Might be the chromebook, might be the pain from the oral surgery I had today. But I will definitely not buy another chromebook in the foreseeable future.

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!