It's incredibly exciting to see how the Web is evolving, and 2013 has a lot more in store. Over the next year, there are a number of technologies coming down the pipeline that have the potential to radically transform how we use and develop for the Web.
CSS Custom Filters
CSS filters are already in Chrome and Safari, and allow advanced styling as as blurring, warping and modifying the color intensities of elements. However, that's only the start of it. CSS Custom Filters let you write your own fragment and vertex shadows in GLSL, a language that has been integral to traditional 3D rendering over the past 10 years or so.
What this means in practice, is that you can create incredible effects. Combined with CSS transitions you can produce beautiful transformations, from page curls, to folding elements. The limit is your imagination!
So when can you use this? Adobe have been pioneering this technology, and Custom Filters are already available in Chrome under a flag. Expect to see them in Chrome early next year. For now, you can play with them in Canary.
This API has the potential to radically transform signups and payments on the web. Autocomplete was designed to make it easer to fill out forms, and there's even now a spec to hint inputs relate to which data.
However, autocomplete is treating the symptoms and not the disease. Back in June I proposed an API to programmatically retrieve autofill data stored in the browser. What this means in practice, is that we can replace most forms with one-click signups, and one-click payments, dramatically improving usability and conversion rates.
The Chrome team have been working on this idea, and in October submitted a proposal and patch to WebKit. This is incredibly exciting and, combined with Mozilla Persona, could revolutionize registration and payments on the web.
So when can you expect to see this in the wild? Well, while the behind the scenes work has been done, Chrome still needs to implement UI integration for it. I think we'll see this late next year.
Google Chrome Apps
What if I told you that Google had snuck an operating system across all your devices, including your laptop and cell phone. Rather than compete with Microsoft and Apple by building a separate OS, Google decided to build their own platform on top of the existing operating systems. This platform is called Chrome.
So step one is distribution, which Chrome has now been achieved with more than 350 million users. Step two is extending Chrome's APIs, giving developers greater access to the operating system and replacing the need for conventional desktops applications.
A few months ago, Google quietly released Chrome Packaged Apps, which let developers build desktop apps powered by Chrome. They can be installed with one-click from the Chrome Web Store, access system APIs such as USB, Bluetooth and UDP Sockets, and can be opened from desktop shortcuts. These apps are completely cross-platform, standalone and appear native to the untrained eye. In many ways, these hybrids combine the best the web and desktop worlds.
So what's the catch? Well, Chrome Apps aren't quite ready for prime time just yet, and the APIs are still in flux. For example, creating a custom drag bar is still tricky. I'd give them a few months to be production ready.
Classes are also on the agenda, with full inheritance and mixins. Rather than emulating modules with CommonJS or AMD, ES6 makes them a first class citizen, inspired by a pythonesque import system.
One part of ES6 I'm particularly excited about, the part that can't be simulated by abstractions like CoffeeScript, is proxies. ES6 proxies let us dynamically look up function names at runtime, allowing functionality like Ruby's method_missing. This, combined with getters and setters, will enable all sorts of interesting DSLs and APIs.
yield keyword. You can see an example of this in task.js.
var data = yield $.get(url);
You may have seen a similar API in Ruby using [Fibers]((http://www.igvita.com/2010/03/22/untangling-evented-code-with-ruby-fibers/). Personally callbacks have been a major annoyance to me when writing evented code in MVC Node apps, and I've been playing around with Node continuations with a library called Ace. I'm really glad these being made native to the language.
--harmony command line option.
Web Components and the Shadow DOM just expose the way native elements are created internally in the browser. Using the API, you can define your own HTML elements, including style and behavior. Like native HTML elements, they can be embedded with a single tag.
A common reaction to any discussion of new Web APIs is a denouncement that it may be many years before any of these can be used in the wild. However, I'm extremely optimistic for the future.
While many of these APIs will take some time to filter over to other browsers, the market share that WebKit wields will pressure other browser vendors to offer their own implementations. Indeed, it hasn't taken long for HTML5 features to become production viable. As for backwards compatibility, many of these APIs can be poly-filled, or progressively degraded.
The reason why the future is so bright is evergreen browsers, or browsers that automatically update in the background. It takes about 18 weeks for a new feature in Chrome's Canary to be rolled out to its ~350 million users. That's an incredibly fast adoption rate, and innovation is happening quicker than ever before.
2013 is going to be a big year for the web!