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.
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.