Bootstrap 4 alpha(blog.getbootstrap.com)
blog.getbootstrap.com
Bootstrap 4 alpha
http://blog.getbootstrap.com/2015/08/19/bootstrap-4-alpha/
215 comments
Thanks for noticing! :)
I spent a lot of time deleting stuff lol. Still more to optimize around though as we work through the alphas.
I spent a lot of time deleting stuff lol. Still more to optimize around though as we work through the alphas.
Saw on your Twitter that V5 will use PostCSS... Is this still planned? If so, any specific details on how it will be used?
I am wondering why it wasn't ported from Less to PostCSS? SASS is more popular, but that port would be too much of disruption of workflows.
Thanks for your work! It's amazing that I can still recommend it to people looking to quickly scaffold something beautiful.
Any plan to support BEM?
Mentioned on github before https://github.com/twbs/bootstrap/issues/9366#issuecomment-2...
Personally I hope they never impose such an awkward naming convention.
Personally I hope they never impose such an awkward naming convention.
No plans :).
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).
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).
Thanks for the work! I would have no clue on UI without bootstrap
+1 for sincere thanks. bootstrap is one of many factors that had made a lean development approach so much easier.
Thanks!
>>> 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 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].
[1]http://expo.getbootstrap.com/
[1]http://expo.getbootstrap.com/
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.
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.
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.
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.
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).
[deleted]
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
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
I actually think all of that stuff is part of the default bootstrap theme. Remove it and try Flat UI instead, I think it looks excellent:
https://github.com/designmodo/Flat-UI
https://github.com/designmodo/Flat-UI
Just out of curiosity, what were your major reasons against using Bootstrap?
"Dropping support for IE8 means we can take advantage of the best parts of CSS without being held back with CSS hacks or fallbacks".
This sure contributed to reducing the size.
This sure contributed to reducing the size.
We had so few IE8 specific hacks. I don't think it really made a large impact honestly.
Similarly, jQuery 2 shrunk 12% because of cutting out IE≤8 hacks: http://blog.jquery.com/2013/04/18/jquery-2-0-released/
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.
* or thereabouts
* or thereabouts
> Ultimately Crash fit into the PS1's memory with 4 bytes to spare. Yes, 4 bytes out of 2097152. Good times.
http://www.quora.com/How-did-game-developers-pack-entire-gam...
http://www.quora.com/How-did-game-developers-pack-entire-gam...
Negative net upgrade is a rare pleasure we all enjoy.
88KB? Pure CSS framework (http://purecss.io) is only 16.8KB!
Ok, so? I'm sure that Pure CSS has as many components and options as Bootstrap
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.
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)
Yup. Though it's not like it's hard to find samples and compare them. Source: I write typesetting software.
I'm curios to know what doesn't work in rtl? Does bootstrap uses `margin-left` and stuff like that? It should be simple to fix it
.some-class {
margin-left: 1em;
&[dir="rtl"] { margin-right: 1em; }
}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:
.some-class {
&[dir="rtl"] { margin-right: 1em; }
&:not([dir="rtl"]) {
margin-left: 1em;
}
}Part of the problem is, that it's highly undesirable having to mark every node as rtl, when it should just be inerited.
Eventually (https://developer.mozilla.org/en-US/docs/Web/CSS/%3Adir) will be able to write it like this:
Eventually (https://developer.mozilla.org/en-US/docs/Web/CSS/%3Adir) will be able to write it like this:
.some-class {
&:dir(rtl) { margin-right: 1em; }
&:dir(ltr) { margin-left: 1em; }
}
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.
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.
Also launching official bootstrap themes: http://themes.getbootstrap.com/collections/all
Edit: unfortunately though, the 'dashboard' theme is not fully responsive (tables (order history) in mobile view)
Edit: unfortunately though, the 'dashboard' theme is not fully responsive (tables (order history) in mobile view)
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.
Wow, only $99 for officially supported Bootstrap themes. I love it.
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.
Also, from their About page at http://themes.getbootstrap.com/pages/about-us
- 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.
Also, from their About page at http://themes.getbootstrap.com/pages/about-us
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.
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?
Wow, $99.
They only provide one type of license: http://themes.getbootstrap.com/pages/our-license
It is comparable to the "Multiple Applications License" provided by WrapBootstrap. Still relatively expensive since most Multiple Applications Licenses are under $99.
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.
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.)
(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).
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.
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.
I agree. I have definitely wasted $99 worth of time struggling with some of the crap commercial $5/$10/$15 Bootstrap themes out there.
It feels like something officially supported would solve much of the poorly-documented semi-custom - virtually untweakable themes you can buy for $5.
This feels (even in alpha) like a HUGE move in the right direction.
This feels (even in alpha) like a HUGE move in the right direction.
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.
Am I allowed to modify it?
$99 to have your site look like hundreds of others? No thanks.
$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.
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.
There are much cheaper, well made templates available for bootstrap, e.g.: http://themeforest.net/search?utf8=%E2%9C%93&term=bootstrap
For my understanding: why is my post downmodded to -1? Could someone explain that to me please so I can avoid the mistakes in the future? Thanks.
Not the same thing.
Have you tried to use any of these?
How is their support?
Documentation?
Have you tried to use any of these?
How is their support?
Documentation?
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.
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."
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.
For an internal dashboard thats just supposed to work and look decent I'd say thats not a bad deal.
On iPhone, the marketing theme loads way zoomed in. Doesn't seem intentional, so probably a bug.
Thought they would be written with BS4. I hope they will be upgraded eventually.
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.
https://github.com/postcss/postcss
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.
https://github.com/postcss/postcss
> 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.]
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.
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 can't help but feel like the anti-native-extensions point of view is short sighted.
Why shouldn't we have optimized implementations of algorithms that we can share across various languages?
Why shouldn't we have optimized implementations of algorithms that we can share across various languages?
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...
Then again, having (at least) two implementations is one way to test compatibility and nail down unclear specs...
You would need GCC to install Node anyway. Not to mention the fact that you probably have GCC or Clang already anyway...
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.
FWIW it is possible to ship a native node.js module that falls back to an emscripten version when a c++ compiler isn't available - see http://insertafter.com/en/blog/native-node-module.html for an example.
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.
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.
I'm on Windows and I don't want to install Visual Studio just because of libsass...
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.
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.
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.
There's no reason to use Ruby https://github.com/sass/libsass
libsass is very strange. It must be statically linked and it requires copyright assignment for contributions.
The LICENCE file looks like standard MIT to me. Where did you find this info?
Here: https://github.com/sass/libsass#contribution-agreement
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.
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.
I've been hearing a lot of noise about that. As a person who went from LESS to SCSS, is there any reason I should again switch my focus to PostCSS?
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.
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.
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.
would you mind sharing what were the significant issues with LESS?
I'm using LESS and just wondering what I might be missing.
I'm using LESS and just wondering what I might be missing.
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.
Because PostCSS allows you to write future spec compliant code, unlike sass. It's like writing ES6 then using a transpiler to generate ES5.
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 same issue exists with v3 needing a LESS compiler.
Only there are TONS of LESS compilers, even a straight PHP one, a pure JS etc, whereas Sass has either Ruby or a C/C++ dependency.
Only there are TONS of LESS compilers, even a straight PHP one, a pure JS etc, whereas Sass has either Ruby or a C/C++ dependency.
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.
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 used to use it (lessphp) for some light LESS use, so it might be faulty for more advanced stuff, but was OK for me.
v4 will compile with libsass by default. You can set the TWBS_SASS environment variable to use the Ruby compiler if desired.
@mdo recently tweeted that v5 will likely be in PostCSS:
> Oh, btw—Bootstrap 4 will be in SCSS. And if you care, v5 will likely be in PostCSS because holy crap that sounds cool.
https://twitter.com/mdo/status/591364406816079873
EDIT: also, elsewhere on this thread, he mentioned:
> Sass is really similar to Less, so it's an easier transition to make than jumping right to PostCSS.
> Oh, btw—Bootstrap 4 will be in SCSS. And if you care, v5 will likely be in PostCSS because holy crap that sounds cool.
https://twitter.com/mdo/status/591364406816079873
EDIT: also, elsewhere on this thread, he mentioned:
> Sass is really similar to Less, so it's an easier transition to make than jumping right to PostCSS.
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.
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.
Notes from the actual post:
> 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.
> 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.
Flex! fantastic. I have no opinion but am curious about why you bailed on Less and committed to Sass. If you see this, can you explain?
Happy to explain!
- 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).
- 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).
From their brief description it seems like it's because Sass is more powerful and faster to compile.
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.
It's definitely more readable. Some of the workarounds less forces upon your code get downright ugly.
I'm launching a not-so-critical thing in 2 or 3 months, currently using Bootstrap 3.
Is it safe to adopt 4 right now, to be more future-proof? I don't mind bugs that eventually will be fixed but is the API stable enough?
Is it safe to adopt 4 right now, to be more future-proof? I don't mind bugs that eventually will be fixed but is the API stable enough?
4 major versions and still not official direction support! that's why i use Foundation because it offers RTL support out of the box.
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.
Blimey, that is an omission.
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.
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.
I'm not sure if one really needs to load in tons and tons of css and js for displaying a site like http://themes.getbootstrap.com/products/marketing
:/
:/
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 try to get my bloat down, I just load the components which I'm going to use (most of the time it's the grid).
There are some tools like purifycss [1] which can delete unused css
1: https://github.com/purifycss/purifycss
There are some tools like purifycss [1] which can delete unused css
1: https://github.com/purifycss/purifycss
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.
1: https://gist.github.com/50kudos/3028fac585eda85aea9a
1: https://gist.github.com/50kudos/3028fac585eda85aea9a
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.
I recently read the blog (http://.ws) of Adam Morse (http://mrmrs.cc) and it gave me some inspiration for my own css stuff.
You can cut the unused styles out after.
<!-- open graph bullshit -->
Kudos to whomever wrote it. The customized meta tags crap for each service has gone too far.
I'm very excited for the move to SASS and ES2015.
Also, the few themes they have on themes.getbootstrap.com look very nice!
Also, the few themes they have on themes.getbootstrap.com look very nice!
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)
(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)
> Pixels have been swapped for rems and ems where appropriate to make responsive typography and component sizing even easier.
Can someone explain the benefit of this?
Can someone explain the benefit of this?
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.
Thanks. What about em?
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.
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.
Thanks for this simple explanation.
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 :)
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 :)
>Moved from Less to Sass.
what was the motivation for the switch?
what was the motivation for the switch?
From mdo's answer in the Slack chatroom:
> more people use SCSS, libsass is crazy fast, syntax is more explicitly clear, and I'm lazy and use SCSS at GitHub
> more people use SCSS, libsass is crazy fast, syntax is more explicitly clear, and I'm lazy and use SCSS at GitHub
I am happy that they now have cards. That is something I can drop from my custom styles.
> Moved from Less to Sass
I felt like this would never happen
> Opt-in flexbox support is here
Awesome. That's the future :)
> Improved grid system
From a quick look, it still looks bloated for people who don't want to design with mobile in mind
> Reboot
they are using box-sizing: border-box so cheers to that
> Every plugin has been rewritten in ES6
nice!
> Improved documentation. We rewrote it all in Markdown
wow it looks really nice now
I've dropped Bootstrap a year ago in favor for Semantic-UI. I'm curious to see how this new version holds up.
I felt like this would never happen
> Opt-in flexbox support is here
Awesome. That's the future :)
> Improved grid system
From a quick look, it still looks bloated for people who don't want to design with mobile in mind
> Reboot
they are using box-sizing: border-box so cheers to that
> Every plugin has been rewritten in ES6
nice!
> Improved documentation. We rewrote it all in Markdown
wow it looks really nice now
I've dropped Bootstrap a year ago in favor for Semantic-UI. I'm curious to see how this new version holds up.
> 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
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.
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.
Sass by default FTW!
It says they rewrote all of the JS using ES6... Does this mean jQuery is no longer a dependency?
It says they rewrote all of the JS using ES6... Does this mean jQuery is no longer a dependency?
Assuming the comment in the starter template isn't outdated, jQuery is still required.
http://v4-alpha.getbootstrap.com/getting-started/introductio...
http://v4-alpha.getbootstrap.com/getting-started/introductio...
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...
The most popular UI framework using the most popular UI library? I don't see the problem.
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.
No, jQuery is still required.
Nice work :) And the migration process (http://v4-alpha.getbootstrap.com/migration/) doesn't look to be too hard, either.
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?
They're probably using a preprocessor like Babel[1] or something like es6-shim[2]
1: https://babeljs.io/ 2: https://github.com/paulmillr/es6-shim/
1: https://babeljs.io/ 2: https://github.com/paulmillr/es6-shim/
I can understand rem units in font-size, but why use rem in media queries instead of px?
The same with margins - when I get the PSD file from the designer, I will have to convert all margins from px to rem.
The same with margins - when I get the PSD file from the designer, I will have to convert all margins from px to rem.
Foundation has a Sass function to do this called rem-calc(pixel size), not sure if there is a Bootstrap equivalent.
I'm not convinced that it makes sense to migrate existing sites to new versions of libraries like this unless a fairly complete redesign is happening.
Looks great though.
Looks great though.
@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).
[1] - http://spec.fm/show/design-details/14701
[1] - http://spec.fm/show/design-details/14701
Hah, happy to hear that. Thanks!
> Want default transitions on everything or to disable rounded corners? Simply update a variable and recompile.
Oh hell no. But the rest is grand.
Oh hell no. But the rest is grand.
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
Please add RTL support to Bootstrap 4 we need it
You ignore the large population reads text from right to left
Please add RTL support to Bootstrap 4 we need it
For anyone interested, there's a PR in the rails bootstrap-sass gem: thehttps://github.com/twbs/bootstrap-sass/pull/954
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.
>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.
probably not the most useful place to point this out.
https://github.com/twbs/bootstrap/issues
https://github.com/twbs/bootstrap/issues
[deleted]
You're moving too fast. I just migrated mine app to 3.
@Bootstrap Team. Any plans of reviving Ratchet(http://goratchet.com) project?
Nice job, Bootstrap saved me so much time already. It really helps by getting the job done! However, in most of my projects I just used the grid.
Is there any reason checkboxes and radio buttons aren't styled, e.g. like in wtfforms? Are there plans to merge that project into bootstrap?
We've got them! See http://v4-alpha.getbootstrap.com/components/forms/#custom-fo... :).
@mdo Any plans of reviving Ratchet(http://goratchet.com) project?
Very interested in the new grid system. It's always been my favorite part of Boostrap—looking forward to see what they do with it.
I'll be interested to find out what level of customization you can do to it.
The fact their grid was so rigid is why I switched to Jeet a while ago:
http://jeet.gs/
The fact their grid was so rigid is why I switched to Jeet a while ago:
http://jeet.gs/
I could be wrong but looks like this doesn't have responsive text alignment? Really miss that on a regular basis with bootstrap.
[deleted]
progress bars has changed
http://v4-alpha.getbootstrap.com/components/progress/
SASS and rem are the biggest features I am looking forward to.
No backward compatibility with Bootstrap 3?
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.
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.
well glyphicons have been removed, didn't even notice it in the docs.
I haven't really been a loyalist to Bootstrap, but this is the shiz.
that card things looks exactly card from picnic css.
fr7anu(1)
Wow the shilling is hard in here, that dashboard is an extremely limited implementation and looks like garbage. Why would you ever pay $99 for 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.