Web development frameworks often are referred to as responsive frameworks, CSS-frameworks, or web-design frameworks—all which in this article are 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, templates, and plugins which often can be implemented by simply copy-pasting a few lines of code. The popularity of web frameworks is well illustrated in the market statistics of Bootstrap (2019), one of the leading development frameworks. Estimated to run 18.7% of all current websites on the web (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 rapidly launched to a low cost, all frameworks comes with several hidden costs that 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 benefits of using web development frameworks and then continues to discuss some of the drawbacks.
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 function and, in most cases, developers using frameworks can be confident 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 its features documented.
Finally, all popular frameworks also have forums and communities where solutions for common issues often can be found 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, also offer pre-written style-classes, 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 comprehensive as Bootstrap with thousands of pre-written classes and hundreds of plugins, every framework are created to solve a wide range of problems. Even if a developer use just a fraction of the features offered by a framework, visitors to sites developed using the framework, still will end up downloading thousands of lines of code which never will be used—ultimately affecting 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 seen in Figure 1, below. As illustrated in this example, a single DIV has ten different stacked classes; each with a separate style definition spread over multiple files.
Fig 1: Class declarations presented on Bootstraps standard blog template (Getbootstrap.com, 2019a)
The problem with this coding approach is that changing the out-of-the-box design and behaviour even on a simple button, demands the developer to locate and change multiple CSS-files and many different CSS-instances which 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, it actually make take considerable more time locating which documents and classes that drives the styling of the element you wish to tweak, than 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 adhering to the latest coding standards. Two examples are accordions and light-boxes; functionality which can be implemented using only a few lines of standard HTML and CSS and without a single line of JavaScript. All leading frameworks, however, instead of utilizing standard HTML and CSS, rely on outdated JavaScript solutions for features such as these, and some even demands additional frameworks such as jQuery for them to function, basically adding thousands of lines of code.
Arguably, framework plugins are complex as they need to be guaranteed to work also for older 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 the 98% and to implement a simple fallback for the 2% who 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 using a framework.
It might be true that frameworks shorten development cycles and enable projects to be launched speedily. But while the cost for getting the first iteration of a website hastily 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). While a framework might be supported today with regular updates and an active community, there is never a guarantee that so will be 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 in the specifics of the framework used, 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), resulting in 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, below, is the published content.
From a design perspective, the problem with using a framework however, is not mainly 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 the objective- or subjective culture of the people who developed it, but might be detrimental when used for communicating to other cultures or types of audiences.
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 would never consider basing their work 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 ready made templates when it comes to the design of their digital assets and not even question the idea of using the generic design offered by a framework which is neither grounded in their business objectives, design guidelines—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 stand out from its competition and is grounded in 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 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 reasons to why developers rely on frameworks: quick solutions to common tasks and problems, and pre-written code.
For an agency or free-lancer developing even as little as five or ten projects per year without using frameworks this argument, however, 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 then will then 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 code inventory, 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 development frameworks. 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 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 hundred thousands 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 make up more than three to six months of work (Erickson, 2019; RC Design, 2017; Hendrickson, 2019; Koopmans, 2014). Using a development framework might shorten this initial development phase with a few months, but seen from a larger perspective, 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.
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 significantly 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 using a specific framework which, a few years down the road, might no longer be in fashion and actively supported.
These facts also are true even if you are a single developer working only with small businesses. If you document your work, you will quickly build your own repository of code which will include solutions to your most common tasks and problems and which will enable you to get your next project out of the door as quickly as when using a commercial framework—if not even 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 does not wish or can afford to pay for an agency or professional developer. If this speaks to you, frameworks are a great tool as they will enable you with just some basic knowledge of HTML and CSS to launch a professional looking website.
- References
- Allen, I. (2019). The Brutal Lifecycle of JavaScript Frameworks – Stack Overflow Blog. [online] Stack Overflow Blog. Available at: https://stackoverflow.blog/2018/01/11/brutal-lifecycle-javascript-frameworks/ [Accessed 25 Apr. 2019].
- Atlanticbt.com. (2019). How Much Does an eCommerce Website Cost in 2019?. [online] Available at: https://www.atlanticbt.com/insights/how-much-does-ecommerce-website-cost/ [Accessed 24 Apr. 2019].
- Awwwards.com. (2019). What are Frameworks? 22 Best Responsive CSS Frameworks for Web Design. [online] Available at: https://www.awwwards.com/what-are-frameworks-22-best-responsive-css-frameworks-for-web-design.html [Accessed 24 Apr. 2019].
- Backbonejs.org. (2019). Backbone.js. [online] Available at: https://backbonejs.org/ [Accessed 25 Apr. 2019].
- Callahan, E. (2005). Cultural Similarities and Differences in the Design of University Web sites. Journal of Computer-Mediated Communication, [online] 11(1), pp.239–273. Available at: https://doi.org/10.1111/j.1083-6101.2006.tb00312.x [Accessed 25 Apr. 2019].
- Collins, M. (2016). Web Design Trends: Why Do All Websites Look The Same? | Friday Blog. [online] Friday Digital Agency | A Digital Marketing & UX Agency based in Dublin. Available at: https://www.friday.ie/blog/why-do-all-websites-look-the-same/ [Accessed 25 Apr. 2019].
- Crestodnina, A. (2019). What is the average website lifespan? 10 Factors In Website Life Expectancy | Orbit Media Studios. [online] Orbit Media Studios. Available at: https://www.orbitmedia.com/blog/website-lifespan-and-you/ [Accessed 24 Apr. 2019].
- 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.
- Dechalert, A. (2019). The homogenization of web design is the reason why every website looks the same. [online] Medium. Available at: https://medium.com/@PurpleGreenLemon/the-homogenization-of-web-design-is-the-reason-why-every-website-looks-the-same-843086610208 [Accessed 25 Apr. 2019].
- Emberjs.com. (2019). Ember.js: A framework for ambitious web developers. [online] Available at: https://emberjs.com/ [Accessed 25 Apr. 2019].
- 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.
- Forsyth, M. (2014). Collins English dictionary. Glasgow: Collins.
- Getbootstrap.com. (2019). Blog Template · Bootstrap. [online] Available at: https://getbootstrap.com/docs/4.3/examples/blog/ [Accessed 25 Apr. 2019].
- Getbootstrap.com. (2019). Bootstrap. [online] Available at: https://getbootstrap.com/ [Accessed 24 Apr. 2019].
- GigaSpaces. (2019). Amazon found every 100ms of latency cost them 1% in sales.. [online] Available at: https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-latency-cost-them-1-in-sales/ [Accessed 24 Apr. 2019].
- 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].
- Hofstede, G., Hofstede, G. and Minkov, M. (2010). Cultures and organizations. McGraw-Hill.
- Knockoutjs.com. (2019). Knockout : Home. [online] Available at: https://knockoutjs.com/ [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].
- Mantri, N. (2019). The Business of web performance: how slow website eats up your revenue | Dexecure. [online] Dexecure.com. Available at: https://dexecure.com/blog/business-web-performance-slow-website-eats-up-your-revenue/ [Accessed 24 Apr. 2019].
- Müller, B. (2018). Why Do All Websites Look the Same?. [online] Medium. Available at: https://medium.com/s/story/on-the-visual-weariness-of-the-web-8af1c969ce73 [Accessed 25 Apr. 2019].
- Quora.com. (2019). Does coding webpages in bootstrap make them load slow? – Quora. [online] Available at: https://www.quora.com/Does-coding-webpages-in-bootstrap-make-them-load-slow [Accessed 24 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].
- Reinecke, K. and Gajos, K. (2014). Quantifying Visual Preferences Around the Worldhttps://www.eecs.harvard.edu/~kgajos/papers/2014/reinecke14visual.pdf. SIGCHI, [online] 1(1). Available at: https://www.eecs.harvard.edu/~kgajos/papers/2014/reinecke14visual.pdf [Accessed 25 Apr. 2019].
- SimilarTech. (2019). Backbone.js Market Share and Web Usage Statistics. [online] Available at: https://www.similartech.com/technologies/backbonejs [Accessed 25 Apr. 2019].
- SimilarTech. (2019). Ember JS Market Share and Web Usage Statistics. [online] Available at: https://www.similartech.com/technologies/ember-js [Accessed 25 Apr. 2019].
- SimilarTech. (2019). KnockoutJS Market Share and Web Usage Statistics. [online] Available at: https://www.similartech.com/technologies/knockoutjs [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].
- W3techs.com. (2019). Usage Statistics and Market Share of Bootstrap for Websites, April 2019. [online] Available at: https://w3techs.com/technologies/details/js-bootstrap/all/all [Accessed 24 Apr. 2019].
- Webfx.com. (2019). Web Design Pricing: How Much Does Web Design Cost in 2019?. [online] Available at: https://www.webfx.com/website-design-pricing.html [Accessed 24 Apr. 2019].