Ember.js: Documentary

Honeypot filmed a great documentary on Ember.js and the story of its development. Brings up so many good memories from 2016.

Back then, I was taking up by an ambitious task of re-writing the checkout service of the company I used work in, from plain PHP with monstrous AJAX spaghetti code, to something more stable, and consistent.

Seeing a pure MVC architecture in JS framework was a real surprise for me, as most of the codebase I faced back then, didn’t have any structure.

Frankly speaking, it was a nightmare going through all that legacy code. However, it took me less than a month to get a full working prototype on Ember to be released as production-ready substitute of the checkout system.

Every now and then I try keeping an eye on the community and where Ember.js is heading. Though, most of the hype on the web is still around React/Vue/Svetle, Ember.js was always famous for its community, that not all open-source project can boast about.

EmberJS: JCF with components

JavaScript Custom Form elements is a useful jQuery plugin for customising your form elements, in case you have to get away from the default styling of the form elements. However, there’s a tiny “but” with the plugin when you use it with EmberJS. JCF initially designed to be used on the global scope, and in some case (like mine), it’s not what you need.

If you’re using custom select-element with JCF without JCF.Scrollable, the list becomes unusable in few cases:

  1. It overflows the layout of the site
  2. Not keyboard-friendly, when you try to filter the options and not scroll till the end.
  3. When you use Ember addons like emberx-select, it doesn’t like custom data-attributes.

Eventually, using components concept of Ember, it’s easier to isolate the setups of JCF.

In my case, language options have only few options,where I prefer to wrap the native select options:

import Ember from 'ember';

export default Ember.Component.extend({
  cart: Ember.inject.service('shopping-cart'),

  didRender() {
    Ember.run.scheduleOnce('afterRender', function(){
      //#currency-options is the action <select>-element
      jcf.replace('#currency-options','Select', {
        "wrapNative": false,
        "wrapNativeOnMobile": true

And, to avoid custom wrapping of dropdowns, for instance, country list, better to initiate JCF like this:

import Ember from 'ember';

export default Ember.Component.extend({
  classNames: ['input2','country-list'],
  didRender() {
    Ember.run.scheduleOnce('afterRender', function(){

Few more samples of the code, could be found in gist.

Ember global meetup: building great products by engineering culture

Great video about building excellent engineering culture by Juan Pablo Burritica from EmberJS community.

JavaScript: shooting yourself in the foot with configs once again


Don’t be mainstream!

I’m not the only one blown away after digging up some of React/Redux boilerplate code. Great article proving some of my thoughts on the subject:

Copy-pasting configs from boilerplate projects always leads to hard-to-debug issues like this. It’s easy to miss somebody’s configuration decisions when you’re not the one making them. Don’t use boilerplate projects unless you understand each and every technology it uses!

I understand Dan’s frustration. But could we look at this from a different perspective? Don Norman’s The Design of Everyday Things teaches that there’s no such thing as “user error” — humans always make mistakes, and the failure to deal with these is on the product, not the user. How would we approach these user errors if we looked at them as design failures?

Yet another justification of “convention over configuration” and the reason of choosing EmberJS at the given time. Sorry React, not now, maybe a bit later.