Testing default and rest parameters

June 7, 2015

Take a look at this example. I set default parameters for ‘a’ and ‘b’ in the function.

If the parameter is not set with a default value, it behaves very much like how it would in ECMAScript 5.1 — undefined. See the parameter c.

The final parameter is a rest parameter ...d, i.e. 3 periods followed by the variable name. This is supposed to take over the older arguments variable. It will always be defaulted to an empty array.

Happy 2nd birthday React.js

May 31, 2015

Happy 2nd birthday React.js. Kind of:

I didn’t realized React.js has been 2 years of fun. At my workplace we shifted to React.js and then out. It’s unfortunate but till the next time we meet!

io.js 2.2.0 released

May 31, 2015

There’s a new io.js release:

Speed-up require() by replacing usage of fs.statSync() and fs.readFileSync() with internal variants that are faster for this use-case and do not create as many objects for the garbage collector to clean up. The primary two benefits are: significant increase in application start-up time on typical applications and better start-up time for the debugger by eliminating almost all of the thousands of exception events.

Full changelog

Grab it here.

[UPDATE: requests changes broke npm and bower on Windows, Linux and Mac OS X. You should wait for the 2.2.1 version.]

Using Uglify’s screw-ie8 option in gulp

May 30, 2015

UglifyJS tries to be IE-proof, you can pass a flag in Uglify if you don’t care about full compliance with Internet Explorer 6-8 quirks. Previously I wrote about how to screw IE8 in grunt.

You can run

However if you are using gulp.js, this is how you can do that:

Several things to notice here:

  1. I use gulp-uglify/minifier so that I can specify my own version of uglify-js
  2. I use gulp-rename to add a suffix to the filename
  3. The screw_ie8 parameter needs to be passed into compress and mangle as options.

It’s really time to move on and ignore IE8.

Share with me other tricks if you have any.

Using npm for browserify and uglify

May 24, 2015

Previously I use gulp.js a lot; I’ll have a gulp file that does everything.

Why you should keep gulp tasks to the minimal

  • Gulp provides another interface to your actual toolchain, it’s much easier to understand the command line since those are pretty well documented.
  • You can trapped by the version of your toolchain supported by the gulp friendly plugin. For example, gulp-less may have an older or newer version of LESS.js that you want to use.
  • Lesser dependencies is makes things neater.

You should keep gulp where more complex tasks comes in.

Using just command line

Here’s an example of my typical toolchain. Let’s start with LESS.

LESS to CSS generation

This one is pretty straightforward:

I didn’t need JS and Internet Explorer compatibility and I want to be able to compress the CSS. This requires you to do:

Browserify

Browserify is a module bundler. I use React.js and browserify brings in the dependencies into one file.

The command itself:

You can also run the corresponding watchify command

Minifying JavaScript through uglify

You can uglify using the following command. The following command does compression and mangling:

Using npm to manage your scripts

You can put the less, browserify and uglify script into package.json’s scripts.

Now that they are in the scripts, you can do these:

Notice that you are also combine npm script commands by using &&.

If you use React.js, you will need babelify as well. You can add the following transform in package.json:

Browserify will use the transform in package.json and you do not need to specify the transform in the command line all the time.

In React.js you should compile the production version this way.

Using uglify, you can remove dead code.

io.js and node merging

May 17, 2015

I’m really excited for this:

io.js and Node.js is merging. io.js agreed to move into the Node Foundation and rename the “iojs” org on GitHub to “nodejs”. It will take some time to reconcile and it all is promising.

io.js TC Meeting 2015-05-13 stand up. We do that at Tremor Video too but it feels so different.

Initial thoughts on Strongloop’s loopback

May 17, 2015

Web development in Node.js is constantly evolving and my work as a frontend engineer pretty much ties me to Express.js most of the time.

This time I am looking for something that is more full-featured that has an authentication module built in.

Pros

It has a really sane folder structure to start with. It’s close to how I would have organized files as well. It has a pretty standard server, common, and client structure which made me feel at home.

What’s clever is also the Loopback explorer which gives you a quick view of your API.

Loopback explorer

I like how easy to see what the available API points are and it makes me comfortable to build an application that is fully REST.

What’s cool is also the slc commands which is reminiscent of Ruby on Rails. In the commands are Strongloop Arc (under slc arc) and adding persistent models.

Cons

Which brings me to the downsides. For Strongloop Arc, it bothered me a little that the GUI is proprietary. I’m not sure how pluggable is Arc but think it will be eventually necessary to write your own services to monitor the application. Either that or run your own tools over Arc.

It also took me a while to get the MySQL part working. I created the models and but I can’t seem to migrate the tables into my database. To migrate your tables in, you need to do this:

I created a file and save it to ./server/boot/create-models.js. This wasn’t immediately obvious to me. Once your tables are created based on what is in your models, you need to comment out this file so that it doesn’t run again. I’m probably doing this wrong.

I’m also a bit confused with the conventions too. For example, should the models be capitalized? Even the documentation seem to give examples differently. It didn’t help that Loopback changed quite a bit through the major version upgrade and documentation and Stackoverflow may not have the most up-to-date information.

Conclusion

Loopback’s still promising, I want to continue exploring it and if it works out, I’ll build something on top of this.

Making Travis build more efficiently

March 15, 2015

If you use open-source projects, I’m sure you’ve encountered Travis CI. Travis CI builds at every single commit. Each build can take up to a couple of minutes. I imagine Travis need to deploy the instance and run your build.

Here are some tips to speed that up.

Use Docker containers

Consider using Travis’ Docker containers as they’re much faster. I observed it shaved of 30% of my build time.

You can do that by setting sudo to false.

Caching your dependencies

If you use Bundler or Node, you can easily cache your dependencies as well.

Example in Node:

Example in Ruby:

Skipping the commit’s build

If it doesn’t need to be built, don’t build it. Add “[ci skip]” without quotes in your commit messages to skip a CI build.

That’s all

My typical .travis.yml.

And remember to give io.js some love as well. :)

CI is tremendously helpful. I use a combination of Travis and Codeship.io most of the time. I’ll write more on Codeship if there’s interest. Hope this helps.

How much of a web page is on React.js

March 1, 2015

This is pretty cool — curious how much a page is using React.js?

One the Web Inspector and run the following:

Source: Pete Hunt

%d bloggers like this: