Tuesday, September 16, 2014

Web Components

I must have come across mention of “web Components” one of the times I reviewed the emerging standards of HTML5 – but put them to one side against the day when they became concrete enough to be worth following up. For them to become established we needed browser support for some specific items, namely; HTML Imports, Shadow DOM, Templates and the ability to define and consume web components. I think I looked away for too long but fortunately ran into a Google IO presentation on Polymer http://www.polymer-project.org/resources/video.html

It looked to me, when watching the video, as if web components addressed a few issues that came up while we were building a very large web application as part of our SBRI “Proof of Concept” project earlier this year. So what were some of the things we found “good” and some things we found “bad” when building a very large web application?

Certainly we have to list JavaScript modules under the good heading. This approach to developing JavaScript allowed us to write a lot of code with explicit name spaces and without having to worry about variable scope leaking. We ended up with a lot of modules dedicated to a particular set of functionality and happily “chatting” between themselves to ensure there was a consistent view of application state. You can find a clear introduction to the code pattern here http://toddmotto.com/mastering-the-module-pattern/ if it is unfamiliar.

As a great deal of the JavaScript was involved in DOM manipulation we saw jQuery as a foundation technology and used custom jQuery UI Widgets to enhance the UI and provide re-usable code that addressed repeated functionality within the web page. As an example, we have a fancy custom widget that consumes html tables and turns them into sortable, searchable, scrollable data grids with the support code encapsulated in just the same way as our JavaScript modules but capable of supporting multiple instances. This was a good start but did not go very far in reducing the overall volume of html that had to be written and de-bugged. Editing thousands of lines of HTML can be quite a burden – it is easy to get lost – so one thing that was bad was that it is difficult to break html pages down into modules and particularly difficult to re-use blocks of html when similar layout and functionality is required in multiple places within a web page. Some sort of “templating” could be just the thing here if you could just “import” a reference to a given template.

CSS3 was a surprise late entry on the “bad” list. Don’t get me wrong, CSS is brilliant and allows us to style and add functionality to a web page in an ordered and predictable way. However there are times when you just wish you could turn it off for a given section on a page. You have some html elements that are being styled incorrectly at a particular point as “rules” cascade. Unpicking or backtracking the cascade and then adding to the CSS to override particular styling for specific elements (or groups of elements) can be time consuming and adds to the volume of traffic that needs to be downloaded to render the page in the browser. Wouldn’t it be nice to be able to just define some specific CSS rules that apply to a given web page section with no interference from any cascaded or global settings? What you need of course is a “Shadow DOM” – a place where CSS rules can only penetrate from “outside” when you explicitly define that behaviour.

The Polymer project https://www.polymer-project.org/ from Google introduces some excellent core web components that you can build upon to create new components of your own. They lend themselves to responsive design techniques http://en.wikipedia.org/wiki/Responsive_web_design and provide the foundation for re-usable web page chunks (that can, indeed should, include CSS and JavaScript) ready to be applied with local overrides as required. Components can be nested and combined to create a highly functional UI with the code modularised and organised in a way that is particularly attractive to developers and (I strongly suspect) designers.

This is not a technical blog (although this post strays into technique) so I won’t get into the detail of getting web components up and running but I can say that it is very simple and you can ignore things like bower, python web servers and node.js (not that node is not a great tool in its own right) and get things quickly working with a vanilla web server (even IIS Express).

1 comment:

  1. Forgot to add that one of our great designers got me looking at LESS which I did not quite get 'till I saw what Trello were doing with it. Now I am on board.