Programming the Web, Pt. I If you travelled back to 1999 and told web developers that one day hundreds of them would pony up cold hard cash to get a feature in a web browser, none of them would have believed you.
1999 was the high water mark of the browser wars between Microsoft's Internet Explorer and Netscape Communications' Navigator.
Microsoft was tying up PC companies as partners, making it a condition of receiving Windows that they also swallow IE. If it owned the PC makers, it owned the web, or so Microsoft believed. Netscape was trying to figure out how to get around Microsoft while also attempting to become more than “just” a browser-maker.
It was a war that drove Netscpe out of business and resulted in a single company gaining near total control of how we saw the web and how we developed for it.
With all this going on, why would developers put up their own money when ultimately they will never truly control the future of a web browser?
Fast-forward to earlier this year, though, and that's exactly what happened – devs did fork out the cash to have a new feature added to a browser. Enough web developers wanted to see a new feature on the web that they put up enough money for Chromium developer Yoav Weiss and others to implement support for the nascent <picture> element in his spare time.
Sure there were some T-shirts on offer and some workshops available for bigger donations, but at the end of the day, most of the money came from smaller donations. That is, from web developers who wanted to see the Picture element working in a web browser and wanted this to the point that they were willing to pay for it.
What's all this then: A crowd-funded browser feature?
At first glance it seems like a crazy idea, asking people to fund development of a feature that will ultimately end up being used by most in a browser owned and controlled by a large company (Google in this case). And yet developers went for it.
Why? Perhaps because it was a chance to directly shape the future of the web. Perhaps because the separation between those who build the web and those who build web browsers is disappearing.
According to Weiss he had two options on getting the Picture element added: “Either wait for the infrastructure to happen naturally over the course of the next two years, or make it happen myself," he said.
Weiss opted for the latter, and picture support is available today in the Canary release of Chrome (you'll need to enable the "experimental Web features" in chrome:flags), and it appears to be on target to make a final release later this year in either Chrome 37 or 38. Weiss's work is also in the process of being ported to WebKit (which would make it available to Apple, should the company chose to add Picture support to its iOS Safari browser). Not to be left out, the Firefox team will soon have a working implementation of Picture.
If all goes well, the Picture element should be available in most major, modern browsers in the near future - marking the first time that a browser feature has been crowd-funded into existence.
Welcome to web development 25 years after the birth of the web and 15 years after the clash of companies that was the browser wars and which left Microsoft to reign supreme with IE – until it didn't anymore.
Today IE’s market share is down but the rise of Mozilla and Google hasn’t substantially changed who “controls” the web browser. Increasingly, however, they do control the future of web, which ultimately matters more as browsers come and go.
It used to be that web browsers and standards bodies handed down new features from on high, but that is changing. Picture might be rare example of what it is, but it’s one piece that makes up a larger picture of the democratisation of web development.
W3C – cool story, bro
Take the World Wide Web (W3C) Consortium, one of the prime standards-setting bodies of the web and home to Greatest Living Briton Sir Tim Berners-Lee.
Once the stodgiest thing on the web, the W3C in 2011 opened up "community groups" that allow any web developer to get involved in the standards process.
The W3C is home to specs such as HTML, and the idea of the community groups is to help incubate new standards from individuals providing a channel for them to meet and work together rather relying on the traditional format of a vendor-stuffed W3C working group.
Granted, software re-use has been something of an industry Holy Grail elsewhere, but I believe these offer the developer something really compelling that will change the web.
Once upon a time being a "web developer" just meant you knew how to coerce IE into rendering a page the way you wanted.
These days IE 6 is less of a "problem" than the limited mobile browsers found on feature phones - which account for a staggering amount of web traffic worldwide. And unlike IE 6, mobile browsers can be handled by modern web development tools - like responsive web design - combined with long-standing best practices like progressive enhancement.
The million-dollar question: Why does my bank's website suck so badly?
The great thing about progressive enhancement is that developers can also offer modern browsers running on more powerful devices a first class web experience with features that would drop jaws even just a few years ago.
So, if modern web development is so incredibly powerful and web developers can crowd-fund whole new features into existence, why does your bank's website still suck so badly?
William Gibson is reputed to have said: "The future is already here - it's just not very evenly distributed." We could stretch that a little further to say that with some of today’s so-called modern websites, the future is often wrongly distributed.
That is, for every truly great example of progressively enhanced, future-friendly responsive design, there are, regrettably, other sites that use the same tools to produce a horrific, bloated website worse than the one it might have replaced.
In other words, democratisation or no, there are still plenty of developers who are "doing it wrong".
This is why we can't have nice things
Pundits and lovers of absolutist headlines would have you believe that this is why the web cannot compete with applications tailored to vendor-specific platforms. We’re talking native apps and the rise not just of apps built for smartphone app stores, but owners of large social networks who’ve made the distinction between web apps and the "native" versions of their apps.
That is of course nonsense. The distinction between what's often labelled as "native" applications and web applications doesn't even exist an any meaningful way any more. Most web applications can tap into an increasingly wide array of native hardware - cameras, accelerometers, GPS and more. Mozilla has created built an entire mobile OS around emerging web standards for accessing device hardware.
Ironically, most "native" applications would be useless without a web to connect to and share data through. The Facebook app wouldn't be much without Facebook.com behind it.
That said, there is a distinction to be made between the process and tools used to build for the web versus the process and tools you'd use for a platform-specific application. In other words, there might be little between web app and native apps to those using a website/application, but there are some very important differences for developers building such sites/applications.
Taking a step back from this, what emerges is a web that has become incredibly fragmented and decentralised. Unlike in 1999, the fate of how we view and develop for the web does not hinge on the outcome of a battle between two software companies. We're in the age of giants like Apple or Facebook, but the future of the web does not rest on their shoulders either.
What does this mean? It means it's up to you to get involved to make the web a better place. It means that every now and then, someone will come up with an idea and seek, and gain, the crowd-funding to make their dream real.
Thanks to efforts like the Picture element and new tools like Web Components, the web has an even bigger and brighter future ahead of it. ®