In 2008 I (Martijn Faassen) built a library called
hurry.resource. It could automatically insert the required
<include> tags into HTML. You could describe
these resources in Python code. It was aware of resource dependencies,
and also had a facility to automatically included minified versions of
particular resources, or bundled versions that included a number of
hurry.resource in the context of applications based on the
Grok framework. The Grok integration was involved; you had to hook in
at the right place to manipulate the HTML, and
not serve static resources itself; it left that up to the web
framework too. While I had written
hurry.resource to be
web-framework independent, to my knowledge nobody used it outside of
hurry.resource in turn was inspired by a library called
zc.resourcelibrary, which did much the same but had a more limited
way to describe resources. The resource metadata system was inspired
by the system in YUI 2.
In 2010, I, Jan-Wijbrand Kolman and Jan-Jaap Driessen rewrote
hurry.resource into a more capable library. We had the realization
that by going with WSGI and by making the system serve resources as
well, we could create a true web framework for static resources. We
decided to rebuild
hurry.resource into Fanstatic.
We were also inspired by the capabilities of z3c.hashedresource, a library for Zope 3 that could generate cache-busting URLs that aid caching and development (see Caching). Since Fanstatic controlled both creating inclusions for resources as well as serving them, we could bring cache busting behavior into Fanstatic.
Another clever hack of Fanstatic was to leverage the Python packaging infrastructure (PyPI, setuptools, etc) to distribute static resources and their descriptions. This way we could easily install a variety of client-side libraries, as long as someone had wrapped them using Fanstatic. The community wrapped quite a few libraries.
hurry.resource, Fanstatic is easy to integrate into any
WSGI-based web framework. This helped Fanstatic to become a moderately
successful open source project. It was adopted not only by Grok users,
but also by many others that use WSGI-based web frameworks. We got
quite a few contributions, and a range of advanced features were added
to Fanstatic beyond that
hurry.resource already provided.
Using the Bower package manager, we can install client-side components without having to go through an intermediary.
Fanstatic has another limitation: just like in Python, you can only have one version of a library installed per project. I was facing a use case where this was not desirable: a large platform with multiple sub-projects that might want to use divergent versions of their client-side components.
So I started thinking about what a static web framework might look like that uses Bower as its underlying packaging system, while retaining some important features of Fanstatic, like automating insertion of link and script tags, static resource serving, and caching.
BowerStatic was born.