The “Backendification” of Frontend Development12th February 2019
Executive Summary (TLDR)
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.
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.
- 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.
- 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
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
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 dept in disguise?
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.
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.
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.
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 😉
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.
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”.
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.
For those who joined web development within the last few years, it’s important to note, this is not normal.
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.
In 2014, frontend developers were objectively cheaper than backend developers. 5 years later and the frontend is now a fullstack.
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.
“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.
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.
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 mix of structure + behaviour + style code crammed into the render function 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 (but not really) and ready to compete on value again.
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 year five years, crossing 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 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:
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.
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.
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:
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:
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).
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.”
The “Backendification” of Frontend Development was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.