An Interview with Vimeo’s Kevin Sheurs, Lead Application Developer

Vimeo is quickly becoming one of my favorite websites. You can find videos on just about any website but Vimeo is different: the site has personality and the user experience is second to none. I recently had the opportunity to chat with Kevin Sheurs, Lead Application Developer for Vimeo, about Vimeo, MooTools, and a variety of other web development topics. Enjoy!

There's no secret that Vimeo is a video sharing site. How would you describe your service? How would you describe Vimeo?

Vimeo is an online video sharing website dedicated to supporting the needs of people that make video. It is a service for anyone who really cares about how their work looks on the web. There's lots of good stuff to watch on Vimeo, but we also have the best tools, highest quality video, and best community for video creators.

How many JavaScript engineers does Vimeo employ?

Vimeo has 4-5 application developers proficient in JavaScript; however, there are no developers solely dedicated to JavaScript development. Given the project, some developers may focus more on JavaScript/UI than others, but for the most part, application developers are doing both PHP and JavaScript code.

Vimeo's website features a host of JavaScript-enhanced functionalities, including AJAX paging, widget creation, tabbing, video switching, etc. When did Vimeo decide that the website needed to be more dynamic than that of a standard website?

I think an original reason for all the JavaScript and AJAX functionality on Vimeo is the nature of our product: video and community. We've always wanted to promote community around our videos and this is best achieved by allowing users to interact while watching video; through liking, commenting, messaging, subscribing, sharing, etc. In addition to this, we always look to keep up with the new tools and techniques that are out there and try out stuff that makes sense for our product. If there is a possible performance and/or user experience gain, we will implement it, test it, and see if it works. Introducing JavaScript and AJAX into different areas of Vimeo has also inherently improved back-end performance and load for us in many cases. Simple things like returning JSON on AJAX requests and creating/ injecting new elements in JavaScript or loading in related videos via AJAX can improve both load and response times.

At what point in Vimeo's development timeline did Vimeo choose MooTools as its primary JavaScript toolkit?

Vimeo chose MooTools as its primary JavaScript framework during a full website redesign back in 2007. That version of the site was even more JavaScript heavy than our current version, so we were really looking for a framework that was complete, fast, and well documented. MooTools, 1.11 released right around that time, excelled in all of these areas and features like classes/inheritance, built-in effects, super smooth animations, and the built-in Penner Easing functions were all appealing to us.

What did/does MooTools offer Vimeo engineers that reinforces the decision to keep MooTools as its primary JavaScript toolkit?

MooTools has remained Vimeo's primary JavaScript framework because of its strong object- oriented class/inheritance model, modular design, and clean/readable code. Having developers that do both PHP and JavaScript development, it's object-oriented approach really makes this common transition seamless. In addition to elegant Element creation, DOM interaction, and Event handling, MooTools goes beyond these things and has allowed us to build powerful JavaScript classes that power Vimeo's video player, uploader, and desktop upload application. Having MooTools extend and provide an API to the full JavaScript language, we feel confident that it can handle any task we throw at it.

Vimeo is currently using MooTools 1.11, which was released almost 3 years ago. It speaks volumes of MooTools that 1.11 is still more than adequate for a production environment. Why have you decided not to upgrade yet? Are there plans to move to MooTools 1.2 or 1.3?

Upgrading MooTools 1.11 and revisiting our front-end code is something we will be focusing on soon. We've wanted to upgrade to MooTools 1.2 for quite some time now, but unfortunately some of our custom classes and extensions didn't play nice with the compatibility file that was posted to the MooTools blog. With that said though, MooTools 1.11 really has held up in our production environment. We still have JavaScript code from the 2007 redesign as well as many new classes from recent projects such as Vimeo Stats, which you can check out at: http://vimeo.com/stats/demo. There is a lot of heavy AJAX, Element creation, Event attaching, and JavaScript/Flash communication going on. This section, in particular, will benefit greatly from features like Event Delegation and Element Storage that are available in MooTools 1.2 and 1.3.

What would Vimeo's engineering team like to see improved within MooTools? Has the engineering team customized anything with the site's MooTools build to better suit the Vimeo website?

The case is rare when I am wishing MooTools did something that is not already available in version 1.2. Of course, we would always like to see continued improvements in performance, speed, and size; but this already seems like a strong focus of MooTools. One thing that has come up though, is the topic of namespacing. If Vimeo were to ever create a script or have the need to inject code into another website, we wouldn't be able to use MooTools because it would conflict with other JavaScript libraries. My only other addition would be community and organization around the library. It was great to see the MooTools Forge launch, but more activity there and more access to the available plug-ins out there would be a plus.

Which MooTools classes have become essential for the Vimeo team? Can you share any details about important custom classes the Vimeo team has written?

MooTools in general allows us to make a completely customized UI for Vimeo. We try to create everything from scratch so we have complete flexibility within our Vimeo framework. One thing we love is how MooTools makes it easy to mash-up Flash and HTML in a tasteful way. Components like our video browser to the right of our videos is a special interaction which allows us to create Flash scrollbars that scroll HTML content. The MooTools framework is sometimes compared to AS3 at Vimeo. Making JavaScript feel more like a legitimate programming language rather than a series of helper functions and animation scripts makes us huge fans. The extensibility and modular design of MooTools also makes us excited to make good classes and patterns for Vimeo.

Creating such an AJAX-heavy, dynamic web application must have presented many difficulties. What major issues has the Vimeo engineering team had to overcome to create a reliable, flexible website?

We are constantly doing back-end improvements to meet popular demand, but sometimes short-term solutions have been to concentrate on front-end UX mechanics through JavaScript and AJAX. Given the page or interface, there can be sometimes be additional costly information, and in those cases we decide to either have users manually load that content in via on-click, or have it AJAX in automatically after the page is loaded to improve user perceived latency. Another issue was we had to create a slightly altered event management system, since certain core Vimeo JavaScript classes act up in different browsers. We heavily rely on the domready event, but depending on the browser we wanted to filter out some of the automatic start-up code and manually call it when the time was right. What we did was pass all instantiation through our custom EventCenter. If the page works perfectly in all browsers, we would do EventCenter.fireAll() on domready. If the page is fickle we would then choose what type of events to call on instantiation.

Vimeo's animated homepage background is a perfect example of a tasteful, unique effect. What can you share about the inspiration and difficulties behind creating the effect?

Why, thank you! The homepage background effect is a perfect example of an effect driven by design. I built the page not really thinking how the sun and clouds would "work", but I knew they needed to be fixed based on their various positions in the sky. I quickly saw this wouldn't work since the elements would stay fixed and collide with the footer illustration as the page scrolled vertically. So, I added a scroll event and set the top position on the elements as the page scrolled, which worked, but was pretty choppy. I ditched the scroll event and instead created a Fx.Style for each element and animated the top position in a function that was called periodically, to allow more flexibility in timing. Executing the function periodically paired with the Penner easeOut animation, the effect really felt awesome.

Can you provide any detail as to how Vimeo is constructed on the back end?

Sure, Vimeo is developed on the LAMP stack. The application itself is written in a custom PHP 5.3+ HMVC framework. We have a bunch of MySQL databases to store stuff like videos, users, channels, and statistics. We heavily use Memcached for our caching layer. We use it for caching objects, collections of objects, rate limiting, and session management. We also use cool things like Solr for search and tags, Beanstalkd for worker queues to offline certain tasks, and Scribe for logging and statistics aggregation. At the moment, our whole infrastructure is virtualized and we use Amazon Web Services extensively so we can scale transcoding and uploading capacity during the day. However, we are always experimenting with more efficient ways of doing things.

Vimeo provides an excellent API which allows anyone with programming knowledge to pull their user or video information. What difficulties did Vimeo encounter while creating the API system?

One of the biggest challenges was building a good upload API that is easy to use and works properly with our back-end transcoding system. A greater challenge than creating the API is maintaining it and updating it to reflect changes in the site, without breaking current applications. This is especially difficult with our video player's JavaScript API because of the high number of Vimeo embeds that are out there. Once someone embeds a video, that code is pretty much frozen in time.

Does Vimeo plan on open sourcing any of its code in the near future? If so, what can we look forward to?

Being more open about our development is something we've been discussing recently. We are constantly developing and implementing new tools and techniques to help us grow and scale and we feel both the development community and Vimeo can benefit by being more open about it. Just recently, we rewrote our PHP application framework with more of a focus on performance, scaling, and security. I think we are are doing some pretty unique things with caching, HMVC, privacy, and data filtering/sorting in PHP to reduce database load. Hopefully in the next few months you'll be hearing a lot more from us.

What can we expect to see from Vimeo within the next year? Next 5 years?

You can expect to see us everywhere.

A special thanks to Kevin for taking the time to chat with me! Be sure to check out Kevin and the rest of his team's work at Vimeo!