Configurator tools for green ingredients and AMEE

Right now, the development of websites is zooming forward at a breakneck pace. The code bloat of 2011 is due in part to huge numbers of new libraries, templates, boilerplates, and frameworks being put out there. As 2011 moves to 2o12, we’re starting to see some organization of these choices into “configurator” websites.

Examples of “configurator” websites

Modernizr Production –


CodeKickOff –

In addition more developer-oriented tools allow JS library configuration at a fine-grained level…

Ender –

All these tools allow you to

  • select libraries, files and code snippets
  • add them to a default project

All well and good, but for Green Boilerplate we need some additional features

  • Database linked to description, api, downloads describing the ingredient
  • Data pulls on performance of the component, in particular what happens the first time is it added to a template
  • A key system so that websites can be “scanned” for included ingredients

This implies greater complexity than current boilerplates. Across HTML, CSS, JavaScript and PHP (ASP.NET later) it is necessary to have a system able to parse and document the occurence of each ingredient in the template. In other words, either comments, or internal comments have to be added to each component.

The best idea for this might be an equivalent of JSDoc. Currently JSDoc scans for comments with a specific format, and build web documentation. We can imagine a similar system throwing the results into a database. Ideally, this database is related to the “core” database containing all the ingredients.

  • Core database – lists all ingredients, plus a keycode for identifying them later
  • Site database – uses Core database to scan a site and document ingredients

In such a system, minify takes on a new meaning. Individual ingredients need to have a comment with at a minimum their unique code ID that can be scanned on a production website.

What’s the best way to impliment this? Well, each boilerplate and framework has a bias. Some use Java, others Ruby, and others are UNIX shell scripts. Some are written for server-side JavaScript execution via Node.js. A few, like LESS, provide JavaScript and compiled versions.

My own opinion is that maximum use requires that we not force designers to understand how to install server-side systems on their local computer. Therefore, the only real alternative is browser-based Javascript. However, JS has a limitation in that it can’t burn files to the disk. And so, the winner might (AG) Flash/ActionScript!

Another thing that’s necessary for this Green Boilerplate model to work is a way to access environmental footprints. Fortunately, the new AMEE database, which aggregrates millions of data sources on environmental impact, has an SDK. This SDK allows developers to embed carbon-footprint analysis into their applications.

The SDKs and APIs for Java, Ruby, Python, and PHP look really good. Now, if only AMEE had data on the embodied energy of a web page….

The coolest tools I’ve seen so far that uses AMEE is the AMEE Location Footprinter. It integrates with Foursquare and does a running calculation of your carbon footprint as you go around your daily business.  Truly awesome.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s