Toolkit: A Front-End Framework for the Modern Web

Titon Toolkit, or simply Toolkit, is a project that I’ve been working on in my free time for the past 4 years. It started out as a MooTools UI framework, which slowly transitioned to jQuery, with plans to be vendorless for 3.0. So why did I write another framework? At its inception, the world of “CSS/JavaScript frameworks” was still young, with Bootstrap and Foundation being about a year old. I was intrigued with the concept of a front-end framework and set out to build my own, with the main selling point being customizability and extensibility.

So, what is Toolkit exactly? Toolkit is a front-end framework that provides a collection of powerful state-based, role-specific user interface components and utility classes for the responsive, mobile, and modern web. It makes use of the latest and greatest in technology — HTML5 for semantics, CSS3 for animations and styles, Sass for CSS pre-processing, Gulp for task and package management, and powerful new browser APIs for the JavaScript layer, just to name a few.

Titon Toolkit website

The core of Toolkit is based on strict but important design principles, which include responsive design, mobile-first design, semantic markup, progressive enhancement, graceful degradation, continuous integration, and configuration over convention. These principles ultimately shape the decisions behind Toolkit.

So, is Toolkit just another front-end UI framework? Yes but, as mentioned, with some key differences: Toolkit was built to be extremely extensible, easily customizable, and efficiently architected.

Let’s look at some of its unique features.

Decoupled JavaScript, CSS, and HTML

A running paradigm in front-end development is tying JavaScript to a fixed CSS structure via class names as well as a fixed HTML structure. Toolkit disagrees with this approach and strives to decouple the CSS, JavaScript, and HTML as much as possible, which opens up the possibility of customizable alternatives. Toolkit mitigates many coupling issues by requiring specific data attributes — all of which are used for element traversal, look-up, and event binding.

The following example uses Toolkit’s carousel component as a proof of concept.

<div class="carousel" data-carousel>
  <div class="carousel-items">
    <ul data-carousel-items>
      <li>...</li>
      <li>...</li>
      <li>...</li>
    </ul>
  </div>

  <button type="button" class="carousel-prev" data-carousel-prev>
  </button>
  <button type="button" class="carousel-next" data-carousel-next>
  </button>
</div>

With decoupling in place, custom HTML is now possible, which isn’t the case when using alternative frameworks. No longer is the markup tied to the JavaScript component; the JavaScript component is now tied to the markup via data-* attributes. Want to add new markup to a component? Go for it! Want to change the markup to match the project? Feel free! Want to remove component functionality? Remove away! Data attributes provide what we think is a much better level of customization.

Easier CSS Styling

Tired of having to overwrite styles? Or dealing with bloat? Toolkit sure was. Because of this, the CSS found in Toolkit is extremely lightweight as it only defines the very bare minimum for the component to function correctly — mainly layout and structural styles. You could say that Toolkit is a themeless and styleless front-end framework. By being themeless, Toolkit is easy to style, and even easier to integrate.

Furthermore, Toolkit opted out of providing Sass variables for CSS theme customization (e.g. for border size, background color, text size, font family, etc). If you want to style an element, you can do so the old fashioned way, using CSS (or Sass, or Less)! You can also take this a step further by integrating Toolkit as a Compass extension, which allows for Toolkit’s Sass files to be imported into scope and compiled directly in your own Sass files.

Customizable CSS Class Names

Another pain point found in existing frameworks is CSS class name collision. Toolkit resolves this issue in one of two ways.

The first way is through customizable Sass variables that allow most CSS class names to be customized. Using this approach will require compilation of the Sass files, either through a Compass extension, or in the source directly.

// Built-in BEM classes!
$carousel-class-items: bem("carousel", "slides");

The second approach allows for global namespacing by prefixing classes. This works wonders when integrating the framework into an existing codebase where collisions are abundant. Enabling namespaces is as easy as modifying a Sass variable and a JavaScript property.

$namespace: "tk-"; // Sass
Toolkit.namespace = 'tk-'; // JavaScript

Do note, however, that namespaces are not applied to state, animation, or behavioral class names.

Extensible JavaScript

The entire JavaScript layer in Toolkit is built around a flexible inheritance based object-oriented class system. Each class manages its own state, events, and behaviors, which allow for complex interactions as each instance is unique. Since this class layer is so flexible, it allows for custom classes to be written, or existing classes to be extended via inheritance.

var Toolkit.Tooltip = Toolkit.Component.extend({
  constructor: function() {
    // ...
  }
});

On top of this, each class supports a set of options for customizability. These options can be set globally, through the constructor, or as data attributes. Option groups and even responsive options are built into the core.

$('.carousel').carousel({
  itemsToShow: 1,
  itemsToCycle: 1,
  autoCycle: false,
  responsive: {
    tablet: {
      breakpoint: '(min-width: 641px)',
      itemsToShow: 2
    },
    desktop: {
      breakpoint: '(min-width: 1281px)',
      itemsToShow: 3
    }
  },
  groups: {
    static: {
      infinite: false,
      loop: false
    },
    dynamic: {
      infinite: true,
      autoCycle: true
    }
  }
});

Flexbox Support

Although experimental, Toolkit offers built-in flexbox support through the Flex component. The Flex component shines in the building of layout and grid based structures through the concept of regions and blocks. A region is an object that contains blocks or other regions, while a block is an object that contains content and is aligned within the main and cross axis. Although being analogous to rows and columns, regions and blocks are packaged with additional support for growing, shrinking, ordering, wrapping, nesting, alignment, and responsiveness.

<div class="region region--grid flow-center">
  <div class="block no-shrink">...</div>
  <div class="block">...</div>
  <div class="block order-2">...</div>
  <div class="block order-1">...</div>
  <div class="block">...</div>
  <div class="block no-grow">...</div>
</div>

Feature Packed

Besides the highlights already mentioned, Toolkit supports an array of features that include:

If you’d like to test out some of Toolkit’s components, you can visit this interactive demo page.

Down the Pipeline

The JavaScript ecosphere is constantly evolving with new technology, functionality, and specifications. Toolkit aims to be a part of this evolution by continuously staying in sync with the latest JavaScript developments. The roadmap as it currently stands includes the following breaking, but interesting, changes for the next 3.0 major release, some of which have already started development.

  • Target evergreen browsers and their previous 3 releases.
  • Remove jQuery as a dependency and polyfill any functionality not present.
  • Rewrite the JavaScript layer using ECMAScript 6 functionality like classes, arrow functions, modules, generators, promises, and more.
  • Integrate Babel for ES6 -> ES5 compilation.
  • Integrate template rendering instead of DOM manipulation.
  • Look into using webpack as the bundler and build tool.
  • Add Less support by integrating a Sass to Less transpiler.
  • Rewrite components using a flux-based uni-directional data flow system

There’s also some discussion about integrating with external frameworks, but this is currently under RFC.

  • Polyfill integration for missing browser features
  • Custom web components through Polymer or another service
  • React and Toolkit component integration

Why not help my work on Toolkit by offering some advice on the direction it should take? Community feedback and contributions are very much appreciated! I’m always looking for new team members and contributors, so if you’re interested, come chat in #titon on freenode.net.

In Closing

It’s been a wonderful experience showcasing Toolkit and its features to all of you. I hope you enjoyed it and find as much use out of Toolkit as I have. If you’re looking for any more information on Toolkit, I suggest visiting the official website, our Twitter account, or the GitHub repo. Cheers!

Sponsors

Replies

  1. Honestly, thanks for reading the article. I appreciate it.

    I do agree that this article is a self promotion type of article, but I wouldn't label it shameless. I shouldn't be ashamed of my work, or this article, as I'm simple talking about it, not forcing anyone to use it. Just my two cents.

  2. I'm the editor for the HTML/CSS content and I can tell you right now that we don't have enough of this type of "self promotion". I would love it if more framework, library, plugin, and tool authors would write honest, down-to-earth articles on their experience building their projects and how those projects can help developers. When the tool is open source, it's hardly "shameless". In fact, we pay for these articles just like any others.

    Of course, that doesn't mean we only want promo articles. We aren't going to publish too many like this, but I don't think we do enough of these. Anything to help new tools get noticed is more than fine by me.

  3. No problem, don't worry about it. And just to be clear: I kind of took your comment to be somewhat half-joking anyhow, so I don't think it's a big deal. You did say "nice" so to me you were saying "good job, self promoting is shameless, but that's ok".... Maybe @RyanReese was a little overly sensitive on this one. wink

  4. First off, to call this "shameless self-promotion" is disingenuous. Besides, when someone has put this much effort to something - in their free time, no less - they're quite entitled to shout about it!

    As for the framework itself. I'll be honest, my first thought was predictable - "another front-end framework?!?". But then I looked at it in more detail, and I like a lot of what I see.

    I'd like to make some comments and observations in list-form, if I may?

    • I'm not all that keen on some of it visually, but that's a moot point - since it's so customisable. I love that the styles are primarily structural, which should make it much easier to style and make unique.

    • Having said that, the demo site might benefit from having alternative "themes" to look at; partly because really good-looking examples will "grab" people, partly because it demonstrates the flexibility.

    • My biggest bug-bear about a lot of JQuery plugins and the like is that they force very specific markup structure on you. Things like carousels in particular. If Toolkit provides more flexibility, that's a great plus-point in my book.

    • The JS being class/component based is great.

    • In fact, modern approaches all round. I particularly like the fact that it uses CSS3 animations where possible.

    • From a personal point-of-view, being RequireJS-friendly is a big plus point. No shims for Backbone work, which is great!

    • Again personal preference, but being SASS-based rather than Less is alright by me!

    • Personal preference once again, but I'd have preferred Grunt to Gulp - but you can't please everyone!

    • Lastly, if there's one thing I think might really help the accompanying website, it's trying to cram as many of the components and styles onto a single page as possible, to make it easier to see what it offers at a glance; having a drop-down and forward/back arrows to browse through the framework is good for viewing components in isolation, but a "single page demo" would, I think, make it more accessible.

    Overall though, really good work!

  5. Two things,

    First I want to thank Sitepoint for publishing this article on Toolkit. I enjoy reading these types of articles.

    Second I want to thank the author, milesj for making this framework available to us all and for an outstanding job of writing the article. I fully intend to give this framework workout once a current project is completed. I like what I've read and am eager to try out the framework.

    Thanks

    Steve

32 more replies