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.

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.

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.

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.

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.

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.

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!

Miles is a full-stack web developer who loves to dabble in PHP, Hack, JavaScript, CSS, and HTML, among a handful of other technologies. As the lead developer behind the Titon Project, his primary focus is a fully featured back-end Hack Framework that runs on HHVM, and an ES6 and CSS3 based front-end user interface Toolkit.

Although I don't have any plans to use this framework in my project at the moment because I have to learn and use Bootstrap for it, I felt this is concise, simple and well-designed when I checked the official web site. So I forked toolkit at github. I want to try it on ruby on rails.One question: are there any compatibility problems with other frameworks, such as compass or susy?thanks.

I did read the article, and was a good article, but doesn't mean my statement isn't still true.

I'm cool if you want to believe that it is self-promotion... because, you are right. And of course, it is shameless! Because SP asked for it. And since SP asked for it. It is NOT spam.

So we will agree that this si self-promotion but not spam.

Now, I think that's clear so we can go back to discussing what's important... the project itself

@milesj Loved the article, nicely written and direct. And it does look like a very interesting project... But I do confess that with so many frameworks out there, I doin't know if to give it a try or not... Call me lazy but right now I just can't choose what framework is better for what

I'm sure that there has been quite a bit of learning for you after developing it for four years. And I bet you're proud of the result. It looks really cool.

But now the I "know" the author, maybe I will push myself a bit harder and give it a try

There should be no collision when using with Compass, especially as a Compass extension (I use this approach in my own projects). The same could be said for Susy but I haven't tested them in the same project before.

However, If there ever are collisions, mainly with class names, they can be customized and changed on Toolkit's end.

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.

I'm curious though... What do you feel that it would be Toolkit's hardest competitor? Do you think about what others do when you upgrade it? Or is Toolkit more a vision of how to build a website?

Sorry if I'm asking too much.

I do have a small project coming up so I will think about using it although I don't know if it will be possible at all because it involves shopify and these type of sites have their own templates so I'm not sure how to ingretate it

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.

I fully agree with you. The article is very well-written and it all makes sense. I didn't think this was going to spark this kind of response, but I can't say I don't like it. I think it's great.

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.

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.

@molona - I'd say that Bootstrap and Foundation are the biggest competitors, simply because the feature sets are very similar. However, I'd say that Toolkit's unique features (JS classes, CSS namespaces, etc), is what will really set it apart.

When working on Toolkit, I take a lot of inspiration from fellow open source projects and developers. I'm constantly iterating and improving on the code base as technology moves so quickly.

@lukaswhite - I'm actually in the process of a new titon.io design that will be accompanied with a new, more advanced demo system. Right now, the demo is a bit sub-par, but it's actually the testing suite I use for development, which can be seen here: https://github.com/titon/toolkit-tests

I appreciate all the feedback! I'll definitely keep it in mind for 3.0.

Nice article..the framework by it selves looks really awesome although the website is just too crowded..hard to find your way around..I can see how it benefits developers searching for a certain functionality although if you see it for the first time..if it wasn't because of your article I would just close it without giving it much thought..right now I am considering though using it for some smaller project

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.

It's always nice to wake up to an article about a new framework that embraces modularity. I dearly want to try it out in two projects of mine (a WordPress theme and a Ruby on Rails site).

One thing that I do find a bit limiting is the drop downs. It's a dicey problem I've found (as a newbie to front-end development) and I want to support click menus in both desktop and mobile. Not having access to nested menus on mobile feels both good and bad; good, because the typical kind of experience is not great on a small screen, but also bad, because I feel there ought to be a way.

Thank you for including ARIA support by the way. I like a web that's accessible, and frameworks that support it are great.... but I'll have to test how good it is in Toolkit when I have more time. At some point I would love to write an article about the accessibility of Bootstrap versus Foundation, and adding Toolkit to the mix is something I look forwards to.

Actually, I invited Miles to write on sitepoint about Titon. As someone who cares deeply about frontend frameworks, code bloat and having to follow someone else's frontend standards, I felt that there is a lot to learn from what he has to say, irrespective of whether you intend to use Titon or not. Not many people maintain an open source software project for that long.

This is pretty exciting! As I read the article, I was looking for one thing. I have to admit, I have been flabbergasted by the lack of knowledge and interest in accessibility more than ten years into the 21st century. Then I saw it "ARIA support". Kudos to Miles for this!

Hi thanks for your Toolkit. It looks good. I like the decoupled JS, HTML and CSS. I also like the fact that using it would me an end to the styling wrestling match that goes on with foundation and bootstrap. And flexbox. Buono.

Great presentation and Toolkit looks really very promising. But the problem with such tools is that there are plenty of them and the amount is growing from day to day. So some short video tutorials will be a excellent way to get many people involved. Do you plan to do something like this? Good luck anyway!

@Dan503 - While it is true that selecting via data attributes is slower than classes, the performance is negligible, as most of the selecting/traversing is done once in Toolkit (or very little), while the context is also per element, instead of the document.

I think I need to put together my own test that spits out the selection time of jQuery class, jQuery attribute as well as the new querySelector() and getElementsByClassName(); selection methods. That would be interesting.

Maybe a .each() method on 100 elements and a single element. That should show how negligible the selection time is.

This is an awesome project, milesj: great the idea of decoupling scripts, CSS and HTML, the minimal styling (it reminds me of the approach behind the underscores base theme for WordPress), the concerns for accessibility, even the project of adding a LESS version for a future release! Great job and well-written article.

One small concern for starting to use your framework would be: after taking care of it for so long, is there any assurance that you'll keep supporting it for at least the same number of years? I know you mention a future release, and I know this is a catch-22 situation: the more people adopt Toolkit the more chances there are that it'll be fully supported, and the more the chances that it gets supported in the future the more people are encouraged to adopt it.

I wish your framework a great success and will start seriously looking into it for my projects