Links

• View in HD on YouTube
• Slides
• Full YUIConf 2011 Playlist on YouTube

The code we write powers features on other peoples’ pages, meaning we’re in the unenviable position of having not only no control over the browser environment, but heavy restrictions in how we use the document itself. Our customers put a Quorus bootstrap script on their pages; everything else needed for our functionality is loaded dynamically and on demand. We go to heroic lengths to make sure that our elements, styles, and scripts do not alter the behavior of anything we’re not responsible for.

We started our present code base two years ago, when YUI 3 was just taking shape. It was a risky decision at the time to commit to a codebase that wouldn’t hit beta for several months. In retrospect I can’t imagine how we would have accomplished what we have without it. I haven’t seen any other framework that has components approaching the power of Loader, Attribute, and CustomEvent.

The Quorus bootstrap script we provide to our customers does almost nothing. Its job is just to load the core of our platform without blocking the rest of page load, and to queue any API calls until we’ve done so. This core script file, called stage2, inlines yui, loader, and oop, as well as enough smarts to load additional libraries to respond to API calls, user clicks, and other conditions in the operating environment. Most other resources are served by a custom combo server that serves custom Quorus and stock YUI modules.

Bootstrap queues up API calls made in the host site’s code between when it loads and when we’re ready to go in an array on our global object, QUORUS:

QUORUS._callbacks = [];
QUORUS.use = function () {
  // turn the arguments object into a regular array,
  // so that it can be stored safely
  var args = Array.prototype.slice.call(arguments, 0);
  QUORUS._callbacks.push(args);
};

Once we’re ready to process API calls, stage2 runs them one by one in timeouts. This ensures we yield control regularly back to the browser, which makes the user experience more responsive. The behavior is a lot like Y.AsyncQueue, but simpler and doesn’t require YUI to be loaded:

// Put the real 'use' function in place for any subsequent calls:
QUORUS.use = function (feature, callback) {
  YUI.use('module-that-provides-the-feature', function (Y) {
    // find the API for the requested feature, and pass it to the callback
    callback(Y.APIs[feature]);
    // process another pending API call, if any:
    setTimeout(processAPICall, 0);
  });
};

// Play catch-up, running each callback in sequence:
function processAPICall () {
  var callback = QUORUS._callbacks.shift();
  if (callback) {
    QUORUS.use.apply(QUORUS, callback);
  }
}

// Start processing the queue:
processAPICall();

The bootstrap file is, by this point, mostly immutable: it’s something we hand off to a customer, who might require a month or more to deploy any new version we gave them—an impossibly long time for an agile startup company. The stage2 file, meanwhile, is small, loads from our own servers, and has a short cache lifetime. This ensures that no end user will have an old version for more than a few minutes. Nearly all the other resources we need are in permanently cacheable JavaScript libraries and CSS files.

When we release a new version of our code, stage2 automatically directs browsers to start downloading from a new location, ensuring that they use only the newest code. This setup allows us to deploy changes quickly without serving up assets more often than necessary. Not only does this keep our bandwidth costs low, but it provides a better user experience: the cached resources load very quickly while the page is loading.

If we were starting our codebase today, with the benefit of the YUI Gallery, there are a number of components we might use to make our lives easier. One of them is Eric Ferraiuolo’s Base Component Manager, which assists with wiring up components (typically Widgets) on demand. Another might be Storage Lite, to help us retain application state across page loads.

Many thanks to the YUI team for their great work, and to the community for their contributions. If you would like to read about our approaches to sandboxing or to coordinating asynchronously loaded components, please let me know in the comments!

About the author: Peter Abrahamsen writes Ruby and JavaScript, manages server infrastructure, and studies user-centered design in Seattle, Washington, USA. He can be found on IRC as Rainhead.

While finishing up the Boxee app we stumbled on the Samsung TV platform and the timing was perfect because they are actually running a “Free the TV” challenge. We came across the contest pretty late in the game and nearly missed the submission deadline, but we pushed hard and successfully recreated the same experience for Samsung in short order. If you have a few minutes please vote/help spread the word about our YUI Theater submission for Samsung – http://www.freethetvchallenge.com/submissions/249. We’ve got 50+ other entries to beat.

Last, but not least — we also just recently completed work on a YUI Theater app for Plex. It isn’t in the official application repository yet, but the request is in. In the meantime you can download it from here if you’d like — http://wiki.plexapp.com/index.php/YahooYUITheater.

Here are a few videos of the applications in action:

• Samsung TV app – http://www.youtube.com/watch?v=e1kRicivfDU
• Plex app – http://www.youtube.com/watch?v=oxBPqVQqdnY
• Boxee app – http://www.youtube.com/watch?v=IK4i1DksuhU

You should expect to see similar efforts for Google TV and Yahoo! Connected TV in the not so distant future as well.

Hopefully these apps prove to be valuable resources for those that can’t typically attend the meetups and/or didn’t make the latest YUIConf. We’ll continue to add new videos as they are released.

Overview

The project involved the refactoring of several disparate Flash tools into a single interactive application based on open standards for a large content publisher. Of high importance, the application had to be highly optimised with a small initial foot print due the large number of daily page impressions the client receives. Several phases were involved, with the first being an initial proof of concept.

The concept involved the development of one view of what would be the completed application. It consisted of:

• An initial seed file (< 1KB) responsible for the dynamic loading of any frameworks (e.g., jQuery or YUI 3) and the initial application file.
• The development and inclusion of jQuery plugins to support form element styling and validation, and dynamic chart visualisations.
• The generation and population of UI, based on user inputs, configuration defaults and the application’s location within the publisher’s site.
• The calculation and presentation of information based on the user’s input.

In the interest of full disclosure, my own experience up to this point had been in developing small, standalone solutions, the type of which you could typically describe as plugins. These included dynamic UI components such as image carousels, interactive maps and Twitter / Flickr widgets. At the time of first dabbling with JavaScript, jQuery was popular, easy to learn and allowed me to quickly pick up the basics needed for the projects I was working on. However these were all standalone units and had no need to interact with other code or as part of a larger application.

First Attempt

On completing the first phase of the project, it became painfully obvious that I was dealing with a very different beast than what I was used to. Having had little experience in code organisation, my code quickly became disorganised, inefficient and repetitive. As a result, the first part of what would become a much larger application was slow to load. In fact it took eight seconds to generate that single proof of concept. A big change was needed and while I had considered using a small library like Dean Edward’s Base or John Resig’s Simple JavaScript Inheritance pattern to add class-based inheritance to jQuery, I decided to go one step further.

What I wanted was a complete, mature framework within which to develop my first OO application. Something that would effectively guide me through the process. In reviewing the available libraries I decided to adopt YUI 3 for the following reasons:

• Integrated, inheritance-based application development support including attribute and class management.
• Long term solution:
  • Support for standards and accessibility.
  • Funded by a large well known organisation, Yahoo!
  • Associated with respected names like Douglas Crockford, Nicholas Zakas, and Stoyan Stefanov.
• Performance optimisation:
  • Initial seed file of only 7KB.
  • Lazy-loaded modules on demand.
  • CDN delivery.
• Varied and comprehensive documentation:
  • Yahoo! Developer Network
  • YUI 3 API Documentation
  • YUI Theater
  • YUI Library
  • YUI Blog
• Mature, consistent evolution between releases.
• Integrated tools in YUI Compressor, YUIDoc, YUI Builder, and Console.
• Not just JavaScript, a CSS framework too.

Take Two

Integrating YUI 3 brought several direct and indirect benefits to the project:

• Inheritance-based architecture and class management through the Attribute interface, and Base and Widget classes producing performant, reusable and organised code.
• Separation of presentation from model and data using the Widget class to render alternate views (inline or overlay) based on the application’s location within the site.
• Sandboxing and dynamic module inclusion through YUI.use().
• Cross-browser console debugging using YUI Console.
• On save, performance optimisation using YUI Compressor in Eclipse.
• Easy inclusion and integration of pre-existing jQuery plugins.
• On save, automated code documentation using YUIDoc.

The final result was a happy client and a finished product with sub-second load times (remembering it took 8 seconds to load the initial proof of concept).

Lessons Learned

Select the right tool for the job

In reading this post I’m sure some readers will view this as anti-jQuery. Not at all. jQuery is a fantastic project responsible for many innovations. But, as with any tool, it has its strengths and an intended purpose. Its strength lies in normalising browser inconsistencies, lowering the barrier to entry for the novice and improving the efficiency of experienced programmers. The primary learning that came out of the project was that you can’t rely on one tool for every job. YUI builds on what jQuery can provide by also offering a well architected application framework. But it’s fair to say that it comes at a cost, see the next point.

Steep learning curve

You need patience, especially when writing your very first application with an unfamiliar library as I did. However the payoff is immense. By learning another library, not only will your core JavaScript skills improve, you’ll also develop a deeper understanding of how libraries work and the benefits they bring. I try to learn something new about YUI everyday and the more I learn, the more I’m in awe of the thought and sheer talent that’s gone into building YUI.

Only load content when you need it

While it’s certainly programmatically easier to just to load everything you may need upfront, the performance improvements gained as a direct result of lazy loading content only when you need it is huge. This was one of the key contributing factors for drastically improving the performance of the application.

Interact with the DOM as little as possible

This point doesn’t relate to the specific library used. By caching the required DOM elements and utilising HTML templates more, UI rendering time fell considerably. Nodes can be cached using Y.one() while node lists can be captured using Y.all(). Also Y.Node.create() was very useful in efficiently converting large text strings of HTML to DOM elements prior to insertion.

Learn by example, use a CDN

In using YUI’s CDN delivered library we decided to deliver all the project’s assets via CDN. This was probably the next largest contributing factor to the performance improvement.

Pub, sub hubbub

For those experienced programmers out there, try not to laugh at this one. Having been used to writing little more than plugins in the past, I had no idea how applications should communicate internally. Even after reading “Custom Events allow you to publish the interesting moments or events in your own code so that other components on the page can subscribe to those events and respond to them,” I still missed it.

As it turns out, YUI’s custom event publish-and-subscribe model works beautifully for inter-class and inter-object communication. You can even subscribe pre and post to events and include dynamic logic to suppress bubbling based on certain conditions.

Integrate best practice into your workflow

Using Eclipse we were able to integrate JSLint and YUI Compressor into the build process. Put simply, every time you hit Ctrl / Cmd + S your JavaScript code is validated and optimised. That means you’re testing against optimised, production grade code from the very first line of code. It also means that you won’t forget to optimise in the frantic final race to the delivery deadline.

Learning YUI on the Job

Although everyone has a different learning style, I thought I’d share what resources I used to learn YUI with a specific objective in mind.

• Watch the relevant YUI Theater episodes to get a general overview of the library or learn a specific module. I can highly recommend starting with:
  • Eric Miraglia’s Welcome to YUI 3
  • Todd Kloots on YUI 3 Sugar
  • Matt Sweeney’s YUI 3 Performance
  • Luke Smith’s Debugging in YUI 3
  • Isaac Schlueter on Solving Problems with YUI 3
  • Eric Ferraiuolo on Web App Development with YUI 3
  • Luke Smith’s Events Evolved
• Read up on YUI on the Yahoo! Developer Network. I try to read a little bit every week and learn more each time I re-read it.
• Read the API documentation. If you can’t find it on YUI Theater or on the Developer Network, dig into the API. It even pays to read the code directly.
• Read and post questions to the forum on YUILibrary.com.
• Play a lot and have fun!

Conclusion

YUI 3 is a full-featured, mature and constantly evolving library suitable for small to large projects. As front end web applications become more complex, the need for libraries like YUI will grow. While for the uninitiated it can be a daunting experience at first, if you stick with it you will be rewarded.

TipTheWeb is a new service that lets people directly support their favorite web content by tipping it. For instance, if you find a great blog post, you could tip it 25 cents.

TipTheWeb is a non-profit organization promoting freely-accessible, high-quality web content by awarding publishers that receive tips. If you publish online, you can use your TipTheWeb account to claim the places you publish to receive tips and be eligible to receive awards from TipTheWeb.

TipTheWeb’s Use of YUI 3

The user interface of TipTheWeb is completely built on top of YUI 3 (we drank the Kool-Aid.) The approach we took was to use YUI 3 as the foundation and structure for our JavaScript code. We’ve built 33 custom YUI 3 modules (56 if you include submodules, plugins, and roll-ups), several of which we contributed the YUI 3 Gallery: Component Manager, Markout, Overlay Extras, and REST Resource.

Page-Level Classes

The core features of TipTheWeb are implemented on a few highly-functional web pages which communicate with the server over Ajax. For each of these pages we created a custom YUI 3 module that exposes a page-level class used to coordinate actions between the functional parts of the page.

In one of our application’s main pages, the Tips page, you can see how this approach is applied with the page-level class TipsWindow. The main functional parts of the page are the widgets: CreateTip used for creating tips, and the TipList widgets for editing, canceling, and funding existing tips.

A Lot of Overlays

We use Y.Overlays extensively throughout our application’s UI to implement user-interactions; this allows us to keep the interface clutter-free while still having the functionality for advanced features available on the page. We needed features that were not built into Y.Overlay, so we developed Overlay Extras, which is in the YUI 3 Gallery and being used by a lot of other YUI 3 powered sites. Here are some place where we use Overlays on TipTheWeb:

Current State of TipTheWeb

We’d love for you to try out TipTheWeb; right now we are in invite-only beta, so request an invite on our site and we’ll send you an invite code.

Be sure to catch our talk at YUIConf 2010 where we will be presenting (more in depth) on how we use YUI 3 and YQL at TipTheWeb.

About the author: Stefan Klopp is the Director of Development for ExpressITech, the parent company of Car Rental Express. Stefan has been developing highly usable web solutions for the car rental industry in various roles over the last 6 years. He currently lives and works in Vancouver, British Columbia, Canada.

Car Rental Express is the leading independent car rental comparison website on the Internet. It lets users rent cars online in more than 1000 cities and airports around the world.

Our user base is largely non-technical, which means they want to compare prices and rent cars as easily as possible. With the relaunch of our website in June of 2010 we have implemented many components of YUI 2 to help provide our customers with an intuitive experience.

Which YUI components are we using?

The components that we’ve been using include Connection Manager, AutoComplete, DataSource, Calendar, Animation, JSON, and Container.

Why we chose YUI

When reviewing the different JavaScript libraries that we could potentially use on Car Rental Express, we found that the YUI was the most complete for our needs. The biggest selling features for us was the very modular approach the YUI took to implement different design patterns, as well as the robust documentation and examples they provided. From a development standpoint this led to rapid development of our application without having to struggle with a library.

How we use YUI

We utilize the YUI in a number of ways. Our 4 most used components are AutoComplete, Calendar, Container, and Connection Manager. Here are some of the ways we use each of these components.

AutoComplete

The AutoComplete component is used extensively on our site to help users find a city or airport in which to rent a car. We really liked how easy it was to implement this component, and how quickly it responds. We cache search results server-side to help improve search results; however, having the client-side caching also helped tremendously in speeding up the response of the component. Another feature that we really took to was how easy the results were to style. When displaying the locations to the user this was crucial as we needed to identify which locations where found in cities and which were found at airports.

Calendar

The Calendar component is also used throughout the site when a renter is filling in dates to conduct a search. We are using a customized version of John Peloquin’s Interval Selection Calendar and displaying it in a YUI Dialog. Essentially what we wanted to do was give the renter a two-month view when choosing their dates, as well as visually show them what date range they currently have selected. Again, this was extremely straightforward to implement using YUI 2 Calendar, and it basically came down to creating a YUI Dialog, setting the body to contain a div for the Calendar, then attaching a YUI Interval Calendar to that div.

Containers

We utilize YUI Containers throughout our website in a number of different ways. In the example above we were using a Dialog to help us display the Interval Calendar when a user was selecting a date. On our rate search results page we make heavy use of Containers to give the renter more information on different aspects of the car rental agency and the vehicle they might potentially rent. Most of the containers on this page are Panels that we re-use for each different listing. For example, the vehicle display features Panel:

Things got a little more fun with the Renter Rated agency ratings. When displaying the ratings, we really wanted to focus the user’s attention to the scores an agency received and to display this information in a clean, easy-to-view way. By utilizing the Dialog Control we were able to constrain the viewport and center the dialog easily to help us achieve this goal. By setting a blank header and footer it made styling simple by just adding the appropriate styles to our CSS. The end result was a clean ratings container that provides the renter with the information they want.

Connection Manager

Connection Manager is used throughout the site whenever we need to pull data via a XHR request. In some of the examples above we utilize this component for requesting cities and airports for the AutoComplete implementaitons and pulling the rating information for the Renter Rated Dialog.

One interesting way we utilize Connection Manager is with our rental center block that sits on most pages. To help with performance we do a lot of full-page caching on many of our content pages. However, we still wanted to display the dynamic rental center block on these pages. This presented us with a problem we were able to solve with Connection Manager. Rather than having to break up our fully cached page and cache only aspects of the page we found it was easier to just include the rental center block via a simple asynchronous request. We found that this allowed us to retain the performance from having a fully cached page, yet still display dynamic content in our rental center box.

Final Thoughts

Overall we have been extremely happy with our choice to use YUI. It provides us with a modular library that is well documented, easy to use and implement.

What is Lamplight?

Lamplight is a database for charities and voluntary groups (that’s non-profits) in the UK. It helps our customers keep their data efficiently, demonstrate the impact they have on the people they work with, and streamline administrative and reporting tasks. We’ve been going since 2004 and re-wrote the entire system in 2009, using YUI2 very heavily.

Lamplight has a pretty demanding bunch of users: they are generally not very keen to be sat in front of a computer — they want to be out working with the people they serve. So Lamplight’s got to be intuitive to use, responsive, and make their jobs easier.

We’re also committed to making it affordable for the smallest organisations — a hosted system starts at £15/month (for the whole organisation). So we work really hard to make a single system that is flexible enough for a whole range of different organisations to use without becoming impossible to manage and administer.

Which YUI components do you use?

It’s easier to list the ones we don’t: Carousel, Charts, Cookie, ImageCropper, ImageLoader, Layout, ProgressBar, Slider, Storage, SWF and TreeView. Everything else is in there to a greater or lesser extent. DataTable, Editor and Menu get the biggest workouts.

Why did you choose YUI?

First impressions go a long way. While I was trying out some of the libraries, YUI widgets seemed to be the most responsive, and/or the most reliable in different browsers. And then it doesn’t take long to realise the documentation, examples, and forums are really impressive too.

In some ways it’s made things harder — we use Zend Framework on the server, which (now) comes with Dojo ‘built in’ — but I’m pretty sure it was the right decision.

What have you had most fun with?

We’re just about to push the new YUI 2 based Diary to all our customers. Diary’s my own creation, and it seems to be working pretty well. It does what you expect a diary to do — drag and drop appointments, click and drag to add, and so on. It’s built on a whole stack of existing YUI 2 components (the Resize utility, Drag & Drop, and DateMath in particular). Diary is on GitHub, along with the API docs and a few examples (http://mattparker.github.com/diary/)

I’ve also enjoyed working with DataTable. I’ve added a column chooser context menu, used and added a bit to Satyam’s work with key navigation around an editable table, and implemented remote sorting/paging with the server returning HTML.

And Editor’s received some attention too: we have mail-merge menu buttons, some extra HTML filter buttons to handle content pasted from MS Word, a document templating system, and a built-in image insertion/uploader (images come from our server).

Finally, we’ve got a very simple ACL system, so that (for example) I only need one set of context menus that enable or disable items depending on who’s logged in — I think it’s good to know what you can’t do, rather than searching for a removed ‘delete’ option!

What’s been hardest?

Managing all the widgets that come and go. There shouldn’t ever be a page load until you log out, and in that time there are a lot of DataTables, TabViews, Buttons, ContextMenus… coming and going. Sometimes these’ll be in a Dialog, so I can’t just destroy() them on every ajax request, for example. I’ve ended up with a singleton WidgetManager, which stores sets of widgets (for example a form with some Buttons and a DataTable) and destroys (or hides them out the way, in the case of Editor) them at the right moment. All these widgets register themselves with the WidgetManager when they’re constructed. And we re-wrote fair chunks so that there’s only a single Editor, Dialog, and Panel that get re-used whenever they’re needed. Fortunately this wasn’t too painful as they’re all wrapped on the server by PHP classes, so I only needed to alter my Yui_Datatable or Yui_Form (for example) classes.

DuckDuckGo is a search engine that uses YUI extensively. Here’s what it uses in particular:

• ImageLoader. Matt Mlinac’s YUI 2 ImageLoader was the first thing I implemented and what originally hooked me on YUI for this project. DuckDuckGo has favicons next to results and often has “Zero-click Info” above results that usually includes an image. I didn’t want these images to compete with the results when loading, as getting results as fast as possible is the ultimate goal.

  The ImageLoader Utility handles this well by loading the images after the page load. DDG also auto-loads the next page of results when you scroll down. Sometimes the favicons icons are therefore hidden, and with ImageLoader their load is delayed (sometimes indefinitely) until necessary. To accomplish this, there is a different image group per (internal) page, each with its own custom trigger.

  div.event=new YAHOO.util.CustomEvent('it');
      var ig1=new YAHOO.util.ImageLoader.group(div,'click');
      ig1.addCustomTrigger(div.event);
      div.ig = ig1;
  

• Cookie. DuckDuckGo has a lot of settings, which are stored via cookies and alternately via URL params. When cookies are used, I use Nicholas Zakas’s YUI 2 Cookie Utility to easily get and set the values.

    YAHOO.util.Cookie.set(cookie, value, { expires: new Date("January 12, 2025") });
    x=ki||YAHOO.util.Cookie.get("i");

• StyleSheet. Some DDG settings change the look and feel of the site. These changes are actually accomplished after page load via Luke Smith’s YUI 2 StyleSheet Utility. Some of these changes are straightforward and I can just use the setStyle Dom function.

  YAHOO.util.Dom.setStyle('b2','display','block');

  Others require actual class changes, which I use the utility to do.

  YAHOO.util.StyleSheet('DDG').set('.ci', {display: "block"}).
              set('.cid', {display: "block"}).
              set('.ci2', {display: "block"}).
              enable();

• Dom. I also use some functions in Matt Sweeney’s base YUI 2 Dom component. I referenced setStyle above, and I also use the related getStyle, addClass and removeClass functions. In addition, I find the getViewportHeight, getViewportWidth, getX and getY functions to be incredibly useful to make things work cross-browser, and now on mobile screens as well.

• KeyListener. DDG has a bunch of keyboard shortcuts that let you navigate results without the mouse. I use the YUI 2 KeyListener component to enable these shortcuts.

  kl14 = new YAHOO.util.KeyListener(document, { keys:[70] }, { fn:not } );kl14.enable();

• AutoComplete. I’m currently working on adding search suggestions to the search engine, and will be using Jenny Donnelly’s YUI 2 AutoComplete component for the front-end. I understand that AutoComplete is getting introduced in YUI 3 soon. Everything else I use has already been introduced in YUI 3, though I still use YUI 2. However, I will be exploring the migration to YUI 3 soon.

About the author: Gabriel Weinberg is the founder of the DuckDuckGo search engine, based out of Valley Forge, PA. Gabriel has been a startup founder for over ten years, and his last company was sold in 2006. Gabriel holds degrees from MIT in Physics and the Technology and Policy Program.

Fast and fun – that was the user requirement for the new Assembla.com Agile Planner – an AJAX interface for adding development tasks, building story/feature outlines, and scheduling them into releases. We were lucky to have YUI 3 to make it fast and fun to implement as well.

I had used YUI 2 for a number of prior projects and I had been impressed by the engineering of the UI components and the underlying library infrastructure. I wanted to learn more about YUI 3, with its compact syntax and deeper focus on DOM manipulation and CSS3-style selectors. This project, with a low dependence on ‘prebuilt widgets,’ was a perfect opportunity to get my feet wet with YUI 3. The facilities for ‘large app’ implementation via custom modules and integration with YUI loader made it a natural choice.

The Agile Planner supports a number of drag and drop user interactions with multiple interaction groups and context based behaviors. At the same time, it handles a complex set of interactions with the server, including merging in new data from the server, and propagating changes to the server.

We improved on the existing Planner which was based on Rails handlers and Prototype.js. YUI’s sandbox philosophy and strong OOP facilities made coexisting with Prototype.js a breeze.

We used a large number of YUI components, including:

• Async-Queue to offer a responsive experience on a page that can involve 1000+ simultaneous tickets
• Drag and Drop with interaction groups.
• IO as a connection manager to queue and massage server interaction.
• Event-delegate to allow simply hydrating html templates and forgetting about them.
• Event-key for keyboard interaction and navigation.
• Collection for giving us a consistent implementation experience across browsers.
• Cookie for easy short-term UI persistence.
• Profiler to find the biggest speed gains
• YUI Doc to leave information for the rest of the team

Working with YUI 3 on an app like this has been fun, and I am looking forward to hearing what our users will urge us to do next!

About the author: Joachim Larsen is a frontend engineer with Assembla.com.