Bootstrap 4's mobile-first flexbox grid system, now used by default
v4-alpha.getbootstrap.com
v4-alpha.getbootstrap.com
Not that there's a need to rush it; I really appreciate Bootstrap's "it's ready when it's ready" stance. Personally I also like that the BS devs had the balls to rewrite their grid system based on flexbox this late in the development cycle, rather than hanging on to something you're not convinced of and focussing on getting a release out the door.
To those criticizing Bootstrap, here are my reasons why I like Bootstrap:
BS was incredibly useful for getting me back into contemporary/responsive CSS after a longer period of absence from webdev. I ended up overwriting many things, but that's why it's called "Bootstrap" after all I guess.
Bootstrap is also very useful as a baseline CSS in larger projects with multiple teams developing a uniform-looking web site.
And you can get a ton of themes for relatively little money (though not everything on offer is great of course). You can also contract an agency or freelance designer to make a BS theme for you, with a straightforward workflow.
Also, you can get relative good and targetted StackOverflow etc. advice on your daily CSS problems.
And, when BS4 finally is released, you don't have to redo your complete site to take advantage of it (or at least I hope so).
I use bs3 and love it, however my plan is not to upgrade to bs4, it's to slowly pull out and replace anything that could be modernised over time. The risk of breaking something is too great.
That's slightly hyperbolic. I don't think they intend for the primary use case to be for people to upgrade in place, like updating a nightly Firefox, but rather to start new projects with the new version. But previous big upgrades have been largely a bunch of search and replaces. There's various tools that people have written to automate this. Again, I wouldn't blindly run it and expect everything to work, but it's far, far less than a complete rewrite.
We all do tend to do a redesign of our sites and apps eventually and that the correct time to make the transition.
Porting BS3 → BS4 can be easy or hard. It took me about a day to port my first site but things have been smooth sailing since then. BS3 is still officially supported (the devs thankfully aren't repeating their unceremonious dumping of BS2 this time around) so unless there is some pressing reason for you to update you don't have to.
Are you sure?
https://github.com/twbs/bootstrap/issues/20631
> Stop all work on v3—today. The open issues, split dev setup, and more holds us back from focusing entirely on v4. I'll close all remaining v3 issues and milestones. Any new changes to v3 will be sporadic and highly irregular.
BS3 is so widely used at this point that point that I think it is fair to call it 'done'. Browsers aren't going to stop supporting the features it uses any time soon.
> 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. v3 docs will also continue to be hosted after v4’s final release.
I do love seeing <div class="table"> around the place. Sigh.
This comment made me laugh. From an outsider perspective it looks like div is the new table. The latest fashion in style
They didn't use it for their grid implementation though, and since they have found and documented a lot of very obscure browser compatibility bugs as part of their work, I'd guess they had a good reason for choosing what they did.
Reminds me of this comic strip from 12 years ago: http://okcancel.com/comic/98.html
As I am more of a back end developer, I've written several interfaces using display:table and then the front end developers cleaned it up into "proper" css. This actually worked out as a good separation of duties and sped up development overall. The programmer in me then asks why this human step is needed if the output is equivalent..
I'm thinking that css is largely about encoding semantic data into layouts, because as far as I can tell it takes tremendously longer to do anything in css today than it did with tables in the 90s. And doing things in tables took tremendously longer than using a GUI like Adobe PageMaker in the 80s. We keep going backwards in productivity but there must be some value in the minimalism of how data is described and organized today.
What is wrong to do is use actual HTML <table>/<tr>/<td> tags for layout, because those impart semantic meaning about the structure of the content and should only be used for tabular data.
I'm not really a web designer so this isn't really my debate. I'm just pointing out that "HN does it" isn't really a strong argument. Something might be the best available option for some particular task but still not optimal for a whole host of reasons. The point remains <table> tags do carry semantic information so it's useful when possible to restrict them to situations where that semantic information is correct.
There is no such thing as Bootstrap div hell, that is utter nonsense.
If you used Bootstrap 3 seriously you'd also know there were LESS/Sass mixins for grids. No need to use divs with classes if you have that arbitrary dislike for genuinely useful presentational classes.
caniuse.com suggests only IE8+ supported it.
E.g. using SuitCSS Grid:
<div class="Grid">
<div class="Grid-cell u-size1of3 u-sm-sizeFull">At the moment i'm plain (non theme'd) SemanticUI. The UX/etc makes a lot of sense, the only downside is i'm using the plain CSS so i don't get a theme - but that's not a big deal. I can always add a separate build step for the css.
Customers with designers often end up with a custom Bootstrap theme. I can't remember the last time a designer sent me a totally custom layout not based on some framework, usually Bootstrap.
My only concern is going with V3 or V4. I'd like to use V4, but that puts me at a lack of themes/etc, which is basically the same spot i'm at with semanticUI.. feels like a no gain then.
I'm not totally sure I'd ever use it over Bootstrap, though perhaps for a small app since it's so light. That said, my first impression of Pure [2] was similar, which is ~4 kb. It's fallen out of fashion a bit, but I still find it useful for a lightweight front end.
[1]: https://news.ycombinator.com/item?id=8315616
[2]: http://purecss.io
Is this a joke?
Of course it's a joke. Use semantic CSS class names. styleElement.appendChild(document.createTextNode(styleContent.replace(/;/g, ' !important;')));This is from their blog when they announced Bootstrap 4
"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. v3 docs will also continue to be hosted after v4’s final release."
Essentially they've stopped working on v3. I don't think they used the words "no longer supported", but that's kind of what has happened.
> If you require IE8-9 support, use Bootstrap 3. It’s the most stable version of our code and is still supported by our team for critical bugfixes and documentation changes. However, no new features will be added to it.
[0] https://v4-alpha.getbootstrap.com/getting-started/browsers-d...
I feel this much better conveys the meaningful change that HN is discussing here and that's otherwise not mentioned clearly on the current link to the docs (vs the blog post linked by another user below).
<div class="row justify-content-md-center">
There's also a justification for the type of classnames you're railing against here:
http://nicolasgallagher.com/about-html-semantics-front-end-a...
I believe Bootstrap adopts many of these ideas. So it's not just a mistake, but an intentional decision as part of a different paradigm. Feel free to suggest that it's not a useful way to build websites, but don't be fooled into thinking they've accidentally broken a rule they intended to follow.
I've read the article, but I still don't see why, to change the login box, I need to modify two places (HTML and SCSS) rather than one (SCSS).
You are working in a bubble, the bubble of expert coders. Most dev are not expert coders, they are expert plumbers.
https://design.atlassian.com/product/components/buttons/
As to your question, if you have an actual design system in place then you can change all primary buttons on your site by only changing the SCSS, and if you want to add a new primary button, or a small button, or a small primary button etc. you can do so by only changing the HTML. And when you do need to do both, it splits some of the responsibility in ways that make the code easier to manage and develop.
If it really comes down to just wanting to do stuff in one place, then there's a bigger picture that's being missed. Think about distribution of responsibility and letting junior staff add buttons, while more senior (or just those with different kinds of expertise) staff control the styleguide. If they each re-invent the wheel then there's not going to be consistency or re-use.
Good point.
> There's even a reasonably sized trend of big apps who think they're too good for Bootstrap but basically implement an internal clone of it.
Everyone should have a set of rules implemented in SCSS. They just don't need to implement them in HTML.
> As to your question, if you have an actual design system in place then you can change all primary buttons on your site by only changing the SCSS, and if you want to add a new primary button, or a small button, or a small primary button etc. you can do so by only changing the HTML.
Buttons are an easier case because they already exist. Anything else - avatar images, login dialogs, etc, are an argument for not using Bootstrap (or BEM, or other HTML based systems)
- Making a design system in SCSS only: to change the login box, change the SCSS for .login-box
- Using bootstrap: to change the login box, add and remove whatever HTML visual classes bootstrap needs for your new login box look (is it '--grid-l4-left-blah-shiny') then modify the SCSS
(Edited this a lot while I wrote it, kind of thinking aloud and have trouble reading in monospace)
On the other hand, your login box is a box, and presumably you have other boxes, a sign-up box perhaps. You may well want them to have some similarity, even on an infrastructure level that is invisible to the user, like consistently only having margins on the top or the bottom. That kind of thing can be provided by the design system out of the box, letting the person who's hooking up the login on the backend have something functional and ready to go with no delay, to later to be handed off to someone who makes it bounce around on mousover and look snazzy. And if other priorities get in the way, then you'd still have a basic foundation level box that wouldn't embarrass you until you get around to redecorating.
Agreed, but that's an edge case caused by mismanagement. People who need to style things should be able to edit styles.
> You may well want them to have some similarity, even on an infrastructure level that is invisible to the user, like consistently only having margins on the top or the bottom. That kind of thing can be provided by the design system out of the box
Sure, but you can make consistent margins on your boxes with a SCSS mixin. It's the same difficulty to set up than moving your site to bootstrap, and much less difficult to maintain.
.my-login-box {
@extend .col-md-4;
background-color: fuchsia;
}
And don't use fuchsia. ;)
I don't include bootstrap.min.css though. I wrote a custom LESS (I'm still using v3) stylesheet to replace bootstrap.less, which pulls in just the bits I want. I also use this to customise and theme the whole thing.
I also don't use Bootstrap's classes in my HTML. These are replaced in my custom version by semantic and descriptive things that work very well on a site-by-site basis for keeping markup low.
And this can be kept just-about-separate-enough from Bootstrap to make upgrading it not too traumatic, as long as you stay within the major version and don't edit the original files (just override or replace them).
Wrapping up just the bits of the Bootstrap JS is the harder challenge IMO but this can also be done. I have a plaintext file that lists the files (in order) that I just cat together, minimise and compress.
Here's my personal blog as an example: https://thepcspy.com/
When you get more features like Bootstrap has, you get "stuff" and weight.
Would be really cool if Element Queries were a normal thing.
And for that, the Bootstrap grid has become slightly worse ever since v2 as the media-query stuff gets more and more exposed on the public API.
I think bootstrap stagnated too much and they just trying to play catch-up now.
The most recent version is alpha 6, and it sounds like they are shooting for their first beta version next: http://blog.getbootstrap.com/2017/01/06/bootstrap-4-alpha-6/
Because since being posted, it's averaged one upvote every 26 seconds and one new comment every 2 minutes, and that's more or less how the ranking algorithm works?
Relax, it's HN... it'll be gone in a couple of hours.
Do you know where we can learn more about this?
@import "path/to/bootstrap/scss/bootstrap-grid"
https://github.com/twbs/bootstrap/blob/v4-dev/scss/bootstrap...
I'm just now ramping up on React and have noticed two schools of thought:
1) Flexbox abstractions are great and make things easier
2) Flexbox abstractions are bad because they just hide the real flexbox and prevent you from learning an important widespread standard.
There are React flexbox components out there with both of these viewpoints. Personally I'd like to find out whatever is most canonical for React, so my code can be widely accepted.
http://picnicss.com/documentation#grids
The syntax is slightly different from Bootstrap though
*sarcasm intended, with some unfortunate seriousness
Btw they dropped IE9 also
>It comes at the cost of dropping IE9 support, but brings significant improvements to component layout, alignment, and sizing.
...less technologically enthusiastic customers.
These same large enterprises that clung to XP to wring every last drop out of those rickety HP desktops with 1.5 GB of RAM are now zealous implementers of Enterprise Managed IE. Typically there will be some old inventory system, or accounting adapter, or ERP plugin, or procurement system, that the company considers mission critical despite its decrepitude. That system itself is probably built with Microsoft's old development tools, and uses IE-flavored HTML, JScript, and ActiveX. Nobody knows how the system works anymore, its creators all died 75 years ago, and all documentation was lost in the great molasses flood.
Rather than spend the time and money to rewrite these magic old black boxes, IT managers configure the entire company so that IE11 actually acts like IE8 (or, hell, sometimes even IE7), in a browser "compatibility mode", enabling their old legacy apps to run, mostly. These downgraded modes are mostly, but not exactly, like the versions they mimic. In effect, they are new, separate, subtly different browser compatibility targets for developers. IE8 itself at least has the advantage of a decade of the collective wisdom of millions applied to understanding its limitations. Ersatz IE via compatibility mode can be worse than the real thing, rife with ungoogleable issues that force developers to engage in primary research like it's the bad old days again.
The kicker is that their end users all think they're "finally on IE11", and IT support often doesn't understand the subtleties of the EMIE situation. You'll hear "we're on IE11 now, so why does your app still look terrible and have strange JavaScript errors?". Allowing an exception so a specific application can run in native IE11 mode — if even possible — is often rejected as a "security risk". And why might it not even be possible? Some of these enterprises will run "vendor apps" inside a — yes — frame served by their terrible intranet system. The outer frameset document itself will be locked into downgraded compatibility mode, forcing the sites it contains to inherit that mode, and even do inexplicable and nearly undocumented things like silently replace the doctype of the framed application's pages.
Or so I've heard.
Lots of complex examples: https://radogado.github.io/natuive/#showcase
Regards.
https://blog.getbootstrap.com/2017/01/06/bootstrap-4-alpha-6...
Biggest one benefit is the ability to align vertically and center vertically
(Serious question)
You are asking if you can use a different preprocessor, for which the answer is 'no'.
The alternative is to maintain a Bootstrap fork that uses Stylus instead of Sass. See https://github.com/maxmx/bootstrap-stylus
Source: https://github.com/twbs/bootstrap/blob/v4-dev/Gruntfile.js#L...
If it was half the size, or more modular, I'd be sold even without new features :)
Does this integrate well with tools like Webpack?
For example, if I want to use a container class, can I do something like:
require('bootstrap/src/container.sass')
I guess I would probably need to require some core sass files somewhere at the top of my application, but besides that, is it possible?
What's the tricky part?
I would probably simply get the bootstrap npm package, sass-loader and try to check which sass files of bootstrap I need to require.
Momentum is a pretty powerful thing.
And at the end of the day, ALL of these frameworks are pretty much limited crutches for appdevs who aren't that great with CSS. They have more in common than they have separating them.
I tend to rank these things on a balance... of having the functionality that I'm likely to use, versus simplicity and learning curve of the functionality that's there.
So I like UIkit for side projects because it has a lot of built-in components that Bootstrap makes me find external plugins for (e.g. datepicker), and doesn't have a lot of Bootstrap crap that I never use (e.g. jumbotron, wells). It looks great, doesn't have any kind of complex "build system", and takes a few hours to learn. If I wrote a webapp that turns into the next big thing, then I'd have a real web designer redo the static stuff anyway.
How about removing SUI's jQuery dependency? [1] :)
Replacing a 100KB jQuery dependency with a 500KB React dependency I'd hardly call a solution. What happens when the next big thing hits JS land? As it stands the SUI author refuses to refactor out the jQuery dependency due to the amount of work involved.
To be fair, if everybody took a little bit of time learning basic CSS nobody would need bootstrap either, especially when rendering differences between modern browsers hardly exist AND the fact that bootstrap doesn't support older browsers anymore.
I guess most websites are "very simple projects" for your standards. Not everyone codes full fledged JS applications with whatever you do. I am certainly not a beginner and I like BS and I think it still has a very bright future ahead. BS 4.0 is the prefect framework for the average modern website. I am sure Foundation and other Frameworks are great as well, I actually never really compared. BSs devteam is highly active and the amount of exposure it gets and the fact that I know how it works makes me stick with it.
Most people use Bootstrap and Foundation completely wrong. They're meant as RAD (Rapid Application Development) frameworks, not production-level frameworks.
For example (using Foundation because I'm more familiar with it), you should never have a `div` with the classes `small-12 medium-6 columns`. That's what you do during prototyping. For production, your `div` will have a class like `main_cta` and in your SASS you are calling Foundation's grid mixin.
Production sites shouldn't include anything not being used, which is why libraries like Foundation have discrete components. You only include the ones you need (both CSS and JS), with the assumption that you are doing your own minifying and combining or whatever.