Service Workers will Fundamentally Change the Web

Prior to 2005, the web was a pretty frustrating place compared to the world of native applications. There was no reliable way to have your web app communicate with your backend without having to resort to full-page refreshes, each of which was a complete server round-trip. Something as simple as filling out a form was an agonizing experience. Building something as advanced as Google Docs? Forget about it.

Along came AJAX

A technology known as XmlHttpRequest (or more commonly called AJAX) changed all that. Something that Microsoft had innocently built back in 1998 and added to IE5 in order to support Web Outlook was suddenly being supported in Safari and Firefox, and one morning the world woke up to the magic of Google Maps - a highly interactive mapping app that seamlessly worked in the browser, no page refreshes needed.

Consider how much the web has changed since then. AJAX is now a key part of pretty much every popular web app, and its usage is so ubiquitous that you don’t even think about it. It has so fundamentally altered what’s possible on the web that hardly anyone builds native desktop apps anymore.

The Next Revolution Begins

Ten years on, the web is on the verge of going through yet another one of these transformative moments in the form of Progressive Web Apps, built on top of a key technology called Service Worker. The addition of this technology will have as much of a profound effect on how web apps are built as AJAX did 10 years ago.

Service worker’s key breakthrough is conceptually simple: allow JavaScript code to be "installed" directly into the browser itself, independent of any single web page. That code can then be executed even when the originating web site is not active in any open browser tab, in response to events such as network requests, push message events, and more in the future.

This one fundamental change enables entirely new scenarios:

• Reliability: Because the service worker can intercept network requests from the browser, it becomes very easy to build web apps that work when there’s no network connection or (more commonly) when the connection is spotty
• Native behavior: Browsers can run service worker code even when the associated site isn’t loaded, enabling web apps to implement features like push notifications the same way that native apps can
• Powerful caching: The service worker API includes a Cache API that can cache data as well as the app’s HTML. This enables the app to cache its UX shell locally, enabling an “instant-boot” experience just like native apps
• Background operations: service workers can register to receive events when the network becomes available, enabling any offline work the user has done to be synchronized back to the server

When you combine service workers with other technologies like the Web App Manifest, your web apps can do things like have a rich homescreen presence on a device, control the app’s layout orientation, and specify a “splash screen” startup experience, giving your app the look and feel of a native one.

It's Already Happening

Some savvy developers have already started to take notice: Facebook is using service workers to enable push notifications on their web app, and Flipkart (India’s largest shopping site) has created an amazing web experience.

These technologies are already supported today in Chrome (both desktop and Android), Firefox, and Opera. Hopefully, Microsoft and Apple will soon follow.

That doesn’t mean, however, that you can’t start using these technologies right away. Service worker follows the principles of progressive enhancement: you build your web apps such that when service worker is present, then users get the benefits, and your default experience when it isn’t. This is the same path that AJAX took when it was first introduced, and there’s no reason why service worker should be any different.

The next ten years of web app development is going to be even more exciting than the last ten. To learn more about service workers, check out:

• The official specification
• An introduction to how they work
• A collection of service worker examples

Happy Coding!

Can you trust your API provider?

In just a few short years, the number of 3rd-party APIs on the web has exploded. Everywhere you look, it seems like just about every important service and app these days has an API available for developers to tinker with.

But can you trust them? How do you know that an API provider is serious about their supporting their developers and won't change things on a moment's notice?

I've spent the vast majority of my career - almost 25 years now - building and promoting developer platforms. I even had my own software company for a while where I was the consumer for an API platform that I myself had helped build, so I've been on both sides.

In this post, I've put together a series of questions that you can ask yourself before you fully commit to an API to try and gauge how much you can trust it - and the provider. Now, I'm going to invoke professional courtesy here and not call out any third parties by name since I work for Google, but I will use some instances from my personal experience to show what I feel are good examples of API stewardship.

An API that doesn't directly support a provider's revenue or strategic goals can be more easily curtailed or changed by the provider if it begins to go in a direction that they don't like.

1. Does the API directly support the provider's revenue stream or strategic product goals?

This criteria is important, but not always easy to assess. Let's take a few Google examples for illustration (again, full disclosure here - I work for Google). The Drive API directly supports Google's main goal for Drive - that is, to increase the adoption of Drive. To that end, the Drive API gives pretty deep and wide access to the service, and makes it easy for developers to integrate directly into the Drive UI itself. Google even calls out apps that use Drive in the Chrome Web Store.

Another good example is Apps Script, the API for Google Docs. Here again, the main motivation for Apps Script is to enable developers to create features that Docs itself doesn't yet provide or address scenarios that are too niche for Google to spend much time on, thereby increasing the appeal and adoption of Google Docs.

In both of these cases, the API exists to further a strategic goal - the adoption of the product in question. As such, developers that adopt the API help further the strategic goal, ensuring that the interests of both the developer and the provider are aligned.

An API that doesn't directly support a provider's revenue or strategic goals can be more easily curtailed or changed by the provider if it begins to go in a direction that they don't like.

2. Does the API give you access to "the good stuff"?

This is also a pretty good indicator of how much you can trust the API. If an API only provides superficial access to data or capabilities that really aren't that valuable, then you have to wonder about the intentions of the provider or what they might do in the future.

APIs that give rich, deep access to the important features of a service or product indicate that the API provider cares enough to think through how the API will be used and to devote engineering resources to the development and maintenance of the API.

An API that only gives you the ability to develop ancillary, convenience features - what I call a "vanity API" - is a pretty good signal that the provider doesn't have a big commitment to the API or to its developers. It's a lot easier to close off an API that doesn't have deep hooks into the underlying service than it is to change one that's going to affect a lot of customers down the line.

Even if the provider doesn't close off the API, the risk is that you're just serving as a free R&D resource for them. If you make a convenience feature that's popular, there's nothing stopping them from just copying it and rolling it into their core service. Caveat developer.

3. Is the API being actively developed, with a vibrant community?

An API that is receiving regular updates and has a large, active community on Stackoverflow or other forums is generally going to be more trustworthy than one that doesn't.

Regular updates that include new features, samples, and bug fixes demonstrate responsiveness and attention from the provider, and an active community shows that there's a well-worn path where you can get support from sources other than the API provider.

4. Are you able to make money using the API, without the provider interfering?

This one is huge. If the API provider puts unnecessary or onerous restrictions on how you're able to charge for your product, then that's a big red flag on how much you can trust the API.

QuarkXPress sold for $895 at retail (back in early 1990s dollars). I kid you not, we actually had a plug-in developer who charged $75,000 for their product (now, obviously, this was not a consumer-facing thing. In this case the product was for large Atex pre-press systems). Did we care? Hell no. We thought it was awesome that someone was able to sustain a business like that on top of our platform. Of course, most of our developers charged a lot less, but the fact that someone was charging 100x our product's price was not a problem for us.

Now, you might have to upgrade your API usage to a paid subscription in order to make your own product charge-worthy, but that's actually a good thing - a provider that charges for enhanced API service is entering into a contract with you, which in turn makes it harder to change or discontinue that API.

5. Does the API Provider itself use its own API for shipping features?

This criteria is a bit asymmetric - if they don't use their own API for their features, that's not necessarily a bad thing. But if they do use it for their own features, that's a powerful indicator that they've got a big incentive to invest in the API.

When I worked on Dreamweaver and then later on Microsoft Visual Studio, one of the things we were most proud of was the fact that we used our own API to deliver new features in the core product. It sent a strong message to our ecosystems that we cared enough about our API that we used it ourselves and considered it solid enough to deliver core features to our users.

6. Does the API Provider actively promote its developers?

Again, this one isn't necessarily a very strong indicator, but it helps to know that if you build a product that's based on an API that the provider will be there to help you promote it.

On the other hand, If a provider is squeamish about promoting its developers, that can be a bad sign. Ideally, you want to have a company that cares enough about the success of its API that it isn't afraid to call out developers who build great products on top of their platform.

Summary

Third-party APIs can be a great way to leverage the features of services that you don't want to have to build yourself, allowing you to focus on the value proposition of your product. Relying on them, however, introduces a certain level of risk. Hopefully, by asking yourself the questions that I've posed here in the post, you can minimize that risk and build a successful product.

In short, look for:

1. APIs where your interests and the provider's are aligned
2. APIs that give you access to the valuable, interesting stuff
3. Active development on the API with a great, supportive community
4. The ability to make money without draconian interference from the provider
5. A provider that uses their own API for new features
6. A provider that isn't afraid to promote great developers and apps

Now, to be clear, the answers to these questions aren't foolproof, iron-clad guarantees that you can trust an API to be there over the long haul or that the provider won't change things (or rip out the rug from underneath you). But if you think about these issues up front, they can help you avoid relying on API services that one day suddenly change their mind about your value to them as a developer.

What jQuery 2.0 Means to Developers

On April 18, 2013, at long last, jQuery 2.0 emerged from Beta and was released to the public. The jQuery library has evolved a lot since it was first released, along with the way that developers use this iconic tool. The 2.0 release includes a couple of significant changes that affect how developers use jQuery, and in this post, I'll discuss what these changes mean to developers.

Dropping Support for Internet Explorer 6, 7, and 8

Many people seem to have overly focused mainly on what jQuery 2.0 does not do - that is, support older versions of Internet Explorer, 6 through 8. The jQuery team decided to split the library into two different versions: the 1.x line, which will continue to evolve and support older browsers, and the new 2.x line, which will remain feature compatible with 1.x while focusing on modern browsers.

This was absolutely the right decision by the jQuery team, for several reasons. Two of the most important reasons are:

• The usage of IE 6-8 continues to decline, and according to the jQuery team, they were able to shrink the size of the library by 12% just by taking out the patches needed to support these older browsers.
• The HTML5 development landscape is a lot more diverse than it was even just a few years ago, and continuing to support older browsers would have held jQuery back. I'll go into more detail about this below.

At first glance, this decision may seem a bit bold, especially since Windows XP still has a significant market share at the moment and IE8 is still in widespread use on that platform. However, since jQuery 1.x will continue to support these browsers, this essentially means that developers need to think in advance about where and how their app will be used, and consider the audience for their application.

HTML5 is No Longer Just About the Web

Notice that I didn't title this post "What jQuery 2.0 Means to Web Developers"? I did that very purposely, as a lot of development around HTML5 is increasingly no longer directly tied to Web browsers. Several application platforms have emerged that use HTML5 as their development language, and for these platforms, the notion of older browser support simply isn't very relevant.

• Chrome Packaged Apps
• Firefox OS Apps
• Blackberry 10 Apps
• Android and iOS Web View based Apps
• Windows 8 "Metro" Apps
• PhoneGap / Cordova Apps
• Browser Plugins for Safari, Firefox, and Chrome

In these and many other up-and-coming scenarios, support for older IE versions isn't needed and results in dead code that will never be executed. By removing this code from version 2.0, the jQuery team can spend more focus on modern development scenarios, which will help position the library for further growth and adoption in the scenarios I've listed above as well as newer ones that haven't even come along yet.

As a result of this change, jQuery 2.0 is just 82K when minified - and that's for the whole standard library. But jQuery introduced a modular build system back in 1.8. Use the custom build system to exclude things you don't need, and you can get it down to under 20K.

These two steps - dropping support for older IE versions and introducing a modular build system - are, in my opinion, two of the most important changes that jQuery has made in the past few versions. They make jQuery more attractive for application development beyond just web sites, which opens a whole new set of opportunities for the library, as well as additional potential sources of innovation and contribution.

So Which Version Should You Use?

The decision about which version of jQuery to use isn't really that complicated. If a project that you are working on needs to run on older browsers, then you should stick with jQuery 1.x. If the project doesn’t need to work on those older browsers, or you're building an app for one of the platforms I listed above, then you can move to the newer 2.x branch.

You can use IE Conditional Comments to make sure that the user's browser gets delivered the right version of the library by using the following code (from the jQuery blog):

<!--[if lt IE 9]>
<script src="/path/to/jquery-1.9.1.js"></script>
<![endif]-->
<!--[if gte IE 9]><!-->
<script src="/path/to/jquery-2.0.js"></script>
<!--<![endif]-->

Of course, Conditional Comments are going away in IE 10, but since IE10 is a much more capable, modern browser, that won’t matter and the above code will continue to work - IE10 will just get the 2.0 version.

When jQuery was first released, its two primary purposes were a) to abstract away differences among browser APIs and b) make manipulating the DOM a lot easier and more predictable. Since then, it has become far more useful and versatile, and the 2.0 release takes it a further step in the world beyond the web browser.

The decision to discontinue supporting older versions of IE may seem on the surface more about saving space and focusing on modern browsers, which are of course noble goals in themselves.

The real news here, however, is that with this decision, the jQuery team is clearly positioning the library to be relevant to development scenarios beyond web applications. That's a significant step in jQuery's evolution, and I'd expect to see the jQuery team flesh this out more as these scenarios become more and more prevalent.