I recently wrote a tutorial on how to build a date picker with React JS, so I figured I’d expand upon that and detail how to write a time picker, too. First things first: just like last time, I’ve put the code up on GitHub if you want to see the full monty. I’ve also made an npm package and a bower package for the time picker in case you want to use it on your site somewhere.

Note: The code is far from production ready, so use at your own risk.

If you’d just like to take a look at the time picker in action, I’ve also put together a (really simple) demo page. Take a look!

I’m going to talk about how to create a simple todo application using React JS and the Flux architecture. React JS is making some waves in the community recently due to its alleged performance increases over other heavy favourites (like Angular JS), especially when it comes to writing out lists. I’m not so concerned with performance, but I am interested in how to write an application that’s easy for the user to use while at the same time being quick to get off the ground.

A few months ago, I started working on a project with a friend of mine who turned me on to the idea of channeling various asynchronous tasks into a pipeline. The idea is that, instead of polluting your local function with a bunch of .thens, you put each of them into a separate module, and then require them into a unifying function that does all the heavy lifting for you. I’m going to walkthrough my implementation of just that right now in a quick Node JS application.

I’m a new fan of Webpack. It’s a great tool for intelligently bundling all of the packages your project needs and its watch feature is super quick. I’ve been playing around with it a bunch for my latest project which uses React (see here: Webpack with LESS and React) so I figure it was about time for me to start writing some unit tests to back up all that fancy code. I did a quick search for running Jasmine unit tests via Gulp that utilize Webpack’s bundling while also allowing for transformations of JSX files into raw JavaScript, but I didn’t have much luck there. I quickly settled on a Karma implementation, as there’s a plugin built especially for that purpose.

I’ve recently been playing around with Webpack and I really like it. It has the benefits of Browserify in that you can specify an entry point that’ll pull in all of your required modules into a single bundle with optional minification, while also letting you bundle your style together in your modules. For example, I can require a style file for a particular module right from the module itself, which allows me to somewhat limit the global nature of CSS rules. On top of that, Webpack allows us to leverage LESS in these included style files, too, that get compiled down to CSS. I’m a huge fan of this, as it allows us to create less coupled modules in that each style file can be tied directly to a module, and only gets pulled in when its required. Webpack also utilizes what they call “loaders”, which are basically preprocessors that perform various tasks. For example, there’s a LESS loader to convert LESS into CSS, and a JSX loader to perform a similar conversion for React classes.

I’ve recently written an article comparing React JS and Angular JS, and it’s been getting a fair bit of attention, so I figured I’d go one step further and show how well each of the two perform. I’ve also added in Knockout JS to the mix here just for comparison’s sake, and also some raw JavaScript DOM manipulation to give a base line as to how well things work across the board.

I’ve put together a quick page that allows you to see the rendering time difference between the three frameworks, plus the raw DOM manipulation. It’s what I’ve been using to figure out how long each framework takes to render large lists, as seen in the results table below. Take a look here.

The WordPress theme for this site has been built (read: over-engineered) with Browserify and React. Most of it is pretty straightforward, but the widgets on the right are a little more complicated. I’ve only just started working with Browserify in general, so I had a relatively difficult time setting up a workflow for testing some of my modules. If you’re unaware, Browserify works by bundling up all of your CommonJS modules and any modules in your node_modules folder for easy use throughout your application using require. You provide the entry point to your application, and Browserify will step through all of the require statements to pull in all the appropriate files and modules. It’s a neat system and, in general, I’m a big fan of it, but I had to change the way I usually test my JavaScript files. I’m using Grunt for my build tool, so the goal here is to be able to type grunt test from the command line and have all my specs run as per usual.

I’ve been using Grunt with Browserify recently to build the theme for this blog (https://github.com/chrisharrington/dapper-developer-theme) and I’ve noticed that using grunt-contrib-watch in conjunction with Browserify is pretty slow: on the order of 1500ms on a JavaScript code change, which I felt was unacceptable. Watchify is a tool used to bundle Browserify modules on change that works much faster because it only rebundles files that have changed. This is great, but I run into a problem if I’m watching my LESS files at the same time, as each watcher will block. I’ve put together a quick Gruntfile that’ll allow you to run multiple watchers using grunt-concurrent, a Grunt task that’ll let us to run multiple blocking tasks at the same time.

I’ve been wanting to write an article comparing the latest and greatest front-end JavaScript frameworks for a while now. I’ll be writing about Angular JS and React JS. Angular is the big dog in this fight, as it’s been around for a while longer than React has, but React brings increased rendering performance to the table.

The purpose of this article is to go over building some simple functionality using Angular and React to give you an understanding as to what it would take to get an application off the ground. It’s not meant as an in-depth tutorial on either of the frameworks. As such, I’m not going to go into great detail for a lot of this stuff. If you ever feel as though you need more clarification on a topic, either throw me a question via Twitter or comment below. The documentation for Angular and React is also pretty good. I’m hoping that after you read this, you’ll have a greater understanding as to which framework is right for you to use on your next project. At the very least, you should have a grasp on how JavaScript UI frameworks operate in general.

I’m going to walk through how to create the typical coding example using each of the frameworks. Once I’ve done that, I’ll move on to some more complicated UI controls, building up our little app as we go.

Today, I’m going to talk about how to create a calendar control using Angular JS, LESS CSS, Font Awesome and Moment. I’m going to assume you’re at least halfway familiar with these tools, but if you’re not, I suggest you take a look using the links above. The calendar itself will be an Angular JS directive that allows the user to select a date, which is set on a controller’s property. I’ve styled the calendar, and I’ll include that style in this tutorial, but you can obviously feel free to tweak how it looks to your heart’s content. If you’re the kind of reader that prefers to view a completed product and just check the source yourself, I’ve put together a demo page which shows off the calendar. You can see it here.

I’m going to break down the write up into a couple of different sections. First, the HTML. It’s pretty straightforward, as it’s just the calendar directive HTML. Then, we’ll walk through the JavaScript code, which shows how I’m using Angular JS to update the directive’s state which, in turn, updates the calendar view. Finally, I’ll describe what I’m doing with each of the CSS rules that style the calendar. While most of the CSS is simple, there are few things I’m going to go over that might be new to the reader.

The more I use Angular JS, the more I like it. I’ve been playing around with Facebook’s React recently, and I went back to Angular, primarily because I found React a little more restrictive with respect to two way bindings. I’ve built a modal dialog control in Angular which I figure you guys might find useful. The modal dialog itself is an Angular directive, and I’m using LESS for some of the slightly more complicated CSS rules. I’m going to assume you’re relatively proficient with both, but if you’re not, I highly recommend you check them out before plunging into this tutorial.

If you’re the sort of reader who just wants to see the whole thing in action, feel free to take a look at the demo page I’ve put together that shows off the whole thing. Viewing the source on that page should give you a pretty good overview of what’s going on.

I’ve recently been playing around with Angular JS and I like it, and so decided to spend a bunch of time converting Leaf from Knockout to Angular. It’s not that I think that Angular is substantially better than Knockout (that remains to be seen) but rather that I figure this is a good way for me to figure out the ins and outs of a new framework. One of the things I really like about Angular is building custom directives. I’ve only been tinkering for a week or two, but I already have dozens of custom directives for all sorts of situations and code snippets. They’re very, very handy.

So in that vein, one of the directives I’ve built revolves around rotating an element based on an Angular scope variable. My first use case for it was for expanding a sliding drop down. In the collapsed state, there’s a Font Awesome angle down icon that indicates to the user that it can be expanded, and after expansion, it changes to an angle up icon to indicate that the user can click again to collapse the panel. The following rotate directive is used to animate a rotation from up to down.

Up until recently, I’d been hosting Leaf on Heroku. I had a pretty good experience with Heroku and would recommend it to anyone whole heartedly, especially if you’re just getting into the Node space and want to play around a little. It has a free sandbox plan, it’s really easy to get started. That said, however, when you’re getting a little more serious, the cost of Heroku’s offering is almost twice as much as what Amazon offers. Prices today sit at $34.50 for two “drones”, which are the equivalent of two EC2 instances, while the EC2 instances themselves can be purchased for as little as $9 a month (or $18 for two instances). On top of the price difference, EC2 instances have the benefit of being almost 100% configurable, so I can poke around and do however I please.

From here on out, I’ll assume the reader is familiar with Amazon Web Services and have already spun up an EC2 instance with SSH capabilities. I’m using an Amazon Linux instance, but any of the *nix based instances will do the trick.

I’ve recently been playing around with the HTML 5 date input controls. They’re pretty robust, especially in the mobile space, as all of the major mobile players have excellent support for most HTML 5 tags. One of the downsides that I’ve come across, however, is that the date controls don’t support the placeholder tag, or any custom display strings. So if I want to show a date in a particular format, I’m out of luck, as I have to stick with the standard “yyyy-MM-dd” format that most browsers natively display the date in. For the most part, that’s ok, but I spent some time coming up with a solution that provides both placeholder and custom date format support to the input date control.

A note here: each browser handles the date controls a little differently. Chrome on the desktop, for example, shows a bunch of different options for setting the date, including typing the numbers for each of the year, month and date fields, while also providing an arrow which opens up a date picker. Mobile browsers all open up the date picker while tapping on the input, which is great for this solution. However, this solution won’t work for desktop browsers, as the date picker doesn’t show until the user clicks on the little arrow, which is invisible.

The Problem

I’d recently been asked to solve some performance problems with a page that had previously been built. The page is responsible for allowing the user to choose an airport. It has some other fancy stuff going on, like favouriting airports and such, but the bottom line was that it was simply a list of airports, one of which the user would select. We saw some unusually high rendering times for the page and when I dug into the code, I saw that the page was being generated dynamically by using JavaScript to iterate over a JSON list of airports and building the view from a template. That list of airports was retrieved asynchronously, which is why the page is built using JavaScript instead of being rendered on the server. There’s a couple of ways to build pages in JavaScript with jQuery.