Tag Archives: Javascript

Upgrading to Babel 6 the awesome way

Upgrading to Babel 6.x can’t be that hard, right? Well, it can if you’re like me who wants maximum modularization. But it isn’t, really.

I love modularization. And making an effort to do so can really significantly reduce your own module size, if not where, when it counts. So yes, npm may not now dedupe by default (whether or not it does when you read this, then awesome) but if a module author decides to do so, then all’s good, right? I especially love lodash and how it’s divided into modules. That’s kinda what Babel does now.

So, how do we upgrade to Babel the awesome way?

Okay, first uninstall the babel package if you still have it: npm un -sD babel —we won’t need it anymore. If you have it installed globally, you might want to uninstall that too.

Next, install either babel-cli or babel-core depending on what you’re using. babel-cli is what you need when you need the CLI. (Good job, Sherlock) For a refresher or if you don’t know already, the CLI programs that come with it are babel, that transforms your code, and babel-node, that’s like a node.js proxy with both a runner and a REPL. Or install both if you need to. They’re modular anyway. I’m not much of a fan of require hooks, but if you swing that way, I can’t stop you.

Okay, at this point if you’re a n00b or a conformist you would now pick one of the presets to support ES2015 functionality, in which case I’m wondering why you’re reading this blog post when you could just go over to the website and follow the instructions. If you aren’t, you may continue reading.

Next, decide on the plugins you wish to include. Now here’s the trick to the awesome. If you’re not yet using node v5 or at least node v4 then you’re being out of the loop. The thing is, ECMAScript 2015 (say what??) has been released last June. So now we can use most of its features really. Support is flaky here and there but most of the usable ones have already arrived in various JavaScript environments. Now, I might be being a bad influence here but I’m only planning to support V8, but you can be better and support, I don’t know, SpiderMonkey? IE?

Anyway, if you’re like me, the point is if I see a feature is already supported by node and Chrome, I won’t have to transform it, right? So just pick plugins that you actually need. kangax’ compat tables might help. Basically, by doing this I have drastically reduced the number of plugins I needed for my code.

For module authors: If you’re not much of a polyfilling fan and would like to drop support for environments only compatible with ES5 or lower, consider not using the babel-runtime module and the babel-plugin-transform-runtime plugin anymore. Basically what it does is it ponyfills your code environment with babel-runtime which contains the JavaScript globals and functions you’ll need in an ES2015 environment, as well as regenerator, which works with generator functions. You’d then include babel-runtime to your dependencies. Not that I’m not a fan of core-js (it is seriously awesome) but native is better if it exists already.

Here’s my package.json for one of my projects using Babel:

  "devDependencies": {
    "babel-cli": "^6.1.2",
    "babel-plugin-transform-async-to-generator": "^6.0.14",
    "babel-plugin-transform-es2015-destructuring": "^6.0.18",
    "babel-plugin-transform-es2015-modules-commonjs": "^6.1.3",
    "babel-plugin-transform-es2015-parameters": "^6.0.18",
    "babel-plugin-transform-strict-mode": "^6.1.2",
    "babelify": "^6.3.0",
    "browserify": "^10.1.0",
  "babel": {
    "plugins": [

That’s just 5! Compare that to how many plugins I get when I actually used a preset.

You may ask: what’s with destructuring? Well, this project specifically has a lot of entry points and I don’t want to risk breaking anything, at least for now. If you didn’t already know, node already has support for destructuring via the --harmony_destructuring flag. If you’re still reading, you should definitely check out the node.js docs and see if you can further reduce the number of plugins you need simply by turning on a runtime flag. As for this specific project, it might be fine since it’s run on the server side, the catch is that it has front-end code. (Check out babelify!) And as of the time of writing, Chrome still does not have destructuring support (by default, anyway) hence the decision I made.

strict-mode is there because apparently I’m too lazy to add 'use strict' on top of all of the code. As you might have seen in kangax’ compat tables, V8 still doesn’t support some ES2015 features without seeing it.

Also, if anybody’s noticed: I put my babel config in my package.json file. This is just a personal preference. Personally, I don’t want so many files cluttering my project. So yeah, that’s why I don’t like Visual Studio Code.

If anyone has been reading my blog recently, this is the same project I had some trouble on.

Here’s one from a super-secret project that a reader has decided to bug me about:

  "devDependencies": {
    "babel-cli": "^6.1.1",
    "babel-core": "^6.1.2",
    "babel-plugin-transform-es2015-destructuring": "^6.0.18",
    "mocha": "^2.0.1"
  "babel": {
    "plugins": [

Simple, right? Only one plugin. Here I have both babel-cli and babel-core installed because I use babel-cli for transforming my code and babel-core to test with Mocha.

TL;DR just read the bolded phrases.

Update: If you plan to support only node v4 and up and presets are totally fine with you then there’s this preset for node v4.

Do not use minification.constantFolding when using Babel on Heroku

I had a hard time debugging why my app on Heroku doesn’t work. It’s being run with babel-node. I encountered EACCES errors without any explanation of what’s going on. So apparently my port has not been changing. Apparently minification.constantFolding folds process.env. as constants. What I’m baffled about is that babel-node does not capture the value of process.env at the time it’s called, even though it should be at that time.

Anyway, for everybody’s guidance.

Why we should stop using jQuery

I thought about giving this post the title “Why I hate jQuery” but aside from the actual piece of jQuery I actually hate, jQuery is a magnificent piece of code.

But why should we move away from it?

jQuery was invented at a time when web developers can’t do things. Cross-browser. But the times are different. Web browsers have evolved. Standards have evolved. jQuery is becoming more and more irrelevant.

On a backwards-compatibility note: sure, jQuery might still be relevant for those purposes, but sticking to the old ways may impact beginning and even expert web developers towards innovation.

Finally, here’s the list of the specifics:

  1. Sizzle, and by extension jQuery’s selectors, are deprecated by Document.querySelector and Document.querySelectorAll. Yes, we have those now. And they’re awesome.
  2. UI? If you ever need new controls, there’s Shadow DOM now.
  3. One thing I really hate about jQuery is their Promise system isn’t compatible with A+. This means I can’t return-and-ignore thens from promises. For the record, ES6 will use A+-style promises. Oh man, this will really confuse people when they come from jQuery to ES6 promises.


  1. Animations? We have CSS3 animations now.
  2. Standards have taken care of the pain of adding and removing classes thanks to Element.classList.
  3. jQuery had supported for custom element data and added support for data attributes when they came but why not just use native?
  4. I don’t like how jQuery hides events in a wrapper.

At least some of these things came to mind because I’m still including jQuery in some of my projects because I need to have Bootstrap, but then why does Bootstrap still require jQuery, right. So what if we had our own pure Javascript/CSS responsive framework? What? Foundation?

Why I like node.js

Months ago I stumbled across this and though, meh, it’s just another one of those dumb programming shenanigans. Over the last few weeks, I got to try to program with it. But before we go there, let’s stop and define what node.js is really.

Node.js is a program. It exposes a framework (an API), on top of which you can program using Javascript. Other than that, it boasts of this framework having an asynchronous nature, which we all know is better than synchronous sh*t.

I have crafted this mini table for a quick comparison. NB: These are all purely my opinion.

Programming language Javascript! (No, node.js is not a programming language!) Visual Basic or C# Freaking Java!
Program (compiler or interpreter) nodejs.exe I don’t know, MSBuild? Freaking javac!
Framework I don’t know, did they give it a name? The glorious .NET Framework Freaking JRE?!
Your friendly neighborhood IDE PhpStorm, Freaking NetBeans?!??!?!, Visual Studio (!) Visual Studio Freaking NetBeans?!??!?! Or Eclipse?
Community resource pool (?) Plugins? npm Nuget ????

Now that’s done, let’s have my answers: why like node.js?

  1. It’s freaking Javascript! It’s a language we all know and love! (It’s a C-based language, which most of us know, but scare most beginners, but hey, you can always alleviate that if you’re into language transformers like CoffeeScript.) It’s the language your server tells your client user agent to do! Now, it’s the language you write your server program in! That’s right:
  2. It’s your freaking own server program! Yes, unlike Apache and PHP, which are separate web server and interpreter, node.js allows you to be free and write your own! Although this creates an issue for hosting providers that might not want to give their customers that much freedom. Although there are some who are willing to give developers a chance. Note that node.js doesn’t have a built-in web server of its own, but it has an HTTP library which can get you started. And there are always libraries that can simplify your intended task.
  3. Yes, and with npm, installing third-party tools are a breeze. Just like apt, it takes care of all the dependencies your third-party library might require.
  4. It’s based on V8, the same Javascript engine used by the awesome browser Chrome! If you’re not familiar with what V8 does, here the thing: V8 compiles Javascript code into freaking native machine code. What this means is that when it’s done compiling, your code will run blazingly fast once it starts!
  5. It’s already in the intro, but it’s based on a freaking asynchronous API! What this means is that when some code reads a file, that code can wait for that I/O operation to complete while other code consumes the precious CPU cycles! This can be really useful especially in the website hosting context where many users can connect simultaneously to your website.
  6. Write a small script and it should just work, whether it’s a simple console.log("Hello World");, a demo to show to your students (given you’re a teacher? Probably…), or just to show off your m4d w3b scr4p1ng sk1ll2. Because Javascript is a freaking scripting language!

As node has many good things, it also has some bad shortcomings. Let’s take a short look at that:

  1. This really is for JS and not node: I am really lamenting the lack of an “await” keyword for JS. It would be really useful since node has an asynchronous API. Right now the closest we have for that is Q.async + ES6′ yield.
  2. Yeah, we all know Javascript, but only because it’s an ages-old programming language. There are a couple more advanced programming languages out there, Visual Basic being my (past? :O </3 oh no!) favorite, Ruby (psssh… only Taric uses this), and Python (Who uses Python anyway? I don’t know… NASA? Freaking Google?) that addresses many of the older languages’ shortcomings. But as these are actively developed, so are the oldies. I do hope Javascript catches up one day. Fingers crossed.

And that’s it! This concludes my fanboyish post about the freakishingly awesome node.js.