From the perspective of a User Experience professional, the use of development frameworks has to be one of the most significant limiting choices an organization makes when deciding to build software User Interfaces.  Before we get too far along, I want to be clear on what I mean in regards to what a “Framework” is in the context of this conversation.  I’m talking about the set of tools/products and libraries teams use to develop and test Web applications.

Don’t get me wrong, I get it…the appeal, a company’s desire to have a standard set of components, expedite and simplify development/test, and a horde of other false promises the tasty Framework of the week offers.  I am in no way saying UI development frameworks can’t be successful, there are many examples out there for great applications being built using frameworks.  However, I have yet to experience an organization’s ability to take a collection of complex products and rely on one single framework strategy to solve complex sets of functions that span those products.  If your organization has a limited product catalog or a few simple products that can adapted quickly…a framework is probably a good choice.  If you don’t have the expertise in house to develop a set of standard components and UI guidelines that will evolve with the company’s strategic direction; it makes sense to rely on a framework, rely on those who have supposedly invested time to provide usable constraints in which to deliver functionality.  But prepare to deal with their way of delivering; there may be little room to adapt UI interactions to meet end-user’s needs and thus a limited or unusable experience for your use cases.

I firmly believe that if you have experienced (aka expensive, but awesome at their job) people developing your User Interfaces, the need for the heavy and unforgiving frameworks all but disappears.  Some frameworks are more forgiving or flexible, while others provide a strict model by which deviation quickly extinguishes any hope for development savings.  So, why are Development Frameworks the devil?

They don’t typically enable enterprises to make design and interaction choices that benefit end users for relevant use cases.

Here may be some practical points to consider:

Time to market, ramp up of design, development and test skillsets

We’ll leave the research phase out of the discussion, once an organization chooses a framework and the relevant technology stack needed to support it, personnel will need to get trained appropriately.  Outside help is another option, assuming it can be found in the timeline constraints for the project(s).  With the increasing pace of these frameworks, by the time the teams are proficient enough to be successful, it’s almost always the time to move on to the next best choice…the cycle continues.

Expertise hard to find

Cutting edge means the internal talent pool likely isn’t up to speed on the latest trends, outside help will be expensive and hard to find.

This is inherently risky for increased time to market; as people learn as they go, the lessons learned won’t apply to the next iteration…which can be too late.

Unattractive (non-sexy) framework choices are less desirable to developers, despite potential usability benefits (again, users not at front), people want to build the skills around what is marketable and what is enjoyable.

Competing frameworks may negatively impact usability

Within an organization, if you have various frameworks in play for UI development, this may not be an issue.  It does become an issue when products and/or functionality is integrated.  Frameworks have their own ways of enabling users to complete tasks, users can very easily pick up on variations (not always a bad aspect of usability), this can lead to conflicting interactions that may lead to usability issues.

Legacy application incompatibility – look, feel, interaction…all different

If you have existing applications, it is likely that your viable legacy UIs will have to be rewritten in parallel with your new applications being developed, if you’re looking for a consistent experience across your products.  If you are brand new or only have 1 or 2 small products, a framework may help compliment your strategy.  However, it may be helpful to choose one that has common design standards but also manages change well…especially if your organization is concerned with aesthetic vogue.  Otherwise, you may find yourself adopting new frameworks every few years, forcing an eternally inconsistent user experience and an even more challenging internal development environment.

Cross browser compatibility

Do you care about cross-browser compatibility?  If your organization is pushing for modern modern modern, ensure this dovetails with any existing legacy applications you may have to support.  Is there funding to update the UI layer of those legacy applications?  If not, going modern and pushing your users to adopt modern browsers may cause a very serious problem.  OR the other problem, not realizing your users don’t have the ability to upgrade to a modern browser may leave them unable to use your modern application UIs.  For example, have you tried to use Angular/Bootstrap in IE 8?  Have you tested your applications in IE11, chrome, safari, FF?  The devil is definitely in the details when it comes to the ability for users to even access content across browsers.  It’s absolutely fundamental to know what you NEED to support and what you want to support long term.  So, does your framework choice enable or hinder cross browser compliance?

In Closing

These days, I’d much rather work with a team of people who are skilled in HTML5/CSS3, Jquery, JS, etc. than those who know x,y,or z framework.  I firmly believe that a solid team who know the fundamentals of web application design will vastly outperform and create a more attractive, usable product than a much larger team of less-skilled individuals utilizing a rigid framework!  I believe it’s primarily the short-sighted financial decisions that lead to the adopting of frameworks in general, organizations don’t want to pay skilled labor wages.  They think they can short cut the process by buying a framework (or going open source) and paying less skilled people to drive as the framework allows.  If your organization is following user-centered design, you’ll more than likely find that what users want, how they need to interact with your application in order to be most successful will NOT be in alignment with what the framework will allow!  And that, my friends, is why frameworks are the devil!