The most interesting part of this release (well, something that came shortly before this release) is Bootlint, their linter for your bootstrapified markup.
I could see myself integrating something like this into a text editor or a build process -- something that watches for bootstrap usage errors and helps my team correct them early and quickly. That is, of course, assuming that we stick pretty closely to vanilla bootstrap, which we usually don't.
One of my biggest issues with Bootstrap (and similar frameworks) is that, beyond a certain point, you find yourself overriding and customizing them to such a degree that it's more productive to just build your own "vanilla" components that are specific to the way your site or organization uses them, and then just ditch Bootstrap altogether.
One thing I'd like to see is a way of generally linting HTML structure (not validity, but actual structure) with a goal of reducing complexity and improving maintainability, regardless of what frameworks you may be using. Something that spits out a ratio of meaningful, semantic markup to "div soup" and tells you where you should spend the most time mopping up the soup. It could also have some understanding of which kinds of div patterns are acceptable -- bootstrap components, your own component library (see: OOCSS), etc.
> you find yourself overriding and customizing them to such a degree that it's more productive to just build your own "vanilla" components that are specific to the way your site or organization uses them, and then just ditch Bootstrap altogether.
This has been similar to my experience. Bootstrap can be overwhelming at times, and there have been a few cases where I had to solve buggy behavior by specific Bootstrap components by writing elaborate fixes that would not have been required had I used my own framework. From that standpoint, working on a time-consuming, yet practically throwaway-type site, Bootstrap was really frustrating.
I do really like the low-baggage approach of Initializr's Responsive configuration as well as the Responsive Grid System.
For small throw away sites I tend to have getbootstrap open and using Chrome debugger cut and paste the bits off CSS I need into my own project.
Things like the nav bar are really clever, but way too much for most of my projects. I like the button styles, but usually modify them... stuff like that.
> One of my biggest issues with Bootstrap (and similar frameworks) is that, beyond a certain point, you find yourself overriding and customizing them to such a degree that it's more productive to just build your own "vanilla" components
I think Bootstrap was meant as components ready to be used out-of-the-box as they are, but not necessarily easy to extend and customize.
I think what we need is a framework that makes components easy to create and extend, and then build a widget library on top of it that provides the most commonly needed components/UI patterns.
If the components where easy to understand and extend, then we can just look inside them, copy paste and make our own by modifying just the part that we need.
The problem is that they are not, in the case of Bootstrap these seem to be quite extended set of jQuery based components that you can spend a lot of time debugging to understand how they work, and modify them to do what we need.
It's interesting to me that people expect that people expect Bootstrap and friends to grow to large scale projects. As implied by the name, Bootstrap's great for getting your new project off the ground. Once you're up and running though, you should have the time (and/or the team) to take care of things in-house.
Why? That's a bit like saying a back end development framework is only a starting point, and you should start working outside of it as soon as your product is mature.
I don't think the name carries the explicit rejection of ongoing use that you believe it does. That you can use it to get started quickly does not mean you can't use it indefinitely; it's often necessary to tweak or hack Bootstrap to fit your specific visual requirements, but for a project that can actually use it without serious modification, I don't see a reason to throw out the convenience and consistency it provides arbitrarily, simply as a matter of course.
But that's just the case. Also back end frameworks give general good enough solutions for problems but they are never optimized for particular use case. If you stay in general framework solution your competitive advantage is often easier to copy so you must make difference with customized / tailored solution. Earlier you start smaller the change is. If you hang yourself to general solution too long switch might be even impossible to make since costs and risk grow too high. And then you are in death spiral when more flexible start-ups begin to eat your share.
Can you give an example of when this has happened? It strikes me that driving your model around being difficult to replicate from a technical point of view wouldn't necessarily lead to good business decisions.
I tried to use foundation on two separate occasions. Each time, basic features were broken (or completely missing!) out of the box, and when I tried to investigate, the code was so tangled and awkward that I either abandoned foundation, or implemented the feature from scratch myself.
Bootstrap is pleasant to work with and extend. Each of the javascript components are simple, isolated, and well thought out.
For me it is about documentation. While Bootstrap was documented thoroughly (with the one exception of not having a transition guide for the changed grid system between 2.x and 3.0), I felt that this wasn't the point for Foundation. E.g. it was never clear for me wether off-canvas navigation was an experimental feature or not. Also scrolling the documentation doesn't feel smooth on my MBP / Chrome.
I really don't like Foundation because of the way it looks out of the box. Everything is way to square and brightly colored. Bootstrap just looks quite good from the start. After a quick look at the markup however, I really think Foundation is winning there.
Foundation used to have a better grid system, better css defaults (border-box) and the "advantage" of using Sass over Less. Bootstrap just looked better since it had a theme embarked and also a nice documentation. Now Bootstrap has caught up, I haven't used Foundation in 2 years but I would think they're still relevant.
The reason I use Bootstrap over Foundation is that there is a lot more community support for it. It's much easier to find solutions to problems. Additionally, the huge number of available themes for Bootstrap make it a very compelling choice for the average dev who has terrible design skills.
I think Bootstrap had the benefit of being called Twitter Bootstrap during the early part of its life. That alone brought a ton of initial interest and it just continued to build from there.
They're basically at parity now IMHO, but Bootstrap has the network effect advantage. It's got a huge community of people developing plugins, creating themes, and doing debugging on it. I've used them both in the past, but prefer Bootstrap for this reason.
- Foundation ceases to be an option since they drop IE8 support in Foundation 3, far too soon IMHO
- Various jQuery UI-based frameworks out there (e.g. Kendo UI) has good Bootstrap theme support
When Bootstrap first came out, it looked way better than Foundation out of the box -- had better typography. I think that's mainly why. I think it's possible Foundation has caught up.
I can't imagine that's a real deterrent is it? Using LESS with Foundation is fairly straightforward. Create an empty .less file and @import 'foundation.css'. Also, LESS and SASS have very similar syntax. There's very little learning curve if you're going from one to the other...
I feel like it's going pretty fast. Do Google or Facebook even officially support IE8 anymore? I think the quicker the issue is forced the better it is for everyone. IE9 is at the very least pretty acceptable to deal with.
Does that 20% come from your own stats or a third party? Most of the third parties look at worldwide market share. IE8 is disproportionately represented in third-world countries which you may or may not care about in your business.
Best I can tell IE8 is somewhere around 6% in the US (these numbers are rough to find because most of the places that collect statistically significant numbers charge for the info). On my site (which centers around a first-world disposable-income-heavy hobby) IE8 is basically non-existent. Your mileage may vary.
On my largest site with a couple million visitors a month, IE makes up about 16% of site visitors. About 25% of those are using IE8. So, about 4% overall. I specifically ensure that the site still works in IE8 and up and was still quite functional on IE7 when I last looked.
Anyone not ensuring their site works on IE is leaving money and customers on the table. Note that it doesn't have to look exactly the same, but it should still work and allow customers to learn, buy, sign in, subscribe, etc.
It depends on your market. I've worked on apps that have never even seen a visitor using internet explorer at all. This happens all the time in b2c software. So that analogy of leaving money on the table is not very realistic.
Of course, it varies. But there are far more users of desktop IE than desktop Safari in the US, for instance. So, once your product spreads beyond early adopters, iPhone users and Mac users (all of which are the minority of the market by large margins in each case) it's important that your site already works with the new visitors as word spreads.
It's not just early adopters vs late adopters. And nobody is saying to disregard all of IE, only very old versions.
We're talking about dropping support for a browser that is mostly used on a thirteen year old operating system that even Microsoft has dropped support for.
My site is unlikely to ever have a significant number of IE8 users. It revolves around a nerdy hobby that people easily spend $500/year on, often in big chunks. They aren't letting their tech get that out of date.
I fully admit that this isn't every market, but you absolutely CAN make decisions about your specific market and decide that IE8 just simply is not and never will be worth it.
On the other hand, there are certain markets that will probably have to worry about IE8 for ten more years.
Gmail is part of Google Apps. That's pretty mainstream. Personally, where I work, anyone using any version of IE is screwed. We don't test for IE. I haven't checked to make things worked in IE as a regular part of development since 2009 and I have worked at a pretty big company that is often talked about on HN.
A few years back I was working on an app with some moderately fancy CSS and JS. We desperately wanted to drop IE6 support but after we pulled the revenue numbers per browser, we worked out our IE6 users could pay for a junior-mid range developer to just sit there and fix IE bugs all day.
I wonder what that's doing to the maintainability of your code base. I'm sure the overall cost is higher than just the pay of a single developer ruining your architecture. Supporting IE6 is more than just about fixing bugs.
Also, something to possibly consider: reach out to customers and ask them how much they need IE6 support. Unless it's healthcare or government, I'm not sure why anyone would use IE6 by choice. Would deprecating support for IE6 lose every single one of those customers?
A big chunk of the old IE users were military people deployed in the Middle East. I'm of the understanding that they have/had some sort of Internet Cafe setup on base, and I guess they were running older browsers.
And what happens when the amount of your users drops slightly or that hired dev is now worth more money? And what about the other costs on complexity in your codebase? I think the revenue needs to far eclipse one dev's salary to justify keeping IE6 support.
I believe (but cannot prove) that the 20% is mostly due to China. Because it's such an incredibly populous nation, it can dominate international statistics like these.
Unfortunately my home nation (though very small) is also on something like 20% WinXP (thus limited to IE8). It's ridiculous, but as long as clients are willing to pay us to support IE8, then that's what we'll do, much as we hate it. In my country it hopefully won't be long before it becomes prohobitively expensive to support IE8, so there's that... :)
How long should the mountain wait for Muhammad, though?
In the UK, analogue terrestrial television was eventually turned off, and replaced by digital, following a lengthy publicity campaign.
I would guess there are very few people staring at blank TV screens and wondering what to do now. My point is, you need to give people a push sometimes.
Anti-virus companies use an IE8 user agent string sometimes for finding dangerous sites.
Other bots and crawlers still use the IE8 string, although it seems like many are switching to Chrome.
I've never been able to find a resource about this, but is there any data available for the breakdown of bots/crawlers and their effect on browser usage statistics?
One reason I ask is that using the web with IE8 is pretty miserable and a lot of sites are flat out broken. I know there is an aspect of corporate networks on it, but 20% just seems really high if you realize that 20% or more of the web is broken for IE8 users.
Bootstrap 3 still supports IE8. You can still use Bootstrap 3, or even Bootstrap 2.
But it makes little sense to develop new tools that support IE8 at this point. By the time Bootstrap 4 is released (probably many months from now), IE8 usage will be even lower.
Further, since it's solely responsible for so many edge cases, polyfills, and hacks, it doesn't hurt to gently push for its demise. Even Microsoft is trying.
Well why in the name of all good design did Microsoft not put out a version of IE9 for Windows XP while it was still supported? That would made everything so much simpler, including for them -- after all, they have to worry about IE8 just like the rest of us, XP or no.
Jesus, I don't mean for me. I haven't touched XP in years, and have very rarely used any Windows OS for the past 5-6 years.
But there are millions of people in developing countries who can't afford to upgrade, or don't know how. Have you considered that? This is not a first-world problem.
Why not accommodate those users? MS doesn't have to support the OS itself, but think of how much trouble it could save developers around the world -- inside of Microsoft and out -- if all these XP machines were automatically upgraded to IE9.
Uh, when was the last time you saw XP on a new machine - from Google Analytics on a UK retail site I'm getting 2.4% of users on XP this month, equivalent month in 2013 was 6.5%, in 2012 was 12.4%, in 2011 21%, 2010 34% - that's basically halving each year for the last 3 years.
Yeah, this is because your users are mostly in the U.S. or Western Europe. It's a different story elsewhere in the world (although even those countries are slowly moving off of XP).
There's an informative talk by Alice Bartlett, a front-end developer at gov.uk (the UK government digital service) on Youtube. In the presentation, she states that two of the requirements for gov.uk are
1. Functional without Javascript
2. Functional in IE7+
The essential point made is that for much of gov.uk, it isn't that difficult to make the site work without Javascript or work in IE7 either.
Purley personal opinion, but web design has become incredibly bloated with so much cruft added to web pages - be it unnecesary Javascript or excess CSS. Web developers pick the tools that make their lives easier (as you'd expect), but that doesn't always mean that users get the best experience.
Heavy use of client side methods seems to break a lot of the benefits of using web apps in the first place. A main advantage of web apps originally was that they worked more or less the same on any machine. That Google Maps worked in exactly the same way regardless of how good your machine was at vector rendering. I wonder if the aversion to maintaining state on the server needs to end. You could do almost anything that a modern web app does with minimal client side code and have performance on low end PCs.
Consider that Bootstrap 3 isn't going away if you need IE8 support, and plenty of sites would be comfortable with that restriction. (Eg, all sites that use <canvas> in a non-fallback-able way)
> Do you expect IE8 browser share to change significantly in the next couple of months?
IE8 implies XP. XP is now actively nagging users about how dead it is every time they boot. The holidays are coming up. It is not unreasonable to expect some people to replace their prehistoric computers around the end of the year.
IE8 is under 4% now globally. Unless your customers are primarily large enterprise shops that's probably a reasonable trade-off even now, much less by the time Bootstrap 4 is actually released.
ALL Developers want to drop support for IE8. Has anyone had fun developing a site for IE8?
Business owners looking to make profit anyway they can DO NOT.
We do A/B testing for very small % gains yet we are ok with delivering a site that wont work in IE8? It is a hard business case to make with clients.
I'm glad the framework is moving forward, we all like playing with new toys, but I hope there is an IE css file that will "fix it enough" to make it work for IE8
If you can convince the 10% of Australia's population to stop using IE8, then I'd be happy to. As it stands, where I work charges a lot more for IE8 support, but most places are happy to pay it :(
The statement may be more to test the waters than to state a hard and fast condition of Bootstrap 4. Also, it's not like someone can't just use the 3 series. For our internal app, we're still using Bootstrap 2.
It's a 5 year old browser. The only operating system stuck on IE8 is Windows XP, a 13 year old operating system. I have a feeling that anyone still using it won't take much notice of things being a little broken.
I disagree. The company I work for provides software to schools and school districts, which tend to be pretty far behind the technological curve. After analyzing our usage patterns, we were able to drop IE8 recently.
If you're using IE8 still, you're probably pretty used to a broken web. For most purposes, I think developing for IE8 should basically be making sure your very basic content and functionality is available in some form. But I think it's ridiculous at this point in the game to be aiming for 100% compatibility. If someone cares enough, they'll upgrade.
Not really. The only people who still need to support ie8 are in enterprise and the enterprise is usually a couple years behind. By the time they upgrade to bootstrap 4 ie8 support will have ended.
My product's client base is 9% IE7 and 60% IE8. Mainly hospitals and .gov agencies use our system. It's getting really hard to even test with those browsers let alone find frameworks that will work for our client base and we can't even force them off, because "IT says we can't install anything because it's insecure." AH!
It's pretty bad. We once got a ticket to make sure our app works with "ALL BROWSERS" because it was broken in IE6. That ticket was 6 months ago. The users are out there.
On highly trafficked sites , IE 8.0 usage can account for a fair amount of users, and conversions etc. It's a tougher decision to make to take those users off the table.
I won't work anywhere that cares about IE. If you are a company that wants to support IE and have competent, professional engineers I hope you pay a high salary.
This is such a stultifyingly stupid attitude it's hard to know where to begin, or to understand how you can be effective as a developer.
Let's be clear – if you develop a service on the web, and a significant proportion of the users or target market uses IE8—enough that there's a positive ROI—then you are making a poor business decision by refusing to support it.
If you have significant resistance to upgrading from Windows XP or IE8, then you need to charge more for your product. Let's face it, maintaining websites on older browsers that have poor standards support is expensive.
I maintain such a web application myself. I work primarily on OS/X as my main development machine, and run various windows versions in virtual box in order to test these older browsers. Since the feature is usually completed using modern browsers up-front, there almost always a QA glitch that has to get worked out on IE8, chewing up another 20-30% of the total time of the project. Time that costs everyone in the business time, energy and pain. Think about that; 30% of the cost of development to support < 3% of the users.
When the large web companies like Google and Facebook remove support for these legacy browsers, every web developer on Earth cheers. Every instance of IE8 that is snuffed from existence is more time we can spend on creating great software features, and not wasting time back-porting.
I'm doing just fine as a developer. What you think is a stupid attitude is shared by pretty much everyone I work with, and others as well. From managers down to individual engineers. It's an attitude shared by many startups too in the bay area. People are either developing mobile apps for iOS or Android, or web apps for Chrome and Firefox, and probably Safari if they care about mobile.
IE updates come in too slow, longer than once a year - it's been a year since IE 11, and IE 12 is not even on the near horizon. Chrome and Firefox have had how many updates since then? Even Safari has updated in that time. Windows 10 is slated for release after April 2015, that's a year and a half since their browser has been updated!
IE selectively implements standards for business reasons and IE has a history of versions sticking around for long periods of time.
IE's developer tools, even in IE 11 are horrible. They're not even a shade of what webkit, blink and mozilla based browsers offer.
Finally, and the most damning of reasons: you need to have a Windows machine or a slow and painful (and expensive) virtualization service to test IE if you don't use Windows to develop. We all use macs, if someone isn't using a mac they're more than likely using some linux distro. I haven't worked with a developer that used Windows as their main development machines in 5 years, and in that case they were actually developing a windows application.
IE doesn't deserve our attention, users can install a different browser or deal with it, but I haven't heard a user complain about it, at all. Once in a long while someone might ask, sheepishly, and not make a big fuss about it when we tell them that we don't really support IE.
I worked in an environment like that a few years ago on an internal SPA. IE6 was so bad in terms of memory leaks, the app was unusable in IE6 after a few hours. Many people were using Firefox standalone for our app (among others) just to be able to keep things open all day.
I use SassC: https://github.com/sass/sassc - a basic SASS/SCSS compiler written purely in C. It's not 100% up-to-date with the ruby version and you miss out on the more advanced features like custom functions, but it's blazing fast and I've never really needed more than the basic features anyway.
> The libsass library is not currently at feature parity with the 3.2 Ruby Gem that most Sass users will use, and has little-to-no support for 3.3 syntax.
That said, it is mostly good enough. I've used it for a few SASS projects in combination with Bourbon and it works great. IMO the huge compilation speedup (I saw reductions from 5-6s to about 200ms) was worth the slight move backwards in features. I became much more productive with a more responsive livereload.
Yes - we use libsass across the board, including building BS3, and have had no issues with compatibility. It used to have a problem with high precision numeric values (like "6.666666666%" in BS) but that's has been resolved.
It's already got a 3.3.0 available, it is kept sync'd.
I have very occasionally run into a bug or problem with the sass port not being kept properly parallel to the original less, but mostly it just works fine.
Yeah, I have run into that too previously, with "QA" on the Sass port not being as good as one might ideally like.
But, hey, look, they already released 3.3.0.1 of the sass version fixing the problem, 3 hours after the ticket was filed, that's pretty responsive, sometimes that's the most you can ask for.
(Part of the issue is it's not JUST a Sass version, people expect a Sass version that works with Compass with or without Rails, and that works with Rails without Compass, and that works with Sprockets without Rails, and that works standalone with nothing but Sass just compiling css like the Less version, and each context has it's own picadillos).
No, but there's a JS file that transforms your LESS into CSS in the browser. It's handy for development but obviously you'd want to pre-compile for production.
Yes, dropped for v.4. Both are good frameworks and these new versions look great, but considering I prefer SASS to LESS I don't think I'll be switching back to Bootstrap any time soon.
Am I the only one who actually thought that video was going to show some sort of demo for the new release? hahahah. I was actually pretty disappointed when that didn't happen.
They started to add it with some automated flipping tech around 3.1 but a developer of a 3rd party Bootstrap RTL project convinced them that it didn't belong in core and should be done manually. The argument made no sense to me but they scrapped their efforts shortly afterwards.
https://github.com/twbs/bootlint
I could see myself integrating something like this into a text editor or a build process -- something that watches for bootstrap usage errors and helps my team correct them early and quickly. That is, of course, assuming that we stick pretty closely to vanilla bootstrap, which we usually don't.
One of my biggest issues with Bootstrap (and similar frameworks) is that, beyond a certain point, you find yourself overriding and customizing them to such a degree that it's more productive to just build your own "vanilla" components that are specific to the way your site or organization uses them, and then just ditch Bootstrap altogether.
One thing I'd like to see is a way of generally linting HTML structure (not validity, but actual structure) with a goal of reducing complexity and improving maintainability, regardless of what frameworks you may be using. Something that spits out a ratio of meaningful, semantic markup to "div soup" and tells you where you should spend the most time mopping up the soup. It could also have some understanding of which kinds of div patterns are acceptable -- bootstrap components, your own component library (see: OOCSS), etc.