Better Than Bootstrap Javascript: Loaders

This entry is part 1 of 3 in the series Better Than Bootstrap Javascript

Bootstrap LogoBootstrap is an awesome tool, and something I use all the time. The ability to have so much css scaffolding in place for you to use is a huge time-saver and makes building responsive sites attainable in a more reasonable, repeatable and budget-friendly way.

On top of the CSS functionality, Bootstrap comes with a suite of javascript plugins that solve some common requirements for your UI. Including a modal, popover, carousel, tooltip and loader (among other elements), it really is a handy way to get some dynamic functionality out of the box, and get up and running quickly.

But when you’re such a large framework, and you encompass so many different areas – that means you’re going to be great for some things, and average (or poor) for others. When the parts are taken individually, their flexibility, capability and quality fall short of other tools that are built with only one specific purpose in mind.

When I’m working on a non-Bootstrap project, it’s rare that I would reach for a Bootstrap javascript component to complete a task – there are just better tools suited to specific jobs. Even when working on a Bootstrap project specifically – you might find a plugin lacking in some way, and want to try something else.

This is the first in a series about Bootstrap Javascript components, and some high quality alternatives.

First stop, user action feedback.

Starting small

This first comparison is of a small area of Bootstrap functionality, specifically centered around buttons. In Bootstrap, you can manipulate “states” on a button and give it behaviors outside of the standard button click behavior. They use it, for instance, to create buttons that can behave like checkboxes or radio buttons. In addition, they demonstrate behavior where a button can react to the users click, and provide the user feedback in the form of a “loading” state.

For instance, a user could click a button with the text “Loading state”, and once clicked the button is disabled and its content changed to “Loading…”.

<button type="button" id="myButton" data-loading-text="Loading..." class="btn btn-primary" autocomplete="off">
  Loading state
$('#myButton').on('click', function () {
  var $btn = $(this).button('loading');
  setTimeout(function () {
  }, 2000);

In our HTML, we’ve provided a button that has attributes about how to behave when in a “loading” state. data-loading-text provides the value Bootstrap will swap out when we switch to that state, and Bootstrap automatically disabled the button for us until we reset it. We just use the button api to tell it when we want it in a state of “loading”, and when done tell it to “reset”. Resetting it will bring us back to our original state: an enabled button with the text of “Loading state”.

Here’s an example of the concept in action:

See the Pen Bootstrap Loader by JP Camara (@jpcamara) on CodePen.

In practice I’ve used these loading states as an immediate indicator to the user that something has happened. Their action resulted in a process being started. For instance, if the user clicks a button and I make an ajax request, changing the state of the button to loading lets them know that something is going on (rather than sitting their wondering what might be happening, and if something went wrong). Humans can perceive latency in as little as 100 milliseconds (and maybe even less), so giving them that immediate feedback is important.

A more dynamic indication

The ability to add this loading state gives the user immediate feedback, and doesn’t leave them guessing about whether their click registered. But it’s somewhat of a jarring interaction (the button immediately changes to the loading state), and isn’t far beyond what we could do manually ourselves (disabling a button and changing its display text isn’t difficult javascript).

I think we can do better.

Ladda UI

Ladda is a UI concept created by Hakim El Hattab that “merges loading indicators into the action that invoked them”. In our case, that gels nicely with the concept we’ve already been promoting by using a “loading” state on our buttons to give the user immediate feedback. But the Ladda concept takes that a step further, and introduces multiple animated feedback mechanisms centered around the button.

Using the Ladda library from Github, the approach we take here looks similar to the Bootstrap states.

<button class="ladda-button btn btn-primary js-expand-right" data-style="expand-right">
  <span class="ladda-label">Submit Right</span>
var $expandRight = $('.js-expand-right').ladda();
$expandRight.on('click', function () {
  setTimeout(function () {
  }, 2000);

Our HTML looks a little different – we’re no longer specifying loader text and we now have a new attribute data-style. The data-style attribute specifies how the button will react when Ladda is enabled – in our case we’re telling it to “expand-right” when the user clicks it. There are several “styles”, including expand-left, expand-right, slide-up, and slide-down, among others (see Hakim’s demo page for all styles available).

In addition, we’ve now split our button and inner text into two pieces: the outer button layer with a class of ladda-button, and the inner span layer with a class of ladda-label.

Our Javascript code is straightforward, and i’m taking advantage of the jQuery plugin Hakim provides to make the setup even simpler. We grab the element using jQuery, apply Ladda to it using the ladda method, and then when clicked simply tell Ladda to start and stop at the appropriate times.

Here is an example in action, also including how to indicate incremental progress as some background action happens.

See the Pen Ladda Loader by JP Camara (@jpcamara) on CodePen.

Perceived Performance

What we’re going for with these two approaches is perceived performance. We haven’t actually improved the performance of our code or our server by including this, but the user feels like their action is progressing faster. Simply clicking on a button with no feedback (except maybe a loading icon in the tab of your browser) leaves the user feeling like things are moving slowly, or are possibly stuck.


The examples provided here are based on using standard Bootstrap and Ladda. If you’re an angular user and want to try this, here are a couple options

Angular Ladda provides an angular implementation on top of the Ladda plugin from Hakim

This gist provides an example of just creating a directive wrapper you could copy into your own project.


The feedback Ladda offers is more visually appealing and gives a deeper sense of progress than what Bootstrap provides out of the box. Using this approach we can make the user interaction more pleasant and responsive than what we were capable of with Bootstrap alone. I’m interested to know if you agree, or if you have any other alternatives that you’ve used in your work. Let me know in the comments!

Next up, we’re going to take a look at Carousels and what alternatives there are to Bootstrap’s native carousel component.

Better Than Bootstrap Javascript: Carousels

This entry is part 2 of 3 in the series Better Than Bootstrap Javascript

Last week we started small, and looked to improve the perceived performance of our website with interactive loaders. We looked at what Bootstrap had to offer out of the box, and then explored a more robust option with the Ladda plugin.

This week we’re aiming to improve the carousel experience. Carousels are ubiquitous on the web and are used for a wide variety of purposes – from picture slideshows to client testimonials to an entire web page experience. And while there are some people who say you shouldn’t be using carousels, the bottom line is they won’t be going away soon, and are a useful tool to use and understand.

So let’s start by taking a look at the Bootstrap approach.

Bootstrapping our Carousel

In comparison to Bootstrap loaders and buttons, Carousels is a more meaty area of functionality.

Here’s an example of a simple Bootstrap Carousel.

<div class="carousel slide" data-ride="carousel">
  <ol class="carousel-indicators">
    <li data-target="#carousel-example-generic" data-slide-to="0" class="active"></li>
    <li data-target="#carousel-example-generic" data-slide-to="1"></li>
    <li data-target="#carousel-example-generic" data-slide-to="2"></li>
  <div class="carousel-inner" role="listbox">
    <div class="item active">
      <img src="slide-1.jpg" alt="First slide">
    <div class="item">
      <img src="slide-2.jpg" alt="Second slide">
    <div class="item">
      <img src="slide-3.jpg" alt="Third slide">
  <a class="left carousel-control" href="#carousel-example-generic" role="button" data-slide="prev">
    <span class="glyphicon glyphicon-chevron-left" aria-hidden="true"></span>
    <span class="sr-only">Previous</span>
  <a class="right carousel-control" href="#carousel-exa mple-generic" role="button" data-slide="next">
    <span class="glyphicon glyphicon-chevron-right" aria-hidden="true"></span>
    <span class="sr-only">Next</span>

To setup the Bootstrap Carousel, you need to manually specify all of the html elements that go into it.

The .carousel class specifies the carousel container.

The .slide class specifies how to transition – in this case sliding. The alternative is to remove the class and the images change immediately.

The .carousel-indicators list specifies the position indicators at the bottom of the carousel.

.carousel-inner is the main content of the carousel, and the elements that get displayed are labeled with an .item class. To make sure your carousel displays at all, you have to make sure one of the items has an .active class applied to it.

For moving back and forward in the carousel, we have the .carousel-control class, and the data attribute data-slide with a value of “prev” or “next”.

Having specified all your markup, you can initialize the carousel in one of two ways.

1. Apply the data attribute data-ride="carousel". The plugin automatically applies carousel functionality to any markup on the page with that data attribute, on page load.

<div class="carousel slide" data-ride="carousel">

2. Initialize the carousel manually in Javascript


The result for our efforts is a carousel with clickable position indicators, click forward and back navigation, and that gives a baseline level of responsiveness based on screen size (it becomes smaller or larger as the screen size changes). It works the way we expect and gives us a solid carousel experience.

See the Pen Bootstrap Carousel by JP Camara (@jpcamara) on CodePen.

In addition to what i’ve shown, the plugin also offers a couple events (before and after the carousel slide has occurred), a few configuration options, and an API for manually pausing and moving forward and backward in the slides.

You can see that the functionality is limited, and the setup is very manual. We specify every piece of our html, and the capabilities we have beyond what you saw in the example are limited. What if we want additional transitions? What other capabilities are there for responsiveness? How fluid is the interaction on mobile?

Truthfully, I’ve never decided to go with the Bootstrap Carousel on any of my projects. The alternatives are just too good, and equally as easy (or easier) to setup. I’d suggest always using one of the alternatives, unless you have a real restriction on a project and can’t bring in outside libraries.


“Best responsive slider. Period.”

The first alternative to Bootstrap i’m presenting is Flexslider. Their boastful claim aside, it is a great carousel library and the functionality it delivers is pretty compelling.

Flexslider is a robust solution and was my go-to for a long time. It offers tons of flexibility, works great on mobile, has integrated swiping and comes with more levels of responsiveness.

Let’s look at an example of our markup.

<div id="flexslider-carousel" class="flexslider">
  <ul class="slides">
      <img src="slide-1.jpg" />
      <img src="slide-2.jpg" />
      <img src="slide-3.jpg" />

The thing we immediately notice is the simplicity of what we need to setup. Whether this is a good thing or not is a matter of preference. The Bootstrap markup is very manually specified, but that gives a decent level of control over exactly what is presented. With Flexslider, it does most of the setup for you and you just specify a small set of markup for it to enhance. It’s something of a Convention over Configuration approach – we provide Flexslider with a simple, consistent structure and it will handle the rest for us. Control over the output past that point comes in the form of configuration options and CSS styling. Personally, I prefer the slimmed down setup so I’m a fan of the Flexslider approach.

The conventional Flexslider setup contains the following pieces.

An outer container with a class of .flexslider.

An inner list of elements, with a class of .slides. This contains typical li items. Whatever content they contain is the content of the carousel.

And that’s it. A couple classes and a list. Having specified that markup, you can initialize the plugin by using the Flexslider API. We’ll also pass in a configuration option of animation here, to achieve the same transition that our Bootstrap example had.

  animation: 'slide'

The results of that effort in this case result in an experience similar to what the Bootstrap plugin offered. It has position indicators, forward and back navigation, and responds to screen size.

See the Pen Flexslider Carousel by JP Camara (@jpcamara) on CodePen.

So if we’re getting a very similar experience, is the only benefit we get is that there’s less markup? Isn’t that just a matter of preference?

Probably the most important benefit you get, before even digging deeper into configuration options and the API, is that the mobile user experience is much closer to a “native” feel.

Click Delay

The back and forward indicators (and the position indicators) in the Bootstrap Carousel suffer from what is known as “click delay”. A common problem on mobile touch devices is that clicking things like links is hampered by a 300ms delay. This is a problem caused by the mobile browser not knowing whether your tap on the screen is meant to perform an action, or if you’re in the process of double tapping to zoom in on some content (a common mobile browsing convention for zooming in on content that is not responsive, invented by Apple and replicated by every smartphone after them). So it mitigates this by enforcing a 300ms delay to determine your tap intention (you can read a more in-depth discussion of this topic here).

This may not sound like a big deal, but as I mentioned in the Bootstrap Loaders post, humans can perceive latency in as little as 100ms. 300ms leads a person to question whether their interaction even registered at all, and is a suboptimal user experience (imagine going through your mail on your smartphone, and every time you clicked an email it took 300ms to respond in any way – you’d probably drop the app, and the phone as well if everything were like that).

In Flexslider, click delay is not an issue. When on mobile, Flexslider uses touch events to control forward, back and positional navigation. This way the latency is non-existent and the interaction is immediate – your carousel moves forward and back as soon as the user taps it.

Swipe to navigate

In addition, a common pattern users have come to expect on mobile is the ability to swipe through things. It has become a natural expectation that many elements you interact with are capable of receiving, understanding and reacting to swiping and dragging gestures. With Bootstrap, the functionality is absent. With Flexslider, the user’s gesture registers immediately and can be used to either swipe quickly through items, or slowly drag between them.


The animations in Flexslider feel more natural than the Bootstrap equivalent and the position indicators give a more interactive feel to the items when clicked.

The first point is around the way we animate in between slides in our carousel, which has to do with what the animations “easing” is. “easing” basically has to do with how objects move – the Bootstrap easing is “linear”, meaning the animation progresses at a constant pace. Since most things don’t move that way (at a constant pace), it doesn’t feel as natural. It doesn’t feel “wrong”, but when we see the Flexslider animation in comparison, there’s a more fluid and understandable feel to it. The Flexslider easing is called “swing”, and it means the animation progresses slower at the beginning and end (you can see examples of lots of different easings here. I think “easeQuadOut” is the equivalent of “swing” in this case).

The second point is about how the positional indicators work. If you have more than two slides in your carousel, Bootstrap never changes the positional indicator behavior. I’m on the first slide and I click the third slide, I’m animated automatically to the third slide. There’s no sense of movement or position in the animation. In addition, it’s somewhat confusing if i’ve gone through all the slides, because casually sliding in the third slide in this case causes me to wonder what happened to the second slide – we’ve bypassed it entirely. In Flexslider, the slides are all quickly animated through, so you see that you’re actually progressing back to the first slide rather than being immediately transported there.

These might be more a matter of preference, but I think the difference is noticeable and an improvement to the experience.

Digging Deeper into Flexslider

For me, the improved mobile experience around gestures and tapping would be enough to warrant using Flexslider over Bootstrap. But i’ll talk about a few more configurations and API pieces before leaving the rest of the exploration to the reader.

An Example

  animation: 'fade',
  selector: '.slides div.slide',
  end: function () { alert('last slide!'); }

Here we’re modifying just a few options to add/change some functionality.

animation allows you to specify how the slides will animation. While not wildly expansive, you can choose “fade” in addition to “slide”.

selector lets you change some of the convention aspect of Flexslider. The convention is to specify a list item li, but here you can modify things so more types of markup are capable of being slides.

end is one of several events, in this case being fired when the carousel reaches the last slide. It’s useful for a plugin to have points to hook into throughout its lifecycle – you’ll inevitably find yourself in a place where knowing the state of your plugin is important due to a project requirement.

Flexslider comes with many, many options, but you don’t need to worry about them until you need them. I’d approach it in the simpler form to start, and add more capabilities when necessary. You can see the Flexslider homepage for more interactive examples.


“the last carousel you’ll ever need”

While probably not the last carousel you’ll ever need, since I learned about Slick it is becoming my new favorite option.

As with Bootstrap and Flexslider, let’s start off by looking at a markup example.

<div id="slick-carousel">
  <div><img src="slide-1.jpg"/></div>
  <div><img src="slide-2.jpg"/></div>
  <div><img src="slide-3.jpg"/></div>

It seems we’re getting progressively simpler. In the case of Slick we have even less to define and even more convention than Flexslider. The conventional Slick setup contains the following pieces.

A container element of some kind. Since we hand the element to the Slick API, it doesn’t really matter what it is, and it doesn’t require any special classes.

div elements to indicate the slides inside. This was something of a strange convention to me since I think of li elements when thinking of slides, but it’s the default. No extra classes required, it just finds the child elements and makes them slides.

After that, we initialize it with a call to the Slick API. We’ll include the dots configuration here to be consistent with Bootstrap and Flexslider (it’s disabled by default).

  dots: true

Again, we have an experience similar to Bootstrap, and now Flexslider – forward and back navigation, responsive sizing and position indicators.

See the Pen Slick Carousel by JP Camara (@jpcamara) on CodePen.

So surely we’re hitting an impass? Bootstrap was ok. Flexslider was alot better. How could Slick be better than what we’ve seen so far?

A Plethora of options

Slick is highly configurable. Not only does it have a lot of options, it also comes with additional functionality that neither Flexslider or Bootstrap offer.

Responsive Display

Flexslider and Bootstrap come with fairly basic responsive capabilities. Bootstrap gets smaller or larger as your shrink or expand your screen size. Flexslider does the same but also offers some variability in the width and margins of its slides, making it seem a bit more responsively flexible. But Slick takes this configuration to a totally different level.

Slick allows you to setup a responsive configuration property, which takes an array of objects defining how it is supposed to behave at any breakpoint you define.

  slidesToShow: 5,
  responsive: [{
    breakpoint: 1024,
    settings: {
      slidesToShow: 3,
      dots: true
  }, {
    breakpoint: 480,
    settings: {
      slidesToShow: 1

In this example, we’re specifying a responsive array that contains an object for each breakpoint where we want a different behavior. Inside the object we define a breakpoint property. Effectively we are creating javascript media queries, and these allow us to change how the Slick carousel behaves at each breakpoint. In this example i’m saying that above 1024, I want to show 5 slides, at 1024 and below I want to show 3 slides and show dots, and at 480 and below I want to show 1 slide with no dots.

Your responsive control is virtually limitless in this case. You have as much control over how your carousel works as you have over how your CSS does. Every option you’ve specified as the base of your Slick carousel can be configured at the different responsive levels.

Drag on Desktop

Sometimes, even in a Desktop browser, you want to drag between images in a carousel. At the time of writing this, the Flexslider folks aren’t particularly interested in that feature, so if you want desktop dragging between carousel items you’re out of luck with them.

With Slick, it’s enabled by default. This may not seem immediately useful, but there are lots of use cases. For one thing, users used to mobile interaction sometimes bleed that mental model into the browser, expecting things to work similarly between the two. Another example would be where you aren’t creating a carousel for the standard “slide through a bunch of images or text” experience – perhaps your carousel is meant to act like a timeline where users can drag between events. In these cases, you have so many features that work for your use case (forward and next, moving to points in the future or past, fluid transitions and good mobile interaction), and all that might remain to you is the desktop dragging behavior. Slick has you covered.

Lazy Loading

Slick also has some support for out of the box lazy loading. It’s a simple setup, and requires a couple additional configuration options.

<div id="slick-carousel">
  <div><img data-lazy="slide-1.jpg"/></div>
  <div><img data-lazy="slide-2.jpg"/></div>
  <div><img data-lazy="slide-3.jpg"/></div>
  lazyLoad: 'ondemand'

Our img tags now have data-lazy data attributes, instead of a src attribute. If you included the src attribute, the image would always load regardless of your intent. This way Slick can pull the attribute out and apply it to src at the appropriate time.

Our Slick initialization now has a lazyLoad option. Supply ‘ondemand’ for it to load the images as you progress through the carousel.

Considering that web page size has been on the rise and 56% of page size tends to come from images – lazy loading is a nice option to have with little to no additional effort.

Digging into Slick

Slick has way more options and features than i’ve mentioned here, so check out the demos it offers for some more impressive functionality. I’ve just offered a few features that i’ve found useful recently – there’s plenty more to try out.


For the angular inclined, here are some options for Slick and Flexslider.




We want to make websites that work great on all devices. We want to be responsive and capable and we want the interaction to be natural. Working with the Bootstrap Carousel our options are limited (by design) and our mobile interaction is bare. We can do better. With Flexslider and Slick we can create a Carousel experience that feels native and responsive to the user.

Have any of your own suggestions? Have a qualm with Carousels in general? Let me know in the comments.

Better Than Bootstrap Javascript: Click Delay

This entry is part 3 of 3 in the series Better Than Bootstrap Javascript

Last week we dug into Javascript Carousels, first analyzing the implementation Bootstrap offers and then examining two alternatives in Flexslider and Slick. We reviewed examples in each and noticed the simplicity of setup as we moved beyond Bootstrap – but that wasn’t enough. Developer productivity and effectiveness is important, but what else did alternatives have to offer?

Ultimately, the user experience was the major differentiator. Flexslider and Slick offered swiping and dragging for navigation, natural animations, and fine tuning for responsive displays. One important differentiator was around user feedback – how the carousel responded to a users tap or click, and the detriment of the click delay.

This weeks post is a bit different in that it’s not specifically comparing a Bootstrap component to an alternative, but comparing the absence of a feature and how you can implement it in your web apps. Let’s get started.

Click delays and the smartphone tap

If you’re an iPhone user, i’d encourage you to visit the Bootstrap website on your phone and tap around on the links and features displayed there. A great example on the phone would be clicking the “hamburger” menu (the three stacked bars you see at the top right corner of the page). You’ll immediately notice the short delay between tapping the menu, and actually seeing the content open or close. Is it loading from the server? Did my action register?


Looking at it in action, it’s not painfully slow. Is there really an issue? Is the perceived latency that big of a deal?

Now go to the Google homepage, and click the menu in the top left corner (again, the same “hamburger” style menu, with three horizontal bars). Here, the reaction is immediate. You tap, and right away it slides open and gives you a scrollable list of pages. Tap it again (now moved to the right) and it immediately slides closed.


The experience on the Google homepage is a clear improvement over that of the Bootstrap site. The Bootstrap responsiveness seemed fine, but then we experience Google’s menu and the Bootstrap interaction feels less natural. The responsiveness of Google’s menu is instant – difficult to distinguish from a native application.

What’s the deal, Bootstrap?

You might be wondering why Bootstrap, being a mobile first framework, wouldn’t take care of something like click delay for you?

I’ve never looked into it specifically, but Bootstrap’s reasons could fall into a few camps – reducing dependencies, inconsistencies between the multitude of platforms Bootstrap tries to support with one codebase, or feeling that browsers will eventually fix the issue for them.

I used to be a jquery mobile user, and their goal is to support as many mobile platforms as humanly possible. They found removing the click delay was problematic while trying to maintain maximum platform support, so they left it as a task for the developer to deal with on a case-by-case basis. Since Bootstrap does the same, it’s up to us to figure out how to approach the issue.

So how can we move ourselves beyond the sluggishness of the Bootstrap site with their click delay to the immediate feedback that we get in the Google example?

Immediate feedback with touch events

The first approach you could take to resolve this might be with touch events. Touch events are fired immediately when a user taps something. Using touchstart, we recognize the users tap and can react right away.

$('.action-button').on('touchstart', function () {
  alert('no click delay');

The problem is that this is only useful for isolated interactions. What about regular pre-existing links on the page – do we apply touchstarts to them all? What if we want to prevent the default behavior and perform a different action when something is clicked? How can we apply this to existing javascript code running on the site without modifying it (for instance, how could we improve the speed of the Bootstrap menu)?

Pretty quickly, the depth of the click delay issue becomes apparent. In principle the solution could be simple, but the reality is that it bleeds into all aspects of your site, and can be inconsistent to implement between browser vendors and devices.

Leveling the playing field with FastClick

The most popular approach available to solve the click delay issue is with a tool called FastClick. They take the issue and approach all of the multitude of scenarios for you, all wrapped up in a very simple API.

Since we’re talking about Bootstrap here, I’ll assume jQuery is available and use it to load FastClick once the DOM is ready. You get a reference to the body element (which can be accessed directly from the document object using the body property), hand it off to FastClick, and you’re good to go.

$(function () {

This is the shotgun blast approach. Everything on your site is now freed of the click delay – buttons, links, click events – all of it. FastClick attaches itself to the touch events that are immediately responsive (similar to what we did with touchstart earlier), and handles the rest for you from there.

Now when you attach a click event to something, the delay is gone. Not only that, but our ability to suppress the default behavior (for instance, a link changing the url of our browser) is also available.

$('.action-button').on('click', function (e) {
  alert('clicked immediately!');

It’s dead simple, and generally it just works.

If we apply FastClick to our Bootstrap example from earlier, we now have the same responsive feel that the Google homepage gave us.


Alternative to FastClick: device-width

You might notice that when I first talked about the issue, I said “If you’re an iPhone user…”. That’s because outside of the iPhone, there are some alternative approaches that browsers and devices take to the click delay.

If you’re on an Android phone, check out the sites I mentioned earlier (Bootstrap and Google) in Chrome. Depending on your Android version, and which provider released it, you may not experience any click delay. This is because some browser vendors have been introducing ways to avoid click delay when your site meets certain criteria. In this case – if you define your viewport as being the width of the device – Chrome on Android will remove the click delay for you.

<meta name="viewport" content="width=device-width">

In general, this is an important setting for mobile-first sites, and a Bootstrap recommendation. Having a width of device-width means your viewport width is based on the device you’re using. So if your site is responsive, and the width of the viewport is device width, you’ll get a display that is better suited to the device.

On Chrome on Android, they piggy back on your viewport setting to mean you don’t need tap-to-zoom, and they remove the click delay for you automatically.

You can read more about this here. That article is also nice because it mentions approaches that apply to Windows Phone as well, which works by a different set of rules from iOS and Android.

Why wouldn’t I always use FastClick?

Learning about FastClick might seem like a good point to stop the discussion, apply it to your site, and call it a day. And in many ways, it could be. If you have a responsive site using Bootstrap and you want to remove click delay across the board, this is the way to go.

There are some warnings here, though. FastClick works really well, but like any project it is continually in development, and it can have issues. New versions of mobile OS’s come out and break things. The browser vendors are not expecting FastClick, they implement their own behavior, and edge cases arise. FastClick meets the browser, meets the rendering and javascript engines, and on the fringes of functionality things can breakdown.

In some cases, FastClick can also impact other plugins. At the time of this writing i’ve had issues personally getting FastClick and Select2 to play well together, and have had to patch FastClick to bypass the issue. This is something that could happen with other libraries as well, who may try to eliminate the click delay issue themselves, or just have some other scenario which ends up conflicting with what FastClick is trying to do.

There’s also the question of whether this user experience matters to you at all. If your site is heavily content driven, and most of the interaction is through clicking links – you may not want to bring in another library just to remove a click delay which only happens as the user intermittently clicks things. Perhaps in this case just manually applying touch events when appropriate is the better approach (for instance, to improve a specific scenario like a carousel, but not to remove it from everything across the board).

The important thing to consider if that FastClick is a tool, and you should weigh the benefit of the tools that you use, and test them on your site. If you’re creating a web experience that needs to give the user a native feel – I’d encourage you to use FastClick. Just make sure you do your due diligence and test your site before pushing it off into production.

Should I always use device-width?

If you’re designing responsive, mobile-first sites using Bootstrap, then you should definitely be setting the device-width on your viewport. But in terms of its impact on click delay be careful, and understand the extent to which it’s available. If you have some sense for what browser or devices you’re deploying to, test to see that it actually works.

I’ve encountered situations where it didn’t work, even when it was supposed to. I had a client with a lower-end Android tablet being deployed to their userbase running Android 4. We were having the client use Chrome and the click delay was supposed to be removed. It wasn’t. Even applying FastClick we still had some work to do – FastClick tries to intelligently disable itself if it detects a browser and device which should have click delay disabled natively. In the end we had to apply a minor patch to FastClick to remove the check for the native feature.

Approaching the problem differently with FastActive

A very different way of approaching click delay is to solve the problem by altering the users perceived performance and offering immediate visual feedback, even if the actual result of the interaction is not immediate. This can be achieved by using the FastActive library.

It applies an .active class to links and inputs, so you can create the appearance that they are reacting immediately (through CSS). This may be an alternative for you if you do not want to risk platform related click issues, and are more concerned with the users perception of performance.


You’ll notice that i’ve talked at length about user perception and interaction in this Bootstrap series so far. This is because despite my love for the web and its potential, the experience of native is compelling and fluid and fast, and the web struggles to compete with this out of the box. More and more people have an expectation of performance, regardless of whether they’re in an app or in their browser. The app experience creates high expectations, and that expectation still remains when using the web. How we deliver on that expectation is through tools and approaches like these.

If approaches like flipboard’s react-canvas are any indication, ios has raised the bar and users are expecting beautiful interactions. Flipboards approach was about flawless animation and scrolling. Click delay wasn’t even discussed in this situation because it’s so basic as to be taken for granted – it’s just not an option. When I hop out of a native app where I can swipe, tap and scroll with ease into a website where I click a link that takes 300ms to register, I feel it. And if your app is trying to compel your users to continuing using it, that may make the difference between them coming back or choosing something more compelling (or ditching the web entirely, and using a native app instead).