One amazing thing to note is that in v3.3.5 (last stable) bootstrap.min.css was at ~123kb. The new 4.0.0 alpha bootstrap.min.css is at ~88kb. WOW. That's just amazing. Congrats to everyone who worked on this project. I'm always so impressed with the work done on it!
Also, I want to add, I don't care where you land on the side of the debate whether to use Bootstrap or not, there is some very smart minds behind the project and there always something to learn from the source code.
I think it's a good idea to avoid "BEM" in such a mainstream project, since the naming pattern clearly puts some people off.
However, what about the problems that BEM tries to solve? Using a naming pattern to communicate structure (element E is a "child" of block B) is a good idea (instead of e.g. a descendant or a child selector) because of:
a) Performance: one class (e.g .blockB__elementE) will be faster to "match" by the browser than .blockB > .elementE /.blockB .elementE;
b) Less coupling to DOM structure: to have the desired style, element E doesn't necessarily have to a child of B.
Similar points can be applied to modifiers. A "btn--large" instead of "btn btn-large" seems like a good idea for performance and also to avoid conflicts (the latter class will override the first, but I wouldn't want to care with order).
>>> I don't care where you land on the side of the debate whether to use Bootstrap or not.
I used to be totally against Bootstrap for a myriad of reasons. Then I got hired to build a fairly complex transactional application for a large health care organization under a tight schedule.
Bootstrap allowed me to get a UI up and running super fast with all the components I needed, out of the box. It literally saved me hundreds of hours of work. I look at it completely different now.
This version looks pretty sweet and I'm already eyeing up version 4 for a few future projects I've got in the hopper.
I never got the hate for Boostrap or other frameworks. They definitely save a lot of time, and you don't necessarily end up looking like every other site if you put in some effort[1].
The dislike for Bootstrap isn't a hate for the framework and its components. It's the fact that most people do not customize it, and so nearly all Bootstrap sites _look_ like Bootstrap. Cartoonish and bulky rounded buttons, overly large menus, etc. The default theme feels equivalent to using Comic Sans MS. It's too Web 2.0 and not very professional looking.
Properly theming (at least in 3.x) took a lot of effort. Just try to make a theme whereby at first glance, you can't tell that Bootstrap was used. It's not that it's not possible to do, it just took a lot of time and effort to nitpick over every detail.
In professional environments (ie: real flesh and blood companies), developers cannot say "we're using Bootstrap's default theme". The business has designers, the designers come up with a design, and unless the developer can customize Bootstrap to accommodate the requirements, in a reasonable amount of time to meet deadlines, Bootstrap is simply not an option outside of using the grid system.
Sweeping generalisation there on people in "real companies" not being able to use Bootstrap's default theme.
That's precisely what we do at my place. We don't do it for customer facing things, but for back office tools why would we spend time customising Bootstrap? There are better things we could be doing with our time.
But even if they did all the look the same, how would that be negative?
How terrible would it be if all your desktop apps had completely different UI components? Indeed, people seem to greatly prefer desktop apps that follow the style and UI conventions of their OS.
So if the Internet were largely made of pages powered by a few popular UI frameworks, I really think it would be a huge boon to users everywhere. UIs would be more familiar and consistent. Seems like a great step forward.
Exactly! if you are building like some custom CRM-ish application ,Bootstrap is really helpful.
Your users(and clients) won't care that the buttons are not flat or that it looks like many other applications ,if anything that's a positive if you build a UI components like Navbars they's used
It seems perfect for back end devs who need to do a bit of front end work. Makes things look good enough without a great deal of effort (certainly better than my own CSS would look).
I used to hate the whole shave kb off a file stuff (its 2015! we'll have superdooper speeds in 5 years!) until someone added up the hardware usage overall worldwide and it made a bit more sense. it made more sense when the crash bandicoot guys had that story about fitting the entire source code onto that cd with 4kb* left.
Does anyone know why they don't want to support right-to-left? I've seen tons of questions and posts about it over the years so I'm surprised that even with the next major release they aren't addressing it. Maybe I'm missing a perspective here though -- don't other people think that rtl should be a core capability of a framework like this? I'm also curious whether accessibility will be improved in 4.x.
They did propose to do RTL in version 3. They used some CSS flipping tech to do the bulk of the work.
However, it got abandoned, as far as I can tell from the outside, one of the people who manually creates an RTL version of Bootstrap basically called them imperialists for trying to automate something that was too precious to automate as it couldnt be 100% perfect and they caved to the pressure.
This is annoying for those that want to integrate CSS flipping into their own workflow.
Also, accessibility has been improving a lot recently, with PayPal and others contributing back and they announced Patrick Lauke would join their team to work on this.
Just to be clear, you're talking about the text direction, for languages like Hebrew and Arabic? (We Americans are typically blissfully unaware that other languages are actually used on the internet - this is a great opportunity to talk about the importance of i18n)
It is a little more complicated because you have to omit the previous rule as well (and overriding it may interfere with other CSS rules), so it should be:
I hope this leads to a 'standard' way of developing Bootstrap-based templates. Something comparable to the submission guidelines on WrapBootstrap but codifying how a template's assets should be arranged, written, etc. Using Bootstrap as a base for new template designs was a major step forward for the template industry because customers aren't walking into a completely foreign codebase with each purchase. If that familiarity were extended further then it could lead to interoperability of component styles between templates developed by different designers, which is something customers have brought up numerous times over the years. It's never quite that simple but I think for example simple namespaces would be a step in the right direction ('.unify .nav-tabs' and '.vitality .nav-tabs').
It is nice to see the bootstrap team creating themes, but it would have been nicer if they had supported the existing bootstrap theme community. Some of the sites like WrapBootstrap, Start Bootstrap, and Bootswatch are helpful additions to the Bootstrap community.
More expensive than some others out there but the quality of other commercial Bootstrap themes tends to be pretty low:
- Many themes out there are never updated. I remember some $15-ish Bootstrap themes for 3.1 that were never updated for 3.2, etc
- Many Bootstrap themes out there are non-semantic div hell. Headers wrapped in <div> tags with a class of "header" instead of simply using h1/h2/h3/etc tags. That kind of thing. Often because they were simple ports of themes from other frameworks. Bootstrap isn't always the most semantic thing in the world... but some of the Bootstrap themes you can buy out there are sheer crap.
If these official Bootstrap themes can excel on those two points, they're a bargain.
We keep Bootstrap funded and available for everyone. To
date, we have never taken money from investors and have
no corporate sponsorships. All our expenses are paid for
by us through ad revenue on our docs.
Pretty good reason to throw them $99 right there, if Bootstrap has saved you $99 of time over the years.
Personally, I'm super happy to see that the creators of Bootstrap will finally be making some money off their incredible work. I'm hoping it really helps them focus on the project without as much stress, pain and guilt (as @fat has shared openly in the past).
the Dashboard one looks nice, but is currently (of course) still using Bootstrap 3. anyone knows if there's a free upgrade to a BS4 version once released?
Yeah. We're adding this to the FAQ right now, but the updates are free for the life of the theme (including updates to future versions of Bootstrap) <3
It is comparable to the "Multiple Applications License" provided by WrapBootstrap. Still relatively expensive since most Multiple Applications Licenses are under $99.
Do I live in some sort of parrallel universe that thinks a well documented base design for dashboard/app that will presumably continue to mature for $99 is SUPER STINKING CHEAP?
If this is officially supported by the Bootstrap project - this to me feels like a nuts deal.
You live in a superposition. It is very cheap! Yet when people are selling the same thing for $4, it also looks like a lot, even though it isn't. I recently bought some themes and I had to make a conscious effort to simply ignore the price. In fact, I wish such sites had an option to hide all pricing info.
(Same in mobile apps. $5 is a steal for a decent app/game, by any direct measure of value. But comparatively, $5 is way more than most apps.)
>Yet when people are selling the same thing for $4, it also looks like a lot, even though it isn't.
Here's your problem: you assume it's "the same thing". Just because the $4 thing looks OK doesn't mean it has the same code quality underneath, or that it wasn't stolen (as lots of "premium themes" are).
I'm sure many of us have spent and hour or two browsing theme, finally buying one, find out it's not going to work, and then start the process over again.
I've bought themes, both Bootstrap and others, that looked great, were dead cheap, and never got past the first open of the templates in Sublime Text. They were just too much of a disaster to work with.
Knowing that I'm getting top-notch quality is worth the $99 for me, if the themes fit what I'm trying to do. The amount of time saved not undoing someone else's mess is worth much more than $99.
That's not to say a cheaper theme isn't going to be good. I've also bought many that were quite good. I guess the difference here is that you can really trust what you're getting, and not have to rely on user reviews. I believe the Bootstrap people have earned enough trust where I know I'm getting a theme I can easily work with.
At first, I was skeptical, but after looking at the completeness and quality of themes are and how well they are documented, I complete agree. This is an excellent deal, especially considering how much it would cost to hire someone to build something comparable for you. Even then, it will not be as well-documented.
$99 to roll out an internal dashboard in hours, so my engineers can focus on more important things? Yes please.
If this is for your personal webpage, $99 might be too much. If this is for your business, and $99 can save you more than an hour or two of employee time, it's a steal.
Yes, I used 'Palas' as a base template for my company's site. Support is in general good, I'd say: lots of elements are worked out so you can build your layout with building blocks very rapidly, and configurability is often high. You still need to do work if you want to have your site look like something unique, but in general these templates are a great way to start.
And they are the same thing, templates from bootstrap or from 3rd parties: you get an example site with several pages, pages with building blocks on them, less based customization css on top of bootstrap, documentation which block does what so it's easy to find where to customize e.g. a header color / font.
You're correct that this is foolish for any entity who's primary differentiator is their website.
If you're Seemless, competing with 10 other companies that do identical things, you probably don't want to also look exactly like them. If you're Cloudflare, Heroku, Twitter, Mint, Chase (or even Google), as long as its not hindering improvements to functionality or ergonomics (which it might - but also might not), who cares?
Meanwhile, primarily this is appropriate for small players. If you're in the early stages of building anything, you want to build your core product but have your website still look professional. The correct sentiment here might be: "$99 to have your site look as professional as all the others! Yes please."
Another way to look at it is that if your boss asks you to build a dashboard for a project at work, then $99 is a drop in the ocean for a quality dashboard theme built by the people that built bootstrap.
They seem pretty confident about Sass; It seems outdated and clunky to me, in part because it's always going to be the only Ruby dependency in any of my projects. The Javascript parser never found parity from what I know.
By contrast, PostCSS is faster and has massive adoption. Seems like the way forward. Anybody think this is wrong?
> PostCSS can do the same work as preprocessors like Sass, Less, and Stylus. But PostCSS is modular, 3-30 times faster, and much more powerful.
> in part because it's always going to be the only Ruby dependency in any of my projects. The Javascript parser never found parity from what I know.
Now that libsass (C or C++ implementation) has matured, the Ruby dependency is not necessary. I always resented Sass (vs. Less) a bit because of the Ruby dependency (in projects not using Ruby otherwise). Now that you can link against libsass, I don't feel like that's an issue anymore. There are JavaScript libraries linking to libsass (if you are using Grunt/Gulp/etc to build your css).
[Note: I looked into libsass a little over a year ago (around June 2014) and they were openly stating that it wasn't production-ready, and they were targeting (I think) August 2014 for some features.]
Thanks for the overview, that was about my timeline too.
The other thing is that PostCSS just looks cleaner, extensible and more future-forward. cssnext+autoprefixer is awesome, for example. There's even a Sass-like DSL. I had been on Less for a long time, but some of its limitations bothered me.
<rant>Yeah I really love how I now not only need Node and npm, but also gcc to install/build a frickin' web project. Because f*ck the platform-independence we got with Node, who cares if a simple `npm install` takes 30 minutes to complete.</rant>
I generally agree with you sentiment -- but with js being within an order of magnitude of C -- it seems the likelihood of incompatibilities between the js version (that could run in rhino, nodejs and the browser for in-place use of sass over css) outweigh the benefits of maintaining a C version (especially as specifications evolve, and need to be ported to C).
Then again, having (at least) two implementations is one way to test compatibility and nail down unclear specs...
Nope, I'm on Windows. I don't need GCC (or any other C compiler for that matter) to install Node, but now I need one because some of my coworkers on Macs decided to throw every possible dependency they could find into the project.
I don't use it, so I don't know, but I'm just wondering, why is it necessary to use gcc to use libsass? Isn't there a PPA for it? Would a PPA be the proper way to distrib what sounds like a really valuable program? Thank you.
System level package management falls quite short of what you want for applications in a lot of ways still.
Different apps will want to specify and build against extremely specific and different versions of their dependencies, and developers will want to be able to change these versions without lots of organizational coordination between owners of dev/CI/stage/production environments.
Currently, this is solved by things like npm/bower/bundler/composer/maven/etc. etc. The code repository describes all the dependencies and they get installed just for that app, testing and deployment process simply incorporate the app's packaging tools.
However, for any dependencies which use native extensions, you tend to need to be able to compile those - across all your environments - which means having working toolchain everywhere.
Not that this is strange or hard in my opinion, but it seems to discourage people somehow.
Should the people that wrote libsass have decided whether or not to write it in C based on whether or not you would have to install Visual Studio to get it working on Windows? As a C library, it allows linking from several different languages, so maybe their motivations were getting a non-Ruby Sass implementation that could be used in whatever language you need it in. Maybe then the people that wrote the JS to link against the C library are the people that burdened you with this hardship then? Should every person that wants to use libsass from JavaScript be deterred against creating that JS library linking against libsass just because it might cause you some sort of "software installation hardship?"
I'm really confused what you feel the "ideal world" of your rant is. That the libsass people should have written it in JavaScript? How then would (e.g.) Python compile Sass? By installing Node and calling out to run the JavaScript libsass? Wouldn't that just lead to more people saying things like "Why should I have to install Node just to compile some Sass?" I'm sure the initial implementation of Sass being in Ruby was great for Rails developers because Ruby was already a part of their toolchain. For other projects that were not using Ruby though, Sass required an install of Ruby just for the purpose of compiling Sass.
Nothing is requiring you to use these tools, but as web projects become more and more complex we develop tools to deal with the complexity. You could just as easily ignore all of this and use server-side rendering in your language of choice.
If I'm going to have to choose between Ruby and Node as a dependency for my project, I'll go with Ruby, and be unhappy regardless. Installing a whole programming language/framework and package manager just for a transpiler isn't my idea of fun.
I think a lot of people feel that way, but it's a false dichotomy based on what I've seen. The more real choice is between Node/Ruby and just Node.
When building a web application, you're basically forced to use JavaScript. It would be nice if this wasn't the case, and there are some transpilation tools that can basically get around that requirement, but it's almost always more painful to go that route. So if you're basically going to need the Node toolchain anyways for stuff like Babel and Webpack/Browserify, having your CSS abstraction library also use it means not needing an extra Ruby dependency. But there's not really an option to use only Ruby.
I think it's unfortunate. While I'm comfortable with assigning copyright to nonprofit organizations with a commitment to keep code free and enforce the license, I'm not comfortable assigning copyright to individual people.
Not unless you like chasing the "latest and greatest" fad. If Sass (or Less) is working for you, then use it. If you are running into issues, then research alternatives. Both Less and Sass are actively maintained projects, so there's not reason to run around switching frameworks unless there is a concrete need for it.
I ran into significant issues with LESS that forced me to switch. I haven't seen any with SCSS, so that's the question. Is it just another new fad, or have people exhibited a real need for switching?
(I wanted to post this reply to DarkTree too, since it seemed equally applicable.)
I've looked at PostCSS a couple of times lately and it seems "interesting", but the cited benefits (speed, modularity, the ambiguous "more powerful") aren't really things I've ever paused to worry about with Sass. And when I look at the first example of PostCSS, it seems dauntingly weird, though presumably some of that is actual future CSS - I have enough trouble keeping up with future JavaScript, so forgive me if I've not really kept au courant with whatever is happening in the future of CSS (I think I lost interest around the time they decided to make variables really, really complicated).
Sass seems to solve all or most of the problems I care about most of the time with CSS, and it's easy to onboard people who've never used it before. In fact, to be honest, I only really use a subset of the features of Sass (variables, nesting, mixins, inheritance), so switching to something that has more powerful features that I would probably more powerfully have to eschew is... not very high on my list of priorities.
Well, I built a theming engine that utilized LESS in combination with a whole host of other stuff. It became a big problem there, but that's not really a use-case that is applicable to most. For more common issues, the way LESS does guarded mixins was super annoying, the breaking changes in minor version release, etc.
I wouldn't say chasing the "latest and greatest" is always the case when trying the new fads. A lot of times it comes down to 'you don't know what you don't know'. I was doing fine using regular old CSS, and then I came upon some SASS examples, and holy cow, you can make variables, mixins, and do math? I never knew that was even a thing and it certainly wasn't a problem I was having with CSS, but I am glad I found it and now use it and its luxury.
CSS shouldn't be so complicated. It's all about selector simplicity, scalability. If you make too complicated sass, css or less, you're doing probably wrong.
They mentioned they're using libsass, a C/C++ port of the compiler. Although it's only an issue if you're using the source and not the compiled CSS. The same issue exists with v3 needing a LESS compiler.
The last time I looked at the PHP one, it compiled fine, but wasn't handling variables scopes in the same way of the JS one. This was a big deal for me.
Yeah, which is one of the reasons why I'm not a fan of Assetic in Symfony. The PHP versions of front-end build components are always lacking, unfortunately. But that's not a big deal in my opinion, you basically always need Node for a front-end application at this point for other needed tooling (Browserify/WebPack, Babel, etc.) so better to use the best-of-breed tooling and ignore Assetic as much as possible.
Yes, I tried using the React filter and failed. I switched to Gassetic (https://github.com/romanschejbal/gassetic) which is interesting but quite new and not well maintained. I couldn't make Reactify working with it which lead to way too long Browerify compilation time.
Next project I'll just use directly Gulp-or-whatever-is-fancy-then and find the simplest way to integrates it in Symfony/Twig.
I'm confused about how the Dashboard theme seems to be built using http://titon.io/en/toolkit instead of Bootstrap. Why it's advertised as a "Bootstrap theme"?
I'm a Boostrap lightweight, but I always respect an organization willing to drop support for old technology (IE8) and rewrite libraries with an improved technology (ES6).
Hell yeah, we love doing it. Keeps us fresh and interested in the ongoing development of the project and helps push other folks forward with new web patterns, tech, etc.
It not only gets rid of clunky code holding you back, but often the code written to keep legacy working is a huge attack vector because it's generally not scrutinized as much. because well, how many people using it really care if the little chunk of code to make it work in IE6 isn't super solid? Not many... how many 0day hunters care? Many of them.
Dropping old tech means projects/companies that require that support have to do it in-house. We need to support IE7+ for much of our UI, unfortunately, because of paying customers in hospital environments where upgrading is a nightmare.
So it's a good thing in that libraries can be leaner/meaner for everyone who doesn't need to care about old tech, but it also means the unpleasant work of supporting the old tech now has to be carried on by lots of different developers in lots of different companies, rather than being done well in one place.
If there's any possibility of keeping alive an "old-browser-support" branch of BS (like jQuery's 1.x and 2.x streams), that's rather better than abandoning it -- in theory we might be able to contribute some developer time into it.
> When we shipped Bootstrap 3, we immediately discontinued all support for v2.x, causing a lot of pain for all our users out there. That was a mistake we won’t be making again. For the foreseeable future, we’ll be maintaining Bootstrap 3 with critical bug fixes and documentation improvements.
The current plan is already keeping basic support in place for BS3, but no new features. That's probably just where we'll stay, then.
- Sass has a larger community of developers.
- Sass seems to be iterating as a tool faster than Less.
- Sass is really similar to Less, so it's an easier transition to make than jumping right to PostCSS.
- LibSass (the C implementation of the traditional Ruby Sass) is super fast, faster than Less in my casual tests).
Less is simpler, and the canonical implementation (IIRC) is written in Javascript. Sass (now) has libsass which is a C/C++ library (meaning presumably faster), and has a larger feature set than Less.
I always liked that Bootstrap 3 was so inclusive of screenreaders, and as a LTR reader, would never have guessed that RTL support wasn't there if you hadn't pointed it out.
Definitely need to do it. We tried to do it as part of v3 but ultimately left it to the community. We saw a few good things come of it, but it's on my bucket list for the future.
Meh, if it means rapidly putting together a high-quality, cross-browser, responsive website with little effort, I'll accept a little bloat. The savings in developer time is more than worth it, IMO. Doubly so given how much of that CSS and JS is likely cached.
For prototyping this is okay. But for production I try to keep bloat as low as possible. I see this as service to my customers. A fat ui framework like this adds its very own complexity and as soon as you want to go out of the crud box you will have to add your own styles anyway.
I didn't compare the results between Purifycss and this bash script[1] yet. But this alternative, not intent to compete, does mainly the same detection e.g. including dynamic class adding detection.
Indeed an interesting tool.
If one keeps the site structure simple enough I think that the no-framework way might fit best. One doesn't have to go as far as for example this site http://bettermotherfuckingwebsite.com but it made me think about minimalistic css while keeping great device support.
I recently read the blog (http://.ws) of Adam Morse (http://mrmrs.cc) and it gave me some inspiration for my own css stuff.
Yeah, I also like the move to SASS! I used to work with an unofficieal sass port of bootstrap, but not in the future!
(I know less / sass is about the same thing, but i have a bunch of folders of old projects i can copy-paste from in sass, and not in less, so i'm super biased)
You can resize a top-level font size value (namely, the "html" node, e.g. to make it smaller for a mobile screen) and the rem-based fonts sizes for all your components change respectively.
Em (which we use to have for lots of years now IIRC), is the same thing, but instead of being responsive to the top level font size, they are responsive to their first sized parent.
So, inside a DIV with font-size: XXpx, em sized sub-elements will change size with respect to XX etc.
So to size them you have to target their px-sized-parents across your document.
Whereas rem sized items you control from a central single value: the font-size of the "html" element.
In this sense a page full of em-sized elements will behave the same as a page full of rem-sized elemements if the only pixel sized element in the page is the "html" node.
It's good to see that Bootstrap is progressing so fast. Frankly, some features like cards (or some variations of it) have been in Semantic-UI for a while now. It's a matter of personal preference, but like one of the other commentators have suggested, I've also replaced bootstrap in favor of Semantic-UI last year and never looked back.
For me, while developing a web app, it's the ability to come up with faster prototypes and then improve upon the UI at later stages that impresses me the most. Bootstrap was the first one to show me how much you can get done in very less time. But, Semantic-UI is simply miles ahead in this aspect. Semantic-UI is a full-fledged package - THe amount of custom CSS I write in comparison to a bootstrap project is way small say, 70-80% less. That's how good Semantic-UI is for me.
However, this new Bootstrap release actually excited me and I can't wait to test run it. Kudos and thanks to the team for this awesome release :)
Congrats Bootstrap team for Bootstrap 4 alpha release great work.
I am a Bootstrap loyalist from Bootstrap 1 release. I looked at Semantic-UI components for last days and agree they are good in looks but not so easy to use for responsive environment. But comes with lot of integrated feature such as Reveal, Sticky content, Calendar, Validation etc. Was hoping lot now with release 4, Feature displayed in official theme could have been part of release 4.
please add those as part of release 4.
> From a quick look, it still looks bloated for people who don't want to design with mobile in mind
Why would anyone not be designing for mobile in 2015? I question why you would even bother using BS if you're building something non-responsive. Might as well just revert back to 960gs... haha
It's not that I don't want to design for mobiles, it's that I don't want to design for both mobiles and desktops. I just want to design for something that would work for both. So I just use xs- for everything, but it's just confusing to me that they don't have a "default" grid system that works on both instead of having all these sizes.
Booooooooooo. Bootstrap is the most popular CSS/UI framework on the planet. I don't get why they continue to depend on jQuery while most modern app frameworks are abandoning it...
Like which? Ember continues to depend on it. Angular uses a lightweight version. I don't think there's a lot of interest in reinventing the wheel as far as cross-browser JS libraries go.
Angular by default is not using jQuery. They have a convenience layer that is similar to the jQuery-API called jqLight. But if you use Angular in the right way you usually don't need to access the DOM with these methods.
Sorry dumb question. How can bootstrap safely use ES6? Isn't there limited compatibility? Are they using some kind of tool to allow it, or are they only using it for new browsers, and falling back to ES5 if they have to?
@mdo - Thanks for continuing the great work on this framework. I just listened to the Design Details podcast [1] with you on it and it was great to hear about the evolution of the project (And where the purple came from).
The wait for RTL still not over?
I've delayed project for long time while waiting to the official RTL support.
I remember you bumped up the RTL support to XXX version and after that to YYY version.
You ignore the large population reads text from right to left
This is the most important part of the announcement
>For the foreseeable future, we’ll be maintaining Bootstrap 3 with critical bug fixes and documentation improvements. v3 docs will also continue to be hosted after v4’s final release.
I am very new to Bootstrap, but it has been such an easy tool to get a website professional-looking in no time at all. Great to see all these improvements from such a young library.
"Moved from Less to Sass, improved grid system, dropped IE8 support and moved to rem and em units" looks like where Foundation was more than a year ago
Our docs are built on Jekyll, which takes either HTML or Markdown for page content. Markdown is so much faster to write in for docs, especially since we no longer have to escape inline HTML by hand haha.
I prefer it that way. Last thing a front-end framework needs is a bunch of legacy cruft, and they're going to continue supporting v3.
The migration doesn't seem like a tall order: http://v4-alpha.getbootstrap.com/migration/ though my v3 projects are going to stay on v3 until it's time for a complete UI redesign.
Also, I want to add, I don't care where you land on the side of the debate whether to use Bootstrap or not, there is some very smart minds behind the project and there always something to learn from the source code.