Gone with the Front

We’ve all been hearing for quite some time already about the EcmaScript standard which is a subset of JavaScript. It is implemented differently in some browsers – JavaScript in Mozilla Firefox, V8 in Google Chrome, and JScript in the Microsoft browsers.

The newest Ecma standard is ES6 (aka ES2015). Ecma stands for European Computer Manufacturers Association, making the notion just a little counterintuitive these days. Released in 2015, ES6 had a lot of innovative features and because of that, the upcoming ES2016 is a little less shiny.

Every browser has its own way of covering JavaScript, thus an ambiguity in a number of common functions. So it got me interested in where EcmaScript comes from, does it have a ‘father’, someone who is single-handedly crafting it. So I did my research and found out that EcmaScript is run by an organization called Technical Committee 39 (aka TC39), or a

“committee of very smart people”.

Those people are representing the largest and most influential companies in the internet industry today. The best developers of Google, Mozilla, Intel and so on are among them.

So this Supreme Chamber gets together once in two months to talk about the issues of JavaScript and figure out where to move further. There are records of their meetings online if you are interested in the process.

JavaScript Preprocessors

Due to the fact that not all the browsers support the newest versions of EcmaScript, it was necessary to create JavaScript preprocessors. Some say that those are separate languages, but I personally think of them as just preprocessors because each of them is compiled in ES5 (ES2011) that is comprehensible even by the most outdated browsers. The most curious of them to my mind is TypeScript, it grows in popularity as opposed to CoffeeScript that is sort of fading.

TypeScript has all the benefits of EcmaScript plus typization, which aided testing significantly by making JavaScript predictable.

CoffeeScript also took a lot from EcmaScript but has some syntactic sugar to it. It has similarity with Ruby and many times a front-end in CoffeeScript has a back-end in Ruby.

Another preprocessor, Babel has no syntactic sugar or any Easter eggs. It is just a EcmaScript compiled into JavaScript that any browser can fathom.

JavaScript Frameworks

Front-end incorporates a lot of frameworks, might be too much, because every front-end developer either tried or have written their own framework. The top 4 are:

• Angular
• React
• Backbone
• Ember

They have their pros and cons and it can be arguable that those are even frameworks, not libraries. Some say that it is better to come up with your own framework composed of different type of libraries. I wouldn’t be so sure, because it’s just nice to have some integrity at times.

Task Managers

Perhaps the most common ones are:

• Gulp
• Grunt

Those are “gatherers”. Gulp is like “gulp for air” after Grunt. Honestly, I don’t know how bad Grunt is, I’ve only used Gulp. So here are the most common tasks for task manager:
gulp-minify-css — compresses css
gulp-uglify — compresses js
gulp-concat — unifies files into one
gulp-imagemin — compresses images
gulp-sprite — creates image sprites
gulp-gzip — creates gzip archives
gulp-svgmin — minifies svg files
gulp-sass — sass preprocessor
That’s a lot of different plug-ins. The tasks can be performed simultaneously which makes the front faster and more convenient.

CSS

I don’t like CSS.

It is lame with no variables, no functions, but has a lot of copy/paste. So again we need preprocessors to make CSS somewhat language-looking. The CSS preprocessors are:

• SASS (SCSS)
• LESS

They are pretty much the same, both tweak CSS, the only difference is in the way they start in some modes.

CSS frameworks

I listed the following CSS frameworks:

• Bootstrap
• ZURB Foundation

In front-end, some libraries can work as frameworks when satisfying the particular need.  If you are developing web apps, take a look at plenty of ready-to-use Bootstrap solutions from Twitter Inc., and extremely detailed BEM methodology of style forming developed by Yandex.

Windup

The usage of latest technologies in front-building helps get rid of the functions.js file which consists of huge amount of untestable functions that look like Spaghetti code.

And those are present on ⅓ of all websites. Also, you can omit one large or several conflicting CSS files and make something as neat as this:

There is a module, components with their own controllers, templates and styles. This module can be compressed and distributed via Amazon services nice and fast. And I am not even mentioning the sheer pleasure of developing in such a way.