Rants & Raves

Musings on software, programming, design, and business.

The languages of the browser, HTML, CSS, and JavaScript are berated, harped on, abused, misused, and contorted to do all sorts of things they weren’t designed to do.  HTML in it’s core is a semantic language intended to organize documents and the relationship between them.  CSS is simple, straightforward, but hardly dynamic.  Even with Less and Sass, the resulting output is a flat static stylesheet that was never meant to power rich interfaces.  JavaScript was designed in 10 days and as we all know is the most misunderstood language – thank you Papa Crockford. As someone who writes JavaScript day-in and day-out, I am fully aware of all the issues with it. However, the community is massive and the toolsets are plentiful. What was originally used to perform superfluous tasks is now a great option for a unified language application. Javascript is the only viable way – today – that we have to express a dynamic interface in a browser.

HTML5 has been a big step forward, but it does not really deliver in terms of fluid interfaces, particularly for mobile.  Older methods of DOM access and manipulation are flawed, and ripe with performance issues. Dealing with these issues is complex. Everyday development cycles should be abstracted from having to deal with limitations like these. Famo.us does this for us, and from what I’ve seen so far – it does it well.

Browsers have gotten really good.  Our desktop machines are crazy powerful.  Most of the time folks aren’t cognizant of any performance issues with the sites they browse on their desktop machines.  All of this often masks the limitations of HTML/CSS/JS, or poor implementation by the developer.  On mobile devices however, the cracks in HTML5 start to show.  Although smartphones and tablets today are indeed amazingly powerful for their size, the mobile browsers they tote are a far cry from their desktop cousins.  This is where it becomes quickly apparent that HTML5 is not as magical as we think it is – or have been told it is.  When Zuckerberg – of Facebook –  said “The biggest mistake we made as a company was betting too much on HTML5 as opposed to native” it was a huge blow to the perception of HTML5 in the mobile space.  Recently there have been rumblings of a Front End framework that is solely focused on providing a toolset to use HTML5 in a performant way.  This framework is Famo.us, and it wants badly for the web to win.

Famo.us is alot of things; a 3D layout tool, a physics engine, a native wrapper (yet to be seen), a MVC (yet to be seen), but more importantly it’s an attempt to solve the biggest rendering performance issues of HTML5.  Stabs to crack this nut in the past have fallen short in my opinion.  Sencha Touch is a very mature JS MVC with a rich UI kit, however it is beholden to a heavily nested DOM which will grind your app to a halt if you try to get too fancy.  Ionic framework is a more modern attempt to create a UI kit for mobile, and leverage AngularJS as the app convention.  Although the DOM is much lighter, it doesn’t address a fundamental issue of nested elements, reflows, repaints etc.

Famo.us recently entered a controlled beta – adding a few hundred accounts a day, and allowing access to early guides and documentation.  I am excited to be attending HTML5 Dev Conf for hands on Famo.us training and hackathon, and to be a part of this beta release.  What I have seen so far is very promising.  There are a few things that Famo.us is doing that will give a speed boost to the DOM by addressing how we structure and think about modern web apps.

The Flat DOM

Famo.us uses the concept of surfaces and modifiers for layout. Surfaces are what they sound like, a flat surface – In the DOM represented by a div node.  Surfaces are dumb, they don’t know where they are, they don’t know what size they are.  Modifiers are objects that hold, and can modify the state of a surface.  This can be opacity, x/y/z position, and a host of other properties. A surface’s associated modifiers control its properties, as well as any other surfaces that follow.  This abstraction between surface and modifier allows the developer to chain modifiers and surfaces together, which creates a representational render tree such that a modifier can affect many surfaces below it on the tree.  This concept is central to how one architects the layout.  The association of surfaces is held in the JavaScript code instead of in the markup.  This allows greater flexibility and expressiveness in the tree.   The result is a DOM of surfaces that are siblings, and we avoid the pesky nested DOM tree of yore.


There is a great article on HTML5 Rocks – A resource for open web HTML5 developers about CSS3 and hardware acceleration.  What is not mentioned in that article the the transform matrix3D – which allows a 16 digit matrix of values to describe a point in space in a 3D perspective along with rotation, skew, and scale.  Famo.us wraps this property up and uses it as the main driver of it’s layout engine – flipping brilliant if you ask me.  This allows them to run operations against multiple matrices of modifiers for super performant, complex transitions.  Deeper under the hood Famo.us leverages the JS method “requestAnimationFrame” to know when to update the matrix – ensuring users perveice the UI at 60fps.

Sticky DOM

Nothing really groundbreaking here I would say.  Caching reference dom objects is one of the first things listed in any best practices guide for DOM speed.   Many frameworks have optimized themselves around reducing DOM touches.  They all have their own special flavor on how they get that done, but the concept is straightforward.  I like to think of JS and the DOM as being on opposite sides of a river.  There is a bridge and, as with all bridges, there is a bridge troll.  Everytime the bridge is crossed in order for JS to talk to the DOM, the troll blocks your path and charges a speed tax.  Famo.us’s modifier / surface separation allows the developer to care less about accessing the surface, since the modifier is where all the slick transitioning is handled.

The performance problems that Famo.us is attempting to address, along with the rich catalog of physics, animations, and other features included make it a framework to definitely keep an eye on moving forward. Bootsoft is committed to the open web, and are looking to leverage any piece technology that helps us move that goal forward.  When Famo.us is ready for prime time, we will happily find the right project to unleash it on.

The face of front-end development is in a constant state of flux. Web applications are becoming increasingly front-end driven, and the concept of a single page web-app powered entirely by REST-ful web services is the new norm. While libraries like jQuery have dominated the landscape for many years, they no longer provide all of the necessary tools for today’s client-side development world. The result is a major push from the front-end community for more robust tools and frameworks that make up for these deficiencies, one of the most popular of these is AngularJS.  Where jQuery is a toolbelt, Angular is framing, plumbing, and electrical.

Angular isn’t the only solution. Backbone is another popular framework that creates separation in the MVC pattern. It is, in my opinion, the most “bare metal” javascript MVC available in the open-source world. Although it provides some syntactic sugar for wiring events to elements with the scope of a view, it does not offer “two-way” data binding in the way that Angular does.  That is, if you assign a model to a views configuration, the frameworks leaves the work of listening to the model to update the view when data is changed. Building dynamic web applications takes a lot of code, and developers are forced to work with low level tools for DOM manipulation. Starting any new project involves writing a lot of boilerplate code to listen for user input, and then linking all of these listeners to some functionality.

Angular addresses boilerplate bloat code with a more graceful document life-cycle, then allows you to access this functionality through additional HTML attributes/tags/class known as directives. All of the functionality you would have to add using Backbone is moved behind the scenes. The philosophy behind Angular is that web applications are living documents that should update in real time. Creating dynamic client-side applications should not be such a messy endeavor.

The big win with Angular is two-way data binding. In a traditional web app, when a page renders it takes data, merges it with a templating system and then displays that data to the user.  At that point the rendered page is essentially static. Developers have to manually wire events for clicks, hovers, keystrokes etc, that update a data model or collection of models based on those events. The page then has to re-render the page using the template and updated data model.

In Angular, the View and the Model are connected by two-way data binding. Changes that happen in the View immediately affect the Model, and changes in the Model instantaneously change the View. More importantly, Angular sets up all of this functionality under the hood, so coding can be as simple as change a few HTML attributes and calling the template without writing a single line of JavaScript.

Two way binding is a huge timesaver, and also helps the developer think more in terms of the state of the app – which leads to a more consistent experience for the user.  Angular is massively robust and contains many other tools that allow for rapid development.  Dependency injection, custom directives, services, factories, and host of other nuts and bolts place Angular squarely in contention for the go-to JS framework.  I should also note that Angular is a product of our friends at Google, and so we may have a relatively high level of confidence in it’s progression and ongoing maintenance.

It’s not every day when one of our longtime clients comes to us and says “We want you to build something cool.” Of course all of our projects are cool, but this was slightly different. Coldwell Banker wanted us to build a piece of software to wow their prospective franchisees. After some discussion about what this might look like, the video wall project was born.

Video Wall – Main Screen

The Video Wall is basically a giant interactive map of the United States displayed on a television screen. All over the map are tweets from real estate agents in different cities and states capable of being filtered by specific hashtags. Users control the map using their hands via the Microsoft Kinect, a motion sensor unit we attached to the television.

Coldwell Banker gave us a lot of flexibility on this project. We had an overarching goal for the project, but we knew some of the finer details would be discovered over time. This made it a perfect Agile project. Agile is a method that  involves incremental development broken down into phases called sprints. Instead of all of the functionality being defined at the beginning of the project, functionality is discovered over time with input from the client. At the end of each sprint, a functioning piece of software is delivered to the client for feedback and the goals of the next sprint are laid out. In this way we were free to try a bunch of new things and find the perfect solution for our client.

Getting Started with Kinect: Microsoft vs the Rest

My role in the project was development using the Kinect. The first challenge was selecting what technology to use. Microsoft provides a software development kit (SDK) for the Kinect using Microsoft Visual Studio and C#, which has several built in functions to recognize gestures and movements. There are also several third party SDKs, which I tried over the course of a month in addition to Microsoft’s Kinect SDK. In the end I decided on Microsoft’s.

The third party options are mostly low-level C++ implementations that largely come out of research projects and minor experimentation by various entities. Although some seem very useful (and certainly flexible), the revisiting of writing C++ code would be a big contributor towards avoiding these APIs. Additionally, the availability of support wildly varied by project and relied mostly on how active (in the project) and responsive the developers are. The issue of course is always time.

Windowed App or Not?

Having decided on using Microsoft’s SDK, we came to another intersection that required choosing between creating a GUI Windowed application vs a console-driven application. The goal was to show a web page in a window and we know that web browsers specialize at this. On the other hand, the Kinect SDK has tons of goodies that make developing a Windowed application much easier than the alternative. After a bit of playing around, it was clear that using the web browser to deliver the “wall” was the way to go due to the flexibility and freedom offered in creating Javascript-rich applications and the ease at which updates could be made available.

Kinect Console Lessons

One of the biggest challenges was implementing gestures. Some gestures the Microsoft SDK provided functions for, such as dragging the map by closing your hand. More complicated functions like zooming in or zooming out I had to code from scratch.

To zoom in or out on the map, the user first has to hold both hands up in front of the screen. Then, the user has to close their hands and either pull their firsts apart to zoom in or push their fists together to zoom out. These functions were not provided in the SDK. That meant I had to write a lot of low level code to recognize these gestures. This turned out to be a little more tedious than I anticipated.

Overall it was a quite a fun project. The Kinect also has the capability for facial gesture recognition and voice recognition, so we only really scratched the surface of the full range of functionality. It was great to get to learn some new technology. Thanks CB!

This month Ian Ainley nailed it.

Working with someone is a huge commitment.  You spend hundreds of hours collaborating, debating, struggling, and eventually succeeding alongside your peers.  Trust is an inherent part of any relationship, and getting into the virtual trenches with someone requires a great deal of it.  My working relationship with Ian has spanned multiple companies and countless projects.  There is no developer I would rather have at the keys than Ian Ainley.  He is a superb programmer, but more importantly is dependable, and trustworthy.  There is calmness to his swagger that helps to right the boat when things get rough, and I have never seen a task or impasse get the best of him.

Ian’s work is uniformly accurate and timely.  On a project that was particularly complex – Ian built the front end for something called “Blue Wall”.  This ‘wall’ integrated a live twitter stream using web sockets to display tweets on a full screen map.  The user then interacted with the map using motion captured by an X-Box Connect.  Ian hand rolled a custom event dispatch system in CoffeeScript to handle the incoming tweets and motion events into what is truly fun and exciting user experience.

Most recently we have been working on a mobile app using the Sencha Touch framework, and Phonegap(Cordova).  This is an area of JavaScript development that has become an increasingly popular option for clients who wish to have their “app” deployed to multiple platforms’ App Stores but don’t want the overhead of developing and maintaining a codebase for each platform.  There are many benefits to going the way of the HTML5/JS/CSS3 to native deployment.  In this solution there are of course hurdles and roadblocks that developers must face to achieve the same level of immersion and integration that a native app can provide.  In my experience as a Web Developer this has been one of the more challenging problems faced.  Thankfully Bootsoft is lucky enough to have Ian Ainley tackling these issues and managing the find the right balance between art and code.

These are only a couple of the projects Mr Ainley has been working on, and there is no question that he has Nailed It.

The last time I wrote about Responsive Design was about a year and a half ago, and there have been so many updates and advancements. I wanted to take this opportunity to talk about how I’ve been using responsive design lately and what I’ve learned by doing so.

In my role as a User Experience Designer at Bootsoft, I get the privilege of seeing new projects move from inception, to design, to development. A big part of designing a site or application, is planning out the architecture. After meeting with the client and hashing out the product’s needs and functions, I do some sketches and conceptual wireframes. Through the wireframes, I am able to annotate and map out on a more general level how things are going to interact. After going through some iterations with the conceptual wire frames, we begin making a clickable prototype. The clickable prototype can be very helpful for showing the client how their product is going to work. Without having to worry about any of the back-end, we are able to show them a prototype that looks, feels and functions like they expect a website or an application to work.

For these prototypes, I have been using the responsive front-end framework, Foundation (http://foundation.zurb.com). I am a big fan of this tool, because it is easy to implement, it has a bunch of great add-ons for prototyping that make mocking up a website quick and easy (like modals, image sliders, etc).  It is also based on a grid, like the majority of responsive frameworks. The grid creates a layout that is controlled by percentages, so when changing the browser size, the content is flexible and logically rearranges itself.

One of the nice things about Foundation is that you can style it as much or as little as you like. Their core look and feel is actually very attractive – especially the buttons, forms and other added components. It’s clean and unobtrusive, which helps the client hone in on the core functionality of the user interface & experience instead of getting hung up on graphic elements.

We have used this framework for quite a few new projects, and so far it has been very successful both from my perspective and the clients. It is very intuitive and definitely makes my life easier when making clickable prototypes. What is nice about it is that when I need to make updates or changes, it’s incredibly easy and flexible to do so. As we move more into the Agile process, it is very important to work with technologies that are fluid and easy to work with, so for the wire framing and prototyping part of our project, Foundation has proved to be one of the best ways to keep with the rapid process.

I am really enjoying this method we’ve adopted for the discovery process, and I’m excited to keep moving forward with new and advancing technologies. It is so important to keep up-to-date with the direction of development and technology, and I am glad we’re are doing so, especially in this early part of a project. If you are trying to figure out a way to express specific functionality to a client, and flat wireframes just aren’t cutting it, I highly suggest using a rapid prototyping tool like Foundation!

Kate Baldwin IS the graphic design arm of Bootsoft. She came directly from University to us and has blazed forth into the professional world leaving a wake of beauty and UX excellence in her wake. Her 3rd Bootiversary just recently passed and she has not lost a drop of the design-force essence that landed her squarely in our midst.

In between juggling umpteen project requests she also manages to push forward our Events and Marketing Committee (EMC) while grooming cats and design interns alike. If that wasn’t enough to quell this constant creative conjuror, a recent volunteer initiative – still to be named – has taken form which aims to provide an out-of-the-box site for a select nonprofit in a weekend session. The first go brought The Autism Program at Boston Medical Center from a back page mention to a full branded site complete with Calendar, Blog, and all the trimmings that go along. For orchestrating the event, curating the “client”, wireframing and designing the site – Kate has been bestowed the coveted “Nailed It” award.

There is no doubt that as the ever constant march of time pushes on Ms. Baldwin will be a central, if not critical piece in the Bootsoft ecosystem. Her presence makes us all better at our job – and that’s just before lunch.

Companies are constantly striving to differentiate themselves from the competition and part of our job as a software consultant is to create a product that helps them achieve this goal. Whether it’s increasing efficiency by simplifying their process or purely taking an idea and bringing it to life, Bootsoft takes on many roles (pun intended) when it comes to client satisfaction. When we were approached by one of our long-standing clients, The Leading Hotels of the World, with a marketing campaign idea combining film and travel, we could not have been more excited.

The main premise was to detail iconic movies that have been filmed on location at LHW member hotels or simply put, #LHWInTheMovies. With 85 featured films and the associated 85 hotels, there was no shortage of brilliant images and back-stories. After the initial discovery meetings, our team was feeding off the energy of enthusiastic project stakeholders excited to celebrate both LHW and the Academy Award’s 85th anniversaries. As one would expect, we incorporated the “must have” social media hooks for Facebook, Twitter, and Pinterest to allow a smooth flow across those sites. Custom verbiage and URL’s were crafted by the client to ensure the messaging was in-line with the rest of their campaign.

To implement the immense amount of static content (in 5 languages nonetheless), we attacked this microsite exclusively on the front end. Breaking from the “traditional way” of including multiple script tags on each page in a specific order, our front end team used Require.js to organize and handle dependencies for the assigned JavaScript files. By doing this, we can call one base file for the page and it will load any module and those modules’ dependencies easily. This boosts performance, as these files are not called asynchronously post page load, i.e. no more JS blocking.

Backbone and Underscore were used to build the dynamic templates for the pages, as well as create a convention for organizing high level JS classes. Finally we marked up the pages using HTML5 and CSS3.With all these factors in place, the code is far more reusable and maintainable.

With a wide range of properties across the globe and movies filmed in every decade dating back to 1925, everyone was eager to share the new site with the world. Check out the final product here and be sure to share with your friends and family. Big thanks to everyone involved on the project!

JavaScript seems to be an odd candidate for a language on the rise. After all it’s not new, and in fact is by most accounts a flawed language. Many would argue that it fails to deliver on the 3 pillars of Object Oriented programming; encapsulation, specialization, and polymorphism. Javascript is very loose in it’s typing, and the apparent lack of those types may drive a “classic” programmer out the window. We have functions as first class citizens and can pass them about without a care in the world. The endless flow of callbacks and a-synchronous patterns can quickly turn any well crafted script into an unwieldy goulash. Within the function body of an event handler we suddenly loose scope and find ourselves hanging from the window, looking in on our locally scoped friends we so desperately need. Yet somehow, someway all the “newness” and “hotness” and “hipster meta tech framework jargon ipsum” is leaning on the back of this once berated language.

With the death of Flash there is one way to script that all the browsers you care about can handle, and that is JS. It’s like our “too big to fail” banks and insurance companies. What happens if a browser decides “nah, I don’t like JS, we are going to introduce a new sexy, semantic language that is going to blow the doors of that antiquated piece of junk”, and stops supporting it? People stop supporting that browser. We have parity; Chrome, FF, IE, Safari, Opera etc … IE is no longer the hegemony it once was, and cannot push us around. In fact IE has to play catch up and support the magnificent modern feature set that webkit and Mozilla dream up.

With that, and the increasing efficiency of the JS interpreters we are driven to code the way of the JS Ninja. The FE days of sad code monkeys pushing pixels has given way to some seriously kick-ass client side devs who are moving this wave further and faster. JQuery is almost a forgone conclusion at this point – some of use are running multiple versions *gasp*. It has made selecting, parsing, and manipulating the DOM dead simple, normalized events and AJAX across browsers, gave us simple animations, and brought IMHO brought the first glimpse of sanity to Client Side Programming. WOW, the term “Client Side Programming” was an oxymoron at one point, wasn’t it? Now there is a sea of emerging frameworks, libraries, tool-belts(?) all calling for our attention and loyalty.

We recently built a prototype for client that was purely on the front end. With the help of local storage, an app experience was born that could be stateful for the user and provide an excellent preiview of a potentional product. After much researching and second guessing I arrived a set of libraries and frameworks to use in our venture. They were Require.js, Underscore.js(required by backbone), Backbone.js, and jQuery. Backbone has a hard dependency on Underscore, and looks for either jQuery or Zepto for DOM work. I was fimiliary with jQuery so that was an easy choice. The decision to use Require was inteded to provide structure and convention for JS dependancy management. Node has it’s own built in “require” and as someone who does not do a whole lot with Node – I was envious.


Backbone claims to be a client side MVC. Model – View – Collection … I hear you, what’s a collection? Where’s the Controller? Backbone had a controller, once, but that is gone now and all that remains is the view – which is actually more like a controller, and where you might think view code should be exists JS templates. JS templates, oh right – and which templating library should I use; mustache, handlebars, underscore/lodash, srender? I’ll say underscore for the sake of simplicity as it’s a hard dependency of Backbone – but I hear people like the handlebars and mustache because they have opinions on logic in your templates. I digress – Backbone, right, so What’s so awesome about it?

  • Nice “extend” synatx for dealing with JS prototype inheritence – very common these days
  • Event Delegation – clean usage of jQuery.delegate, handles the “this” gotcha of the scope bounce with event handlers
  • Patterns for binding views to data models – this is really where the juice is.
  • Native underscore methods of collections (Array of JSON Objects)
  • Reusable code patterns


Underscore is the only dependancy of Backbone, but shouldn’t be needlesly tied to it. If there is one thing that you take away from this post, it’s that you should go get Underscore/lodash right now. Underscore gives MUCH needed functional tools to JS objects, arrarys, arrays of objects(collecionts) and has some other bonus love as well. There is NO reason why you should not be using underscore, unless your in some larger framework i.e. Sencha. Another glorius takeaway from underscore is that you can now reuse your BackBone data models and collections from Node in the browser, as it has brought all those functional compemenets up. Brilliant!


You should be using AMD patterns for your JS, just like you should never use == and always use ===. Require isn’t perfect and can be ugly, but it’s better than nothing and comes with a handy dandy optimizer (r.js) – which runs on Node of course. The learning curve for me was steepest with Require. Not using a singleton global APP object pulls the rug to be sure – it takes some getting used to. In the end it results in better more re-usable JS code IMO.

There are many JS frameworks and plugins and helpers and tools, and it’s moving super fast. Being able to use one of these tools is the only way to learn, and decide if it’s right for you. There is no right way to use them, though certainly there are wrong ways but the most important thing is keep opening them up, diving head on, and hoping for the best. This is NOT an industry where you can sit still – and I like that way. JavaScript may give way to CoffeeScript of ECMA 6 or Dart, or who knows what – but right now you should know it and love it.

Byron joined Bootsoft a year and a half ago and has consistently nailed it.  With increased responsibilities in recent months he has continued to put hammer to nail -making him an obvious choice as the recipient of the January 2013 Nailed It! award.

As a front-end developer and tech lead, Byron’s skills are top notch. More than anything, what sets Byron apart is his ability to combine his strong work ethic, excellent teamwork and thoughtful leadership. Despite moving his base of operations to Portsmouth, NH, Byron has maintained a strong presence within the team and has proven an effective manager as Director of User Interface.

Byron is leading us on the cutting edge of front-end technologies having successfully implemented the following tools as part of a highly interactive responsive design tablet project for Pearson:

I am proud to count Byron as a colleague, and I know that he will always deliver work that is on-time  and of the highest quality while simultaneously bringing a humorous, uplifting and creative voice to the table.



The Bootsoft team recently completed the development of coldwellbankerpreviews.com. Coldwell Banker Previews is the Luxury arm of Coldwell Banker and therefore a high level requirement of the project was to convey an air of luxury with the website. This meant using high quality images while maintaining fast page load speeds, rendering single image files in color and black & white and sophisticated property search technology.

Speed vs. Consistency

With such a visual site, it’d be easy to load the page with lots of data for the user to download in order to achieve the desired look and feel. A few years ago, a site like this would easily be over 2mb to download. Fast forward to today, one of mantras that we always say when developing:

“Delivering speed and good UX is more important than visual or functional consistency”

Creating a website to be “pixel-perfect” across all supported browsers should no longer be a priority. When users interact with your site, it’s more important to deliver the content quickly. The New York Times recently published an article, where users’ expectations of page loads are getting shorter and shorter. If the page takes too long to load, users will click away. There was also a recent case study of how Wal-Mart improved online business through better page speed performance.

Paul Irish, one of the leading developers on the Google Chrome team, wrote a blog post about “Tiered, Adaptive Front-end Experiences”, or the TAFFEE approach:

TAFEE (pronounced: taffy): tiered, adaptive front-end experiences. Customizing the experience to the unique capabilities of each browser, prioritizing a fast and good UX over consistency.

A good way of illustrating this approach is by comparing this to an escalator. You can associate a working escalator to the latest browsers used today (Chrome, Firefox, etc). However, when an escalator breaks down, you can still use it as regular stairs (IE7/8, in some cases IE9).

(cartoon by Jody Zellman from BWOG.com)

Another way of illustrating, as mentioned in Paul Irish’s blog post, is to compare to the various TV sets out in the market. There are black & white TV sets, then there are the latest and greatest HDTV’s you can get today. It doesn’t make sense for TV broadcasters to deliver their shows all in black & white, just so that the show can look the same on all TV sets.

HTML5/CSS3 With Fallbacks

To that end, we looked to HTML5/CSS3 for delivering a visually stunning site, while providing a graceful fallback for older browsers based on feature. To achieve this, we used the following technologies/tools:

Not too long ago, front-end developers had to use a fair amount of jQuery or equivalent to achieve visual effects like animations and fading. Today, we can leverage most of these effects through CSS3. This brings the heavy lifting more to the browser, and also cuts down the code that is loaded on the page. Some of these effects are even hardware accelerated, which is better for users’ batteries on their laptops/tablets.

Reducing Images

With CSS3, we were able to shave off our image download size by cutting corners, essentially by not cutting corners (amongst other tricks). We use CSS3 rounded corners, gradients, opacity, text shadows, transitions, the works. Even the styled buttons are not images, which was especially helpful since Coldwell Banker Previews is a multi-language site. Older browsers will simply fallback to non-gradients and non-rounded corners, which are fine since the site will still load quickly and still will look fine.

The biggest “bang for the buck” was to utilize HTML5 canvas in order to render the black & white versions of all images. While the site itself is very lightweight, the largest download is the large image carousel on the homepage, where each image actually accounts for more than half the file size of the entire homepage. Downloading just one color image, then allowing the browser to render the black & white version reduces the download size tremendously.

Resource Loading

One of the key goals for any website we create is to only deliver what the user needs. It doesn’t serve the user to load the entire kitchen sink of images, styles, and JavaScript files when they only need to see a fraction of that at any given time. With that in mind, we utilize a couple of techniques: lazy loading and resource management.

Lazy Loading

There is no shortage of image carousels on the Coldwell Banker Previews website. It would be a huge amount of images to download if the user had to download all of the images at once. This is why each carousel only loads what the user sees, then lazy loads any image that comes into view when the user interacts with it. In addition to this, all pages load images only when the image comes above the fold. This is especially useful for smaller screens, and when the user has to scroll through anywhere from 10-50 properties or specialists on a search result page.

In the screenshots below,the image on the left shows images only below the fold loaded, while the image on the right shows the page after it’s been scrolled to the bottom of the page, enabling lazy loading of all images on the page.

We also do not limit lazy loading to images. Many JavaScript/template files are only loaded when there is a user interaction that requires it. A good example is the property detail page. When the user scrolls down, there is a mini-map that shows the property location via Bing maps. However, the Bing map library is somewhat large, so we only load it when the map comes above the fold.

Resource Management

While users are browsing the site, they only need a fraction of the resources used for the entire website. For example, when a user is on the homepage, they do not need any JavaScript files or styles necessary for the property detail page. Since this site runs on Java, we utilized wro4j, a web resource optimizer for Java. One of the benefits of using this tool is that it also pre-compiles our LESS files, which is highly recommended over processing the files on the client side.

Filling the Gaps With Polyfills

In an ideal world, we can leave behind the browsers that do not support the latest and greatest features in modern browsers. Allowing functionality to simply fall off in older browsers, like HTML5 placeholder, HTML5 form validation, etc., would otherwise be acceptable if we didn’t have a large enough user base using said browsers. In order to fill this gap, we use what are called “polyfills”. As described by Paul Irish, it is “a shim that mimics a future API providing fallback functionality to older browsers”.

In order to only include these polyfills for the browsers that need them, we use Modernizr for feature detection, and will only include the polyfill if the feature cannot be found.

An example of how it works:


//checks if the feature “HTML5 placeholder” exists in the browser
test: Modernizr.input.placeholder,
// if the feature isn’t found, it will load the jquery plugin for placeholder
nope: ‘jquery.placeholder.min.js’,

callback: function(){

// after the polyfill is loaded, initializes the polyfill for older browsers


complete: function(){

// runs a set of code regardless if the feature exists or not



As illustrated, the polyfill only loads if it is needed, otherwise it saves the bandwidth. Modernizr has a built-in utility/plugin called “yepnope”, which adds the flexibility of conditional loading and behavior.

Putting It All Together

Today, the site averages 2-3 seconds on first time view, and coming in at a fraction of a second on repeat views.

A few novel approaches to development that were employed in addition to our normal process include:

  • New object model for fetching and saving customizable data utilizing a website -> page -> components pattern that saves data directly in JSON format so that little to no pre-processing is needed for display, making front-end AJAX calls really fast.
  • New versioning strategy employed to avoid merging issues that occur when the trunk gets too far out of sync with the development branch.
  • Language support built in for supported languages, including Spanish, German, French, Japanese and English.
  • Locale support to handle automatic selection of currency and area unit based on selected language.

Both Coldwell Banker and Bootsoft are very happy with the final product. Great job team!

Visit http://www.coldwellbankerpreviews.com.