An Introduction to Frontend Frameworks

Frontend frameworks have seemingly taken the Web development world by storm in recent years. Anybody operating as a Web developer, designer, programmer or architect, especially those new to this game and even more so those just working Web design as a hobby rather than a full time role, will know all too well the pace at which this industry moves. Keeping up with the relentless speed at which new technologies are released and old technologies are updated is one of the most crucial and critical tasks anybody in this industry must undertake. To not do so for more than a few months results in us feeling lost in a sea of information, unable to consume at a rate any faster than the technological output. Once you’re out of touch, it’s difficult to step back in touch.

And so this leads us to frontend frameworks; arguably one of the most basic, yet genuinely and technically beneficial developments the Web site development industry has seen in recent times. (By the way, when we say ‘industry’, we refer to both professionals and hobbyists… it’s a rare industry that doesn’t distinguish between the two, but ours is one of them).

What are Frontend Frameworks?

You possibly know them as Bootstrap or Foundation. These are the two most popular frontend frameworks, but there are many more that we’ll discuss later in this blog post.

Frontend frameworks themselves are nothing new. In their most basic form, they’re nothing more than a predefined set of CSS classes and Javascript functions for a developer to quickly and easily tap into. Some are even more basic, stripping out the Javascript and just being a list of CSS classes.

This technique of pre-defining pieces of markup for reuse over time has happened for many years, but more often than not in private, whether it be an agency who have built their own classes, libraries and functions to speed up production, or a one man hobbyist who wanted to work smarter, rather than harder. The difference now, of course, is that frontend frameworks have gone public, gone mainstream, and become accessible to the masses.

One of the clear disadvantages to a privately developed, in-house framework, was the leg-work it took to develop in the first place. Sure, it saved those people time and effort in the long run (and I’ve no doubt it was worth it long term) but that initial leg-work to create an in-house framework was (and still is, should you create your own) significant enough to be considered a separate project stream all in itself.

A public, mainstream, accessible and pre-developed framework such as Bootstrap by Twitter or Foundation by ZURB, however, takes this initial leg-work away from the user and places it upon the framework developers themselves. So now frameworks, a concept primarily developed privately to speed up in-house development, have helped Web developers become even more efficient thanks to a bunch of friendly people whose role it is to develop frameworks for those of us not only lacking the time to write all markup from scratch (first problem), but also too strapped for time we can’t even write our own framework to solve the first problem. Clever, and incredibly useful!

Why Would I Use a Frontend Framework?

Frontend frameworks have a variety of benefits, primarily focusing on aiding the developer to speed up production and reduce bugs throughout the markup development stage of all frontend Web development projects.

Speed and Simplicity

The primary goal of frontend frameworks has always been to speed up production for the developer, reduce costs, increase yield, and do so while keeping it simple, concise and straightforward for even the most novice of Web developers. Every good frontend framework achieves this goal, allowing those not familiar with the markup to quickly pick up and learn the defined classes and and functions with minimal effort.

There’s nothing more frustrating than taking charge of a Web site you didn’t develop and having to spend days, or potentially weeks, familiarizing yourself with the previous developers markup. We all have unique handwriting, and HTML, CSS and Javascript markup is the same. Each Web developer has their own unique signature; their own way of structuring markup and their own approaches to common bug fixes. A common, public framework solves this problem immediately, because the structure and markup signature is defined not by the end-user, but by the framework developers, and is recognised the world over.

I could walk into any company, any hobbyist’s office, any agency, and as long as they were using one of the frameworks listed in this article, I’d be able to recognise, understand, and importantly feel comfortable with their markup within a few minutes. That’s the benefit of a common language backed up by a common structure and a common set of rules to achieve common goals. Without a framework, or with a framework developed in-house, this benefit does not exist. Instead, developers are stuck trying to familiarise themselves with inherited markup for the first days or weeks of any project they undertake from a past individual.

Responsive, Cross-Device Support Built In

In a world where the majority of Internet traffic to Web sites in the Western world comes from a handheld device, be it a tablet or smartphone, there’s very little excuse for not catering for this market with a responsive Web site. Developing a responsive stylesheet to target all required screen sizes and devices can be tricky to master from scratch. At what screen resolution should the smartphone landscape CSS kick in? How about smartphone portrait? And don’t forget tablet landscape and portrait. And extra large resolutions seen on some televisions and smartboards. And devices with retina screens. Do you know what the width breakpoint is for all those potential devices and scenarios to allow you to target those individually with CSS? Some of you may. Many others won’t.

While it’s useful to do your research and know (I’d strongly recommend it), just the thought of having to write the stylesheet template to target all those scenarios makes me cringe.

There’s good news though. Most frontend frameworks are built to be responsive, to expand and contract gracefully for any device and any screen resolution.

For example, the ability to hide and show different containers on different screen sizes is nothing more than the addition of a class to your <div>. (<div class=”hidden-xs”> to hide a div on a smartphone device using Twitter Bootstrap, by the way). It’s simple, straight forward, and as long as you have a handy list of all available classes and functions (which we’ll discuss shortly), it’s far easier than having to figure out the exact screen width you need to target and then write the rule to set this div to display:none. Of course, this is still happening in the background, but it has been written for you already and all you need to do is target it with the correct pre-defined class.

Pre-Tested Markup

You can be confident the markup contained within any good frontend framework has been tested and has passed a rigorous set of criteria before it was signed off and handed to you, the end-user. Common and not so common bugs have already been identified, assessed and resolved, leaving you with very little bug fixing to do throughout your project.

The Decision Making Process is Made Easy

While developing Web sites, often the most time consuming aspect is not writing markup, but making decisions regarding the functionality as we code. Even the best designers will sometimes leave elements open for interpretation by the developer, and so making decisions over whether to have a sticky header, sliding nav bar or sticky footer can sometimes fall to us as we code.

Without a framework, implementing some of these would be time consuming and potentially pointless, should we decide to use a different method after we’ve built and seen it working. With a frontend framework, however, switching on elements such as sliding navigation bars, sticky headers and footers and other interactive elements, as well as styling buttons and providing smooth hover effects, is made as simple as adding a defined list of classes to the correct elements in your markup. Now, creating a navigation bar with styled buttons, a drop down menu, and a sticky header, is a five minute job rather than a 30+ minute job.

Detailed Documentation and Wide Support Network

As we discussed earlier, frameworks are very useful when you have the documentation to back you up. It’s a worthless tool without the documentation to explain the structure of the framework and the classes and functions available for you to tap into. Fortunately, all good frontend frameworks come with excellent documentation, and most come with a fantastic community support network, made up of both the framework developers and experienced end-users.

The Flaws of Frontend Frameworks

There are many benefits of using frameworks, but there are flaws too. It wouldn’t be right to discuss one without pointing out the other, so below we discuss a few of the problems frameworks may throw into the mix.

Customization Difficulties

While frameworks and their common structure and rules throughout the markup can be positive in several ways,, this same benefit can also become a flaw when you try to heavily customize a Web site using a framework.

Frameworks must try to find a balance between providing you with ready-to-use elements, whilst also not locking down the functionality and customization ability of these elements. Sometimes, this balance isn’t found, and we end up using functions and classes that are already pre-styled for us and programmed to work a specific way. To deviate from this is often quite difficult. This brings us on to the next flaw.

The Potential for Web Sites to Look the Same

With the struggle to customise specific elements of frameworks, there is always that potential for Web sites to look the same. While it’s absolutely possible to customize the layout of the whole Web site and each individual page, elements on that page could (and probably will) look similar to other Web sites. For example, Bootstrap has pre-styled buttons. While it’s quick and easy to change the colors of these to match your Web site, it’s more time consuming to start changing the hover state, the animation and the gradient effect. Most end-users of a framework only change the basic style settings, such as fonts and colours, which leaves other more subtle styling in place as per the default framework. You might not notice this too much, but I guarantee, once you’ve seen a Bootstrap or Foundation styled button, taken note of the hover and transition effects, you’ll start to spot them all across the Internet.

A Lack of Code Familiarity

While it’s an excellent advantage to use a common framework and be able to edit Web sites the world over within minutes of inspecting the source, once you start trying to edit a framework’s raw markup, instead of just using the system as an end-user, it becomes tricky. With hundreds of lines of CSS and hundreds of lines of Javascript, all written by the framework developers, your familiarization of that code will be non-existent, therefore making it extremely laborious should you wish to edit the framework functionality itself.

A Need to Update the Framework

Like a software package, take WordPress for example, frameworks need to be updated on a regular basis. New releases are developed by the framework teams, bugs are fixed as the community reports them, and new features are produced.

While you may need to update your markup once every few years as new versions of HTML/CSS are developed if you had coded it from scratch with no framework, you may end up upgrading your framework markup every few months. This is both time consuming and potentially risky.

Do we Restrict Our Own Development Knowledge?

One argument against frameworks is they restrict our raw knowledge of HTML, CSS and Javascript. After all, if somebody is providing us with a list of CSS classes, already styled and pre-defined in a stylesheet, as well as a common HTML structure, and pre-written Javascript functions, surely our own knowledge as an end-user has the potential to dwindle. Maybe so, and it’s for this reason that we should always push ourselves and push frameworks to ensure we (and our customers, should you develop for them) always get the best user experience, regardless of whether or not we use a framework.

The Most Popular Frontend Frameworks

So assuming you would like to use a frontend framework, which one do you use? There are many out there, some more popular than others, and some made for those more technical than a novice. Here, we’ll briefly look at some of the most popular.

Twitter Bootstrap

Bootstrap, developed by two employees at Twitter, has widely become the world’s most popular frontend framework.

While not the first framework to be fully responsive, it now is so, and handles all devices and screen resolutions exceptionally well.

There is an excellent community of Bootstrap developers and experienced end-users on hand to help, and the documentation is carefully thought through.

Bootstrap’s classes and functions tend to be very ‘complete’, often styled fully with fonts, colours and the traditional Bootstrap brand. As a result, it can be difficult to steer your ship away from this feel to ensure it looks unique. That said, with some work it is possible absolute possible to develop a Bootstrap Web site that appears custom and unique to you..

Find out more about Bootstrap
.

ZURB Foundation

Quite often the choice between using Bootstrap or Foundation is purely personal preference due to how similar they are, but Foundation has several features that may sway your vote in this direction.

Firstly, Foundation’s elements are not as ‘complete’ at first glance, so steering away from the default look and feel to give your Web site it’s own unique brand is generally very easy.

Foundation, unlike Bootstrap which uses pixels, uses rems for font sizing. While this may seem like a subtle difference, it makes absolute sense to use a relative unit such as rems on a responsive design, as opposed to an absolute unit such as pixels.

Foundation also has some excellent built in features that Bootstrap doesn’t contain, such as built-in form validation and Interchange, a system used to dynamically load responsive content for different browsers depending on device and screen size (this is especially useful for loading smaller images on mobile devices, instead of loading larger dimension images that one might require on a desktop).

In addition, other built in features include right-to-left support to
easily allow you to switch copy so it reads right to left, as well as built in pricing tables.

Foundation has all these features, plus most of what Bootstrap contains, and as a result is often seen as the go-to framework for intermediate to professional Web developers.

Find out more about Foundation
.

Pure.css

One of the largest gripes of developers using Bootstrap or Foundation is the amount of bloated markup these contain. There are thousands of lines of CSS and Javascript, and chances are, you’re only going to tap into and use a small proportion of this.

Pure.css, referred to just as ‘Pure’, combats this problem with its minimalistic take on development. As the name suggests, this framework is purely CSS (ie. no Javascript).

To use it, it’s as simple as including one CSS file in your Web site.

Pure has many different elements that can all be taken and consumed, or you can decide which elements to take and remove the rest, therefore keeping markup bloat to a minimum.

Pre-developed elements include a robust responsive grid system to work on, much like Bootstrap and Foundation, as well as form styling, buttons, tables, and menus.

Find out more about Pure
.

Which Framework Should I Use?

There are so many frameworks to choose from. We’ve listed three above, but there are even more, some more well known than others. Often, the choice comes down to personal preference.

My own preference would always be to choose Bootstrap or Foundation, purely because I know this sets me up well to work on tens of thousands of other Web sites. Should I find myself in a position where I takeover a Web site from another developer, there’s a high chance that developer will have used Bootstrap or Foundation.

When deciding between Bootstrap and Foundation, I often assess the features I know I’ll need for each particular Web site. For example, an Arabic language Web hosting site full of pricing tables is going to push me straight towards Foundation for its right-to-left and pricing tables support.

A basic brochure Web site for a customer looking for something quick and simple with minimal fuss is going to shift me more towards Bootstrap, safe in the knowledge that Bootstrap’s components provide a solid and complete base with which to tweak and amend.

My advice would be to try them all over time and learn them well so you can pick up the correct framework based on your needs for each project.

Should I Even Use a Framework?

It almost feels wrong to ask this question at the end of an article talking about the benefits of individual frameworks, but it’s a question often asked amongst the development community, and ultimately, like all things frameworks, it’s purely personal preference.

If you have the time and inclination to write responsive break points and develop a grid system each time you develop a new Web site, and you prefer to write your own markup for drop down menus and fly-out responsive menus, then my advice wouldn’t be to use a framework. However, I’m almost certain that if you do choose to write all those from scratch, once you’ve done it more than twice you’ll start to save them separately as components to use in future projects. And suddenly, by doing this, you’re starting to build your own framework.

Ultimately, all frameworks are powerful tools to improve our output as developers, whilst helping us to maintain a common structure. They’re an excellent way to quickly and easily develop powerful, user friendly responsive Web sites. Whether you develop your own components and have these quickly to hand, or you use a common, public access framework, our jobs as developers are now a little easier thanks to people trying to work smarter, not harder.