Dev Chat: Vlad Filippov of Mozilla
A conversation about open source software and front-end web development
I recently met up with Vlad Filippov of Mozilla to chat about open source software and the state of front-end web development. You may know Vlad as @vladikoff on GitHub and Twitter; he’s a core contributor to Grunt, and a member of several large open source projects.
We began by chatting about automated functional testing with Selenium Webdriver. Using Selenium, Vlad and the Firefox Accounts team run functional tests on “headless” Firefox with every commit to their web apps.
“Headless” Firefox
Running tests on “headless” Firefox is done by using a program called Xvfb which performs graphical operations without showing any screen output. Using Xvfb with Firefox, you can run browser-based tests on a CI machine or a remote dev environment which doesn’t have a physical display. To set up “headless” Firefox testing, check out an example build config for Travis CI here.
In addition to running tests on Firefox, the Firefox Accounts team also test their apps on a variety of browsers available via Sauce Labs’ cloud. To do so, they use a Jenkins server to centrally integrate a number of web apps once they each pass their own respective test suites on Travis CI.
This workflow of using “headless” Firefox every commit and an array of Sauce Labs browsers as the final barrier to release seems to hit the sweet spot between productivity and thoroughness. It lets developers get quick feedback on changes but also makes sure that software works as expected in all supported browsers before shipping code to production.
To run their Selenium tests as well as JavaScript unit tests, the Firefox Accounts team uses the Intern test runner. If you aren’t familiar with Intern, it provides an all-encompassing solution to run JavaScript unit and functional tests for your web application. As of the 2.0 release, Intern now ships with a new Webdriver client, Leadfoot, which claims to smooth out some of the incompatibilities in different browser drivers which are a pain to deal with when writing functional tests.
To learn more about Intern, check out the tutorial here which covers how to write both unit and functional tests.
Something that has been top-of-mind for me recently is choosing between Bower and npm as a client-side package manager. I recently argued in favor of npm so that my team could have the package.json be the single source of dependency management for a node.js-based project. Installing packages via npm also works well with CommonJS-style module loaders like Browserify and webpack and finally there’s the point that Bower itself has npm as a dependency :p.
When asked about why a developer would use Bower vs npm, Vlad brought up the risk of a single entity, ie. npm, having a monopoly over all JavaScript packages. Developers using other server-side languages also might prefer a package manager that solely focuses on the client-side rather than one that tries to support two different runtime environments. In addition, Bower de-dupes dependencies by default so that if you have two jQuery plugins with different jQuery version requirements, it will alert you of the issue and make you choose one.
For many node.js developers, package management with npm can be a blessing and a curse. It is great to use for development with its nested dependency resolution, streamlined publishing, and localized node_modules folders for each project. However, it can be painfully slow to download all the modules for every build in CI and deployment/testing may be blocked if there is an issue with the npm registry.
Enter Freight, a tool to solve all these problems and speed up both development and deployment. Freight creates a compressed archive of your node_modules folder and then serves it to your CI server during builds or to your dev environment during project installation or updates. You can read more about it here.
Note: if you are using Travis CI’s pro offering you can also use the directory caching feature to cache the bower_components and/or node_modules directories to speed up your build.
Although a bit off-topic, I wanted to mention something cool that Vlad showed me during our chat. He was carrying a ONEPLUS ONE CyangenMod Phone which had a super customizable interface and snappy performance.
He showed me how the CyanogenMod version of Android offered startling levels of customization like the ability to remove the Google search bar from the home screen, remove text from app launcher icons, or modify fine grain permissions within apps. I was pretty wowed as an iOS user at the level of customization available, and would seriously consider getting this mod if I was an Android user.
Conclusion
Thanks to Vlad for taking some time to share his thoughts on these subjects! I hope this conversation provided some useful information, thanks for reading!
