Executive Summary (TLDR)
Asynchronous JavaScript in the form of Single Page Applications (SPA) offer an incredible opportunity for improving the user experience of your web applications. CSS frameworks like Bootstrap enable developers to quickly contribute styling as they’re working on the structure and behaviour of things.
Unfortunately, SPA and CSS frameworks tend to result in relatively complex solutions where traditionally separated concerns - HTML-structure, CSS-style, and JS-behaviour - are blended together as a matter of course — Counter to the lessons learned by previous generations.
CC BY-SA 401(K) 2012
This blending of concerns can prevent entry level developers and valued specialists (Eg. visual design, accessibility, search engine optimization, and internationalization) from making meaningful contributions to a project.
In addition to the increasing cost of the few developers somewhat capable of juggling all of these concerns, it can also result in other real world business implications.
Examples include:
- litigation
- flat growth
- inability to pivot
- missed opportunities
- recruitment and staffing nightmares
What may appear to be a prudent technology decisions could result in long term costs as maintainability issues come to light.
The potential cause of this trend could be the movement of traditional backend developers into the frontend coinciding with the shift from server-side to client-side web applications. In an attempt to augment their own weaknesses, these new entrants are introducing tools and practices which serve their own needs, but fail to consider the organization as a whole.
If the upfront value of CSS frameworks are desired, it’s recommended that you avoid baking them into your application directly. Instead, use them as decorators for your own in-house CSS framework designed around domain specific business language.
For SPA frameworks, it’s recommended to adopt coding practices which enforce a healthy separation of concerns. While this can be done with React, Vue.js offers a superior approach to achieving this which invites better collaboration with more traditional frontend developers.
Index
- Preface
- Background
- History: Asynchronous JavaScript | CSS Frameworks
- Symptoms: Div Soup | Blending of Concerns
- Problems: Elusive Ninjas | Loss of Expertise | Loss of Nimbleness | Problem Impact Summary
- Root Cause: Backendification
- Solutions: Dealing with CSS Frameworks | Dealing with SPA Frameworks
Clap and Follow: Mike Taylor
Preface
In 2014, I entered a web design program at the British Columbia Institute of Technology (BCIT). Upon completion, I was recruited by the school to help with online learning. When they told me I would be working with Bootstrap, Twitter’s super trendy CSS framework, I got pretty excited…
It wasn’t long before that excitement wore off though. After working with it, I couldn’t help wondering why it was even necessary. The cryptic class names and liberal use of <div> tags seemed to stuff all the logic into the HTML. Soon, complaints started to come in as other functional groups struggled with the new overhead.
We were a Technical Institute, but our department was designed around instructor success. The online courses our team produced would eventually be put in the hands of non-technical instructors from business, media, nursing, construction, etc. If they couldn’t figure it out, they would call Ed-Tech Support. If Ed-Tech couldn’t figure it out, the work would land back on our desks [often with a giant *thud*].
This was catastrophic because all of us were criminally under staffed. Instructors were stretched thin, support was always swamped, and our team was the narrow bottleneck that instructional design consultants would try to ram courses through right before term-start.
These frameworks lured us with the promise of ease and simplicity, but it turns out those are relative terms. For us, Bootstrap (and some other failed experiments) resulted in a lot of struggle with little reward. It was just a maintenance trap in disguise.
After a few months of hinting, the team started to buy into the vision of creating a custom framework designed around actual simplicity (or rather stripping all of the complexity out of the HTML). A solution designed around super clean code using terminology specific to online learning.
The resulting product(s), became wildly popular, despite a small barrage of political setbacks still scarring it (and me) today. In addition to completely eliminating the maintenance challenges, it also improved both quality and efficiency across the entire online course life-cycle.
Most importantly, our team was no longer the bottle neck pinned up against hard-deadlines.
Since then, I’ve grown more wary of frontend tools and their rampant proliferation. I tend to think our department’s lack of technical depth may have allowed us to spot the inherent problems just a little sooner than normal. My concern is these tools are being adopted in the interests of their implementers rather than the organization as a whole. It made me wonder:
Are many of the modern frontend tools and practices just technical debt in disguise?
Background
Before web development, I finished a diploma in Marketing Mangement Entrepreneurship plus a few courses towards a BBA. My particular interests are in Product Management, Organizational Behaviour, Operations Management.
I have no doubt my opinions will be controversial to some. Please respect the fact that I’m attempting to make reductions that are generally applicable rather than axioms whose truth is unquestionable. This is simply an effort to evaluate relatively narrow technical decisions from the wider perspective of an organization as a whole. Whether or not these ideas are relevant to you will depend heavily on the specific context of your business.
History
Asynchronous JavaScript
In 2005, Google astounded the world with the launch of Google Maps. Drag the screen and, like magic, little tiles would pop into view, one by one.
For many, this was the first time they would experience the power of AJAX in action. It was the “killer app” that proved client-side applications had the potential to deliver massively superior user experiences. This was a major step forward on our journey towards the modern Single Page Application (SPA) of today.
CSS Frameworks
In 2011, Twitter, the envy of the technology world, welcomed us into their style of development using Bootstrap.
Bootstrap was the first widely adopted CSS framework “Built for and by nerds” “For all skill levels”. It instantly lowered the bar for working on the frontend. Suddenly, every backend developer coding a server side page template could slap a few classes onto the elements and voila — No CSS necessary. They gained powers that matched and even exceeded the abilities of a large contingency of traditional frontend developers.
Symptoms
Edit: It seems that this section has led some people to jump to erroneous conclusions about the article. If you find yourself disagreeing with the recommendations in this section, it’s odd because I don’t actually make any…My actual recommendations are in the ‘Solutions’ section 😉
Div Soup
In present day, CSS Frameworks have become nearly ubiquitous. Bootstrap seems to have hung onto supremacy, with honorable mentions going to ZURB’s Foundation and Google’s Material Design. There’s also a growing support for composable frameworks like Tailwinds that claim to avoid some of the heft found in all the others.
SPA frameworks have been a little more volatile than their CSS counterparts. Backbone, Knockout, and Ember reigned supreme until Google’s Angular made an appearance. Other frameworks came and left, none really offering much of a leap in value, but all generally contributing towards the feeling of “JavaScript Fatigue”.
Then Facebook jumped into the picture with React which was based around the idea compositional components and a lightning fast Virtual DOM. It was like building lego with motors and paint.
This all sounds fine until you open the developer tools. Under the hood, you’re faced with a cluttered mass of class names scattered throughout an awful mix of “div soup”.
Bootstraps “ArchitectUI HTML Dashboard Free”
The only thing that makes this feat remotely possible is heavy reliance on an intricate microcosm of components that effectively abstract all of the details away. Unfortunately, the isolated complexity of these component based architectures also enable seemingly harmless, yet tragic shortcuts like hard coding presentation rules directly into the bones of an application.
Blending of Concerns
When adding 6 or 7 cryptic class names to an HTML tag qualifies as “styling”, I would argue we’ve taken a massive step back in time. We’re safely beyond table layouts, but just barely above the use of inline styles.
Speaking of which, developers are now actively encouraged to inject CSS properties directly into HTML style attributes. Worse yet, those tags are now littered with ternary expressions and map functions that force developers to ping pong back and forth between HTML and JavaScript.
For those who joined web development within the last few years, it’s important to note, this is not normal.
Note Hyrule in the background.
I love this tweet, but their example is noticeably void of any presentation rules which can be even more infectious to a React project. Add Bootstrap into the mix and you have the perfect recipe for a “big ball of mud”, verging on the side of concrete.
EDIT:I was informed that the famous Chris Coyier recently published an article called The Great Divide which delves a little deeper into the symptoms of this phenomenon. If you’re hungry for more detailed evidence of “Backendification”, I highly recommend giving it a read. Otherwise continue reading for my analysis of the problems, it’s origins, and some available solutions.
Stolen from Chris… Muhahahaha!
Problems
Elusive Ninjas
In 2014, frontend developers were objectively cheaper than backend developers. 5 years later and the frontend is now a fullstack.
HIPPO
You’ve probably already noticed that your list of must-haves in your job descriptions have grown exponentially. Your top talent is being poached and the candidates you want are being lured elsewhere with higher wages, better benefits, and more flexible work arrangements.
Don’t get me wrong, this is a net positive for at least a small slice of society, but potentially devastating for anyone trying to run an small to medium sized business (SMB).
When your strategy for success hinges on your ability to recruit, train, and retain an all-star cast of heavy hitters, you might find yourself running around in circles.
Loss of Expertise
Ninjas don’t actually exist. The jack of all trades is really the master of none. As a generalist myself, I’m fully aware that you can’t be good at all things (even though I try). While generalists certainly have a place in your business, it probably shouldn’t be working alone within the depths of your codebase.
When every developer on your team is a “JavaScript Ninja”, you’re actually leaving yourself exposed to blind spots. No doubt applications everywhere are littered with tragic instances of <div className="btn" onClick={this.handleClick}>.
“Who care’s, it works fine” you say? While it may work for an able-bodied person, those reliant on assistive-technologies will be completely unable to access parts of your application.
Accessibility (A11Y) up front generally leads to better user experiences for everyone, so if you’re taking shortcuts here, you might be short changing more than just the visually, physically, or cognitively impaired.
If you’re not morally compelled, then perhaps you’re more motivated by money. You should really consider the fact that A11Y oversights actually represent significant economic risk, both in terms of lost business opportunities and the threat of litigation.
[National Federation of the Blind] and Sexton claimed that Target.com violated the [ Americans with Disabilities Act] because blind users cannot browse among products and purchase the item they want. Blind users also can’t access information such as employment opportunities, investor news, and company policies. NFB and Target settled the lawsuit on August 27, 2008 for $6,000,000 plus additional damages and a stringent ongoing monitoring to ensure continued accessibility.
Furthermore, in a rush to simply make it work, your JavaScript specialists could be glossing over simple techniques for improving your Search Engine Optimization (SEO). This one can hurt a lot since flat revenues against rising burn rates can be a death blow to any business. It doesn’t matter how good your product is if it completely fails to gain traction.
Loss of Nimbleness
Frameworks like Bootstrap and React are appealing because they offer incredible up-front velocity. Bootstrap is often heralded as an excellent prototyping tool. Yet prototyping tools inherently produce low-cost, low-fidelity representation of a finished product.
Good-Fast-Cheap: Pick Two.
Even the word “bootstrap” implies working with limited resources. In the “good-fast-cheap” model, you’re choosing fast and cheap — Whether that decisions is conscious or not. Phrased another way, you‘re choosing to invest in a product full of technical debt.
Don’t believe me? Consider a future where your styling starts to feel dated. New competition enters with a more compelling user experiences and it’s time to up-your game or face irrelevancy.
You embark on a rebranding project starting with tweaks to Bootstrap’s endless list of “handy” variables. You survive the unavoidable paralysis of illusory choice only to find the changes you hoped for were only as broad as your rotating cast of developers were consistent.
Furthermore, the deep customization you really want involves building an intricate maze of CSS specificity hacks to override Bootstrap’s liberal use of direct decedent selectors.
You want to modify the layout but you find every component has been hard coded with a slurry of col classes. Sadly, every element competes for space at a variety of screen resolutions. A change here requires five more over there.
It wouldn’t be so bad except every single change needs to be made deep within the cobweb of unreadable structure, style, and behaviour code crammed into the render function found at the bottom of each file in your infinitely divided component based architecture…
🤯
10 lbs of coffee and a few months later, you’re kinda ready to compete on value again (but not really)…
If your goal is short term acquisition, you might not care. But remember, nimbleness and agility in technology is power. If the long-term vision for your product is a slow lurching machine, you might find yourself low-balled at the bargaining table.
Problem Impact Summary
Between skyrocketing labour costs, risks of litigation, forgone business opportunities, limited customer acquisition, and the inability to quickly steer the ship, seemingly insignificant or even wise technical decisions are suddenly having real world business consequences.
For some organizations working on some types of applications, everything I’ve discussed might be perfectly under control. However, other organizations working on other types of applications, could be walking blindly into long term commitment with a high-maintenance nightmare.
Remember, compared to development, software will spend the majority of its life under maintenance. A quick search found the following rules of thumb for maintenance cost allocations:
- Annual Maintenance = 15–20% of initial expenditures.
- Lifetime Maintenance = 40–80% (60% average) of total expenditures.
Here’s what $100 of initial development at 20% annual maintenance looks like over the course of 10 years:
As you can see, the maintenance costs overtake development in just 5 years. It crosses the 60% total cost threshold between years 7 and 8.
This is however a simplification. Most likely development will continue throughout the life of an application where the larger a project grows, the harder it becomes to maintain. From a long term perspective, short term objectives can result in long term consequences which only compound over time.
I also wonder how unmaintainable projects excluded from these rules of thumbs simply because the maintenance costs became so high the projects were simply abandoned as failures…
Root Cause
I believe the major shift from server-side to client-side applications pulled a large number of talented developers from the backend towards the front. With a much different set of strengths and weaknesses, these programmers started to shift the way frontend development is conducted to accommodate their own needs and preferences.
This is just an armchair hypothesis, but I think this diagram helps explain the vicious circle that we find ourselves in:
Skill Gap Preclusion Cycle
You’ll notice a liberal usage of “air quotes” in that diagram and for good reason. “Highly skilled” is simply relative to other developers’ abilities to introduce frontend tools. “Complexity” is relative to the problem being solved. “Low skilled” is relative to the complexity of the tool now used in production.
It’s reasonable to assume that “highly skilled” developers are introducing tools that augment their own weaknesses on the frontend rather than strengthening the abilities of an organization as a whole. For example, the person with the most to gain from using CSS framework is the person least capable of maintaining CSS.
A common theme I hear among Bootstrap proponents is “how easy it is to create a good looking working prototype”. Similarly, React proponents will say “I like that I never have to leave JavaScript”.
If these are the dominant narratives in your organization, your technology stack may be designed around the needs of more traditional backend developers who happen to be working on the frontend.
I once witnessed a heated debate regarding an infrastructure solution where one side pointed out:
“This makes easy tasks hard for the sake of making trivial tasks even easier.”
When I saw the types of things that our team was trying to solve using Bootstrap and later other alternatives, I didn’t see the need. To me, they were attempting to use an unwieldy solution to circumvent a trivial problem. Unfortunately, trivial is a relative term. For the proponents of these tools, they offered solutions to what seemed like serious challenges.
Solutions
Dealing with CSS Frameworks
In order to start cutting your dependence on frameworks like Bootstrap, my recommendation is to stop applying framework specific classes directly to your HTML. Instead, I would encourage following:
%our-warning-button {@extend .btn;@extend .btn-warning;}
.empty-shopping-cart-button {@extend %our-warning-button;}
This approach helps decouple your application from CSS frameworks by treating them as “decorators” for your own in-house CSS framework. You can now easily swap frameworks, override styles, or even roll your own code without sacrificing upfront velocity.
The ability to centralize your styles means UI designers can work on CSS without diving into a maze of components. The use of domain specific language also allows for better communication with non-technical team members and stakeholders throughout the organization.
Lastly (and most importantly), you now have a clear separation of concerns between your structure and style.
Dealing with SPA Frameworks
This might be controversial and feel like an incredibly long-con, but I recommend switching from React to Vue.js and here’s why:
<template><!--Structure--></template>
<script><!--Behaviour--></script>
<style><!--Style--></style>
What you see here is Vue’s “single file component” which encourages a nice clean separation of concerns. I absolutely love Vue for this (as well as their general commitment to simplicity).
I think there’s an incredibly strong business case for using Vue because it lowers the barrier for non-JavaScript developers to jump in and contribute. In addition to the value of their expertise, they will also free up your ninjas to perform amazing feats of talent somewhere else.
Don’t get me wrong, Vue has all the trappings of a framework like React. It’s very flexible allowing you to create whatever ball of mud you like. Similarly, React can be implemented in such a way that it starts to become a little more approachable (although nowhere near the extent of Vue).
In general, my suggestion is simply to adopt coding practices that enforce a strong separation of concerns. Reduced to an easy set of rules, I would say:
1. Never put anything into your template that isn’t a direct reference to pre-computed data, methods, or components.
2. Only apply styles through classes of your own design and avoid using style attributes at all costs.
The above plus dividing your codebase into smart and dumb components should keep your HTML sufficiently logic and style free. It might eliminate a few shortcuts, but the long term maintainability payoff will more than compensate the initial upfront cost.
I’ll leave you with one final though:
“The tools we choose affect our careers.”I’m good at JavaScript, I swear. — jsday 2017, Jose J. Perez Aguinaga
Choose wisely!