It’s just data

Frameworks as Stepping Stones

Joe Gregorio: But something else has happened over the past ten years; browsers got better. Their support for standards improved, and now there are evergreen browsers: automatically updating browsers, each version more capable and standards compliant than the last. With newer standards like HTML Imports, Object.observe, Promises, and HTML Templates I think it’s time to rethink the model of JS frameworks. There’s no need to invent yet another way to do something, just use HTML+CSS+JS.

I’m curious as to where Joe believes that these features came from.  For example, promises were first proposed in the 1970s, made their way into a number of frameworks, were extracted into a common implementation and then standardized.

The true story is that Joe’s “gradient” picture is incomplete:

There’s actually a gradient of code that starts with a simple snippet of code, such as a Gist, and that moves to larger and larger collections of code, moving up to libraries, and finally frameworks:

  gist -> library -> framework

A more complete picture:

  gist -> library -> framework -> standard

And even that isn’t complete.  Standards are backported using polyfills, and frameworks are updated to use feature detection to make use of standard implementations as they become available.

I’ll also mention a few libraries/frameworks I’m fond of, and how they fit:

In each of these cases, I’m confident that the best ideas of these libraries and frameworks will make their way into the web platform.  Meanwhile:

The future is already here — it’s just not very evenly distributed.


Reading this reminds me of a discussion I had a while ago, where we concluded that what Bootstrap does should be just as unnecessary as what jQuery and Underscore does. Having to pile kilobytes of CSS and JavaScript on top of HTML for it to be remotely usable is a joke.

Because let’s face it: A plain HTML document is unusable. Not only by today’s standards, but by any standard. Not doing any sort of alignment, using colors and fonts that are inarguably bad for accessibility and usability is just plain dumb. It has always been dumb. A plain HTML document, with no CSS or JavaScript, should be usable, accessible and beautiful out of the box.

Posted by Asbjørn Ulsberg at

Sez Asbjørn Ulsberg: “A plain HTML document is unusable. Not only by today’s standards, but by any standard. Not doing any sort of alignment, using colors and fonts that are inarguably bad for accessibility and usability is just plain dumb. It has always been dumb. A plain HTML document, with no CSS or JavaScript, should be usable, accessible and beautiful out of the box.”

...Depends on context. (Man, I wish I didn’t need to dash in a second.) I’ll pose my answer as a question: for native apps and heavy duty Web logic we have MVC. Why shouldn’t the visitor-facing Web stack offer something comparable?

HTML describes your data. CSS adds presentation to that, to be changed out at will. JavaScript adds behavior to THAT, again to be changed out at will.

The immediacy and ephemerality (sorry, Sam Johnson) of the Web NEEDS that kind of layering.

Posted by ben at

@Asbjørn Ulsberg: I agree that the average 2014 HTML page will be unusable without CSS (and possibly JS). I feel this is mostly due to all the auxiliary content and decorative markup that is added into every page. A site with pages that only contain semantic primary content and meta-data would still be usable.

It is unfortunate that “separation of content and presentation” is simplified to “HTML is content, CSS is presentation, and JS is behavior”. We shouldn’t forget that:

- Page layout is presentation not content, but it invariably adds HTML elements as layout containers
- Banners, sidebars, footers are not essential content (not why the user is visiting a particular page)
- Semantic HTML has some good (or at least accessible) behaviors built-in.

Given the near ubiquity of AJAX we should feel free to deliver minimalist pages (usable even in “lynx” or ancient browsers) and depend on AJAX to add-in page-layout (HTML), auxiliary-content (HTML), stylesheets, additional-behavior,  etc in a device and browser appropriate manner. You could probably call it “total progressive enhancement”.

Posted by Sean Hogan at

Add your comment