History¶
hurry.resource¶
In 2008 I (Martijn Faassen) built a library called
hurry.resource. It could automatically insert the required
<script>
and <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
files.
I used 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 hurry.resource
did
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
Grok/Zope 3.
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.
Fanstatic¶
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.
Unlike 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.
BowerStatic¶
A bottleneck of Fanstatic is that someone needs to sit down and write a Python package for each JavaScript project out there. This takes time. To upgrade a package to a newer version can be cumbersome. Fanstatic makes the developer of Python wrapper library the intermediary, and while this intermediary can add value, they can also be an obstacle.
By 2014, a lot had changed in the client-side world. Fanstatic’s reliance on the Python packaging infrastructure was turning from an advantage into a drawback. Bower has become the de-facto way for many client-side libraries to be distributed and installed. Faced with the task to wrap a range of JavaScript libraries using Fanstatic and then maintain those wrapping libraries, I decided to give Fanstatic a rethink instead.
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.