That looks odd...

Recently, we have been transferring some of our client’s web apps from an Adobe ColdFusion(ACF)/Windows stack to a Railo/Nginx/Ubuntu stack. Along the way, we’ve experienced the usual collection of surprises involved with any transition between flavors of ColdFusion – as well as the change from a Windows environment to a Linux one. Early last week, I was testing out one of the apps in our collection and I noticed an odd visual difference. The Railo version was missing the tabs (a JavaScript, not a ColdFusion item) and the Adobe ColdFusion version was not. In fact, the tabs were working perfectly on the ACF stack. Now, since the tabs are not a ColdFusion implementation (they’re ran by a JavaScript library) I was initially confused as to why these two stacks were handling JavaScript differently.

JSMin FTW!

One of Luis Majano’s cool tools is a JSMin compressor. Like most things that Luis makes, his JSMin compressor has a variety of options and customizations that appeal to developers with different needs and styles. It can also be used in a variety of ways, making it quite a handy tool. For our purposes, we were specifically taking the locally stored JavaScript and CSS files, compressing them together and storing them as a cached file for our application. This is very handy because it cuts down on the number of includes that the application has to load and reduces the amount of traffic between the client and the application server. For applications that manage moderate to heavy traffic, features like this are essential.

Where did my JavaScript go?

After some more poking around, I realized that I was missing at least one of my JavaScript files. So I went into Chrome’s DevTools and started analyzing my script files. Embedded between two of my JSMin compressed files was this:

3 question marks

This was curious. Clearly whatever this ‘???’ was, my app couldn’t interpret.

The app was presently running on the Railo/Nginx/Ubuntu stack, so out of curiosity and good practice, I switched over to the ACF/Windows stack to see what I’d find. I found this:

Byte Order Mark symbols

Much better! At least now I have something to work with. Also, with this symbol combo () in the cached JavaScript file, all my JavaScript worked. The Dev Tools interpreted "" as "\ufeff", essentially a space.

Turns out that this symbol combination () is the infamous BOM (Byte Order Mark). Some Googling revealed its purpose and place in the computer science world. It also exposed that the BOM can create problems in a variety of environments. The solution was simple: all I had to do was open the file in a good text editor and re-encode the file with it, removing the BOM. This is not possible in all text editors, but most modern versions have an encoding feature in them.

Removing the BOM

I use Sublime 2, so this is the process that I used:

  1. Opened the file that the BOM preceded (the file that followed the BOM in the JSMin compression)

  2. Went to the File menu option in the top left of Sublime Text Editor

  3. Put my mouse cursor over the ‘Save with Endoding’ option

  4. Selected ‘UTF-8’. This removed the BOM from the file

This is the Save with Encoding option in Sublime Text 2

Below The Surface

One of the things I questioned in this process was the purpose of the BOM, aside from causing me this particular pain. There are a variety of articles available on the topic, including the Wikipedia page I noted earlier and this one.

The short story is this: there was a period before HTML5 standards in which a variety of encodings for files were being used simultaneously in the browser environment. To help browsers understand what they were working with, the BOM was invented as a marker to announce which encoding each file was written in. There is, of course, much more to this. But that is the short story. The good news is that in a closed environment, (e.g. in our own app, using it to compress our local JavaScript files), we don’t need the BOM. That is why we can remove it before using JSMin compression.

Takeaway

So, the takeaway from all of this is that we can use JSMin to conveniently compress our JavaScript files into a locally stored file in our application’s cache. This will ease traffic between our server and the client and make our apps more efficient. All we need to do is clean up our local files BOMs (via reencoding on save) to ensure that it runs smoothly in a variety of ColdFusion environments.