September 07, 2015

ES6, Babel and all between

Keeping pace with the latest JS progress? it's mad, I know.
I would like however to talk about the fundamental staff which is changing under our feet, more precisely - ES6.

ES6 or ECMAScript 2015 (catchy, indeed...) was recently finalized and all the web is swarming about it, though the browsers do not fully support it, which is like showing a candy to a child but behind a glass window.
Thing is, that along side with it came the era of Transpilers with TypeScript and CoffeeScript standing out from the rest and for a long time I was trying to decide which path is more reasonable to follow.

I know that the comparison is not exactly symmetric, but you have to admit that ES6 can sometimes be seen as a mere transpiler especially when using Babel, though it is not... and TypeScript is gaining more and more popularity now that Angular decided to embrace it on their 2nd version, added to that VSCode which support TypeScript so nicely and you have a nice debate inside your head.

Having said all the above, I would like to share my reasons of why I think on going with ES6.

ES6 is not a Transpiler Syntax

Setting Babel aside for a minute, ES6 is the new standard of writing JS soon to be embraced with it's full capabilities by every browser which respects itself. This will not be a ES5 under the hood, but rather a JS engine which knows to read and execute the new syntax, with optimizations which come along. This is an important thing to understand, for most transpilers convert their syntax to plain ES5.
Now TypeScript can transpile their content into ES6, with features that keep on adding to the supported stack, but you need to realize that the process today will probably look like this -

TypeScript >> ES6 >> ES5

Since we said that browsers do not support the full spec and so we have to transpile ES6 to ES5, which does not make much sense to me.

TypeScript is a proprietary Transpiler

Yes, you know it.
Microsoft is the proud parent of TypeScript. Not that there is anything wrong with it, but it kinda makes you think of it's future, whereas ES6 is the De-facto ECMA standard which does not belong to anyone.
Don't know about you, but I remember some time ago that one Steve Jobs (and many top industry personas followed) said that having a proprietary technology is bad and this is one of the reasons Flash should be banned from the web. So why treat TypeScript any different?
This can mean that Microsoft might cease to support it, or go in a direction which fits it's own interests but not the common web development agenda.
You can look at GWT as Google's sort-of proprietary transpiler. Where the hell is it now?

Babel is cool

Damn it's cool.
If you don't know what Babel is please go and check it out. There is nothing too complex about it, just a simple tool which takes your ES6 and spits out ES5 on the other end. There are other tools which do that, but Babel seem to be the one growing on the community these days.
BTW - It's also very interesting to see how it implements the new ES6 capabilities into an old ES5 implementation.
One more thing - you can also run node on ES6 mode, with babel-node, which is cool cause you can start writing the backend in ES6 as well.
But please note - this is ES5 in the end, so what you're getting from it is just the chance to experience with ES6 and perhaps you will lose some performance over what Babel does with the code in order to convert it to ES5.

So basically, what I'm saying is this:
Soon all new JS code will be ES6 and browsers will support it to the fullest.
ES6 does not belong to any cooperation and you can start using it now, to the fullest, with tools like Babel, and later on, you will simply drop Babel from the stack and stay with the JS engine of your chosen platform.
You simply prepare for the future, with basically no risks... why not go there?

Do you feel I'm missing something here?
Do you have a reason not to start coding in ES6?
Please share...


March 03, 2015

Check it out - You Can't Be Great without Technical Excellence


I wondered and bumped into this great presentation which again states what many of us already know but still wonder how come this is not common knowledge and practice.
This presentation is given by James Grenning, which I had no idea who he was prior to watching it, but it makes no difference...

The presentation can be found here.

James, after bubbling a little bit about agile, makes some strong points which even the thickest mind can grasp and relate to. To be honest, one's head should be really stuck in his rear bottom in order not to see the light James is talking about.

The mathematics of thinking before doing, TDD and code-quality is so evident it seems that this talk is redundant, but sadly it's not.

If you're impatient, allow me to point you to certain parts of the presentation which sums it nicely:
  • 17:35m -  WTF is a "hardening" period (which some of you may know as "stabilization" period)?
  • 23:15m - Not doing TDD is like...
  • 30:30m - What happens when practicing Development followed by Testing
  • 55:55m - Yes, you are special but it does not matter.
  • 1:01:10 - Motivating and De-motivation

February 10, 2015

Stop and Resume Binding in AngularJS


There comes a time when you need to tweak the native behavior of a framework.
For me it was pretty straight forward desire to stop and resume binding for DOM elements.

The reason behind it was that sometimes I have several elements on the DOM which listen to the same data, but not all of them are viewable. Only one of them is viewable and this is the one I would like the binding to keep updating, while the rest shut the hell up and do nothing over the data changes.

AngularJs is not too kind when it comes to tempering with it's biding mechanism and I guess they have they reasons. The binding mechanism is something that can dramatically affect the performance of an application.

If you go little bit deeper (really, no too deep) you find that binding is all about the digest cycle which in turn invoke watchers, which are functions set to watch for changes and invoke callback accordingly. It is these $$watchers which you would like to remove and retrieve in order to connect and disconnect to the digest cycle.

I've made a simple POC where I created DOM with 2 identical directive bound to the same data on their parent scope. I also added buttons to toggle their binding - pressing it once cuts off the binding for a specific directive while the other keeps on updating. Another click resumes the binding.

Simple - you can find the code here on Plunker

Take care.

January 27, 2015

Javascript Event Payload Preformance Effect

I recently had a debate with one of my colleagues about why he shouldn't put redundant details on a Javascript event payload.

I strongly urged him to avoid putting information that no one needs just because it's there, and he claimed that it has no influence on the way the application work and preforms - which immediately lite up my "this is a task for JSPref" bulb.
You see, aside from being hard to maintain and in many times read and understand, having a lot of information over the event is simply slower than having less.

So just for the sake of your future debates over this, here is a JSPref I ran, where you can see that even clearer on FF.
Avoid redundant data transfer when possible :) 

Events Payload Performance Effect JSPref

If you think this JSPref is not accurate feel free to fork it.


January 20, 2015

Component Directive Options over Multiple Attributes

Hi guys,

When building a directive component in AngularJS you'd probably ask yourself - how will I expose the component's API to the "outer world". Putting "events" and "data" aside for this one, I want to focus on the components behavior configuration.

I would like to share a direction which I tend to go with, and that's using a single "options" or "config" object which pretty much controls all the behavior (not the data, but rather what to do with it) aspects of component.

Let's take for example a component directive which display a chart, a bubble chart for instance. I would like to tell this component what are the colors palette it should use, where to put the legend, how to distribute the ticks on the axis etc.

Now, the naive way of approaching this is to set attributes for this directive and say "colors" attribute will hold the colors array. the "ticksinterval" will hold the ticks configuration and so forth. Before you know if, your component looks like a very very long line on the DOM, with numerous attributes each, BTW, creates it's own watcher and effects the overall performance greatly (if you bind it to the scope, which you probably do).

That should be enough of a reason to consolidate all these configurations into a single object, but there is a catch here -
When I do this I avoid registering any reference to executable code on the configuration object. The rule of thumb I follow is: "treat this configuration object as a JSON file that later can be loaded from a distant server", doesn't know the code, no callbacks, nothing.
So he question might rise - how will I execute API's over this component? I would like to select a single bubble in this chart, how do I do that?

So again, think of this "selectedBubble" as an attribute you would normally put on the directives  - something like "selectedIds" which receives an array of ID's and knows to track them down and mark them as selected on the chart.
That makes sense right? but wait - aren't we trying to avoid these multiple attributes? so instead, you've guessed it, put in on the configuration.
The component will know to read it from the configuration object and act upon it.

As with anything else, each "direction" or "rule" has it's exceptions and you should consider what suites the use-case best :)


July 13, 2014

Constatus - Find those Strings and Const'em!


Not so long ago I've opened a random file on the code base I'm working with and saw the horror of many Strings values which have "why am I not a constant?!" written all over them.
I figured that a re-factor is in order but I wondered how will I know that if covered all the instances of a particular String value?

Good thing there is NodeJS around and some nice modules like Esprima, which can help with that, and so I found myself coding this little harmless tool which does the following:
Goes over the code and finds Strings which, according to configuration, should be made constants.

Deadly simple and dare I say dumb as it gets, but guys - it does the work, so why not put it on Github? ;)
So feel free to visit the project on Github with the mind-blowing name: Constatus
It is not complete, there are many more features that can be added, but it's out there for you to abuse ;)

Take care

May 29, 2014

New Quake-Stats improvments

Yeah, I know - it has been a while since I wrote but trust me, I had important things to attend to, and still do BTW ;) don't worry, it has nothing to do with work, code or debugging shit.
Anyhow - I just wanted to let you know that the "quake-stats" open source application has gained some nice new features!
For those of you who don't know what I'm talking about, you can read about it here and of course visit the Git Hub repo.

So, we got MongoDB into the stack and so we can save games across time. Hold your horses, this doesn't mean that we have over-time game statistics but it means that we're on the way going there.
If you want to upload games files into the application there is an "easter egg" for you. Just go the to "/admin" route and before you will reveal itself a nice upload screen (well, not so nice but it does the work). Once uploaded, the game will be stored on your MongoDB and later can be accessed easily via the "Game" dropdown menu. This great feature is a contribution of Haim Litvak. Cheers mate!

I also added another feature to enable Quake scores over maps per a single player. This feature will display the score Quake calculates for each map and display it on the "player" screen under the "Kill, Deaths & Q-Score" chart.

That's it so far. If you think something is missing, fork it and do it yourself :)