Most of everything in this article is taken from their blog posts, their new docs, looking through the source, and checking out the Bootstrap 4 pending Pull Request [1].
Really just wanted to test all the new features and see what was what with it. Decided to make some demos to compare some stuff too.
Yes, thanks for the post. Helps to understand the differences quickly. I'm in the process of planning an update to B4 and it will save me lots of time.
I'm glad they're supporting Bootstrap 3. The switch to Sass is unfortunate. I never had a problem with compile times and being able to pick and choose the bootstrap I needed in my own less build was really nice. I don't think I'll be using newer versions of Bootstrap. Once they stop supporting 3 I think I'll move on to a new CSS framework. I just think they shouldn't change builds like this on frameworks that are already widely used. I'm sure Sass developers were making use of Compass or other Sass frameworks if they needed to integrate the framework with their own builds.
If you are using Less, why bother with Sass, since it isn't that much different?
NB: It's their project, they can do whatever they want, and I'm extremely thankful to everyone who has contributed to what I consider the most important project for web usability in the last decade. But I still view this as a deeply pointless change that will cause lots of unnecessary pain.
I don't know, I never really liked Less and never understood why they picked it over Sass in the first place. In Less everything looks quite slick until you start doing loops, loops are just looking terrible (you can have a look at the documentation here: http://lesscss.org/features/#loops-feature). Since having loops is a big advantage of having a preprocessor, I never understood why Less was so popular.
Less was CSS compatible before Sass was, that's why I started using it. I really haven't ever had the need for loops. Less is also widely supported by all kinds of build tools, editors, IDE plugins etc. There's no searching for the wrong kind of Less as there would be for Sass since from what I understand there are two different types of Sass (Sass and SCSS).
I find it way easier to install less with node & npm, than it is to setup ruby & sass. If I'm developing with a "mean" stack, its kind of a nuisance to have to set up ruby instead of just using something node based.
None of the bootstrap stuff works with Angular out of the box anyways, and I always thought it was very verbose. Honestly all I like was the grid system anyways, so I don't see much need to upgrade.
> This is great because Sass tends to be more favorable by front-end developers
I don't understand what this mangled sentence means. How do they know what's favorable to front-end developers? Nobody asked me what I think. They did a valid random sample?
I will never be able to understand why the grid class names are abbreviated. It's borderline unreadable and it's one of the primary reasons I avoid bootstrap when I can. Foundation is much better in this regard class="large-6 columns" makes much more sense than class="col-lg-6".
This is a good article though. I've been wondering what changed in the new version.
It takes longer to parse. The same way "Wht r u talking abt" takes longer to parse than "What are you talking about". The former requires my brain to do several extra lookups before I arrive at the meaning. I would rather just type the extra characters for the words Column and Large.
After you've typed a thousand of these things your brain will just be doing a single lookup. From a newbie perspective, your opinion has merit but for long-term use it makes less sense.
"It seems though that if you need Internet Explorer 8 support, you’ll have to stick to using Bootstrap 3."
I'm kind of surprised. No doubt some user bases have user bases running newer browsers, but with IE 8 still sitting at ~13% market share[1] I suspect this will prevent many people from using Bootstrap 4, including myself.
I don't know where Net Market Share is getting their data, but that's _way_ off compared to literally everyone else who's reporting. The tip-off for me was that they report all of Firefox+Chrome as ~10%. See https://en.wikipedia.org/wiki/Usage_share_of_web_browsers - the IE share reported on that site is being overestimated by at least 2.5x and more likely around 4x.
Or everyone else is getting it completely wrong, I guess.
I'm at a fraction of a percentage for IE 8 as of yesterday in a sampling of over 100,000 sessions. If the sample is from desktop only users, that numbers moves up.
That is still a large enough number to matter for a startup where those make or break growth & retention numbers matter. It would be insane to throw out 1% of your visitors while other employees are doing cartwheels in A/B testing for 2% improvements.
The general principle I follow is drop support if a platform no longer receives security updates. The second part of that is to continue to produce a simplified version of your site that should work on all browsers. This provides big benefits for disability access, low bandwidth users (which is all of the developing markets), and edge cases.
Probably depends on a site's audience. I know in the financial industry that an unfortunately large amount of people still use IE8 as many vendor websites require it (long live Active X). But I imagine the visitors to many B2C websites no longer use IE8.
> That is still a large enough number to matter for a startup where those make or break growth & retention numbers matter.
I disagree. I work at one of said startups, and we have dropped support for IE9 and below. We figure the 50+% increase in productivity (directly translated into new features, speed improvements, etc.) is well worth it.
Thanks for pointing out that Google's chosen data may be questionable. I found two other sources citing more like ~2.5% market share, which is in line with what you cite. I was motivated to go check our analytics and we're at more than 7% IE 8, so way too high for us to think about dropping support.
I speculate that sites with low numbers of IE 8 users are typically oriented towards more technically savvy users, and/or if those sites were never working for IE 8 to begin with and so never had an opportunity to pick up IE 8 users in the first place.
Flexbox and Sass-first is a nice surprise, but the switch to rems steals my attention. I know that backwards-compatibility goals kept them on px, but that has long been my one complaint with Bootstrap (as a regular user, not as that guy who "would use it except [minor reason]").
I stayed away from Bootstrap 3 for that very reason in my front-end work.
I would keep my own REM and %age-based "starter grids" (1, 3, 4, 6 and 12 column grids), along with a more simplistic <!--[if IE ]> pixel-based grid (IE = rounding problems), on a USB stick which I would carry around from project to project - allowing me to quickly mobilize from site wireframe to initial mockup with a very short turnaround. For anyone who wants to waste the setup time that I did, I used calculations by-hand along with the "Responsive Grid Calculator"[0]
The other thing selling me over is the _opt-in_ flexbox support as well. If your client has only one big user who is on IE8, and this includes more non-tech companies than I'd like to acknowledge, you will undoubtedly have to support IE as well.
Actually, there's a lot of stuff in there that I'm going to find useful. The flexbox integration is great, and hopefully will lead to wider adoption of flexbox in general. Cards are something I've had to implement myself, and the core one looks much nicer.
Perhaps it's not going to be useful for you, but for me, I'm grateful for all the work put in by those involved in this open source project.
Seriously I love that they added cards and dropped Panels and Wells. I used to have to create something like cards on nearly every project and used Panels/Wells maybe once.
Agreed! What I like about Bootstrap's development is giving people the flexibility to jump into something new like panels/well & then look for other plug-ins/hacks to customize the experience. Once those trends become more mainstream, they do us all a favor and incorporate them more cleanly. Cards are such a natural extension for a responsive layout.
As a front-end dev, I'm excited to use v4 in my next project. It has more features and the styling is even _less_ opinionated, which equates to fewer overloads.
