Since launching the site I’ve been getting quite a few emails. A lot of them are questions about how I built the site, with the most common regarding the HistoryAPI and pushStates.
What library did I use? How did I make it so fast and snappy? Here’s some of the answers.
I actually didn’t use a library for pushStates as my site is pretty simple and only really has two states: the homepage with the horizontal scrolling panels and the article view (which you’re looking at right now). This made it really easy to manage navigation. Also, for browsers that don’t support the HistoryAPI (early versions of IE) I am just doing a page reload rather than messing around with hashes.
I was familiar with using the HistoryAPI from working on the recently relaunched USA Today site but I also found this article a really good summary – it’s a short article and will possibly just reiterate the stuff you already know but it’s worth a read.
I did do a little researching into libraries though and this one definitely seems to be the most popular and if (or maybe when) I go about cleaning up my code and refactoring I might use it. I have plans for a Labs section on my site which will add some routing complexity.
How is my site so snappy and fast to load articles?
Something I found that really helped with keeping the site smooth is preloading adjacent articles. This initially happened by accident as I needed to load the next / previous articles in order to find out the background color for the left / right arrows. I guess preloading depends on the site design and UX. It lends itself really well to my site as I can easily predict the content that a user is likely to view next.
If you’re going to add preloading to your site plan it carefully. I personally don’t like it when a site aggressively loads stuff that I might not view. You also don’t want to delay the user from getting to the content they are initially on your site for. Below is the flow for how content loads on this site.
If you arrive at the site on the homepage:
- Load the homepage
- When a user selects an article load that article and display it once it’s loaded
- Now the user has the article and can start reading it, let’s preload the next and previous articles (they won’t even notice, they’re busy reading the article)
- If a user clicks the next / previous arrows on the article view we already have it loaded so BOOM we can show it instantly
- Repeat step 3
It’s similar to when a user deeplinks to an article:
- Load the article
- Again, now the user has the article and can start reading it let’s preload the next / previous articles
- If the user clicks the close or logo to navigate to the homepage we’ll then (and only then) load the homepage
So in conclusion
In conclusion I didn’t use many libraries for this site. I used JQuery for obvious reasons. I used a couple of JQuery plugins like jquery-mousewheel and I also used Underscore.js.
The decision to not use many libraries was a conscience one. I only started really getting into heavy JavaScript development about a year ago. Prior to that I was spending most my working days writing ActionScript (I haven’t done any Flash work for over a year but that’s another blog post). I wanted to use vanilla JavaScript for stuff like the HistoryAPI to make sure I fully understood how it worked. It’s all very well using libraries, and I use them day to day on sites I build at work, but I think it’s sometimes good to get a full (or at least a mild) understanding of what the library is doing. For this reason I decided to not rely too heavily on libraries.
I guess another reason is that I grossly underestimated how much JavaScript would be required for this site. I did most the development late in the evenings after working all day. I’ll admit I didn’t plan it very well and that’s why the code is a bit of a mess. I plan to clean it up one day though and then maybe I’ll even release this site as a WordPress theme for others to enjoy. Addy Osmani summed it up brilliantly in a recent tweet:
That’s the way this site was built. I just wanted to get something out there and I’m pleased I did. I still have work to do though, there’s still bugs but I’ll get there soon.
I’m not sure if it’ll work (depends how you’re doing your preloading), but were you aware of link prefetching? The browser already has this capability 🙂 Providing the target for preload is accessible via url it should work. See this article on MDN: https://developer.mozilla.org/en/docs/Link_prefetching_FAQ
24 Apr 2013Hey Jonas. Not to my knowledge but there might be something out there. Try checking out microjs.com – good luck!
16 Apr 2013Is there a jquery plugin somewhere that do the preloading-next-page-stuff you describe?
15 Apr 2013+1 to learning how things work without libraries first (the hard way?) – I always like to know at least vaguely how plugins / libraries / frameworks are working behind the scenes.
Also +1 to chrome sniffer, love that extension. Another good one is a humans.txt, works in a similar way.
3 Apr 2013A simple way of checking what libraries are used on a site is the Chrome Sniffer Extension (https://chrome.google.com/webstore/detail/chrome-sniffer/homgcnaoacgigpkkljjjekpignblkeae). It adds a small button to the URL-bar which shows you which CMS was used and a whole lot of other scripts and libraries like Backbonejs, JQuery, JQueryUI, Modernizr, …
26 Mar 2013