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.

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:

Underscore.js. This library implements a number of methods that really should be a part of the language. And in a few cases, are (scan that page for the word native). I’ve been a member of ECMA TC39 off and on for a decade and a half, and based on what I have seen, JavaScript will catch up with Underscore in 30 to 50 years.

jQuery. Their official slogan is “write less, do more”. While that’s true, “make DOM suck less” is equally as true. Like with Underscore.js, it predated features like querySelector. One last comment before I move on: abstract away the platform is not true for jQuery (nor for any of the libraries/frameworks I’m mentioning here). The key abstraction jQuery provides is a collection of DOM nodes. You can determine the number of element in the collection by using the length property. You can access individual DOM nodes using indexes: [0], [1], [42], etc.

Bootstrap. While this project contains JavaScript, its true focus is on providing a higher level of CSS constructs than the browsers currently provide. Things like modal dialogs, dropdown menus, tabs, etc. It is worth noting that they do this with “just” HTML+CSS+JS. Sure, you can reinvent these concepts for yourself, but why?

Angular.js. Joe mentioned that he hasn’t needed data binding yet. I’ve written a fair amount of small web applications. Some have grown to become bigger and unwieldy. I’ve taken a few of these and started to separate out the client side model, view, and controller, and in the process found data binding to be quite handy. Now I can write larger web applications, and go back and add features months later without being afraid that I am going to break anything.

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:

Tue 13 May 2014

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.

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.

Wed 14 May 2014

@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”.