All posts tagged gio

The theme for this week seems to have been “building a consistent web platform.” The question of whether this is a real focus in my circles for the week, or the mere overactive pattern recognition of my human brain, is moot. Here are some of the items that caught my attention:

Normalizing CSS

A colleague sent an article Introducing Normalize-OpenType.css. It looks pretty handy to me – I have never been a fan of browser inconsistencies, and anything that can bring them in line to have a consistent base on which to build is valuable in my books.

Naturally this caused me to check out the original normalize.css project, so there’s another hole in my knowledge patched up.

No more frameworks

Earlier in the week I listened to JavaScript Jabber episode 112:Refactoring JavaScript Apps Into a Framework with Brandon Hays, in which Joe Eames brought up No more JS frameworks by Joe Gregorio. The discussion got me interested, so I looked it up and started reading. In the article, Joe (the latter Joe) promotes the use of the core web platform (HTML + CSS + JS) directly, over abstracting it away behind frameworks. Joe argues that frameworks require developers to learn an extra layer of abstraction, but do not free them from dealing with the underlying platform since the abstractions are inevitably leaky. Joe advocates using web components to get reusable pieces of functionality that don’t have the compatibility issues of framework-specific components.

Libraries compose, I can keep adding more. Frameworks surround, I can have only one. @raganwald

All this talk of moving away from frameworks brought to mind, which was presented at the latest CampJS last month by Jonathan Ong. This is a really interesting project that aims to do away with a whole lot of the extra mess used in web development at the moment, such as package managers, build systems and their glut of accoutrements.

The enduring aim of the project is to support a workflow in the Normalize philosophy, allowing developers to use ES6 modules and Web Components with no need for local build tools. provides a suite of tools to support this workflow. The enduring tools are an intelligent file server that deals with dependencies and uses SPDY push (removing the need for file concatenation), and a caching proxy that understands semantic versioning and acts as a registry for all clients. Since the requisite browser features are not yet manifest, there is also a temporary tool, nlz, to fill in the missing functionality until browsers can take over.

“Once browsers support ES6 modules and Web Components, nlz(1) will be completely optional, and it’s main purpose will be dependency inspection”

Later in the week I re-listened to the NodeUp 65: A CampJS Show, in which Jonathan discusses some of the philosophy behind Normalize.

Web Components

Web components require 4 different pieces of browser functionality: templates, custom elements, shadow DOM and imports, according to today’s draft of Introduction to Web Components by W3C. It looks like none of these parts are yet fully endorsed by W3C, according to Web Components Current Status | W3C. The various stages of the endorsement process are shown in the W3C Process Document, 7.4 Advancing a Technical Report to Recommendation, but it is a little dry and does not exactly match the terminology on the status page; suffice it to say that in the present one does not simply use web components.

So how does one use web components without browser support? One uses polyfills. Joe Gregorio’s “No more frameworks” article mentions several polyfills to look into: Polymer, X-Tag and Bosonic.


In keeping with the theme, while I was getting ready for work on Thursday morning I saw a tweet by Domenic Denicola linking to the Google IO live stream. I managed to catch part of a couple of web component talks: Polymer and Web Components change everything you know about Web development and Polymer and the Web Components revolution.

According to Addy Osmani in the Componentize the Web video, Polymer provides a convenient and opinionated layer on top of vanilla web components. This strays a little from the theme of filling in the inconsistencies of the web platform to work with standard technologies, since it adds data binding, event handlers and touch gestures on top of standard web components. My instinct is concern, but I get the impression that the additions can be safely ignored, so concern is probably an overreaction.