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

декември 07, 2016

Web worker, RAF, nextTick - what is there to it?

Let's start with the premise: we want to know the details on how a combination of a web worker (i.e. event based communication with a separate thread in JS) can be used to process data and communicate with the main thread in regards of asynchronous job scheduling.

What is what

Request Animation Frame - from MDN

nextTick - an API for scheduling work after the event loop is emptied. We use an emulation using iframes so basically we get message broker in frames covered instead of the actual setImmediate as it only works in IE10+.

Web worker - single threaded JS execution environment that is a separate process from the main thread (i.e. it does not share anything with it and scheduling execution in it is not related to the scope of async programming from JS developer's perspective - we cannot influence when things are happening there but we have the guarantee that those things that happen follow the same rules: async, single thread)

So what are test results showing

  • responses from web worker always come in order (assuming no async programming is done there)
  • the timing of the responses varies (i.e. run the test several times and see how sometimes 1, 2 or 3 responses arrive before the RAF or nextTick execution kicks in)
  • nextTick kicks in after the first RAF

If you want to review the results make sure to: a) run the test several times and b) test in different browsers.

The code is here.

Conclusion: it is not trivial to drive animations and data processing from a worker instance if you depend on input for it.

януари 15, 2016

Reducing time to first paint

This post is about the new techniques recently discussed on events related to web app for mobile: how to make our web application behave more like a native one and reduce friction for our users and meet their greatest expectation.

In this post I will discuss how we managed to reduce the time to first paint in an app we already had developed. We will be measuring several things:

  • time to first meaningful paint
  • time to app readiness
  • time to first paint on first visit
  • time to app readiness on first visit
Why there is a difference? First visit is important for several reasons: even with service workers being readily available in Android one still needs to consider those first visits to the app which can happen at any time and any network condition, forcing the user to wait is not going to be very good for any conversion strategy.

Secondary visits, especially for devices that to not have the service worker enabled (or in case we decided to not use it for our app for some reason) can also be potentially problematic for several reasons: busted browser cache, new version of the app etc.

Lets start with some numbers!

The app is consisting of a single html file, a processed (built) css file and a javascript (also built).

index.html - 566 bytes
app.build.css - 50702 bytes
app.build.js - 188824 bytes

What were the measurements on load time with this initial state:
First visit:
  • time to first paint: 850ms
  • time to readiness: 1000ms
Secondary visit:
  • time to first paint: 15ms
  • time to readiness: 1000ms
Its not that bad, but this is a relatively small application and also we use landline network to load the app.

The one problem is that in first visit the user is staring at blank screen for almost a second, loading on slower networks would only exaggerate that and can make the user give up on our app.

How can be possibly reduce this time to first paint on first visit?

We can attempt and utilize a technique described as 'fake' first paint: provide only a skeleton on the actual app view and how it would be looking like when ready and provide it as soon as possible (possibly in the initial HTML with CSS only for it). 

This sounds okay, but the fact is we already have the application built and we did not wanted to invest too much, also the additional markup and styling would have to be maintained separately and updated every once in a while as the application evolves. 

We decided to go with another approach: separate the code that is responsible for the initial html structure into a module to be loaded first, let it execute (i.e. unblock the event loop) and only then load the rest of that app that will 'decorate' the pre-rendered html and make the application ready for the user.

How does this look like in the context of a mid-sized closure tool driven application?

Several steps were taken:
  • create a new namespace and render the main app template in it, it should be doing only that - requiring only the template and dom utilities
  • create the HTML loading module that invokes the namespace from previous step and asynchronously wait for the next event loop tick to start loading the application logic module
  • create the application logic module which should simply invoke your app (basically your main entry point from static (non modular) version
  • make sure your main app logic accepts a new option to tell it that it should decorate a preexisting html structure as opposite of rendering itself
An example:

//Step 1
app.html.rootElement = goog.dom.htmlToDocumentFragment(
      user: app.settings.RUN_AS_USER

//Step 2
html_init = function() {
  // Add thr whole view to the document.

  // Wait for the rendering to kick off.
  setTimeout(function() {
    // Configure modules.
    var mm = goog.module.ModuleManager.getInstance();
    var ml = new goog.module.ModuleLoader();

    // Tell module manager that the html module is loaded
    // start loading tha app module.
  }, 10);

// Fireoff things immediately.

// Step 3
app_init = function() {
  // Instanciate the app controller.
  (new app.Main(true));
  // Tell the module manager that the app has been loaded.


// Step 4
app.Main = goog.defineClass(pstj.control.Control, {
   * @constructor
   * @param {boolean=} opt_useDecorate
  constructor: function(opt_useDecorate) {
     * @type {boolean}
     * @private
    this.useDecorate = !!opt_useDecorate;

As you can see the change is trivial, but it allows us to do two things: reuse the actual application template (might it be not functional yet, but it looks exactly like the final result) and thus its automatically kept in sync with the application as it evolves and two: reduce the initial load size (the size of bytes needed by the app to reach first paint that resembles the app view for the user).

What are the new results (after this change):

First visit:

  • time to first paint: 400ms
  • time to app readiness: 1100ms
Secondary visit:
  • time to first paint: 15ms
  • time to app readiness: 1100ms
Not that bad for 20 lines of code: we managed to reduce the time to paint on first visit (or cache miss) by a half with a simple change of order of execution. 

Now one question arises: why not simply do it inside the main build: render the view first as a template, then free the event loop and then decorate the application logic on top of it. 

Yes, this was initially the intent, that is why we went with the option to tell the main app entry point to use rendering or decoration (step 4 in the example), but since closure compiler is so good with modules we decided to start using this technique to be ready for the growth of the application and instead of adding feature after feature to the main build simply module-base new features and load them on demand, but not before the user needs them. This will allow us to have a 10 times bigger application but still keep the initial load size (and times) the same. 

As you might have notices the separation of the built JS binary to two modules had a cost: ~100ms delay until application readiness, you should b aware of that and carefully examine the trade-offs when deciding if you should use this approach or instead go for the one described in the beginning and simply use a dummy scaffold in the HTML. In our case we wanted to stay as close to the existing code as possible.

How does this change result in code size?

index.html - 782 bytes (because we included the module info in the html, it could be instead pre-pended to the first module)
app.build.css - 50702 bytes
module_html.js - 70231 bytes
modules_app.js - 118707 bytes 

As you can see the size impact is insignificant. Interesting side effect since the change we made for the modules is that the initial module (module_html.js) does not change significantly or all if the templates do not change (for example if we add new views but use the rendering path instead of decoration one the views logic and its structure will still be in the later loaded modules thus not impacting the initial load).

As a final though: working with modules in closure is fun but is not as intuitive as one might expect it. Also there is no guided module separation and for this reason the developer has to be an expert on how closure dependencies work and how to arrange the files in such a way as to avoid direct dependency and instead add dependencies and code indirectly. In more modern solutions (like Dart for example) requiring a piece of code (or a whole library that is) lazily / on demand is as simple as adding a modifier to the import and whenever you need make sure to load it first

import 'myasynccode.dart' deferred as myasync;
// later on in my code
main() {
  // Wait for user to request that piece of functionality
  await myasync.loadLibrary();
  // call code from library

Never the less closure can be used successfully to manage async code loading and thus help us with the task of greeting our newly come users as fast as possible with the best product we can offer.

Happy coding!

септември 26, 2015

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.

Price (ownership): 1299$
External ssd disk (for backups): 199$
Text editor/IDE: 70-100$

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!

август 25, 2015

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

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


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. 

август 20, 2015

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.

август 10, 2015

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.


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.


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

юли 27, 2015

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

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
   } else {
     // 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.


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.

януари 12, 2015

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.

януари 01, 2015

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!

ноември 02, 2014

Little red ranting hood... in the JavaScript forest.

This is my rant about all the 'fixing JavaScript' "effort" that has been going on for some time now. The post is pretty long even fro me and it is really a rant I do for fun sometimes, in fact I have used or use some of those technologies, so don't get your torches and head to my house yet...


First there was CoffeeScript. Oh my God  - what a brainfart it is! So, you take the JavaScript shitty way of doing things and then you slap Python on top of it and then even better you slap 'custom passes' on top of it. So at the end you write in a language that no Virtual Machine understands, that no online editor can help you edit and with files that no JavaScript developer ever wants to 'figure out' because your syntax is way off the language you are actually targeting but in the same time it is exactly the same language with messed up syntax. There are no 'Coffee script' developers, those are just JavaScript developers with aneurysm. And you cannot run your code (oh yeah, I know about 'compile on save' - so I have to ask you, which will be faster: 'reload on save' or 'compile on save'. Wrong question, you cannot actually do that either, you have to reload on compile....). 

Now some people that like to call themselves experts in JavaScript, Closure (and surprisingly on something that does not really exists - Coffee script (OMG there are people that teach this!!!)), would even go further and add a pass that converts to 'closure compiler compatible' JavaScript. Lets review - you write in something that is fictional, then translate to something that is halfway there, then you have to compile it (if only to check types) and then you have to test in both development mode (source files that are actually not sources but translation results) and production mode (translation results compiled). Lets just say that this might get a bit slow and that it might be hard to set up this workflow on any kind of environment, let alone an online one..

But that is not all, ladies and gentlemen, it gets better - those same sick people are now "helping you" when you have JavaScript question with code snippets written in Coffee script!! Yes, like the crazy people they think you see the dragons that are only in their heads. Well that's messed up...


Going further in time - Dart was born. A completely new language that is all so much powerful and faster and better and shinier. Only if it could work in browsers... but it cannot. You are still debugging JavaScript at the end. There is (as with Coffee whatever) virtually no IDE support for it, you are stuck with DartEditor (which you might find nice, unless you want code collaboration, online editing of something that does not require  rocket fuel powered computer to run at acceptable speed). Oh, you say there is support for Sublime? Really? Have you tried it? The 'support' is basically born-again approach from the end of the 70's. Yes, you read it right - 45 years aaaggggooooo! You save your file then a script runs and then it collects the output of that script and then it presents you the result (in a surprisingly unhelpful way). There is no real intelligence in the completion or there 'should be' but it is not working. Same goes for another brilliant project - WebStorm.

Assuming you are fine with IDEs written in Java (which most of us are not - after all I am developing on the web for the web - Java exited the web like a decade ago and is slowly turning into corpse on the server as well) the Dart 'support' in WebStorm is somewhere between unsatisfying and completely unreliable. Oh, and the last build is broken as well (mind you, the product costs MONEY!) so you will have to either downgrade or wait for a fix... because we forgot to include complete intellisense for dart because.... well because on large projects we just like to crash the whole IDE, "but on the other hand we improved on the start-up speed so you are on the track", don't worry, keep paying...

Lets say you like the 70s, the music was great and the IDE's were non existent, the real men wrote code with text editors. Like Vim. Like scrolling is not a real thing - right, it is much faster to type gg/goog^M^[jjjVapk:sort:w - right! Your hands do not have to move like at all. It would have been sooo great is we as humans have evolved without the lower parts of our bodies (well maybe the penis should stay) and maybe.. hum.. little hands (like the ones found on T. rex) with lots and lots of fingers. Then maybe Vim would have been the ultimate and final - best of all, end of universe - editor.  You can sit (well, you would always sit without the lowed part of your body, but would it be called sitting?) all day long and use only your fingers, we would not need shoulders because we do not need to move our hands, we would just type and be really 'fast and productive'. I see paradise... but then Dart would have come.... Well, the Dart story in Vim is sad, just like with Sublime text. And that paradise would have been ruined. Just like Dart feel like on Vim....

But otherwise Dart is great. Its like 'twice as fast' than JavaScript (well.. on benchmarks, in real world it is twice as slow but don't be discouraged, we will get there, give it 15 years or so of evolution and I can almost guarantee you it will be as fast on the server as.... Java). On the browser... YES, it is twice as fast there as well... oh well not really because v8 catches up and now it is only like 20% faster.... on benchmarks. But we cannot really use it in the browser because no browser really supports it and we have to compile to JavaScript and in theory it should run as fast or faster than hand written JavaScript but... it does not. At least not when someone who actually knows what he/she is doing write the JavaScript.

But its fine, as the development story goes it is really fun to write in Dart. You 'save and reload' just like in JavaScript. Well not really, because you have to use Chromium, which supposed to be Chrome but it is not really and has bugs that are not found on Chrome and you have to figure out if the problem is your code (for CSS for example) or the browser quirks. And then again you have to test in all browsers because you know... it is not really clear if the generated JavaScript is working everywhere, it is supposed to be but... who knows. I really liked the video where the Dart developers explain how trivial the generated class code is, how it is almost one to one transpilation from Dart to JS. Well it is not. This is just a lie and you can read the generated file all day and still you wont be sure how does the result maps to your original code. At the end of day 3 you will figure it out eventually, but does it worth it? The problem is really simple - Dart does not compile to JavaScript idioms, it compiles to a JavaScript blob that is internally emulating how Dart is working. Trying to read/fix the compiled code is almost as trying to fix the result from the C compiler. Pointless. You have to go and 'fix up' your code (well because it works in Dart/ium) to 'make the compiler' happy(er). If you are still on the Dart bandwagon at this point (and you are still read the Dart passage) you might need a dominatrix in your life. There is a lot of internalized pain you need to let out...


Microsoft (I always liked that name, it is so 80s, like Sun microsystems.. omg!) did not wanted to be left behind in this new era of computing, they wanted to appeal to the new type of developers that like the web and want to stay on it as much as possible and even develop inside of it (can you imagine that William?). So how about we take a guy, that at his peak did do some good stuff and let him create a 'superset' of JavaScript that looks like ES6 (but is not really and cannot be run as such even if the browsers support it) and slap some type system on top of it. Well the type system should really be fun, it should be something that is half useful, half making the JavaScript developers go grey and die off, so we can reignite the Windows era (if possible, please... pretty please...?). So TypeScript was born. Have you tried it? I guess you did! 

The problem is that TypeScript tries to add types to functional code (i.e. not Object oriented code) and presents it as 'safety'. There is however one simple catch: most functional code that already exists deals with the JavaScript's lack of types in a funny way, so you have functions with 10 different signatures. I especially like the ones where the middle arguments are optional, you basically cannot infer the types based on their positions as arguments. This is especially funny in jquery where the number of arguments does not really implies the types of those arguments. Have you seen the definitions for jQ? What is really funny is that MS embraced JQ as main library (kind of like a standard library in TypeScript) hoping to appeal to larger audience and as a result no one really writes OO JS in TypeScript, instead everyone writes functional style and then impale themselves on the type system and wait for slow dead. Does the type system in TS make something useful? Well yes, of course, it made MS learn NodeJS. But no, I would not rant about nodejs in this post, here I will be only targeting the 'JS augmentations'. Another problem Microsoft did not foresee with TypeScript was that JavaScript developers rarely know anything about types.

Even if they know something about OOP, OOP in JavaScript is a different story and there are (really fat fat) books about OOP in JavaScript and the fun part is that they present so many patterns for OOP and explain so many things that are not actually useful in practice for one reason or another, they are so purely academical studies of the language capabilities and how far you can go about it, that I have been asked questions directly taken from the 'check your knowledge' sections of those book on job interviews!

I really enjoy citing the author, book title and page where the question is taken from to the 'technical' interviewer and then tell them that if his company is using any of those absurd patterns I will not work there. It always gets to them and distracts the 'knowledgeable' interviewer from you and wake up some internal fears that they themselves are not good enough, which automatically makes you appear more knowledgeable. What do they say? Play the player, not the game?

Sorry for the digression. Where was I? Oh yeah, TypeScript. One thing they got right (shorter syntax for classes) they kill with the type system. Every other negative side of Coffee script apply to TS as well, you still need to transpile just to test run it. Fortunately the results are much more predictable, but the lack of real support from tools (other than Visual studio) simply repulse most developers. I know developers that use TypeScript. Can you guess what their specialty is? Hang on - its .Net! That's right, TS appeals mostly to people that already use VS... ah, the irony...


This is the last dumpling from Google. I like how Google is shooting in all directions in recent times, makes them look really desperate. I also like it when they send someone to do a technical talk and then that someone says something Google did not expected, but the talk was recorded and ends up on youtube, only to 'disappear' a week later when they realize what had happened. If you wonder why I will never Angular? Well they did a tech talk. Yes, about that 'first large internal project'. First of all it was done with Dart, which is already a red flag, then the guy said that 'we had to rewrite/do custom versions of pretty much all directives because the ones that are built in were too slow for our use case' - that really pinpointed it. It really said " the idea is great on paper, but not applicable in practice". Well, the idea is so great they decided to reiterate on it, hoping that this time something will be done right. Finally some teams at Google talked to each other and someone said:

Sooo, we have those great things (decorators/annotations) in Dart that no ones know how to use really, but they look nice and give legitimate use for the '@' sign which is pretty cool sign, right, so, you know, how about we slap it inside JavaScript as well. It should be fun.

And the other team said:

Cool, lets make some interns proud of themselves and give them something to live for, let them do a new language. But we will not call it a new language because of some jokes that are circulating around the Internet, something about the problems and number of solutions, don't look at me like that, I do not spend my time browsing comics, i DO work... sometimes, soo... okay where was I, ah yes, lets do this 'super set' thing that Microsoft did. We will take es5, then slap es6 on top of it, then slap typescript on top of it and then we will put the annotations on top of it.

Oh, oh, oh, wait wait, someone wrote an assertion library and management said if we do not use it for something they will fire the guy and he is like a great and nice guy, so we have to use it for something, right, so he does not get fired....right, can we do that, pleeease!

At this point everybody is looking suspiciously at the person that said the last line assuming a work related romance/bro-mance/gay-mance/whatever, but they decided to go with it anyways and as a result we have a new 'super set' that has everything poor old bastards at Microsoft had, but with annotations and runtime checks.  Ladies and gentlemen, I present you AtScript. And because it was a talk between the Dart angular team and the normal Angular team management would be really happy if this new thingy is 'beneficial' for both projects, so lets make it compile-able to both Dart and JavaScript. After all, we can always market it as a good thing....

So now we have to not only write JavaScript, an 'almost HTML, but not really', now we also have to compile it before we run it. Oh, oh oh and you know what, closure team has been doing this angular pass for year now, lets include them in the party, lets run the compiled JavaScript with another compiler, that would be fun!

Yey, Google is such a wonderful place to work at, you can get something and then mix it with something else and then talk to other teams and make really ridiculous things and we can always expect people to like it, especially developers because Google is such a magical word for developers, we can actually get away with anything it we figure out a way to make an internal project with it...

So now we have  AtScript. Of source there will be IDE support.... somewhere in the future... let say we will make a bash script that will monitor files for change and automatically compile them to both Dart and JavaScript, how about that? But that is down the road, for now you can happily use vim or anything else because you see, there is really no such language as AtScript, it is 'a super set' and as such no tool nor IDE nor virtual machine really understands it, so it is simply a dumb text file. But you can use it, Google uses it, so it must be great! Oh, and by the we are not really compatible with es6, nor TypeScript but we will get there as well, I promise!

Did I miss something?
Let me know in the comments:)