This week we established a few depressing things.
- The mobile site is going to have to support IE because Windows Phones use it.
- Zepto doesn’t just not support old IE, it doesn’t work on IE9 and 10 either. This means we can’t rely on it on Mobile.
- Backbone depends on jQuery/Zepto more than we thought.
For the mobile site, we are acutely aware of code efficiency and file size. For this reason we are unwilling to include jQuery on it. This has created a spiral of difficulties for us though this week.
Backbone needs jQuery or Zepto’s document ready function to use Routers. We tried a few home-written alternatives and none of them worked. This wasn’t a huge disaster though because we were already having some difficulty with the Router. Because we weren’t using it entirely as intended – just using it to detect which page we were on and run the relevant script we were finding issues. We are not using it to produce a One Page App. Our architecture still involves speaking to the server through Query Parameters, which the Router was not great at handling. So we came to accept that we were going to have to get rid of the Router.
In doing this, we removed Zepto from the page we were working on and found that this broke our Backbone View. With a little digging we established that the View was indeed using Zepto. It makes sense really, we were perhaps a little naive to think otherwise. Backbone uses a very similar syntax to jQuery for binding events, why wouldn’t it use it?
As an interesting aside, Zepto was not being listed as a dependency to require by the View, but it was being loaded into the page. This meant that our require module had acquired a silent dependency on it. This isn’t wholly surprising but I suspect we’ll do well to remember this is possible in the future.
We saw three reasonable responses to this
- Provide a fallback, so users on IE would download jQuery to replace Zepto. This would make our lives easy but really destroy the experience for Windows Phone users
- Create a custom jQuery build with just the bits Backbone needed and hope it was reasonably sized
- Remove Backbone from the mobile site
Falling back to jQuery
This was lazy-me’s favourite solution, but clearly we weren’t going to do this. Even Windows Phone users deserve to use the site in a reasonable way.
Creating a Custom jQuery
We didn’t look deeply into this. I created a custom jQuery bundle without any extraneous modules and still found it far too big for us. I also tried substituting in Sizzle for jQuery in Backbone. All this did was tell us Backbone Views use more than the selectors from jQuery
Remove Backbone from the mobile site
With the other two out, this is what we’re doing. Now that we’ve made the decision I’m ok with it really. Our brief flirtation with Backbone was good but it was not adding enough value to our site to merit the extra file size. This is not a criticism of Backbone, if our application architecture was different then it would be awesome. But most of its work is already being done by the back end, and the rest we will be able to recreate in a smaller bespoke package and by obeying conventions in our coding.
We may well still use it on the Desktop site though, once we get there.