Hacker News new | comments | show | ask | jobs | submit login
Bootstrap 4's mobile-first flexbox grid system, now used by default (getbootstrap.com)
263 points by berry_sortoro on Jan 11, 2017 | hide | past | web | favorite | 146 comments

BS 4 has only very recently gone all-in on flexbox so what's the expectation towards a 4.0 GA release date? A major benefit of Bootstrap is that it's really well tested on all kinds of devices (something that's difficult to achieve with your own CSS). But now that it's using flexbox for its grid doesn't that mean that testing has to be restarted all over?

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

Bootstrap is ridiculously good. It may take criticism here, because this site is naturally going to bias toward people doing things a bit more advanced/complex than what BS was intended to facilitate. But for someone like me who needed to get a professional-looking, mostly static website up and running in a weekend for a side gig and hadn't done any (and I mean any) web development since 2002, Bootstrap was just the framework.

I have to agree with you, Bootstrap has been a boon for my productivity, especially prototyping. When you're looking to get a MVP off the ground ASAP, I can't think of a more useful CSS framework than Bootstrap.

BS3 still exists for people who absolutely need old browser (cough IE) support. Everyone else has FF, Chrome, or Safari which are all very good at nagging people to stay up to date, even on toasters.

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.

> BS3 is still officially supported

Are you sure?


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

How big a problem is that in practice?

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.

I don't think it's a big problem, but I also wouldn't call BS3 "supported". It still exists, that's about it.


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

Ah, that's good to hear!

Upgrading from bs3 to bs4 is as close to a complete rewrite of your front end as you can get. Just the fact they switched from less to sass means that if you use less as well to extend and build upon the bs components you need to completely rewrite everything.

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.

"Upgrading from bs3 to bs4 is as close to a complete rewrite of your front end as you can get."

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.

Completely agree, wasn't intending to be hyperbolic. My intention was to indicate to the GP that upgrading an existing project from bs3 to 4 would be hard and mostly unnessasery. And clearly not the main intention of the bs team.

We all do tend to do a redesign of our sites and apps eventually and that the correct time to make the transition.

There has been a sass branch of BS3 for a long time and BS4 has always been sass-only so it's not like they have just suddenly dropped this on everyone.

Now I can use CSS like I was using tables 15 years ago.

This strikes a chord with me, as I never really saw what was so "bad" about tables.

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.

Your front end devs in this case were suffering from a bit of cargo culting (not truly understanding the difference between HTML and CSS). There is absolutely nothing wrong with using the display:table css properties (as long as its layout quirks around the way it decides to space things don't mess things up visually).

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 may be wrong, as it's fuzzy with time, but I think when this all started, you couldn't use display: table in IE, and since IE had like 90% share at that time, it simply wasn't an option.

caniuse.com suggests only IE8+ supported it.

Open an inspector on your HN comment.

Just because HN happens to use the simplest thing that could possibly work doesn't mean that the objections to tables being used for layout aren't valid.

What about the HTML emails you receive in your inbox everyday ? I don't see much difference between Bootstrap div hell and tables in terms of semantics.

I hate them mostly? I've sent HTML emails before and they're a pain in the ass because they don't fully implement CSS. I've heard arguments that grid layouts are a step backwards because they put layout information back into HTML.

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.

I was never convinced by this this argument (It's just a DOM node after all) and found the `crusade` mentality back in the early 2000s a bit immature. I respect your point of view but we don't agree

You haven't written HTML emails (cross-client) if you think Bootstrap' s grid and the kind of HTML you have to write for emails are comparable.

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.

eg: the only valid use of tables is my valid use of tables

The only problem I ever had with tables being used for things other than tabular data was strictly from an accessibility POV. I had 2 blind roommates in college and helped set up their screen readers. It was nearly impossible for the readers to follow the page so when it was outputting audio it just sounded ridiculous. So much so that my roommates just gave up on their computers and and would take their assignments into some office to have student aids type them up for them and to help them do online research when I wasnt available. Switching sites to tableless css design helped immensely. I dont know if things have changed but that would be my reason against table design, pure accessibility.

Yup, it would appear that "tables are back" in a sense. Layout should be intuitive and easy. the table metaphor clearly works... maybe we should just accept it !

Reminds me of this comic strip from 12 years ago: http://okcancel.com/comic/98.html

I don't think "tables are back" here, per se. Tables, like any HTML element, are to be used semantically, like for displaying tabular data. They bring a lot of extra, unneeded markup and they're not a good layout mechanism for different size screens. I do think Flex-box takes the good elements of tables and turns them into something great :D

Now I can use flex-box like I was using flex-box 3 years ago including on IE8. It's almost like living now but if now was then.

And if "then" your flex-box usage actually worked for people not on Internet Explorer.

To be fair you've been able to do that with display: table-cell etc.

I do love seeing <div class="table"> around the place. Sigh.

As someone who does minimal front-end work I rely on bootstrap when I need quick UIs and try to read HN to understand the trends.

This comment made me laugh. From an outsider perspective it looks like div is the new table. The latest fashion in style

Just as an fyi, I count 17 uses of display: table-cell and it's siblings in the Bootstrap 3 less code (possibly more once compiled to CSS).

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.

Better that way than the standard practice of littering your code with semantically meaningless divs that are there just as hooks for CSS rules.

Not exactly, you couldn't get colspans or rowspans with that.

Yeah, they really dropped the ball on that. Being able to specify vertical and horizontal layouts this way would have solved a lot of problems that now require flex and soon CSS grids.

I hadn't thought of that.

I don't think that's quite true unless you had your tables dynamically laying themselves out by viewport size too.

E.g. using SuitCSS Grid:

    <div class="Grid">
        <div class="Grid-cell u-size1of3 u-sm-sizeFull">

Yeah, thats a good thing :) tables are intuitive - Except now you can do a lot more stuff too!

I use bootstrap mixins + Sass for all my layout. If you're coupling it with your markup that's your fault.

For someone who doesn't really like CSS and has little design "sense", what would be your most recommended CSS Framework? I'd like lots of built in features, and a grid/layout system that makes the most obvious sense in usage.. ie, if it invents custom terminology for what is a row or column, or perhaps has lots of "always use this class with a new row" style rules, that is stuff the developer needs to learn. Lower barrier to entry means it's easier to pick up and "get shit done" for side projects/etc. Less looking at documentation.

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.

Bootstrap served me well. I'm a developer. I'm OK with CSS but I have little design "sense": I can tell if something is ugly or beautiful but I can't make something beautiful. Ugly yes. That's where Bootstrap came into help: it gave me reasonable defaults that customers without designers are OK with.

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.

I'm really liking SemanticUI, but i'm thinking of switching to BootstrapV4 in the near future. The main reason being that Bootstrap has such a long history of tons of developers using it. Lots of devs mean lots of themes, documentation, etcetc.

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've really liked Picnic CSS [1]. The main selling point for me is that it styles most elements by default without you having to add redundant classes everywhere. Instead of Bootstrap's <button class="btn btn-default btn-hover"> you just do <button> and Picnic makes it look nice. It also leaves your HTML uncluttered if you do need to move up to something like Bootstrap later on.

[1] http://picnicss.com/

Thanks, hadn't seen this one before. Looks like it was quite popular on HN when it was introduced [1].

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

Bootstrap V4 introduced spacing utility classes (like a class m-t-1 to get margin-top: 1rem!important), which inspired others to create this great universal.css project: https://github.com/marmelab/universal.css

Don't play with our feelings that way...

    Is this a joke?

    Of course it's a joke. Use semantic CSS class names.

I was terrified for most of the way through that page that it was serious.

The first time I saw this project I went on an emotional roller coaster from shock & horror, through to laughing until tears fell out of my eyes :)

Laughed at this one:

  styleElement.appendChild(document.createTextNode(styleContent.replace(/;/g, ' !important;')));

Which was announced over a year ago and the project is still in alpha... Not to mention v3 is no longer officially supported.

Where do you see v3 is no longer officially supported?

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.

Bootstrap 3 will still get bugfixes. Under the Internet Explorer section on [0]:

> 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'm not sure "no more forward feature development" translates to "no support".

It seems that V3 is mature enough to not need daily PRs to fix bugs.

Suggestion: Change headline from "Bootstrap 4.0 includes a powerful mobile-first flexbox grid system" to "Bootstrap v4a6 uses flexbox by default".

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

Ok, we've added "now used by default" to the title above.

Thank you, dang!

If you're using flex - particularly if you're using flex by default, what does bootstrap get you, asides from putting a bunch of visual styling:

  <div class="row justify-content-md-center">
into your HTML?

An ecosystem of attractive looking templates, devs who know how to use it, various tools that integrate or output it, examples and tutorials to learn from, code samples to re-use etc.?

There's also a justification for the type of classnames you're railing against here:


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'd argue more developers know how to use flex than bootstrap right now. And many developers would spend additional time researching how to do things the bootstrap way. If you don't have developers and want templates, use Squarespace, bootstrap is a poor fit.

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

There's a wide range between using Squarespace, and building an entirely custom website from scratch. It's a big 'ole niche that Bootstrap and other similar systems have been filling for a while. 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.


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.

> There's a wide range between using Squarespace, and building an entirely custom website from scratch. It's a big 'ole niche that Bootstrap and other similar systems have been filling for a while

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)

Regarding --grid-l4-left-blah-shiny, bear in mind that some people, say users of a corporate CMS maybe, simply do not have access to the CSS for the page they are designing. For those people, very granular visual styles have an important use case. This is however something that can be abused, and I've seen people who don't "get it" create problems for their future selves by not understanding when and where to use those kind of classes.

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.

> some people, say users of a corporate CMS maybe, simply do not have access to the CSS for the page they are designing.

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.

Or use Bootstrap 3's SASS port, and

    .my-login-box {
      @extend .col-md-4;
      background-color: fuchsia;
or whatever, and don't touch the markup to add any BS-specific classes.

And don't use fuchsia. ;)

Works for me - I'd have no objections if Bootstrap actually did that in their documentation.

Yep. I mean by default, rather than encouraging HTML.

Most dev I meet don't even know what flex is. In my last year of dev, I have seen only one code base that was using it. Everybody else was still using float, margin, etc.

You are working in a bubble, the bubble of expert coders. Most dev are not expert coders, they are expert plumbers.

I disagree with with this. Im like the only one on my team who knows flex right now. Most debs know the old ways of doing things flex box does better.

I agree with you (and am in the same boat). Bootstrap is ubiquitous, and using it as a scaffold means you don't need to use flex.

I've always built interfaces by hand, but for a recent project that is going to be heavy on the use of selecting options/button/etc, I was considering Bootstrap for the first time. However, looking at the source, and the sheer amount of "stuff" in there, I'm just not too keen on it. Is there a much lighter alternative, that satisfies quick standardized UI creation? SemanticUI i saw mentioned in here.

I agree but still use Bootstrap. There's too much well-thought out stuff to ignore or attempt to reinvent.

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/

You can select which options you are going to use a download a lighter version of bootstrap. As a bonus, you can save your configuration to make downloading updates all that more simple in the future.


Use the Sass source and comment out what you don't need

purecss.io, skeleton.css, spectre.css are three pretty nice ones.

When you get more features like Bootstrap has, you get "stuff" and weight.

tachyons could be something you might be interested in?

[0] http://tachyons.io

Flexbox is great but auto adjusting/sizing columns are a real PITA if responsiveness (@meda query) is tied to the viewport and not the parent container element.

Would be really cool if Element Queries were a normal thing.


Perhaps I'm a "bad web citizen" for not wanting to go mobile first with responsive design, but most of the work I've done over the past 5 years for clients has been "desktop first", fixed-width web applications (with native mobile apps or separated mobile views if applicable). It's hard to do responsive right and it costs real time and money for what is, sometimes, only a theoretical use-case.

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.

Check your analytics. Many sites are now seeing more traffic from mobile devices than desktop devices - the switchover for your sites may have happened in the last six months. Desktop first is making less and less sense.

I find that foundation's flex grid system is much more simple and powerful to use...

I think bootstrap stagnated too much and they just trying to play catch-up now.

Could you elaborate on that? I've used Foundation before, but never got to use Bootstrap, but the latter seems to be more popular so I considered using it for a future project.

Why is this at the top of HN right now? It's still in alpha. It's a good alpha and I've been using it on some projects, but I think some people might be mislead that this is the final release with the "4.0" in the title.

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/

> Why is this at the top of HN right now?

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.

Presumably because one of the big announcements contained in alpha 6 was that this flexbox grid was going to become the default and only implementation. In alpha 4 they had it available as an opt-in option. This change means they don't have IE9 support anymore.

The blog post you linked should be the story URL. I don't see any mention on the current story URL of a switch to flexbox being the default.

You answered your own question with your second paragraph. Alpha 6 is a big deal because it is flexbox only afaik

I am using bourbon.io for the flexbox grid system. My final css compressed is less than 4k for the whole site.

They will have a SASS API, you can use the Bootstrap mixins and have a similarly small footprint.

You can just include the grid system alone [1] right now if you want to right now:

  @import "path/to/bootstrap/scss/bootstrap-grid"
[1] https://github.com/twbs/bootstrap/blob/v4-dev/scss/bootstrap...


A SASS API just for the grid system or for all elements?

Do you know where we can learn more about this?

Is it a good choice to use this for layout in a React web app?

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.

I will shortly be starting a new project and was hoping to use Bootstrap 4. The problem is that a big component of the Bootstrap value proposition is the themes and controls - both commercial and open source. And the frameworks are built on top of these themes and controls. It will likely be many months before this long dependency chain has migrated to V4.

If you want to try a flexbox grid system today you can use Picnic CSS, we've been including it for a couple of years now:


The syntax is slightly different from Bootstrap though

Obviously the most important question though. Will it work in IE8?

*sarcasm intended, with some unfortunate seriousness

Let it die.

Btw they dropped IE9 also

>It comes at the cost of dropping IE9 support, but brings significant improvements to component layout, alignment, and sizing.

If your work has to support "enterprise" clients, you'll find no shortage of companies still living in the smoldering compatibility crater where tens of thousands of old desktops met their demise. The coal-fired machines themselves have generally been retired by the forcing function of Microsoft's EOL policy for XP. So one might think this means the end of the scourge of IE8 and friends. Sadly, one would be wrong.

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.

Sadly some companies still have to support IE8 for the sake of some of their... umm...

...less technologically enthusiastic customers.

I wish More had "Courage" to say 'we don't support IE8'

Funny, because my grid has those features with IE8 support and also equal height with vertical alignment, embedded vertical grid etc: https://radogado.github.io/natuive/#grid

Lots of complex examples: https://radogado.github.io/natuive/#showcase


Here is the alpha 6 release blog post from a few days ago


What exactly is the benefit to the grid system in Bootstrap 3? Looks the same to me.

Simplified answer:

Biggest one benefit is the ability to align vertically and center vertically

You can use class="col" for automatic columns. E.g. col col col-6 would be like col-xs-3 col-xs-3 col-xs-6 in BS3.


We've banned this account for posting only uncivil or unsubstantive comments.

One might write their own grid system while waiting for bootstrap 4, a year now...

To be fair: Versions up to 4 also had a grid system.

flexbox based grid I mean :P

Ok looks good but what if I don't like to use Sass but want use Stylus?

(Serious question)

You don't have to use SCSS at all. Just fetch the compiled CSS from a CDN and use your favorite framework to generate another CSS that overrides the defaults.

The alternative is to maintain a Bootstrap fork that uses Stylus instead of Sass. See https://github.com/maxmx/bootstrap-stylus

You are toasted. It's like asking what if I like wordpress but I don't like PHP? Can I use wordpress with Ruby?

I thought Bootstrap is about frontend being backend-agnostic or what do I miss?

I think you have some things mixed up, Bootstrap is a front-end layout framework built with a CSS preprocessor, in this case SASS. It's got nothing to do with backend.

You are asking if you can use a different preprocessor, for which the answer is 'no'.

I think the answer is "yes" for those willing to use a fork. If your favorite preprocessor is popular I bet someone already made one.

It was just an example that it won't work, sorry for the confusion.

Personal anecdote: I went from SASS to Stylus and now back to SASS again. Reason being, Stylus has a lot of magic going on, and the loosely constrained grammar breaks stuff.

Does 4.0 still depend on jquery? I've wanted to use bootstrap for a while, but every time I mix jquery with react, I end up with a buggy shit sandwich.

Yes, it does. In the Grunt config file they use to build the package, they specify jQuery version >= 1.9.1 and less than 4.0.0.

Source: https://github.com/twbs/bootstrap/blob/v4-dev/Gruntfile.js#L...

It may be just me, but none of my browsers actually seem to render the example grids correctly... (Chrome does better than Firefox)

What problems are you facing? It renders correctly in my latest Chrome.

The pages doesn't tell how it differs from other flexboxed based css frameworks?

It's the manual, not marketing copy.

what's the size of Bootstrap4? is it smaller than 3? is it more modular?

If it was half the size, or more modular, I'd be sold even without new features :)

Download the bootstrap source, open /scss/bootstrap.scss, comment out the features you don't want to use, and rebuild it. Completely customisable and much smaller.

Good point.

Does this integrate well with tools like Webpack?

For example, if I want to use a container class, can I do something like:

and be done with it?

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?

Yes, it does. I'm currently using. It's a little tricky as you have to use postcss-loader as well (along with sass-loader).

Very cool :D

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.

I did exactly what you suggested, and the tricky part was figuring out postcss was needed as well.

for what exactly?

For adding prefixes to older browsers.

Couldn't you do that before with the less version of bootstrap?

Bootstrap is useless except for simple static websites. I am not here to start a flame war but I think Bootstrap has no future unless for beginners and very simple projects. For jQuery based frameworks, I recommend Semantic UI.

I'm doing a root-level reply so it doesn't start out too buried :)

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.

If you're goal is a UI with widgets for a dashboard then yes, using Bootstrap makes no sense.

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.

The thing is... I would say that UIkit is better, and there's some other guy at the bottom of this thread getting downvoted into oblivion for saying the same thing about Material Design.

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.

With Semantic UI, you can control every single parameter, remove useless components, and you can add/override rules without messing with/modifying its files.

You know what else can do that? Writing your own CSS in the first place, no more complex than it needs to be. :)

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.

Of course you're right, I was talking more about serious projects run by a very small number of people (1-3), and under very limited timespan and budget. Companies won't need css frameworks anyway in most cases.

> remove useless components

How about removing SUI's jQuery dependency? [1] :)

[1] https://github.com/Semantic-Org/Semantic-UI/issues/1175

I'd love to use SUI with effects written in plain javascript sans gigantic dependencies.

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.

UIkit looks really nice, I'll have to give it a try.

Pretty bold claim to say the most popular framework has no future.

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.

I meant by "very simple projects" static websites and dynamic websites that have very limited dynamism, pages. But something like Semantic UI, you can rely on it to build complex dynamic structures with sensible and good looking defaults, If you want more, it's very easy to customize without conflicting Semantic files with your customizations.

Material design is better. This project is not needed anymore.

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact