Blog
Drupal Should Use an External Front End Framework
Preface
The purpose of this blog post is intended to be a comprehensive analysis and response to:
#2289619: [meta] Add a new framework base theme to Drupal core; to encapsulate how I believe core should move forward with a default theme. For brevity, the term "framework" in this post will always refer to "front end framework".
The Problem
Core has always provided its own themes, however the benefit of sustaining this model is becoming increasingly difficult to justify.
Fast Moving Front End Technologies
In regards to the front end, core has historically been more reactive than proactive. This isn’t all that surprising, nor a bad approach, when you take into account what core originally had to deal with.
Now consider for a moment, all the different technologies and techniques that are used on the front end today and compare that with when Bartik was created ~6 years ago. Things have changed rather drastically with the advent of Responsive Web Design, HTML5 and CSS preprocessors like SASS and LESS.
Web Components are possibly the next major milestone in front end development with an impact potentially just as large, if not larger, than that of HTML5 and Responsive Web Design. While the concept isn't necessarily new (frameworks have had "components" for years), it is definitely being sought to become a "web standard" with Google leading the way. Web Components are an encapsulation of multiple front end technologies supported directly by the browser. This could also likely be the future of what we now consider "frameworks" today: a consolidation of web components. Perhaps the web as a whole, only time can tell.
Video:
2015 DrupalCon Los Angeles Session: Drupal 9 Components Library: The next theme system
The 1% of the 1%
Generally known as the 1% rule, only ~1% of any given internet community is responsible for creation. In regards to Drupal, this figure is actually even more drastic with only about 0.02% that are core developers.
This fact is what makes core developers a "rare commodity". I would, however, like to take this a step further. Of that 0.02%, how many of those core developers are front end developers? I’m sure no one knows the exact ratio, but it is commonly accepted that core front end developers are an even "rarer commodity".
Back end developers are the majority. They have little to no interest in current front end technologies, techniques or "Best Practices™". I'm not discounting the fact that there are back end developers that cross over or vice versa, but there are just a handful of "unicorns" .
Without enough of a front end ratio in core development, it is impractical and unfair for everyone involved to expect any sort of "solid theme" from core. It is because of this fact that not having an external framework is actually hurting us from a community, development and maintainability standpoint.
"Getting off the Island"
Core has already adopted the "Proudly Found Elsewhere" mentality for a lot of its back end architecture. The benefits that this approach has brought to our community has proven predominantly fruitful. The front end should be no different.
Core really hasn't accepted this direction for front end themes, but doing so would allow core development to focus solely on the integration of an external framework. This would reduce a lot of the technical debt required to sustain the design and implementation of CSS and JS in a core theme.
Video:
Keynote: Angela Byron — Drupal 8: A Story of Growing Up and Getting Off the Island — php[world] 2014
Automated testing
While the automated testing infrastructure (DrupalCI) is definitely improving, it is still primarily focused on the back end side of things.
Core has wonderful unit testing. These unit tests include and ensure that a theme can implement the necessary hooks available to it via the theme system APIs. It is also great at ensuring that a theme's markup is correctly generated.
However, that is where the benefits of automated testing of core themes ends. Any patch that affects CSS or JS must undergo a very manual process which requires contributors to physically apply patches and "test" changes in multiple browsers. This often results in bucket loads of before and after screenshots on an issue. This is hardly ideal.
The reason many front end oriented projects live on GitHub is because of their ability to integrate amazing automated tests through tools like Travis CI and Sauce Labs. Being on GitHub allows front end projects to rigorously test around the specific areas for which their technologies implement and leads to the stability of their codebase.
Perhaps one day the core and contrib themes could leverage the same type of abilities on drupal.org, perhaps not.
Regardless, testing is just as paramount to the front end as it is for the back end.
Unless the testing infrastructure is willing to entertain the possibility of theme-based CSS and JS testing, an external framework is really our only alternative for stable front end code. At the very least, implementing an external framework allows us to defer this decision.
Popular Drupal-grown base themes
There will always be use cases for the popular Drupal-grown base themes. It really just depends on the project and capabilities of a front end developer. There's nothing wrong with them and I have used them all. They are without a doubt a very powerful and necessary part of our ecosystem.
There is often a lot of misunderstanding around what these base themes actually are, though. Many of them started out simply as a way to "reset" core. Over time, many have added structural components (grid systems), useful UI toggle and other tools. However, the foundation for many of them is simply to provide a starting point to create a completely custom sub-theme. Intended or not, they are essentially by front end Drupal developers for front end Drupal developers.
The priority for these base themes is not "out-of-the-box" visual consumption, but rather providing a blank canvas supported by a well groomed toolset. It is because of this "bare nature" that they can actually become more of an obstacle than a benefit for most. They essentially require an individual to possess knowledge of CSS or more, to get even the most basic of themes up and running.
Their target audience is not the other 99.9998% and not viable for core.
The Solution
Due to the complexity of the theme system, the work with Twig has been a daunting task. This alone has pushed a lot of what we thought we would "get to" into even later stages. I propose that the next stage for a default core theme is to think long term: adoption of an external framework.
Proudly Found Elsewhere
Core cannot continue to support in-house theme development, at least until there is a higher ratio of core front end developers. External frameworks live outside of Drupal and helps ensure fewer "Drupalisms" are added to our codebase. It also allows Drupal to engage more with the front end community on a level it never has before.
Vast and Thriving Ecosystems
Because frameworks typically live outside of larger projects, they usually have a vast and thriving ecosystem of their own. These often produce a flurry of additional and invaluable resources like: documentation, blog posts, in-depth how-to articles, specific Q&A sites, support sites, template sites, forums, custom plugins/enhancements. Drupal would instantly benefit from these existing resources and allow our community to offset some of the learning curves.
Back end developer friendly
These resources also allow a back end developer to focus more on how to implement existing patterns than worrying about having to create new ones. This would allow core developers to focus solely on the theme system itself and providing the necessary APIs for theme integration, rather than the more complicated front end CSS or JS implementations.
Why Bootstrap?
There are many frameworks out there and, quite frankly, attempting to find the one that is "better" than the other is futile; frameworks are simply opinionated "standards". You may agree with one’s opinion or you may not. It does not change the fact that they all work.
The question that remains is: Which framework do we put in in core?
I strongly believe that it should be Bootstrap. A lot of individuals, including myself, have already put in a great deal of time and effort in contrib to solve this exact issue: how to use an external framework with Drupal.
Another advantage of using Bootstrap is that it is already backed by a massive external community.
The main strength of Bootstrap is its huge popularity. Technically, it’s not necessarily better than the others in the list, but it offers many more resources (articles and tutorials, third-party plug-ins and extensions, theme builders, and so on) than the other four frameworks combined. In short, Bootstrap is everywhere. And this is the main reason people continue to choose it.
In just two-and-a-half years, the Drupal Bootstrap base theme has grown exponentially at a whopping 2596.67% (based on 7.x installs from: 1,070 on January 6, 2013 to: 70,531 on July 12, 2015*) and has become the third top most installed Drupal theme on drupal.org.
*Note: I have chosen to exclude the past two weeks of statistics as I believe they are in error due to #2509574: Project usage stats have probably gone bad (again).
While I cannot attest to the exact reason this rapid adoption has occurred, here is an educated guess: it's what the people want. I purposefully made something that was easy to install and worked right "out-of-the-box". Ensuring that the focus of the project was on the other 99.9998%.
No other Drupal project that implements an external framework can claim this or even come close to it.
Ease of use is paramount and often overlooked by developers. This "philosophy" is what has allowed sites like Dreditor to be born and this one, Drupal Watchdog, to be redesigned given some rather severe time constraints.
Conclusion: Drupal 8, 9, 10...
Adopting an external framework is just the logical next step in core's "Proudly Found Elsewhere" mission on the front end. Regardless of which framework is ultimately chosen, I think it is more important to see why Drupal needs an external framework.
We already have too many issues and tempers flaring around even the smallest of details on the front end. By outsourcing a theme's design (CSS & JS), we would allow our community to instead focus on the integrations of themes, like the future of components and much larger issues.
While this issue isn't about trying to add a framework to core just yet, I think it is very important to have this discussion early on. I do think that ultimately, a framework based theme in core should replace Bartik, but that won't and should not happen until D9.
Since adding an external framework base theme would be purely an API addition, there isn't anything that would prevent us from adding it in an 8.Y.0 release (solely opt-in, of course). In fact, I would strongly recommend that we add one before D9 so we can smooth out any remaining details before tackling something as gigantic as #1843798: [meta] Refactor Render API to be OO.
I have a feeling that D9 will be "the year(s) of the front end". While yes, Twig is awesome, the fact remains that the underlying theme system (and default theme) itself hasn't changed all that much and needs some serious tough love.
I believe integrating an external framework is an excellent way for us to, not only reduce both our technical debt and maintenance burden, but also focus how we should be developing our theme system. We have an opportunity to transform the first visual impression of Drupal.
Let's do it for the 99.9998%.
Comments
From a system builder perspective you have completely nailed it. Thanks Mark for taking this position (even if politically unpopular). Drupal needs to reject the "not invented here" mentality and take a stand for embracing other front-end frameworks that don't require development skills (like headless drupal). In D7, working with bootstrap is a constant battle yet it is so widely adopted that clients often request it because they can understand how to modify it. It would be a dream for system builders to just buy or generate a bootstrap theme that just "works" without extensive patch management and debugging.
Respectfully, I have to disagree with most of your points.
The current pace of evolution in the front end space is exactly why we should be wary to include any third party libraries or frameworks into core. A key example of this is jQuery in D7 - it didn't take long for the bundled version to be outdated, requiring solutions like jquery_update to work around a lagging core. While I believe this particular issue is thankfully solved in D8 with the great enhancements to the theme system, shipping a framework with core would cause this exact issue again. While adding an external dependency is more or less trivial, you are then dependent on core release schedule to get updates for that dependency. Adopting an external framework into core means core and its implementation of that framework must be kept up with the framework's development schedule, which opens the potential for a core release to either a) be blocked by having to account for the framework's changes or b) be forced to ship with old versions for potentially multiple releases until core has the time to catch up. It's also important to remember that historically, it is not trivial to remove things from core once they are put in.
The best place for implementations of front end frameworks is contrib, where it is independent of a core release schedule, and can focus on maintaining parity with its parent project. While this was historically a lot of work, in Drupal 8 it will be much easier to build a base framework theme. Contrary to your claim, the theme system actually has gotten a lot of tough love to help solve this very issue, while also keeping the purists and the people who don't care as much what core spits out happy and able to develop in their own way. We have never had better defaults, and between the new .libraries.yml implementation and twig, it has never been easier to ditch core markup, classes, styles, and js. The vast majority of that work will be possible without touching a hook_preprocess, saving that work for more logic-heavy and complex situations.
You make the point that core can not continue to maintain its own themes, but implementing a front end framework does not solve that problem. If a framework were to be included in core, it would need to be included as a core theme, especially if it is to be provided as an "optional API". That means adding a theme to the list of themes to be maintained, and, as stated before, requires keeping up core's implementation with that external dependency. That will not be a simple task of dropping in the new release files and moving on, especially when the next major release of that dependency hits. Overall, I fail to see it solving the problem of maintaining core themes. Bartik may be ~6 years old, but I believe it is getting some love in Drupal 8 to help catch it up. It's also just a default theme - it's there to give something decent out of the box, but it's a small set of people using that theme in production, and an even smaller set of people building off bartik as a base. As for a framework being "backender friendly", I think it's the completely wrong approach to look at the lack of front end developers involved in core and essentially say "oh well" and outsource the work. The Drupal community instead needs to focus on continuing to get more frond enders involved in core.
I think a better solution overall would be to open up the 8.Y.0 releases to routinely ship new default themes, rotating out the old as we go. This would provide an approachable way for front end developers to get more involved with core, and gain exposure to core developers so they know who they can reach out to when they hit a front end related problem in core. It would also provide the benefit of routinely giving core a fresh coat of paint, that could represent the current "state-of-the-art" both in terms of latest front end dev techniques, but also the current design trends.
Adopting a front end framework will do nothing to resolve the ongoing debate and disagreement in details for how front end things should be done in core. It's no secret that many front end developers work differently and have different approaches. In an area where this is much opinion, it makes little sense to choose a highly-opinionated solution to end the discussion. This would only serve to alienate rather than bring consensus. Core needs to be as un-opinionated as possible, to not only account for all the opinionated approaches, but to stay as flexible as possible to the ever-evolving front-end space.
As for Twitter bootstrap itself, I think it would be a poor choice for an enterprise-class CMS to ship with a framework that is primarily purposed for rapid prototyping. Bootstrap has many fundamental flaws in regard to text sizing, accessibility, responsive design, and more. It's also nearly 150kb of delivered-to-browser bloat on a core that is trying to be fast by default. I won't go into further details as this is already a long-winded post, but snugug's slide deck points out many of the critical details (albeit in a somewhat sarcastic way): http://snugug.github.io/winning-the-web/
In closing (yes finally), I do appreciate that you are starting this conversation, and it's one worth having, but I think overall, again respectfully, what you propose is not the right approach to solve the issues core faces in the front end space (of which I think you summed up quite well). It is my hope that the tremendous work done in the theme layer in Drupal 8, in conjunction with the new semantic versioning-based releases, serve as a foundation to address those problems in a way that we can iterate on through D8's lifecycle. Contrib will find more ease and freedom in D8 when developing themes, which is where the testing grounds and proofs-of-concept should be, as has worked well with the module space. We then have the option with our new semver releases to add new technologies when they're appropriate for everyone.
I'd like to thank you for taking the time to read this through and responding in a detailed manner. You have brought up many issues that I had originally wanted to address (as I anticipated such a response), but decided that writing a novel would detract from the topic at hand:
why Drupal needs a framework for the other 99.9998%.
I suppose, however, there really isn't any way of getting around that. I feel it is necessary to address the several issues you have brought up and will attempt to summarize them in the sections below. Please forgive me in advance for, essentially, writing another blog post.
Versions
As someone who was a long time consumer (and now also a co-maintainer) of jquery_update, I am all too familiar with the "stuck core version" issue. Frameworks actually take this concept a step further though. It isn't just simply "files" that will need to be replaced, but rather ensuring that the necessary markup and classes are appropriate for each version.
While this issue has, in fact, been on my mind for nearly over a year now, I only just recently created an issue in our queue to officially address it: #2547363: Figure out a way to deal with versioned changes .
Ideally, we would want something that is accumulative in nature. Once a change has occurred in a framework (e.g. addition of something new or a bug fix), it is typically included throughout all future versions. An example of what I am referring to would be how Bootstrap has added icons over new releases.
While not yet fully working, I have already started documenting these changes in the Drupal Bootstrap base theme just for my maintainability sake: _bootstrap_glyphicons().
Note: if themes were actually able to participate in updates (hook_update_N), this could also help resolve some of these issues (especially around theme setting changes).
Whether this is a core issue or a contrib issue, someone will eventually need to figure this out. I am a little perplexed as to why this has to be considered an immediate "downside". If anything, we should take our previous encounters around this topic as a challenge and formulate a universal way to handle this exact issue. This is just a problem to be solved. It should not be used as an excuse for why this "cannot" or "should not" happen.
Releases
The notion that core would be "blocked" or "stale" by a framework is only valid if we attempted to keep only the latest version of said framework. That would, of course, be very limiting and almost doomed for failure. This is why figuring out how to support multiple versions of a framework is actually a necessity. Core would, then, not be restricted by attempting to keep feature parity with a framework and instead simply introduce newer "versions" of a framework in minor releases (as these would simply be additions and not break anything). I actually was not suggesting that a framework to go into core until details like this were properly handled.
Maintainability
Because we would only be focusing a single newer version of a framework at a time, it would actually be easier to maintain and implement. Most frameworks have their own release notes of what has changed (e.g. Bootstrap 3.3.5). Not all of these items would be actionable on our part. Many of the changes are simply internal (to the framework) CSS/JS fixes. The only time we should ever be concerned with a change in the framework is if/when markup or classes have changed.
It is for this reason that having a framework in core would actually be more beneficial. We would be able to groom an even shorter actionable list from the framework's new "version" and it could be iterated on by all core developers, not just the smaller ratio of front end core developers who require knowledge of CSS/JS (like it currently is with our themes).
Consensus Banana/Classy
I was part of the group at DrupalCon Austin that helped come up with this idea. I was one of the proponents that asked to introduce a "Classy" base-theme to assist, from my perspective, cleaning up core so framework based themes could flourish more easily. I am all too familiar with how core was at making too many assumptions (in regards to markup/classes, not the theme system). Classy is a blessing for framework based themes in Drupal, because we don't have to use it.
Existing Improvements
I'm not discounting the massive effort (by many dedicated people, including a little bit from myself for ~1 year) to help standardize how we define or implement some of our front-end technologies. Make no mistake though, core is far from "done". The front end changes made in D8 are merely baby-steps.
Libraries
Yes, we "standardized" our hook based info definitions into YAML files. Yes, we also standardized how we include these libraries (assets) via #attached. But that's as far as we really got. The internals of asset handling really haven't changed all that much. There is the following issue that will help with this, but it was postponed: #1762204: Introduce Assetic compatibility layer for core's internal handling of assets. I also suspect that libraries may be able to be leveraged in some way to possible help with the "versioning" issue mentioned above, not entirely sure yet.
SMACSS/CSS Standards
Yes, a great milestone was accomplished by restructuring the CSS in Bartik (part of the larger core effort). However, SMACSS is not a "framework". It is just a concept/guide for architectural decisions. Most frameworks, of any kind, implement some sort of principles that are or relate similarly to SMACSS. While the addition of SMACSS in Bartik has certainly made things a little easier to manage, it hasn't necessarily "fixed" the issues within it; it more so just rearranged them.
There is no defined direction for how Bartik should look exactly, like the style guide that Seven now has. This has led to contributors producing radically different solutions. This has improved, slightly with newer CSS standards, but those really do not enforce consistency, merely suggest it.
I often liken the importance of a framework to that of a PHP class interface. Creating an interface isn't actually necessary for the class to operate. However, when an interface is defined and a class does not implement the proper methods/signatures, then PHP throws a fatal error and halts. The principle is relatively the same for frameworks. If you don't provide the correct markup and classes, the framework ultimately fails and elements are left un-styled and non-functional.
Twig
I love Twig. It is, without a doubt, far superior to that of PHPTemplate in almost every way. I am not disputing this fact at all. To re-iterate what I said on this issue, however:
"Twig is simply a template engine, that's all. It is essentially the last step in the process. It is not involved with how we provide the data to templates."
Theme System
The above "improvements" were associated with the statement I said about the "theme system".
When I refer to the "theme system", I meant it in the literal sense: the internal APIs that govern the actual theme system itself: registry, hooks, preprocess, render arrays, FAPI, etc. I, among others, have actually made it a career priority to spend a considerable amount of time understanding how the entire theme system, of Drupal, actually works. The "improvements" mentioned above really are just the tip of the iceberg of what truly needs to be accomplished in Drupal for the front end.
Aside from the process layer that was removed, the primary goal was severely postponed (see all open child issues too) simply due to the shear amount of time it took to convert everything to Twig.
Default Theme
I'm a little confused with what has been said about this topic.
First, the importance of a default theme in core was diminished by stating that it is essentially for cosmetic purposes and that people really don't use it. I actually agree with that statement and is why I'm proposing something a little more stable, widely used and familiar than our current implementation.
Adding a framework to core, even a default theme one, does not prevent people from choosing a different solution. People currently do this already anyway.
Later, it was suggested that one of the ways to "involve" more front end developers is to "introduce new themes and rotate out old themes". This is where I am confused because it was also acknowledged that one something is in core, it cannot be removed.
Thus, this "solution" would actually cause a logistical nightmare in ensuring that all these themes were supported properly. This would, in fact, place a much heavier burden on core developers and maintainers. This is a nice idea, but completely unrealistic and unmaintainable given our current core front end developer ratio. There's also no hard evidence to suggest that this would actually increase front end developer involvement.
Just compare Bartik with what has been done for Seven. Seven was essentially rewritten, from the ground up, based on the aforementioned style guide. While most of it has been implemented, there are still a few issues still left.
The immediate questions and concerns this raises in me from past experiences are:
Nevertheless, Bartik will at some point be considered "inflexible and quite dated looking" by everyone just as Garland was.
Core Front End Developer Participation
"I think it's the completely wrong approach to look at the lack of front end developers involved in core and essentially say "oh well" and outsource the work."
Respectfully, I think you missed the entire purpose of this post.
I'm not saying "oh well". I'm saying that we have to view this issue realistically and responsibly. Despite obvious and justifiable negative social connotations towards the word "outsourcing" in America, there is nothing necessarily "wrong" with using the word when it is appropriate to do so. In our industry, specifically Open Source CMSes, it actually makes more sense to do this when there is a lack of bodies to truly sustain something.
"The Drupal community instead needs to focus on continuing to get more frond enders involved in core."
Obviously, what we have been doing isn’t working all that well. I'm not saying that we can't do better or come up with different strategies to help promote front end developer involvement in core. One day, when this ratio improves, we could move back to a more in-house style production of a default core theme. We're not as "stuck" with an idea as some may believe.
From my perspective, I think a lot of what detracts front end developers from core is two fold: the bike-shedding that occurs when two or more front end developers have a difference of opinions and the sheer level of scrutiny that is involved with every little decision (which is often perceived as such because of the former).
I personally believe that the only way we could begin to "solve" this issue, would be to appoint a front end oriented individual with the same authority as the other "core committer/framework manager" individuals. This would allow core to focus and resolve these types of issues with an individual whom has a relevant skill set and understands the importance of UI/UX.
That would be just the first step though, in likely many years of other needed improvements to help "boost" this ratio. Until that day arrives, however, we cannot simply just ignore these facts and continue on "hopes and dreams" that this ratio will increase. That isn't responsible management.
Even though our CSS/JS standards have become more solid over this release, we still lack something as fundamental as a "style guide" (like Seven now has) for Bartik. But to take that a step further, we also need a "default core theme/framework guide" to define what it is a default theme should or should not be doing.
This has actually already been mentioned several times, more or less, under the guise of "components". While that issue is specific about implementation in core, it doesn't stop us from actually developing an "official guide" in the meantime (which is what I meant by "smooth out any remaining details" in my OP).
<side-rant>Many of our core/contrib front end individuals are stellar developers, they have had to be. Many of them could create their own frameworks and many of them have. Many of them are wizards at CSS and JS (even some PHP).
I want to call all of us front end developers out (including myself):
For us to argue about which framework "isn't following standards" or "isn't doing things correctly" is, quite frankly, complete rubbish. The only real "standards" that exist are the HTTP, HTML, CSS and JS specs that define how a browser should interpret said technology. It hasn't helped that each browser has had its own way of doing things for the longest time either. This is certainly getting better, but the damage has already been done.
The "standards" many of us front end developers spout out are actually just a consolidation of technologies and techniques in an effort to recognize commonly used patterns (e.g. cross-browser compatibilities, responsive web design, SMACSS, etc.). These "standards" are subjective at best and their survive depends merely on quick adoption and any lack of a real existing standard from said technologies.
Just because our opinion doesn't match that of someone else's, doesn't make them necessarily "wrong". It makes them different. Personally, I am a little sick of the egotistical pride and arrogance that many of us have allowed to perpetuate into this community. This mentality has to stop. I implore all front end developers who truly want to help "contribute" to this issue to start thinking about the needs of the other 99.9998% of people, instead of "how I would do it".
This issue really isn't for us or even about us.
</side-rant>Bootstrap's "fundamental flaws"
I guess what they say about first impressions is true, they last a lifetime. It actually completely baffles me how people will continue to use outdated "facts" to justify current and future versions of Bootstrap. Just like with any other software, it evolves and becomes better (as we have with D8). I do, however, wish to go over the details that were mentioned:
Font Units (text sizing):
A lot of people either do not know or completely misunderstand the font unit battle that occured in Bootstrap and their reasoning to initially use, and their decision to stay with, pixels. Suffice it to say, we can blame IE8 with no REM support.
Bootstrap 3 supports IE8 and because of their unwillingness to support nested EM hell, this major version of Bootstrap has been tied down. I actually do not disagree with this decision at all and can respect it, considering. As noted in that issue though, the switch to REM will happen in Bootstrap 4 when they drop IE8 support. For those less patient, there are various work arounds for this, like this one.
Accessibility
I will not disagree that accessibility is something that had previously lacked very severely in Bootstrap. This is, however, actually getting better and better over each iteration. In fact, more recent release notes have had their own "Accessibility" sections. It isn't like they are actively against it.
I would imagine that it is just part of their "maturing phase". It wasn't until D7 that "accessibility" actually became something we endeavored to actively address. It also wasn't until D8 that it officially became one of our core gates. Accessibility is something that is tackled over time and like with any requirement/feature request, the squeaky wheel tends to get the oil.
Grid (responsive design)
Yes, Bootstrap 2 did get a lot of flack for not being "mobile-first". They listened to what people wanted and then decided to change their entire grid system in Bootstrap 3. This topic is purely subjective in nature though. There are many resolutions and theories for how responsiveness should be handled (all of whom "know they're right"). Bootstrap chose a commonly used class based grid solution around four breakpoints, nothing more.
They then refactored it to make it more maintainable and a smaller distribution size. It doesn't prevent anyone from changing the defaults or even implementing a more refined or custom implementation if so desired. The fact of the matter is: people who really care about this topic are front end developers who are aware of the different types of responsive designs and can implement their own needs.
Bloated (file size)
Aside from the font units, this topic is probably the most heavily used argument against all frameworks, not just Bootstrap. There are three different types of "bloatedness" front end developers often refer to when they bring up a framework's "file size weight".
Regardless of which "reason" is used, this argument as a whole is commonly abused, often misunderstood and generally only ever used to focus on just a single negative aspect rather than encompassing the entire topic as a whole. I strongly recommend reading this article: Everything Is Bloated.
Page Load Time
As the Senior Front End Performance Engineer at Tag1 Consulting Inc., I have actually spent a great deal of time on this topic on various fronts. It is a common misconception amongst front end developers that "file size" determines how "fast" something is. This is usually and largely completely FALSE!
Anyone who has spent a marginal amount of time on the back end (server) side of things will tell you that it has more to do with the following: server latency/upload speed, server congestion/traffic and location, location, location.
You can have a 100Kb file that actually takes much longer to load (for some, because it would would have to travel clear across the world) than that of a 500Kb file that is served from a significantly closer network location via a CDN distribution node.
In fact, the global average internet speed is currently ~5Mps. We're well past the turn of the century when dial-up was still considered "commonplace". Most can download a file rather quickly depending on how close it actually is to them.
Yes, there will always be some who truly care about the millisecond differences they can leverage to "boost" front end performance, but those are not the 99.9998%. In reality, what most people talk about (or rather, care about) is a website's "perceived" page load time. There are numerous techniques (minification, footer loading, etc.) and technologies that help offset this, including Gzip (which is also rarely brought up).
Take for instance, the CDN the Drupal Bootstrap base theme now uses out-of-the-box: jsDelivr. The combined "weight" of both bootstrap.min.css and bootstrap.min.js only totals ~32.9Kb (gzipped) and typically transfers (for me) in less than ~50ms.
There is also often little to no mention towards the fact that browsers actually cache these files once they are loaded. Given the popularity of Bootstrap, the chances are actually very high that one would have already visited a site that utilizes a CDN like this and has the file already cached locally.
DOM Parsing
After debunking "page load time", this typically becomes the next topic of attack. A lot of this argument also correlates with the following section, but is usually specifically addressed as a "reason". The arguments goes something like this: "Large (file size) frameworks require the DOM (browser) to parse more CSS and JS."
While yes, this is technically true, the "downsides" or "performance hits" people often refer to here typically stem from older browser CSS/JS engines and the blog posts that talked about them. The reality is: browsers have been listening to us complain for years. They are often (now) rather quick to fix or adopt a new solution to increase performance of said engine.
This isn't to go without saying, though, that there can still be expensive techniques or properties used incorrectly or excessively. This is actually common with new front end developers that traverse the internet for a quick "snippet" on how to do something. It can also be common with newer frameworks that were created from a single minded purpose opposed to following a wider set of "Best Practices™". However, these frameworks often mature quickly due to the same "negative" feedback, as has been the case with Bootstrap.
Generally speaking though, many front end developers prematurely "optimize" selectors based on an engine's past or current performance of DOM parsing. These performance fixes or tweaks should really be left to the engine (browser) itself to rectify in future releases.
Unused or Excessive Features/Classes
This topic is largely due to improper implementation, lack of design/adoption or simply no architectural focus whatsoever. Many people can simply install a framework as a "base", but that is where it (unfortunately) stops. This is also where we see a lot of blog posts written (both negative and positive).
These individuals rarely fully utilize the framework and build with it. Instead, they build on top of it with additional 3rd party tools and plugins that may not necessarily actually work or work well with said framework.
This isn't the fault of the framework. It is the fault (or perhaps laziness) of the individual who implemented the framework to begin with. If one decides to utilize a framework, then utilize it. Don't ignore what it's providing.
This isn't to say that the framework is "forcing" someone to do anything either. If one decides that something the framework offers is unacceptable, disable that component and implement something better. Just ensure that whatever is implemented actually works with the framework, not against it.
Enterprise
Enterprise level developers/clients actually love frameworks, it allows for more uniform and consistency when trying to train their employees on how to manage their website.
This is actually why many of these frameworks were, in fact, created by them.
Here are just a few enterprise level examples using Bootstrap:
http://expo.getbootstrap.com/2015/07/30/nasa/
http://expo.getbootstrap.com/2015/06/03/ing-world/
http://expo.getbootstrap.com/2015/06/01/vevo/
http://expo.getbootstrap.com/2015/04/17/new-relic/
http://expo.getbootstrap.com/2015/03/25/spotify/
http://expo.getbootstrap.com/2015/01/19/mint/
http://expo.getbootstrap.com/2014/09/30/vogue/
http://expo.getbootstrap.com/2014/02/12/newsweek/
I personally have worked on several enterprise level projects that specifically requested the use of Bootstrap as the base for their front end. To casually dismiss and categorize Bootstrap as "non-enterprise quality" is highly inaccurate.
The common misconception about Bootstrap's "copy cat" look has more to do with the lack of any real theme design and style guide (from a real designer), than that of the framework implemented. While there are many reasons this can happen, I suspect a lot of it has to do with one of these reasons: no budget for a designer, no budget for time, no budget period or pure laziness.
In fact, I know from personal experience when I created Dreditor's, all of these reasons played a role in my decision to just "slap bootstrap on it". There's nothing wrong with that approach either. It is purely circumstantial.
Fin
I do expect people to disagree with me, there is no getting around that. Front end developers are a wily bunch of folk, all with different levels of expertise, skillsets and opinions. All I ask is that we base this discussion on facts rather than wild assumptions and overly used generalizations. That serves no purpose.
To reiterate, this issue is really about supporting the other 99.9998%... not us front end developers.
Marc. Here us a great post on bootstrap popularity https://www.ostraining.com/blog/coding/bootstrap-winning/?utm_source=fee...(OSTraining%20Drupal)
There is so much talent, training and support for bootstrap that ithe could make drupal much easier and accessible . You could actually focus on system building if drupal would rally around it. Obviously betting the farm on bootstrap is stupid but IMO a fragmented and poorly supported front end ecosystem hurts or kills many mainstream drupal projects. Popularity is important!
And the first alpha of Bootstrap 4 just came out: http://blog.getbootstrap.com/2015/08/19/bootstrap-4-alpha/
The 8.x theming model may lend itself better to Bootstrap/Foundation/etc. in the contrib space.
It might be interesting for a contrib theme like Bootstrap to get promoted into core at some point, and that sort of thing seems possible with a lot of effort from the Bootstrap theme's maintainers on the 8.x branch.