Fork me on GitHub

Why Feaxures?

Feaxure is a combination of Feature and Fixture which means "the fixed state used as a baseline" (with respect to unit testing). Plus, finding a domain these days is tough and when you find a name that has a domain name that is available you should stick with it. :)

What other problems does Feaxures solve?

Besides placing the "progressive enhancement" responsibility to the browser, Feaxures can help with:

  • Don't Repeat Yourself. Defining a feaxure is very easy and it takes very little space (99.99% of the time) and most of the times you're using the same libraries/plugins to enhance a page. This means that you can build a collection of feaxures, put all the required files in a folder that you copy from a project to the next and you're done. No more typing hundreds of times the script tag and domReady events.
  • Refactoring. By placing the feature's definition into an external file it means you only need to make one change for an entire project. Imagine you've been using jQuery UI tabs in many places in your app and you want to optimize by using a smaller plugin. Instead of going back to dozens of files to replace the <script> tags you only go to one place. Of course, each plugin may use different configuration options but you can convert from one set of options into another one right on your feaxures' definition file.
  • A/B Testing. You can decide what features to be active on your feaxures' definition file. For example you can choose to test user's satisfaction for an ecommerce website by comparing a lightbox versus a magnifying glass as methods for viewing product details.
  • AHAH (Asynchronous HTML over HTTP). Many times you're loading pieces of HTML content only when users performs an action (ie: load the content of a tab when the user clicks on a tab). That piece of HTML may contain elements that have features as well. If that's the case you would need to load those files in advance although the user might not ever view that tab.

What about FOUC?

Loading resources after the DOM is ready (eg: load jquery.ui.tabs after the page is displayed to the user) will definitely cause a flash of unstyled content. This can be aleviated using different techniques, like this one. That's why Feaxures doesn't come with one but you can find an implementation on the example.

What if I don't use jQuery?

Feaxure's dependency on jQuery is abstracted away and you can replace the parts that depend on jQuery. The library works with Zepto to some extend but there are some limitations due to Zepto's data() implementation, which uses the data- attribute. I'm using this functionality to store which elements are enhanced or not.

You can customize the Feaxures dependencies to your liking so you're not required to use jQuery.

What loaders should I use?

In my projects I use curl.js because of its small size. I've tested the library agains RequireJS as well. For RequireJS you need to include the proper modules to load JS and CSS file. While RequireJS was build initially as an AMD loader, curl.js was build from get-go as a resource loader (curl stands for CUJO Resource Loader).

If you're using another resource loader all you need to customize your dependencies.

What is the performance hit when using Feaxures?

Obviously Feaxures JS will take its toll with regard to performance but I think the advantages are bigger than the performance hit. I did a simple speed test (available on the Git repository) and there's a 50 milliseconds delay when using Feaxures. Some of it is due to the loader's dependency solving.

What's on the roadmap?

I've tried to cover most of the use-cases with this script but there is at least one case that is not handled well by this script. For example if a user changes the orientation of her tablet from portrait to landscape your design may not require some feature to be active.
Other stuff that needs to be done include: improving the documentation, adding more examples and some new features... not feaxures :).