October 06, 2015

Basic Webpack with ES6, JSX and React

Hi there,

I promised (sort of) on my twitter account that I will look into the integration of Webpack with ES6, JSX and React, you know, just because I read a little about Webpack and it does seems like a very nice solution for bundling JS modules and static assets while slicing them into chucks which can later be loaded on demand.
Before jumping into anything, a series of POC's is probably what you should do, so here is the first one on my behalf.

So how well and easy can Webpack be integrated with the latest out there, which is basically ES6 and React (but it does not have to be React. It can be pretty much anything)?

After playing with it for little less than an hour, I have a nice example which demonstrate how one can bring up a client to life, with ES6 and basic (I mean basic) react view, all this with the benefits of live reload. If that's interesting to you, keep reading:

BTW - All the code can be found on GitHub, so you can reference it along the way.

first off, I've created and empty folder and 'npm init' it.
Now I was able to install Webpack to the project (I generally don't install on the global scope, but you can if you have no fear of backward compatibility mess) along side with webpack-dev-server.
It is this webpack-dev-server which will enable me to listen to any change made on the source files, bundle them on the spot and render the page with the latest changes, no gulp, grunt or what-have-you involved.

Now I need a configuration file for Webpack, which defines which is the entry file, and what loaders participate on this compilation (among others). If you have no idea what those are, please read more about them on the Webpack site.
As you can see from many example on the web, the configuration file is using a CommonJS-like module system which is different than what ES6 is using, so if to be pure, the configuration file should also support the ES6 module system and for that we need to do 3 things:

  • Install babel on the project using 'npm install babel --save-dev'
  • Change the configuration file to export the module the way ES6 does
  • Change the name of the configuration file to be "webpack.config.babel.js"
There you go, you're configuration is now pure ES6.

Now we would like to start coding the actual stuff, which is in my case a simple "Hello React" component and render it to the DOM. I created a file for the component which has JSX for displaying the caption.
At this stage you are probably wondering what takes that lovely ES6 code (not to mention that lovely JSX) and converts it to plain old ES5 - well, for this we have the Babel webpack loader. We install it using npm again, and define it on the webpack configuration (check out the code on GitHub).

The entry file now imports that component I've just made and uses React to render it to the DOM, and that's about it.
Launching the web server using the webpack-dev-server we can now safely browse to localhost:8080/webpack-dev-server and see for our eyes the wonderful caption.

Now... let me see if I forgot anything. No. I think that I have all covered so far.
If you have any comments or questions you can comment below.

Hope this helps you :)


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 :)