Proliferation of Javascript libraries and bad start to the year

Ah, good old O'Reilly Rhino
Ah, good old O’Reilly Rhino

As a front-end developer, I can’t help but notice all the innovation going on. Especially compared to the backend, I feel that front end technologies these days are developing at quite a rapid pace. In particular, the areas of HTML, CSS and JavaScript.

HTML5 has of course been the hot technology as of late, which I regret not using more HTML5, because my company has to support legacy browsers like IE6/7 (which of course cannot support HTML5).
“But Tong, why don’t you use Modernizr or another shim to take advantage of graceful degradation?”
Well, the fact is that we are lazy, so we don’t want to rewrite a lot of our code for graceful degradation / progressive enhancement. And I’ve also noticed new templating technologies such as HAML, Jinja, JST, Mustache, and Handlebars, which uses JS to compile Handlebars templates, which itself is built on top of Mustache.

Another area is CSS. Of course my company can’t use CSS3 for much of the same reason as HTML5; support for legacy browsers. Take note that like HTML5, CSS3 is continually expanding and browser support is very inconsistent (so just look to W3C for guidance for now). However, there is also much innovation in the realm of styling as well. There’s LESS, which extends CSS with variables, mixins, operations and functions, much like a scripting language, and SASS, which adds much of the same things. Then we have frameworks that build on top of LESS/SASS, like Compass.
Notice how alot of new technologies are themselves improved or extended by even newer technologies, and so forth.

Nowhere is this more evident than in JavaScript. A little bit of history: Netscape originally developed JavaScript to be a lightweight interpreted language for amateurs (ie. users of VB). They named it JavaScript to take advantage of Java’s popularity, not that the two languages share anything in common. It was very popular, and because Microsoft had their own standards of the language, it wasn’t standardized until the late 90s into ECMAScript. In the late 90s/early 2000s, JS was mainly used for light scripting events such as submitting forms, animating icons, etc. It wasn’t until DHTML and AJAX came about that JS really started to take off, especially with professional programmers.

Hence, where we are at now. Ajax took off, and JS libraries (some may say polyfills) came out that significantly expanded JS’s use in everyday browser scripting. My company uses Prototype.js and Scriptaculous for UI. And certainly there were other popular libraries at the time like MooTools, and widget libraries like Dojo and YUI.

But the most popular JS library that came out in 2006 that really started web 2.0 computing was jQuery. Every web developer knows it, and 91% of websites probably use it. Jquery made ajax applications and dynamic application scripting as easy as cake. Hence my point now is that 90% of libraries today is built on top of, using, or extending jquery. It’s so ubiquitous. Want some boilerplate for your code? Bootstrap uses it. Want to add some structure to your single page app? Backbone.js uses it. How about mobile? Well jQuery mobile has got you covered. And jQueryUI has most of your UI needs down. jQuery has become a foundation of modern JS frameworks and libraries.

And now you can pretty much build your entire app, full stack, using only JavaScript. Rails developers can be more productive using CoffeeScript and Batman.js. BackboneJS, AngularJS and EmberJS have got you covered on your client side MVC needs. Need a utility library without Prototype.js’s namespace interference and object pollution? UnderscoreJS is there (while also being a dependency for Backbone). Modular JS components? RequireJS is there. Making vector graphics? Sure, RaphaelJS is there. UI widgets? How about Google Closure, jQueryUI, ExtJS, or the aforementioned YUI? Maps? Yup, LeafletJS handles that. Need just CSS selectors? SizzleJS does that. What about media overlays? Yes we have both ShadowboxJS and LightboxJS on each side of the force. In fact you can even build server side JS using NodeJS and SocketIO, as well as frameworks building on top of those, like ExpressJS. Mobile browsers? How about ZeptoJS, Dojo Mobile, or the aforementioned jQuery mobile? Or how about giving me a full stack framework like Meteor? And yes, JS can even compile templates on the client side without being horrible slow using Handlebars and JST. Unit testing frameworks similar to server side programming languages have appeared for JS, such as Qunit and Jasmine, themselves written in JS. And yes, there’s even JS Dependency Injection.

All this to show that, there are way too many JS libraries out there. Not that its a bad thing, but it seems to have exploded recently. Backbone.js wasn’t released that long ago, and there’s already extensions like Backpack.js and MarionetteJS built on top of Backbone, which itself is built on top of jQuery, which itself is written in native JS. My concern is that modern front end devs are forgetting the important foundations of JavaScript and the native JS API, when they are using all these libraries which seem too magical and obfuscate how JS works. We used to DOM-script, now we have two way data bindings, which do updating and ajax calls for you. Soon, front end devs won’t even know what an ActiveX object is, or how to handle IE specific bugs, because its all done in the background. And its all happening a bit fast… what might be the hot library of today might be the legacy library of tomorrow… my company experienced this first hand using prototype.js… which at the time was as popular as jquery but now is used by less and less websites. This makes it all difficult for front-end devs to absorb, which libraries are considered the front-runners and will be viable in the future. Who knows? It’s a concern I have…

HTML validation
Thanks to my friend Chris (the Polish juggernaut) for this tip:
[Unix commands] use xmllint –html *.html to check if your html document is well formed, but use tidy *.html for full on HTML validation. Little known unix commands, but useful.

Other news
And in other news, I’ve been having a terrible year so far, compared to last year. So far, in just January alone, I had:

-At the very start of the year, the power on my Mac went out and all the pictures I took in San Diego on the Mac guest account were deleted and cannot be recovered (this is a “feature” of unix guest accounts and works differently than windows guest accounts).
-alot of my good Korean friends went back to Korea.
-lost 6k in stock market options (each time the market went the other direction – go figure)
-pay $1340 in parking fines and traffic fines (because I had high beams on? geez)
-had to come in late for work or missing from work many times due to the stress of my new apartment, mortgage loans, escrow, new bank, etc.
-Didn’t get internet for two weeks due to no cable wiring
-Didn’t have electricity in the living room for two weeks due to faulty circuit breaker.
-Toilet cannot flush – now have to use the lobby restroom until a repairman fixes it.
-washer and dryer doesn’t work – all my clothes come out smelly and unwashed
-After doing tax returns, found out I owe the government $2600 in taxes.. ugh…

So yeah. In one month, I had more bad news that all of last year. Happy year of the snake.


Startup Weekend San Francisco 2012

Wow what a weekend it has been. I attended Startup Weekend SF, the second SW I’ve been to, and it was a blast.

Edit: Apparently this is the app that won at Startup Weekend Google. Similar idea, different name? Interesting.

Team SplitMyTab
Team SplitMyTab

My team consisted of me (the frontend engineer), a designer, a business person and two backend engineers. Our App idea was called SplitMyTab, which helps people with all the trouble of calculating and figuring our their restaurant bills when tips, tax, credit cards, and cash all give people headaches when they split the bill. As you can see, we actually won honorable mentions in the competition for good storytelling and customer validation (as well as a free year of SendGrid service), hence the medal :).

App details
While the idea was simple, the app was actually difficult to implement. When the app is loaded, it asks you to take a picture of the bill using the camera. This part required iOS and native functionality. After this, our image OCR algorithm done in Python processes the image and extracts the data out and sends it to our Ruby on rails service, which stores it. The Ruby service uses templating along with Bootstrap and jQuery Mobile to display the web/mobile site.

Since I was the front end engineer, I was in charge of doing the web/mobile stuff. So I used HTML5 Boilerplate (I could’ve also used Bootstrap) and jQuery Mobile, along with jQuery UI and Backbone.js to support the JS animations and structure, respectively.

So initially we thought about using the phone’s contacts / numbers as a way to tell users what they owe, using PhoneGap or iOS to access native features, and Twilio for SMS, but turns out no one really knew PhoneGap or Objective C, and not enough time to figure out in one weekend.

So, we decided to go with Facebook API to message/email people.

Initial screen
Initial screen

We force users to login to Facebook on the initial page, with the photo that they’ve taken shown, and assuming that the image data from the receipt is available. Then we land on the calculate totals page, which calculates the total of the bill including tips that you enter. There’s also an autocomplete which pulls from your facebook friends list, who we assume you are eating with.

Calculate totals page
Calculate totals page

After that, we go to the final page, which is the page where we calculate who ate what and what the final totals were.

Receipt Totals Page
Receipt Totals Page

And after you confirm, it sends a message to all your facebook friends who ate with you telling them how much they owe you.

First, technology decisions. I chose jQuery Mobile over Sencha because it relies all on HTML5 page-roles and semantics, which is really nice and easy to learn, whereas Sencha has a learning curve. I used Backbone.js over AngularJS because Angular would’ve required more time to learn the syntax.

Interesting issues:
1) We couldn’t figure out a good mechanism in time for the Python program to communicate with our Rails server.
2) I figured out too late that jQuery mobile has quirks with dynamically inserted html, and should’ve used Ruby templating instead. I don’t know any Ruby so I had to work with just HTML5 without any templating engine like PHP/Rails.
3) jQuery mobile apparently doesn’t execute all the JS after an Ajax form submission. Actually, all of its page changes uses Ajax.
4) jQuery mobile fires its mobile initializing way before the document is ready, this causes problems with dynamically generated DOM elements.
5) Facebook API apparently deprecated its legacy REST API, and its Graph API doesn’t have a good way to message or email friends.
6) jQuery mobile apparently doesn’t play nicely with jQuery UI.
7) jQuery mobile also doesn’t like it when you put custom JS page init events in the main data-role=page div.
8) Always JSON stringify / parse objects when storing and retrieving from localStorage
9) DOM elements from a jQuery array are not jQuery objects themselves and have to be re-wrapped in a jQuery selector. This differs from Prototype.js which always wraps each sub-element in its selector.
10) Facebook API has terrible documentation. Seriously.

So yeah, I learned alot of interesting quirks about jQuery Mobile and Facebook API over the weekend. Next time, maybe I’ll try a different mobile framework, and use Zepto.js instead, a lighter weight jQuery alternative. And try using AngularJS, because Backbone requires a lot of boilerplate code to be written, though I like its use of MVC and SoC patterns. And yes, I’ll consider looking into SASS, Node.js, and CoffeeScript (there’s too much stuff to learn blah). Overall I learned a lot, which is all I really wanted to get out of these events anyway. Take a break from CFM (coldfusion) and FTL (freemarker) for a while.

Where’s the app code?
Relax, the Github repo is here, and the prototype mobile site I’ve built is here (it’s not fully functional because of the jQuery mobile quirks).