Which browsers do I support?

December 20, 2014

This is one question that you cannot simply ask a product manager or a developer.

Product managers want to achieve the greatest customer coverage and it’s natural for them to choose to support, if possible, all browsers.

Developers want to use the most cutting edge technologies and they do not want legacy code to support the older browsers.

Each time this question is posed, the two groups frown at each other’s decisions. I generally go with supporting the latest 2 versions of Safari, Firefox, Chrome and Internet Explorer. That means I support Internet Explorer 10 and 11 only, and once Internet Explorer 12 is released, I drop support for Internet Explorer 10.

Faster testing

There’s significant test effort involved in testing over multiple browsers and if we need a product to ship fast, we need to work to simplify the implementation process. Let the QA testers have lesser to test so more features can be tested. Modern day browsers are more closely aligned, the chance of CSS not working is lower.

Faster development

Developers benefit from having to write lesser code, more importantly, they maintain lesser code. I can’t reiterate the hidden effort of having the maintain the code that is written. Code don’t just stay there are work for till the end of product lifeline; it needs to be kept up to date to the latest browser. Having legacy code coexist with current code requires developers to be really disciplined in maintaining.

Smaller file delivery size

Supporting lesser browsers mean cutting out the legacy code. This point is harder to sell to product managers because developers cannot answer how much larger will the JavaScript file be if a legacy browser is supported. It’s even less convincing to convey that the 30 kilobytes you save makes the app JavaScript download 20 ms faster.

What about customers who are using an old browser

Customers are important. We need to identify the customer that is using the older browser.

The questions to ask are:

  1. Can we afford to lose the customer to make product development go faster?
  2. Can we help the customer with upgrading to browser that is more modern?

If the answer to question 1 is a straight no, you may need to reconsider dropping support your customer’s favorite browser. To gently push the customer to upgrade, one way is to invite them to upgrade to use the newer features. For example, the product team plan for a new Live Analytics page, you can make that exclusive to modern browsers and urge your customers to upgrade. This way you can support the customer through the upgrade path while implementing the feature quicker.

Removing a class in an element

December 20, 2014

Isn’t it common to remove class from HTML? For example, I want to remove the class “foo”.

Removing class through jQuery:

To do this in JavaScript, you will need:

  1. Select the ID “mydiv”
  2. Get the class list of the selected element
  3. Remove the class “foo”

Let’s do this one by one.

1. Select the ID “mydiv”

There are many ways to select #mydiv. The most straightforward one will be:

If you prefer something more like jQuery, there is the document query selector that allows you to use a CSS-based syntax, similar to what jQuery lets you do:

2. Get the class list of the selected element

This is support by all modern browsers, including Internet Explorer 10.0. If you’re in the unfortunate situation of developing for Internet Explorer 9.0, you will need a shim (get it from Mozilla).

classList returns a token list of the class attribute of the element. It contains methods such as

  • add – Adds a class to an element’s list of classes. If class already exists in the element’s list of classes, it will not add the class again.
  • remove – Removes a class from an element’s list of classes. If class does not exist in the element’s list of classes, it will not throw an error or exception.
  • toggle – Toggles the existence of a class in an element’s list of classes
  • contains – Checks if an element’s list of classes contains a specific class

3. Remove the class “foo”

Now we can remove the class “foo” easily.

When to use jQuery and when not to?

Compare this jQuery solution:

to the vanilla JavaScript solution:

It’s obvious that jQuery is a lot more concise here. In most cases, jQuery’s shorter way is easier to read and understand, and if you’re adopting the jQuery library, you should go ahead to use jQuery’s solution. You do not need to worry on Internet Explorer 9.0 support as well.

However, the vanilla JavaScript solution has a significant performance benefit (unsurprisingly). You should consider using the non-jQuery solution in areas where it is within a loop. For example, if you need to loop through a set of table rows and adding or removing classes over many rows, the performance gained starts to become obvious.

In my organization, we encourage the usage of jQuery to get the nice benefits of chaining and the solution is often less alien to newer developers. It does look cleaner and more consistent with the larger part of our codebase. However we need to be mindful of performance tradeoffs when using jQuery; remember that performance matters most to users.

Slight change of directions

October 26, 2014

Previously I wanted JavaScript.sg to be more of a post-based blog of my every day development work however it may not be relevant to much people. I started to give more thought how this blog can be more relevant and also receive more organic visitors.

A few things I deem as important:

  1. Code quality and syntax highlighting
    Syntax highlighting previously just isn’t there. It makes things harder to read. This is corrected. Code are reduced to be more concise now.
  2. More lists
    Lists are always easier to maintain and it suits my work style. Typically I grow an article over time and it was looking like a list before it becomes a full article.
  3. Less of a blog, more of a magazine
    I’ll be queuing more posts rather than just publishing randomly from 2015.
  4. Better indexing by search engines
    I want search engines to be able to locate my articles better. That means a better set of maintained tags.

Other nice-to-haves:

  1. Twitter shares
    I want people to share my articles on Twitter. Perhaps a share button would be good although the previous time I have that, almost nobody clicks on them.

Useful gulp plugins

October 26, 2014

gulp-sourcemaps

If you use uglify, you probably would find gulp-uglify most useful. But what if you want to have sourcemaps, then gulp-sourcemaps is what you need.

gulp-newer

gulp-newer is a useful gulp plugin. Currently my work involves 30+ images to be compressed. This means each time the imagemin command is ran, it goes through all 30+ images and attempts a compression again.

The final leg

August 28, 2014

This can’t be more true:

“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”
–Tom Cargill, Bell Labs

In order to mitigate this, I used to multiply my effort by two.

Things I look out for that could potentially derail the development time:

  1. Number of points of integration
    This may sound obvious but we often forget that tasks cannot always happen concurrently, it’s a lot of waiting in between. The time coworkers take to finish varies and they may themselves underestimate or overestimate the complexity of their parts.
  2. Interfacing format definition
    If it is going to be JSON, it’s great but remember to come up with the data structures early. Usually if my counterpart is someone I am familiar with, I do roughly know what to expect from him or her. Make sure everyone encodes and decodes at their own end.
  3. Uncertainty of task
    For work that is highly exploratory especially, it’s important to add sufficient overheads.

Integrating docker.js with Gulp.js

August 19, 2014

Docker is a documentation generator built on the foundations of Docco and Docco-Husky.

In this example, Docker.js is integrated with Gulp.

This file is gulp-docker.js.

Usage:

Using Uglify’s screw-ie8 option

August 18, 2014

By default UglifyJS will try 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.

You can run

If you’re using Grunt, check out the grunt-contrib-uglify package.

Example usage:

At my work, we recently were given the option not to support IE8 and I’ve been removing my IE8 hacks since.

Using Jade

August 18, 2014

If you haven’t already used Jade, you should give it a go here.

Jade is a templating language that’s well suited for Node.js projects. It’s less verbose, supports inheritance for templates and have blocks. Through this Jade promotes reuse.

My only grip with Jade is you always have to keep declaring the template you extend from. I wish this could be defaulted somehow.

Example of Jade:

Example output in HTML:

Another useful resource to convert HTML to Jade is Html2Jade which I use to convert much of Bootstrap examples to Jade for easy incorporation into my work.

The mustache-spec languages

August 18, 2014

Interesting background on Mustache.rb in Jan Lehnardt’s blog on why Twitter wrote Hogan.js:

Around the same time Twitter started using mustache.js in the frontend and it was a great honour. But they too preferred a proper parser/compiler implementation so @fat & team went ahead and wrote Hogan, a mustache.js-compatible implementation with a faster load and runtime. @fat talked about this at his 2012 JSConf US talk, he got asked why he didn’t submit a pull request to mustache.js instead of making a new project. He said that a Pull Request that consists of “Hey, I threw away all your code and replaced it with mine” isn’t such a good idea. I agree, it wouldn’t have left the best impression.

Mustache has grew to become one of the most used templating languages, thanks to its expressiveness and simplicity. Designers especially love it.

JavaScript templating engines such as Hogan.js, Underscore, handlebars and Angular are using the mustache spec in one way or another.

Talk on identity and cookies

August 18, 2014

I gave a talk regarding identifying users without cookies.

Today, cookies are harder to use for tracking purposes for analytics companies. One of the major usages that come up from cookie tracking is behavioral targeting. In advertising terms, behavioral targeting is about tracking what pages the user is visiting and building a profile of what kind of advertisements would interest the user.

However, we also learnt that one-in-three web users delete their cookies in a month. This reduces the capability of this technique.

Ignoring the obvious social aspects tracking, I wanted to delve into how to track users without cookies — by fingerprinting.

Here’s my deck:

If you’re interested, you can take a look or contact me at t@kw.sg to learn more.

Disclaimer

I work as a web UI (frontend) developer in Singapore for a video advertising trafficking and analytics company Tremor Video.

%d bloggers like this: