Advertisement

In the Spotlight: Brian LeRoux

by

This Cyber Monday Tuts+ courses will be reduced to just $3 (usually $15). Don't miss out.

The explosive growth of the mobile space has accelerated the search for a robust and viable cross-platform solution. In 2008, shortly after the introduction of the iPhone SDK and after fiddling with Cocoa and Objective-C, Brian LeRoux and his colleagues at Nitobi decided that their time was better spent building a cross-platform solution than building native mobile applications.

Today, PhoneGap powers tens of thousands of mobile applications. For Brian and his team, a lot has changed since the inception of PhoneGap. In 2011, Adobe acquired Nitobi and the source of PhoneGap was donated to the Apache Software Foundation as Cordova.

In today's spotlight, I talk with Brian about the early days of PhoneGap, the future of mobile, and why PhoneGap's destruction is a good thing.

PhoneGap has been around since the start of the mobile revolution and is well known among developers. For those who don't Brian LeRoux or PhoneGap, can you tell us about yourself and how you're involved in the project?

PhoneGap was created by a small group of people most of which worked at Nitobi, in Canada at the time.

The first commits where landed by Brock Whitten and Rob Ellis for iOS. These days, iOS is completely the domain of the prolific Shazron Abdulla. Joe Bowser hacked out the very early Android and continues to maintain it to this day.

Dave Johnson added various BlackBerry bits, now largely maintained by BlackBerry themselves with the help of Lorin Beer. Jesse Macfadyen cut the Windows Phone incarnations working closely with Microsoft.

Michael Brooks rocked out the documentation and much of the CLI (Command Line Interface) and test tooling with Fil Maj. Anis Kadri has lead much of the plugins tooling and discovery. Steve Gill has been responsible for releases and contributed much of the related tooling. 

Herm Wong started up Firefox OS and now our new GUI project. The branding identity started with Yohei Shimomae and has since been taken up by Joni Rustulka. Google and IBM have a whole bunch of contributors too.

A tidy creation story with a single hacker in the basement is a kind of fantasy that our industry loves but is rarely the case. Software is always a collective effort and everyone that contributes deserves recognition. I'm missing a Canadian metric ton of contributors here, but you get the idea.

For myself, I worked at Nitobi, contributed plenty of code to various areas of PhoneGap from incarnation, but my main focus was building the early project culture, philosophy, and goals—the things crucially important in communicating direction and galvanizing community.

Testing, tooling, and onboarding were other early key concerns for me. Eventually my focus shifted more to growing the committership beyond Nitobi, which culminated in the source donation to Apache as Cordova.

With PhoneGap being close to six years old, most people have at least heard of it. For those not familiar with PhoneGap, can you tell what problem PhoneGap tries to solve?

PhoneGap is for building mobile apps using HTML, CSS, and JavaScript. We support all major mobile operating systems for building and distributing to native app stores. But we are web developers foremost and PhoneGap's intent is to demonstrate the web as a first class development platform. We want to build web apps, not proprietary traps.

Ultimately, PhoneGap gives you a fancy full screen web browser and an extensibility model for accessing native platform functionality through a simple plugin interface. The plugin model makes it trivially simple to expose anything on the operating system to the web view. In this way, downstreams can rapidly prototype new web features and application developers are not constrained by the traditional web view sandbox.

In recent years the bulk of our effort has been dedicated to creating tools that abstract common native mobile development workflows. Compiling, emulating, logging, installing plugins, and that sort of thing.

What did the early days of PhoneGap look like? When did you realize PhoneGap was a solution to a problem many companies and developers were facing?

The early days were ridiculous and fun. PhoneGap was a side project mostly and the early core developers often hacked and philosophized at the Alibi Room, a famous beer bar in Vancouver, after hours.

Slowly, as mobile began its meteoric rise, many other developers came to the fray, attracted by the philosophical understandings we were sharing.

It was, and still is, a group fed up with proprietary platforms, changing operating systems, and locked in developer ecosystems. Fatigued by software platforms claiming "one true way", only to update "that way" every six months and later deprecate it—if not disappear altogether.

All through years of this abuse, the web platform was slowly improving and apps that targeted it still ran. We were no longer falling for the shiny marketing material calling itself "human interface design guidelines".

The web has never suffered any threat, but we found a hack that could bring the fight to the very platforms threatening it. The project was always open source, respected the web first, and designed to demonstrate features we felt the platform needed to remain competitive to proprietary alternatives. It has always been a scrappy group of hackers, but we are careful to not take ourselves too seriously.

A few years ago, you said that PhoneGap "isn't a golden hammer" and that PhoneGap isn't the solution for every mobile application. Is that still true or are we coming closer to a mobile web that's as powerful as the native experience?

The spectrum of potential apps is always growing wider as browsers, and the devices they run on, improve. I would never advocate PhoneGap as the ultimate solution. There are technical considerations such as native platform affordances and there are softer concerns such as business drivers, employee skills, existing content investment, licensing, reliance in third party platform vendors, and even partner relations.

Technology choices always bring tradeoffs and investing in web technologies like PhoneGap is no different.

The real challenge faced by developers, and especially in the enterprise, is recognizing that mobile app development is just like regular software development. This isn't just some point in time marketing spike. There is an entire lifecycle to consider; design, development, testing, analytics, and monitoring.

Mobile development requires ongoing maintenance and resourcing. One-offs by a consulting firm will need updating when a new version of iOS or Android ships. The marketing department needs to understand what content is performing and have the ability to quickly publish changes to content that isn't performing. The IT department needs runtime crash reporting and access to push notification infrastructure.

The longer game that requires deliberate strategic resourcing is only just being recognized as many organizations are only just now discovering that they, at least in part, are becoming software companies themselves. A strategic investment in technology that relies on a third party proprietary ecosystem is a business risk. PhoneGap can help mitigate that risk. Ultimately you'll never lose a bet on the web.

The acquisition of Nitobi by Adobe was an important milestone for PhoneGap, but Apache Cordova was probably even more important. How has Apache Cordova changed the platform?

The acquisition of Nitobi by Adobe was absolutely important. We were freed of crazy consulting work to focus solely on PhoneGap and there is no question that the platform benefitted tremendously. The donation of PhoneGap source to Apache as Cordova is equally significant in a longer view.

Working with Apache brought a whole new level of discipline to the project. Our release process is far more formalized and while it has been challenging to keep up our cadence, our community wins the legal safe ground that Apache is famous for.

This neutral territory is a great environment for individuals employed by different organizations to collaborate without concern. Since joining Apache we have welcomed committers from IBM, BlackBerry, Microsoft, Google, Intel, HP, LG, Samsung, and more.

As a result of this, we've seen many new downstream distributions of Cordova. My bias is for Adobe PhoneGap, but developers can choose to target BlackBerry Webworks, IBM Worklight, SAP SDK, Telerik, Intel XDK, or Google Mobile Chrome Apps.

Some folks just use vanilla Apache Cordova and create their own downstream. I love this diversity. All of this points to a vibrant and healthy ecosystem that our developer community can count on. We iterate fast, address bugs quickly, add new features on a regular cadence, and have a very well understood contribution process anyone can participate in.

Apache has a well earned reputation for politics and bureaucracy, but improving it is a part of our job too and working with the ASF (Apache Software Foundation) has been ultimately the right path for our community long term. I am very proud of what we have accomplished with the ASF.

PhoneGap is a great platform for developing mobile applications. The deployment remains cumbersome on many platforms, but you've tried to solve this with PhoneGap/Build. PhoneGap/Build does sound like a golden hammer for developers who are looking for a cross-platform solution. Can you tell us what the service does and what problem it solves?

PhoneGap Build is a compiler hosted in Adobe Creative Cloud. Using PhoneGap/Build, you can target any mobile operating system we support from any web browser. You can build an iOS app from a netbook or even your own phone (meta).

Initially we thought this might be helpful for continuous integration and testing purposes. It has become an all-around utility for the very discreet process of compiling an app and giving the resulting artifact a URL. It does just that one thing and it does it rather well. We've seen many people use PhoneGap/Build as an API or as their compiler.

You once said that you believe PhoneGap's future lies in its own destruction. Can you explain what you mean by that?

Yes, the ultimate goal of PhoneGap is to cease to exist. We do not want to write native apps. We have been down the road of proprietary client development and know it leads to risky ecosystem lock-in.

We want to build web apps and PhoneGap always has been a stopgap solution until browsers, or perhaps installable web apps, are capable alternatives. I think we are very close to that reality today. For many applications, web first is absolutely appropriate.

In order for mobile web apps to succeed with the ubiquity we see on the desktop, it is helpful to demonstrate the areas the web needs to improve. The PhoneGap plugin architecture is a really slick surface to create discreet prototypes for exposing new features to the traditional web surface. This subtle philosophy helped light the right directions for us, by implementing standards, pollyfills, collaborating with the W3C on API design, and bringing concerns to the browser vendors that lead to new platform features.

Open acknowledgment of ultimate demise could either be a tragic event in time or strategic understanding to plan against. To witness to our own undoing, PhoneGap needs to do everything it can to see the web platform win.

What are some of the painpoints that we still need to solve on the web? In other words, how close are we from a mobile web that offers an experience rivaling that of native applications?

25 years on, it's hard to criticize the web platform. However, bashing the web, on the web, is a time honored tradition of the webmaster craft.

The #1 revenue generating category in the App Store is games. So let's think about what it takes to be a great game. Audio overall is messy, but the Web Audio API is crazy awesome. WebRTC, or whatever we end up calling it, holds great promise for making real time apps more real.

Then there is a bunch of plumbing that hasn't quite landed ubiquitously such as Full Screen and Game Controller. When all of this stuff is generally available, it will shake up gaming. Data intense APIs like Web Audio, WebRTC, and WebGL are going to help us find the edges of JavaScript execution performance and all early indications are extremely positive.

Layout is getting quite good. Flexbox is great and I have high hopes for CSS Grids. The last version of Firefox (28) fixes the last bugs with Flexbox. I have no idea when CSS Grids land, but I am patient. Media Queries, sometimes known as Responsive Web Design, are helpful. I want a more robust capability model to allow us to render adaptive interfaces optimally.

The biggest opportunity is really cracking the offline story—probably better termed "occasionally connected". Installed web apps—like PhoneGap apps—are intrinsically offline, but a full permission model remains to be defined. Mozilla, Google, and the W3C are working on it.

Many of our readers have the ambition to develop for mobile. If you were starting out today, where would you start? What advise would you give yourself?

Mobile isn't much different than regular client programming. The classic advice is to test on real devices and I do encourage people to learn the native platforms, but to not grow too attached to them. A good example would be the iOS 6 to iOS 7 update. A well architected and designed PhoneGap or regular web app was not fragile to that update.

Otherwise, all the regular programmer wisdom applies. Be ambitious in your scope but discreet in your implementations. Create lots of branches and be prepared to throw most of your work away. You are not your code, so refactor ruthlessly and seek critical feedback.

Small modules and prototypes are easier to reason about, course correct, test, and validate. Don't get caught up in framework and library fashion. Focus on the problem space you have and iterate furiously and dispassionately. Write tests and make it dead simple for someone new to the codebase to run the tests themselves.

Finally, be super excellent to your colleagues. The web has a long memory, this industry is smaller than it first may appear and nobody wants to work with an asshole. No one has ever thought a rude person was being smart. Flaming is just insecure behavior and professionally immature. Programming is hard enough, we can all learn something from each other and opt for a pleasant experience in doing so.

Future Insights Live 2014

I'd like to thank Brian for his time and for sharing his ideas and insights with Tuts+. You can hear Brian speak at Future Insights Live 2014 in Las Vegas in June. The conference has an impressive list of speakers covering the best in web design, development, and mobile. Use coupon code TUTS for 15% off.

Advertisement