The Future of the Web

This post is more than 2 years old.

I know, I know. The title sounds like SEO-link-bait, I apologize. I want to talk about something that I'm fairly excited about, and I hope it excites you as well.

Last week I had the pleasure of listening to Dan Callahan give the keynote at cfObjective. I didn't get a chance to meet him in person (I basically ran to my presentation and then to the airport), but I greatly enjoyed his talk. His central theme was a simple one - it is time to learn JavaScript. This is a message that I just kind of assume that people already know, but as I still encounter people struggling with client-side development, it is apparent that we (we being the greater web community) still have quite a bit of growing to do.

If there was one thing I would have added to Dan's talk it would have been a reminder that web developers are probably also somewhat behind in their HTML knowledge as well. I've been using HTML since 1993 or so. I spent a long time doing just server-side development for a while but even then I was still generating HTML. But at least once a month I'm reminded about some particular tag or attribute that I've forgotten about. Don't get me started about CSS. Every time I remember that you can specify hover stuff in CSS I remember how many times I wrote the same damn code to highlight menu items with JavaScript.

I've made it my mission over the past few years to focus my energy in this direction. Anyone who reads this blog or listens to me give presentations knows this. Developing for the web can still be pretty darn frustrating, but at least the tools, and the environment, are growing in leaps and bounds. There's some growing pains here, but my God, there's growth.

That is why I'm so excited to be hearing more and more about Web Components. Web Components refer to a few different technologies (that I'll list in a moment). But in general, they represent an incredible change in the web. To me, they truly are "Web 2.0." For the first time you'll be able to define new building blocks (tags, behavior, design) by following web standards. You'll be able to extend the web. That is awesome.

So what are Web Components? In general, they describe the following technologies/specs:


Anyone who has worked with templates in JavaScript know how powerful this can be. Templates allow you to create reusable blocks of content that can be added to the DOM with JavaScript. As a simple example, imagine you are using AJAX to fetch content from the server. As this content comes back as pure data, you need to write this out to the DOM. While you can certainly just create large blocks of HTML in JavaScript strings, this gets unwieldy pretty darn quickly. Hence the rise of multiple JavaScript template frameworks.

The Template feature will provide native support for this. You will be able to use a template tag within your HTML document. The content in the tag is not executed until you actually clone the template and add it to the DOM yourself. So any images or script blocks won't be loaded until necessary.

To be clear, this isn't the exact same as something like Handlebars.js. You don't get token replacement. But it is native to the browser itself which means less additional code.

You can read more about the spec here:

Shadow DOM

Shadow DOM is - for me - the hardest concept to get my head around. I probably will not do a great job describing it, but in essence, it is a way to create a "black box" style system for content. Let me give you an example. Imagine you are writing some HTML that is meant to be consumed by someone else. Your HTML is just a H1 tag and a paragraph. You want to style this content, but in order to do so, you have to ensure your CSS does not conflict with anything in the parent document. An iFrame can solve this, but iFrames create other challenges as well. With the Shadow DOM, you can essentially say, "This CSS will apply to this block only. Period. Nothing will leak out or in."

Again - I'm not the best person to speak on this. You can read more about it at the spec ( or check out the excellent HTML5 Rocks article on the topic.

Custom Elements

The most exciting part of web components, for me anyway, are custom elements. As you can guess, they allow you to create new HTML elements. Right now they are prefixed (x-), but if you have ever wanted to define your own markup, this will allow you to do so. You get full lifecycle support (ie, knowing when your element is loaded, shown, etc) and you can even use this feature to extend existing elements. Of course, you can also tie your own JavaScript events and mix in both templates and the Shadow DOM.

If you have ever used something like jQuery UI's Tabs to add tabs to your site, web components will allow you to do it all via web standards.

HTML Imports

The final piece of the puzzle is HTML imports. Essentially, once you've defined a custom element, applied some layout to it via the Shadow DOM and custom behavior, you can then create a reusable template that can be shared with others. In the same way you import a style sheet, the link tag will allow you to import custom elements. For example, x-tab or x-cowbell.

You can find the spec for this here:

So What, I Can't Use It Now!

I bet you're asking, how well is this stuff supported? Right now support is pretty limited. In fact, custom elements aren't supported at all yet. The features that do work now are limited to Chrome and Firefox Nightly. The specs are still in development. Keep in mind though that a majority of our major browsers now are moving to a continuous update cycle. If you are still of the mindset that you don't need to care or pay attention to web standards then you are failing in your job as a web developer.

Want to know more? There is an awesome, and short, video by Eric Bidelman of Google that you can watch on this topic. I've embedded it below. You can also find his slide deck here: Do note though that you are supposed to click the right arrow to start the presentation. The initial gray screen confused me a bit and I assumed something had broken.

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA

Archived Comments

Comment 1 by Raymond Camden posted on 5/22/2013 at 6:54 PM

Additional resources:

That's a high level look at the specs from the W3C.

Comment 2 by Jay Van Voast posted on 5/22/2013 at 7:06 PM

Great article Ray. Thank you again for all you do for the developer community.

Comment 3 by Tink posted on 5/22/2013 at 7:14 PM

http://www.polymer-project.... is worth taking a look at.

At the moment IMO JS just isn't cut out for building large scale enterprise apps. We tried it and it gets very untidy, there is still a long way to go, and the scaremongering around Flex has left a huge gap which Sencha does a really (no seriously really) crap job of trying to fill.

Comment 4 by Raymond Camden posted on 5/22/2013 at 7:27 PM

@Tink: I think the crucial part of your comment is, "At the moment". Although I do think you can build large scale apps with JS, I know many folks don't agree, but, whoever is right, I think this is changing rapidly.

I can remember waiting years to get new features. :)

Comment 5 by Dave White posted on 5/22/2013 at 7:29 PM

On the javascript front I have been using it for years coupled with CFML on large enterprise apps.
While I agree that building a large enterprise app just with javascript is not that feasible, I do think that
a mixture of X (CFML, ASP whatever ) and javascript ( pure, jQuery, Angular etc ) is fast becoming the norm.

With regard to Web Components, I think that Web Developers SHOULD look at it and try it out

It looks really good, I need to go away and "play" with it.

Great article Ray, thanks.

Comment 6 by chris pilie posted on 5/22/2013 at 7:45 PM

Thanks Ray. I definitely feel better about moving in the JS direction.

Comment 7 by Nick Collins posted on 5/22/2013 at 7:58 PM

So basically, in three years or so, when IE 11 or 12 is out and finally implements this stuff, we will be able to do web development the way we should have been able to all along? I wish there was a technology that allowed all these concepts that was available now... oh wait there is! It's called Flex! :-)

Comment 8 by Raymond Camden posted on 5/22/2013 at 8:04 PM

Actually, IE10 is going to have a rolling update feature as well (afaik).

Flash/Flex did a lot of this. There is no doubt. But - the world is moving on to web standards.

Comment 9 by Tink posted on 5/22/2013 at 8:22 PM

I not saying you can't, and we have tried and tested the water on smaller projects, and it hasn't been great, mainly falling back on Sencha for its flakey components and Deft for IOC.

Again this is only my experience, but I've working in enterprise for the past 6 years, and not yet have a come across a project that uses CFML. Thats not to say that there aren't any or put CFML down, but every project I've worked on have a JavaScript backend.

Comment 10 by Nick Collins posted on 5/22/2013 at 8:29 PM

@Tink I think it often has a lot to do with who your clients happen to be. For the past 10+ years all but one of my clients was using a JEE backend, and the other was using .Net with MVC4. I have yet to have a client that was using solely serverside javascript with Node.js or whatever, but I know in some circles it is extremely popular.

Comment 11 by Tink posted on 5/22/2013 at 8:31 PM

Bugger, marketing is forcing JS into my brain :). I meant to say Java backends. Funny the marketing thing, how Sencha had a big "HTML5 is ready" campaign and yet I don't think they used anything that people bundle under HTML5 banner due to backwards compatability in Ext JS.

Comment 12 by Nick Collins posted on 5/22/2013 at 8:42 PM

@Tink I took a look at Sencha when they were doing their whole "Come to us all ye who use Flex" campaign, and dismissed it pretty quickly. I have recently started doing more JavaScript, and I have come to settling on an "architecture" of sorts using a combination of jQuery, AngularJS, Mustache.js, and GSAP.js (aka TweenLite/TweenMax). I essentially use Mustache's templating to create ItemRenderers, GSAP to do any animation, Angular for dependency injection, MVC and such, and jQuery because there are some things like modal dialogs that are just easier with jQuery/jQueryUI.

It's not Flex, but it's doing alright. Now when I have time I am really interested in Dart with WebUI (similar to Angular).

Comment 13 by Richard Migambi posted on 5/22/2013 at 8:52 PM

I was going to Google this stuff tonight after seeing it on Google Hangouts. Great article Ray.

Comment 14 by Brian Rinaldi posted on 5/22/2013 at 9:04 PM

We should probably refrain from saying something cannot be done unless we are certain. I've met a lot of developers at a lot of large companies that are already doing large scale apps in JavaScript. Some companies are even using a Node backend meaning they are end to end JavaScript. Is it easy? Probably not. Maybe even not as easy as it used to be with other technologies. However, it is possible.

Comment 15 by Nick Collins posted on 5/22/2013 at 9:51 PM

@Brian I agree, we should refrain from stating an absolute like it cannot be done. Almost anything can be accomplished given sufficient time spent engineering. That being said, just because something "can" be done, does not mean it is particularly well suited for that task and "should" be done. If JavaScript was truly up to the task and well suited to it, then we would not have Dart, CoffeeScript, TypeScript, etc. Developing with JavaScript frameworks and libraries makes me feel like I'm coding with duct tape. :-)

Comment 16 by Raymond Camden posted on 5/22/2013 at 9:56 PM

"Developing with JavaScript frameworks and libraries makes me feel like I'm coding with duct tape."

Why? I mean, I like the fact that Backbone gives me a framework to help organize my code. It isn't duct tape. It's more of... a plan I guess. It lets me focus on the biz rules and less the 'where do i put this damn code' part. To me, I don't see it as I "have" to use a framework on larger apps, but that I "want" to use a framework.

Comment 17 by Nick Collins posted on 5/22/2013 at 10:13 PM

Well, this is just my personal opinion, but to me developing with JavaScript, as it is now, is kind of like assembling Frankenstein's monster. Take this piece from here, and this piece from there, throw in a few extra parts in case someone is using IE, and add some duct tape to hold it all together, then pray that you didn't accidentally give it an arm where it should have had a leg somewhere ( lack of strong typing and true interfaces ). I realize some people love this dynamic, loose nature of the language. I myself use an Android phone instead of an iPhone because it allows me to play fast and loose with the UI and UX on my device. I don't personally care for that same ideology when I'm programming though. Just my 2p.

Comment 18 by Chris Bowyer posted on 5/23/2013 at 12:52 AM

Can you recommend a reading order for learning JavaScript?

Comment 19 by Raymond Camden posted on 5/23/2013 at 1:21 AM

@Chris: I'd recommend MDN: https://developer.mozilla.o...

Comment 20 by roger tubby posted on 5/23/2013 at 5:35 AM

Chris - I've really gotten a lot out of the following books (in some order of interest to me):
- Javascript - The Good Parts (Crockford)
- Javascript - Web Applications (MacCaw)
- Javascript - The Missing Manual (McFarland)
- Javascript Patterns (Stefanov)
- Eloquent Javascrip (Maverbeke)
- Javascript The Definitive Guide (Flanagan)

I guess I am still a book junkie since I like to sit down and read and absorb away from the screen. However all of these have tutorials/examples that you can do online.

Comment 21 by JNT posted on 5/23/2013 at 11:34 AM

Keep calm, learn to ignore your brain and your own thoughts. Just trust Google, JavaScript and the global movement to braindeath. JS is just PITA because JS is not a PROGRESS (think HLL paradigm!) in software architecture but a giant step back, the exact opposite of an advancement in technology. The lame and very small common denominator of supported features as the expected (!) result of companies that would have to build standards, but are, of course, aiming at private profits and giving a shit about users, giving a shit about devs when it really comes to business.

It's crazy how people around the world think, companies that work against society and moral, because they're often forced to by market requirements (!), could come up with something social that could serve the community.

I hope more people will realize that freedom of information can never be achieved by market competitors, never be gained by the love of money. The economic system is based on competition, there is basically no interest in free and common standards, no interest in free communication.

And regarding the funny arrogant statement about web-development:
People who suffer from weak self perception often cannot see their own traits. Then, they tend to tell other people what they should to do ('if YOU don't ...'). So if any hipster person has not read enough about the authoritarian personality (not seldom these little dictators of IT) or narcissism he should ask himself what are underlying personal motivations to tell people to do bullshit and stop thinking for themselves. JS is like jumping out of the window - everybody does it now, you should do it, too!

So is it an awful global brainwash astroturf campaign that makes people believe, it would be a technical solution. But it's only an economic solution, to keep people working and to find as much bloatware as possible in order to be able to sell the always accelerating computing power of CPUs in the future.

So narcissistic child's play with computers, McLuhan already knew it. It wastes nerves, times and energy and is the futile attempt, to find a common language, reliable standards among hard fighting competitors. Have fun by leaving all the thinking up to big corporations, they know that it's best for us to. Use a crippled scripting language for serious development? The holy browser wars start over and over again - thanks for producing more work, red

believe Google and throw your brain away. There have never been high-level languages for serious application development, developers and engineers do not have the skills to tell the management what

Comment 22 by Tink posted on 5/23/2013 at 1:19 PM


"We should probably refrain from saying something cannot be done unless we are certain. "

I don't see a comment on this post that says seomthing can't be done. Where did you get that from?

The app I'm currently working on has over 2,500,000 lines of frontend code in around 16,000 classes. It has a huge amount of custom UI controls, works across all browsers and desktop and has been in development for over 5 years and it still actively having new features and modules added to it by a team of people spread throughout the world along with a constant mass of bug fixes. I have no doubt it could be built in JS, but I also have no doubt it would be an absolute nightmare, something we have found out by experience in porting very small parts of it with limited functionality to Sencha Touch for rollout on mobile along with experimenting with rebuilding smaller apps we have with Sencha.

Ray mentioned 'There is no doubt. But - the world is moving on to web standards.' That may be true, but although there is experimentation, I don't see it happening yet in finance.

Comment 23 by Raymond Camden posted on 5/23/2013 at 3:53 PM

@JNT: Best comment ever. What AI program did you use to create that?

Comment 24 by Nick Collins posted on 5/23/2013 at 4:02 PM

I must not code in JavaScript.
JavaScript is the mind-killer.
JavaScript is the little-death that brings total obliteration.
I will face JavaScript.
I will permit it to pass over me and through me.
When the JavaScript has gone, only ActionScript will remain.
*Tongue in cheek, naturally*

Comment 25 by Raymond Camden posted on 5/23/2013 at 5:39 PM

@Nick: Bravo, man, bravo. :)

Comment 26 by Michael McConnell posted on 5/23/2013 at 6:21 PM

Just curious....Why did you dismiss Sencha so quickly, if you don't mind saying.

Comment 27 by Raymond Camden posted on 5/23/2013 at 6:31 PM

@Michael: Your comment was to Nick, but I wanted to ring in about Sencha as well. This is based *entirely* on my impressions and with NO real use. To me, Sencha looks incredibly powerful for "apps", not so much for more content drive sites. If I were building a mobile version of my blog, Sencha would seem like overkill. If I were building a mobile version of my bug tracker, it would seem better suited.

Also, Sencha is *very* code oriented. So like, to build a panel, you do stuff like (and again, let me stress I'm making this shit up):

var p = new Panel();

That approach works, but feels a bit awkward to me for designing a web page. You compare that to something like jQuery Mobile which 'dresses up' regular HTML and it just feels better.

So yeah, long story short, Sencha seems epic in terms of features, support, etc, but the *way* it does stuff just didn't feel right for me. Totally a personal thing. I'd love to take some time to get real training in it though and give it a proper fair shake.

Comment 28 by Nick Collins posted on 5/23/2013 at 6:48 PM

My impression was pretty much like Ray's. Most of the "applications" I have been doing lately are more cinematic in presentation, as opposed to form-based applications (although there are usually some forms).

The franken-framework that I have kind of settled on is to use Angular.js for the dependency injection and application structure logic. for my applications. For more content driven dynamic sites, I use jQuery which ties in very nicely with the Greensock Animation Platform (GSAP), particularly since GSAP.js comes with a jQuery plugin to have it hijack any jQuery UI animations and provide some substantial performance gains. I will use Angular's data-bound templating in my Angular apps, but also have Mustache.js in my bag for the jQuery sites.

Comment 29 by Michael McConnell posted on 5/23/2013 at 6:48 PM

Your comments and interpretation are spot on. All I do are enterprise apps for desktop and mobile. Sometimes I forget that people do other stuff on the web :)

Comment 30 by Daryl Banttari posted on 5/23/2013 at 7:35 PM

I put off diving into JavaScript as long as I could. But then a colleague showed me AngularJS and now I'm a believer! :) Most of my CF is now limited to providing services (not pages), and the pages are .html files. (AngularJS has a significant learning curve, but Flex devs have a head start. That being said, if you can't find the headspace to relax and let your framework do the work for you, Angular might not be for you.)

Comment 31 by Tink posted on 5/24/2013 at 1:50 PM

"Also, Sencha is *very* code oriented. So like, to build a panel, you do stuff like (and again, let me stress I'm making this shit up):

var p = new Panel();

Generally you create you views with JSON markup, although obviously like Flex, you can fall back to using the underlying (AS/JS)

items: [{
xtype: 'panel',
width: '100%',
height: '100%'
xtype: 'anotherItem'

Comment 32 by Raymond Camden posted on 5/24/2013 at 2:42 PM

@Tink: To me, that sounds the same (JSON markup vs AS/JS).

Comment 33 by Tink posted on 5/24/2013 at 3:23 PM

You could view JSON markup being akin to MXML, JSON being an alternative for XML, both of which are data-interchange formats, that can describe objects, unlike AS/JS which are programming languages.

As mentioned though you can use JS in Sencha, which is how their components are written, as in Flex where components are written in AS.

Comment 34 by Raymond Camden posted on 5/24/2013 at 3:24 PM

Hmm. I'm not sure I'd call JSON like MXML. But - again - I haven't actually looked at Ext/Sencha in quite some time.

Comment 35 by David McGuigan posted on 5/25/2013 at 1:57 AM

Shadow DOM kind of sounds like an !!!importantAndNothingElseIsImportant equivalent.

Comment 36 by lionleaf posted on 5/29/2013 at 12:45 PM

I definitely agree with you on this: "web developers are probably also somewhat behind in their HTML knowledge as well."