The future of the web platform is in your hands

by Steve Brownlee

For the TL;DR version (which skips my long winded trip down memory lane) go directly to the Future section below.

We've had this dream since 1997

Fragmentation.

It's the dirty word of the web application and services development community. We've got plenty of it. Now that doesn't mean that companies and OSS communities haven't tried to help us out. They really have. Sun, Adobe, Microsoft, and Google have all put massive resources and weight behind trying to be the One True Platform of the web.

The problem always was the money keeps getting in the way. Every vendor keeps trying to lock in the developer community to their own opinionated platform because, of course, their ideas are the best (and in many cases, just so happens to support corporate profits).

Let's take a look back and see where we've been and how we've tried to accomplish the dream of a common platform for the web.

Java Applet (1996-1999)

Ah, the language that everyone loves to hate, right? Well, not everyone hates it but web application developers who have more than a few years experience tend to have a deep-seeded loathing of the language.

Why is that?

Well, it may have something to do with Java Applets. Now, for those who weren't around in 1995 when the Java applet was introduced to the language, you won't have any context for the rise and fall of this very first attempt at a common platform for the web.

Many of you have likely never even seen the <applet> tag in an HTML document before, and you might want to count yourselves as lucky.

In fact, even before that - before web application development I mean - there was Windows development. Now before the World Wide Web came along and first started its disruption of the desktop OS, Windows developers were battling (and continued to battle for at least 5 more years) something called DLL Hell. Oh, I think back on it with sentimentality now, but I still remember how frustrating it was.

Well, Java Applets became their own version of DLL Hell as some browsers would support them, and others wouldn't. Then only certain versions of certain JVMs would be supported on certain browsers. Then, as always with a new technology, the scum of the earth found out how to exploit it for nefarious purposes, so you can stack security issues onto the pile.

Then, the first inklings of a community for the web became aware and thoughts such as, "we shouldn't be depending on third-party plugins," and "the web should be open and not running binary applications where you can't see the source code" started to enter our collective consciousness.

As quickly as it burst onto the scene, the Java applet quickly withered as the savior of the web.

AJAX (2005-Present)

With the applet gone, we trudged along the wastelands of the web for a few years, making incremental advances, but nothing really revolutionary happened. Then, in February of 2005, an article was published by Jesse James Garrett titled "Ajax: A New Approach to Web Applications". I remember the first time I read it. I was working in Pittsburgh at the time for EFI, building ColdFusion and Java applications, with JavaScript powered front ends.

We take it for granted now, but when we were first introduced to it, it was exhilarating. The dream of building true applications became a reality in our imaginations, as we were tired of the multi page paradigm we'd been handcuffed with all these years. Yes, we used frames and iframes to get around it, but XMLHttpRequest (XHR) put an end to all that. All our code could run in the same page without a secret hack we hid from the users.

Then Google Maps came out, and that started the revolution that's still going on today. It showed the true power of the AJAX promise. AJAX continues to be one of the underpinnings of moden web application development. However, perhaps its days are finally numbered with the WebSockets API Specification rapidly gaining hold in the community and full modern browser support.

Personally, I am entranced by the Meteor framework, and my current application, stackd.io, was originally built in it. Alas I had to migrate away, but in hindsight, I might have been better served staying with it.

Flex (2008-2012)

Man, I loved Flex. For as much as it completely went against everything that I stood for - open web, open standards, and open source - it really was freaking awesome. Finally, FINALLY, we could write desktop quality applications and use the web and browser as the delivery platform.

Of course, it was Java applets all over again, but those same arguments we made to kill to applet, we conveniently forgot when Flex came along. It was oh so pretty... and shiny... and new... and we could build even prettier, shinier things with it. If we had all been 12-year-old girls, the world would have been drowned in one big squeal of delight emanating from the dungeons where they kept the programmers.

However, there were islands of light still fighting the good fight. The W3C, Apache, Mozilla, and other organizations were still pressing on to make specifications that browser vendors could implement, so that we would, once again, be freed of the shackles of corporate underwriting.

Flex is still alive under the guidance of the Apache Foundation, but it, like the applet, has been quickly shuffled off to the fringes of web application development.

Silverlight

As a quick footnote on the whole embedded vector graphics plugin era, Microsoft was late to game (seems to be their calling card since the Era of the Desktop) and released their competitor to Flex, called Silverlight. It arrived on the scene just in time to see the entire platform be disrupted and marginalized.

The JavaScript Boom (2010-Present)

I wrote an article on my old blog back in June 2011 entitled "The World is Changing - The New Landscape for Application Development". In it, I described a fundmental change that I saw emerging; a change where everything would be powered by JavaScript on the web platform; a platform on which I was betting and still am. Three years my prior, Jeff Atwood proposed a corollary to the Rule Of Least Power, self-named Atwood's Law, that proposes that "any application that can be written in JavaScript, will eventually be written in JavaScript."

Even when I wrote my article 3 years ago, people poo-pooed the idea that any and all applications would be written in JavaScript. I believe that many of those applications have since been written in JavaScript and the list will continue to grow. It could be partly because we just aren't able to see what advances will be made in the future, particularly if we think those changes are threatening.

Now with tools like LLVM, Emscripten, and asm.js, application developers can take traditional desktop applications, and compile them down to highly optimized JavaScript for delivery in the browser.

I'm betting on the web.

HTML5

There are many parts that make up the all-encompassing HTML5 specification, but for web application development, there are a handful that will make a significant impact once adopted across all modern browsers (and many of them already are).

All these new features of web browsers will allow app developers to make richer user interfaces without having to jump through all the hoops we've been using for years, and will reduce traffic and memory usage.

Mobile Revolution

Not since the introduction of the World Wide Web to the average consumer has there been such a fundamental disruption to our daily lives, and the life of an application developer. The fact that we all carry powerful computers around in our pockets that take pictures, record HD videos, let us deposit checks, play good games to pass the time, keep up with our friends, provide GPS directions when we're lost, hold every bit of information we have about our friends and family, check the weather, find a restaurant, read the news, and the million other things we can do with a computer is still astounding to me.

In fact, why we still call them "mobile phones" is beyond me. They should be called "pocket computers", if anything. I rarely use mine for making phone calls anymore.

One thing that you might not have considered is that the recent advances in application development for the web have been driven by the mobile revolution. Responsive designs, media queries, local storage, location data... all these things are being driven by mobile revolution. I doubt many of us would have cared about those things without the existence of pocket computers.

With HTML5 and mobile development still in its infancy, we've yet to see the amazing things that will come out of them, and there will be amazing things; I just don't know what they are, but I'm excited nonetheless.

What does the future hold for us?

The Future

I'm excited about the next few years of application development for the web. I'm not even talking about native mobile app development, because I still believe that the web will win. Native mobile applications will always be needed, much the same as native desktop applications will always be needed, but over the next decade, the tools and infrastructure will continue to be built to make the web the main platform of distribution for applications.

It may not seem like it now, but there's a massive community of very bright people working very hard to make it a reality. Just because it doesn't exist now, don't let it limit your imagination.

Web Component Platform

I really want the web to be an open and cohesive development platform. A lot of other really dedicated and smart people want the web to be an open and cohesive development platform. But what does that really mean? Here's what I'd like it to mean.

  • I want to as easily include and use UI components as a Node.js developer would include and use the file system - var fs = require('fs');.
  • I want there to be one component repository and management tool that handles publishing and consuming components (ok maybe there's two to be realistic, but I'm dreaming here). Think of npm for Node developers, and bower for packages.
  • I want these components to be as granular as possible, without dependencies on any other component, parser, or generator, but still have the flexibility to have logically grouped components be available as packages. For example, if I want to include the entirety of the Angular library in my project, I should be able to do so, but if I just want to use the data binding, but not all the other features, I should be able to do that as well.
  • The components should be written in a way that they can be easily used by a build system, or task runner, for concatenation and compression.
  • The components should not include custom styling by default, but can provide some, if requested.

Why don't we have this already? Well, the answer is simple. We just haven't gotten there yet, but we are getting there. For me, the most important aspect of the HTML5 specification is the Custom Elements. The point of this feature is to allow web application developers to build custom, self-contained components that will be rendered right in the DOM of an HTML page.

For an example, this would be valid syntax and would render a list of bananas.

<html>
   <head>
      <link rel="import" href="lib/bananaWorld/bananalist.html">
      <link rel="import" href="lib/bananaWorld/bananatype.html">
      <link rel="import" href="lib/bananaWorld/bananaorigin.html">
   </head>
   <body>
      <bananalist>
         <bananatype></bananatype>
         <bananaorigin></bananaorigin>
      </bananalist>
   </body>
</html>

Polymer

One of the first projects that I found that is trying to tackle this new frontier is Google Polymer. It provides a large library of already-built components that you can try out. On top of that, Polymer is intended to be a next generation framework, by implementing all of the specifications from HTML5 that it can, while having polyfills for those that it can't.

It's a truly ambitious project, and, if combined with some other tooling (which I'll discuss below), my dream workflow will be a reality.

Brick

Now Mozilla, who I'm a huge fan of, has also started their own project called Brick which, while not as ambitious as Polymer, is also tackling the challenge of creating a library of custom elements for use in web applications. The reason I really like Brick is because of Firefox OS which shares my belief of betting on the web.

We're getting very close to having a complete development environment in the browser, supporting web applications built on a common, core set of UI components that are reusable, interoperable, and composable.

It currently has components like:

Not a whole lot right now, but we are just getting started.

component.io

Back in 2012 T.J. Holowaychuk published an article about JavaScript components in which he proposed a detailed vision for delivering encapsulated components that can be used, and reused, in any JavaScript application. He elucidates how current package managers like npm and bower aren't really fulfilling this need, and are simply buckets that hold everything from single libraries to entire frameworks that can be included in projects.

I urge you to read his entire article, but my own TL;DR version is this; stop publishing opinionated libraries and components. Make things as composable as possible, with the minimal styling possible, and as encapsulated as possible. If you want to publish a framework, it should be comprised of standard components itself that can easily be pulled out piecemeal, if needed, and included in another project.

This is a completely new way of thinking about front end development. Those who have experience in "backend" development are familiar with this style of writing software. The tenet of writing composable classes and functions that do one thing, one thing only, and do it completely independent of any other class or function is exactly what we should be doing with components.

Both npm and bower moved the entire front end software industry forward, and are integral parts of our development and ops workflows, but we can't divert our eyes from the real goal.

Based on the vision from T.J.'s article, there are now two tools that are the move in this new direction. First is component, which is the CLI tool you can use to pull and publish CommonJS components. There's also the component.io web site that let's you search and browse currently available components.

This kind of tooling is what is needed, in conjunction with libraries like Polymer and Brick, to make web development more standardized, more cohesive, and more understandable. Then will come the arduous task of creating editors and IDEs that pull all this together for developers.

We still have a long road ahead of us, but at least we're on the right road now and driving along.

customelements.io

There are now some sites like customelements.io that are trying to aggregate components that are being published so that front end developers can get their feet wet building application on top of them.

WebComponents

Another great aggregation site is WebComponents.org where you can read the specs, browse articles about custom elements, watch presentations, keep up with current browser support, and see links to libraries that are being created to leverage these new technologies.

sweet.js for those non-web type developers

If you haven't yet, you really need to check out sweet.js. To prime you, think of CoffeeScript or TypeScript. Those syntaxes are sugar on top of JavaScript that allow you to write code in a more concise way, but then compile down to pure JavaScript for deployment.

Now, I'm not a huge fan of learning a completely new syntax for writing an entire JavaScript application because I feel it's a level of abstraction that is too large to make up for the conciseness of the syntax. That said, I do believe that using sweet.js macros to make some parts of JavaScript application more standards compliant would be a good thing.

Let me explain that in more detail.

There are two competing standards for how to build modular applications right now - AMD and CommonJS. Now, I prefer AMD because of its pervasiveness, but I also like CommonJS because of its cleanliness. For those developers who are used to Python, or Java, or {name language here} that are used to a syntax like...

import os
import sys

or

import java.io.*;
import java.util.*;

We can use a sweet.js macro to write JavaScript code like this

import twitter.bootstrap.form;
import twitter.bootstrap.button;
import knockout;
import sockets;
import express.router;
import box.DataStore;

var init = function () {
   var CloudStore = DataStore.createCollection("cloud");
   CloudStore.populate();
};

and have this produced from it

define([
  'twitter/bootstrap/form',
  'twitter/bootstrap/button',
  'knockout',
  'sockets',
  'express/router',
  'box/DataStore'
],
function (form, button, knockout, sockets, router, DataStore) {
   var init = function () {
      var CloudStore = DataStore.createCollection("cloud");
      CloudStore.populate();
   };
});

In this specific case, the macro would convert those import statements into AMD style module definitions, but could also produce CommonJS style composition - whichever you use in your applications - and now the source code looks more comfortable developers from other languages, thus making it easier to understand, without having to learn a completely new language syntax on top of JavaScript. The rest of your application would be written in native JavaScript.

Betting on the web

I've used this catch phrase a couple of times in this article, and I'm not even sure where I picked it up, but I'm a firm believer in it. There's a whole lot of passionate, articulate, talented, intelligent and motivated people who see the web winning for application development. Progress continues despite the naysayers. New tooling is being developed despite the short sighted. It's the long play, and having a shared, common vision that includes making standards, fighting fragmentation, and resisting corporate self-interest will make that play successful.

It's the long play that's currently in its 17th year of strategy rollout. It's had its ups and downs, but over time, the final goal has remained consistently in sight.

The future is in your hands

The future of the web is in your hands now - you front end developers who are just starting your journey. Front end development will be entering its Golden Age soon (heck, it may have already started). More companies are realizing that they need people who can make cohesive, high-performing, scalable, resilient web applications that can serve multiple delivery platforms (desktop/mobile/TV) and engage with customers.

My time will be ending sooner than later. I've been doing this for over 20 years now, and I've been spending a lot of my time lately passing down skills and wisdom to the next generation of developers. I still am deeply passionate about keeping my finger on the pulse of what's currently available, but lately I've been shifting my efforts towards helping out with what may come.

It's time to start thinking about how we, as a community, can further the goals of the World Wide Web as the greatest development platform ever conceived. It may not seem like it on a daily basis, but the choices you make today may have a deeply profound impact on how the web platform evolves. Are you going to help it or hinder it?

Choose wisely, my young padawans.