Why frameworks such as Bootstrap do not have a place in a professional web development workflow.

Posted On 25th April 2019

A framework is a standardized set of concepts, practices and criteria for dealing with a common type of problem (Forsyth, 2014) and translated to the world of web development a framework often is defined as a “package made up of a structure of files and folders of standardized code (HTML, CSS, JS documents etc.) [Awwwards.com, 2019].

Web development frameworks which often are referred to as responsive frameworks, CSS-frameworks and web-design frameworks, in this article will be referred to as ‘development frameworks’ or simply ‘frameworks.’

Development frameworks have become increasingly popular as they allow web developers and designers to quickly develop projects by offering readymade code-snippets and plugins which often can be implemented by simply copy-pasting a few lines of code. The popularity of these frameworks is well illustrated in the market statistics of Bootstrap (2019), one of the leading development frameworks. Estimated to forming the basis for 18.7% of all current websites on the Internet (W3techs.com, 2019), Bootstrap is by far the most widely used framework.

While frameworks propose a tempting offer both for the sellers (developers, agencies, freelancers) and buyers as they on the surface looks like a quick fix for getting projects quickly launched to a low cost; all frameworks come with a number of hidden costs which to a large extent are ignored by the framework advocates; often by negligence of their customers real needs and problems, and even more often by incompetence.

This article begins by discussing some of the major arguments made by the proponents of web development frameworks and then continues discussing some of the backsides. Finally; a conclusion is made whether web development frameworks have a place in a professional web development workflow.

Frameworks; the upside.

All frameworks offer ready-made solutions to common development and design problems. By offering pre-written code, starter templates and plugins ready to be copy-pasted, developers quickly can launch projects by not having to re-write code from scratch which saves time and ultimately money for both sides of the buying table.

Framework code also is guaranteed to work and in most cases developers using these frameworks can be sure that the sites they create will work perfectly in all major browsers which saves time and money not having to perform cross-browser testing.

Developing projects using frameworks also comes with the benefit of not having to spend valuable time on documentation as all frameworks have a manual available on their websites.

Finally; all popular frameworks have forums and large communities of developers (remember Bootstrap which drives 18.7% of all websites on the web). Solutions for common development issues often can be found by searching for an answer on these forums as it is likely that someone else has encountered the same issue, and if not finding an answer to a problem, the people in these communities often are quick to help which for inexperienced developers, of course, is very attracting.

Downsides of web development frameworks.

The main value proposition of all frameworks is to give developers and designers solutions and short-cuts to common needs and problems related to developing websites.

All major frameworks, to a varying extent, offer pre-written style-classes and JavaScript snippets and plugins for common functionality such as navigation, accordions and light-boxes. Most frameworks also have start-templates which in principle are finished websites ready to be published after adding a logo, content and tweaking the colors.

While not all frameworks are as extensive as Bootstrap with thousands of pre-written classes and hundreds of plugins; every framework are created to solve a wide range of problems and even if a developer using a framework just for some core element styling like navigation or for defining a grid, visitors to the finished site still will end up downloading thousands of lines of code which never will be used and which ultimately will affect performance and download speed.

While framework proponents often argue that downloading a few hundred KB extra of framework code will not affect performance (Quora.com, 2019), it bears to mind that even a 100-millisecond delay in website loading time can hurt conversion rates by 7% or more (GigaSpaces, 2019; Everts, 2016; Think with Google, 2019).

The goal of all frameworks also is to offer a universal solution easy implemented also for unexperienced developers and most have a structure which separates design attributes in multiple classes as can be seen in Figure 1, below, where, as can be seen, a single DIV have ten different stacked classes; each with a separate style definition spread out in multiple files.

The problem with this coding approach is that changing the out-of-the-box design and behaviour even of a simple button, demands the developer to locate and change multiple CSS-files and many different CSS-instances which any web professional having worked with a framework can testify is an error-prone and time-consuming process of trials-and-errors. While it up-front might appear like you save time by using pre-written style-classes offered by a framework; if you plan to make any adjustments to the out-of-the-box design, in many cases it will take you considerable more time locating which documents and classes that drives the styling of the element you wish to tweak, than simply writing a new class from scratch.

While frameworks offer a simple solution for implementing core functionality by a few lines of code, there is nothing to say that the code offered by the framework is efficient or using the latest standards. Two examples are accordions and light-boxes; functionality which with modern web techniques can be implemented with a few lines of standard HTML and CSS and without a single line of JavaScript. All leading frameworks currently offer plugins for light-boxes and light-boxes, notably Bootstrap, Foundation and UIkit; however, rely on outdated JavaScript solutions which in turn also rely on additional frameworks (jQuery) to function.

Arguably; framework plugins are complex as they need to be guaranteed to work also for old browsers, but if your analytics data shows that 98% of your visitors use modern browsers you might be better off focusing on making a great experience for these 98% and to implement a simple fallback for the 2% whom not yet have updated their browser. Implementing a framework for functionality such as accordions, light-boxes or navigation simply makes little sense on today’s web as these standard components are easy to implement without a framework.

It might be true that frameworks shorten development cycles and enable projects to be quickly launched. But while the cost for getting the first iteration of a website quickly out of the door, this does not mean that the long-term cost will be lower compared with developing a non-framework custom solution adapted to the exact needs of the organisation and its customers.

As all frameworks have a limit to their scope; anytime you want to move outside the frameworks standardised structure such as implementing a specific e-commerce platform, a new CMS or want to tweak the standard design, this always question for custom solutions and sometimes extensive refactoring of the framework’s codebase which might demand considerable resources (Atlanticbt, 2019; WebFX, 2019) or even be impossible.

It is also a fact that frameworks come and go into fashion (Allen, 2019) and while a framework is actively supported today with regular updates and an active community, there is never a guarantee that so will be the case three or five years in the future. This is well illustrated by Backbone (2019), Knockout (2019) and Ember (2019); the three most popular frameworks in 2012 but which today have a total market share of less than five percent (SimilarTech, 2019a; SimilarTech, 2019b; SimilarTech, 2019c) and a rapid decrease in updates and community support.

Another important consideration related to hidden costs and technical debt is the cost of training new members of the team in the specifics of the framework and also the fact that it might be very difficult to find a good agency a few years down the road who develop in a specific framework if it have lost in popularity and no longer has an active community.

Using any framework always means building up technical debt and is one of the most neglected areas by framework advocates.

Homogenization of design.

The problem with using pre-defined style-classes and starter templates offered by a popular framework is that your design will borrow the same look as thousands of other sites (millions if you are a Bootstrap user) which include the possibility that you might end up having a website looking exactly the same as your main competitor. As discussed by Dechalert (2019), Müller (2018) and Collins (2016) the increasing popularity of frameworks have led to a homogenization of design on today’s web and many times the only design attribute which differ between the websites of two competing organizations, as can be seen in figure 2, next page; is the published content.

From a design perspective, the problem with using a framework; however, is not mainly a matter of the risk of looking the same as your worst competitor but the fact that preferences of design differ, not only between demographics, but also between cultures (Reinecke and Gajos, 2014; Callahan, 2005; Hofstede, Hofstede and Minkov, 2010; Cyr and Trevor‐Smith, 2004). The design offered by a specific framework might be very attracting for one type of culture or demographic but might be detrimental if used for communicating to another. The problem with blindly adopting a framework is that you might end up implementing a design which seriously hurt your business.

Fig 2: Dribble and Behance; can you see the difference?

It is also interesting to note that while most organisations and agencies when developing brand strategies and traditional communication assets such as adverts would never consider basing their work and strategies on a generic brand manual or advert template found on the Internet, change the colors, add imagery, copy and call it done.

Even in small branding projects and campaigns, clients expect the design to be unique and grounded in the business objectives of the organisation. It is therefore remarkable that even large agencies and companies accept just this when it comes to the design of their digital assets and then not even question the idea of using the generic design offered by a framework which is neither grounded in the core objectives and key results of the organisation; nor have been tested on the target audience of the project.

With the increasing competition and shrinking margins in today’s global markets it is essential that any design used by an organisation stand out from its competition, is grounded in clearly defined business goals and most importantly also is adapted to the needs, wants and preferences of its target audience; three objectives which are very difficult to achieve when using a generic framework code.

Do frameworks have a place in a professional web development workflow?

Before answering this question it is imperative to first consider the main reason developers in increasing numbers are relying on frameworks for their work: the fact that frameworks allow for a quick solution to common tasks and problems by offering pre-written code ready to be copy-pasted.

For an agency or free-lancer developing even as little as five or ten projects per year; this argument has little merit if the code from each new project is documented and modularised so it can be easily implemented in future projects. With each new project, this inventory of code will grow and even a single free-lancing developer after a few projects will have an extensive repository of code-snippets ready to be re-used.

By building your own inventory of code you also save visitors to the websites you or your team create from having to download thousands of lines of unused code as is the case when using any development framework. By developing your own code inventory it also will be easy to implement new technologies; style-classes will be easy to locate and adjust; you will not build up hidden costs and technical debt; and your designs most certainly will have a better chance of standing out and fulfilling your clients business objectives by not looking the same as millions of other sites out there.

For organisations with internal development teams using frameworks makes even less sense. An internal development team with three to five members is a long-term investment making up a few hundred thousand US-dollars per year in salaries and benefits. For a team of five to build a web interface from scratch grounded in extensive usability testing, the exact needs and wants of the target audience and using the latest standards; in most cases do not constitute more than three to six months of work (Erickson, 2019; RC Design, 2017; Hendrickson, 2019; Koopmans, 2014). Using a framework might shorten this initial development phase with a few months, but seen from the bigger perspective and that the average website have an expected lifespan of three to five years (Crestodnina, 2019); delaying a launch with a few months to have time to create a site grounded in the organisations business objectives, preferences of the target audience, and data from usability tests undoubtedly will pay-back long-term.

So; should you use a framework as a base for your work?

If you are a professional web developer, an agency, or an organisation with an internal development team the short answer is no. If documenting and modularising your code in an internal inventory for easy re-use; even after a few projects your development cycles will be even shorter when using your own framework/repository compared to using a third-party framework like Bootstrap, Foundation or UIkit by the simple reason that you will know it from the inside out. You also will not build up technical debt and the work you and your team deliver won’t share the same generic design as millions of other sites out there. Most importantly; you also will not risk being trapped in a framework which a few years down the road no longer is in fashion and actively supported.

These facts also are true even if you are a single developer working only with small businesses. If you start to document your work; even after a few projects your repository of code will include solutions to your most common tasks and problems which will enable you to get your next project out of the door as quickly as when using a framework – if not faster.

The only exception which merits the use of frameworks considering all the downsides discussed in this article is if you are a small business owner or organisation who do not wish or can afford to pay for an agency or professional developer. If this speaks to you frameworks is a great tool as they will enable you with just some basic knowledge of HTML and CSS to launch a professional looking website.

Cyr, D. and Trevor‐Smith, H. (2004). Localization of Web design: An empirical comparison of German, Japanese, and United States Web site characteristics. Journal of the American Society for Information Science and Technology Journal of the American Society for Information Science and Technology banner, 55(13), pp.1199-1208.

Erickson, B. (2019). How long does it take to build a website? – Bill Erickson. [online] Bill Erickson. Available at: https://www.billerickson.net/how-long-does-it-take-to-build-a-website/ [Accessed 25 Apr. 2019].

Everts, T. (2016). Time Is Money: The Business Value of Web Performance. 1st ed. O’reilley.

Hendrickson, M. (2019). How Long Does It Take to Build a Website? – DreamHost. [online] Welcome to the Official DreamHost Blog. Available at: https://www.dreamhost.com/blog/how-long-does-it-take-to-build-a-website/ [Accessed 25 Apr. 2019].

Koopmans, T. (2014). How long does it take to design and build a website?. [online] Lift Interactive. Available at: https://liftinteractive.com/blog/how-long-does-it-take-to-design-and-build-a-websi/ [Accessed 25 Apr. 2019].

RC Design. (2017). How Long Does it Take to Build a Website That Looks Great & Works?. [online] Available at: https://rcdesign.com/how-long-does-it-take-to-build-a-website-that-looks-great-and-works/ [Accessed 25 Apr. 2019].

Think with Google. (2019). Find Out How You Stack Up to New Industry Benchmarks for Mobile Page Speed. [online] Available at: https://www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/ [Accessed 24 Apr. 2019].