For everyone saying "Foundation" when people ask what else... let me explain why Bootstrap is used so much more frequently than all other options combined.
Foundation's link takes me to a page where I have a bunch of options, and a bit "build a custom generated version".
Bootstrap's takes me to a screen with 3 options, but also - and this is key - CDN links. Right there. I can paste a few lines in my HTML template and start working.
I don't need to download/generate code.
I don't need to install node/npm/etc.
I don't need to install and learn sass stuff.
I don't need to make a lot of decisions or do a lot of extra unrelated stuff to get started.
Bootstrap is the PHP of the css/grid/framework world (for better and for worse).
I truly hope they keep the CDN hosted stuff for Bootstrap 4.
EDIT: didn't mean to pick on foundation specifically - this "take control of every aspect of all your layout/grid/css" that most other frameworks require works to their disadvantage when it comes to popularity and uptake.
> Foundation's link takes me to a page where I have a bunch of options, and a bit "build a custom generated version".
Their navigation is fuck all. Bootstraps is easy.
Bootstrap:
- Here's how you get started
- Here's the components and how to use them
- If you want a custom build, go here
Foundation:
- Getting started? "Sites Docs" which is in a menu under their "Docs"
menu
- Components? Included in the same menu under "Sites Docs" on the same page as getting started. The components are in the right hand menu.
- Custom build? Located in the "Resources" menu under "Develop"
Not at all intuitive. I still remember being frustrated at how I had to fumble around their site trying to find stuff.
> Bootstrap's takes me to a screen with 3 options, but also - and this is key - CDN links. Right there. I can paste a few lines in my HTML template and start working.
This has been available for Foundation for a few years already:
This is a biggie. I've been doing a lot more static site development and the JS frameworks now to create a decent website can been a huge PIA. There are a ton of them out there now - they're having the same issue JS frameworks are having, people are being fatigued by the amount of choices out there.
Compare that to MVC4 or 5 where I can get a Bootstrap template setup with views and controllers and create multiple templates in a matter of minutes, it's insane.
I second this. I never got to dive into Foundation just because its docs are not accessible and I can't just put a link into my html and forget about the setup. With Bootstrap I just navigate to the "CSS" page and pick up some example code and be done with it. Even if I think that Foundation might look better I just don't feel that it worths the extra time I need to put in to make it work.
Bootstrap has much better form layout/controls/components that makes it superior to foundation for app development. At least it did when I was looking for something to recommend to the team 4-5 years ago.
Yes. But oddly enough Bootstrap seems to have held up well none the less. Perhaps not ideal but if you did an average site in BS3 today you wouldn't be a complete fool.
Again, not ideal. But doable and certainly not fatal.
It was an early player, and there's inertia, but beyond that... why did it have so many plugins and themes for it early? because it was easy to get started.
and... forgot to mention - the entire thing looks decent out of the box. not great, but it's decent - every element is styled consistently, and looks far better than most people (especially devs) trying to roll their own UI/theme/colors.
For experimenting and throwing an example together. So you have something in mind, maybe a wireframe or something one of your designers has made, or a customers existing site.
You go to bootstrap, hook into the CDN and start throwing some tags down. Boom. Bootstrap have you, you've invested time, effort and emotion into it. 90% of coders move on to the next profit making exercise. I know I did.... Sure, there are better CSS frameworks out there. But bootstrap is better than the crufty stuff we used to use, so it's win win win for me.
They both came out within a month of each other or so (bootstrap had a slight edge, I think). Having the Twitter name behind it gave it some PR, of course, but as I mentioned in another comment, having decent looking and consistent style out of the box from day one was yet another factor cementing their popularity.
Zurb answers "Why Doesn't Foundation Have as Much Styling as Bootstrap?" with "We purposely left our styles sparse. We didn't want to end up in a world where all the sites looked like Foundation." So... on purpose, I don't have a consistent and full 'out of the box' experience. I am required to do more work than I want to make it look decent (that's how I'm reading it, and my limited experience with zurb at that time).
True, it's a different philosophy. Having the added styling in the box like Bootstrap works for people who are good with the visual look of it out of the box. With Foundation, it's supposed to look like a wireframe to allow for your visual identity be easily laid on top of, a truly custom design.
Example:
Bootstrap Nav Bar Link
`.navbar-default .navbar-nav>.active>a`
Foundation TopBar Link
`.menu > li.active > a`
Foundation usually uses less selectors to override, lower specificity.
And I don't use Sinatra because I always end up waste time to add to it most of what Rails gives me out of the box.
In CSS space, if the customer has a designer, I use whatever the designer decides to do. It's his task to fill the gap from Foundation to Bootstrap or (more often) customize Bootstrap and make it look nice. If the designer is me (laughing) then I use plain Bootatrap and that's the end of it.
I'm still using Bootstrap on my own small website for nearly this reason, and I still haven't really found a reason to install the framework to customize my build of it. My traffic is simply too small, and my site unimportant enough. The default options are just fine, and with minial effort look great on all the mobile devices I have at my desk to test with.
I don't use the CDN links though; something just doesn't sit right with me with that option. I'm glad it's there, and I'm sure it helps newer programmers or those that want to just toss it in a template to see how it works, but I'm not comfortable relying on a third-party server to house such a critical part of my site. I always self host those files in production.
Or maybe it's because Foundation hasn't been around as long, hasn't become a household name, and isn't as mature. Last time I tried to use Foundation I found some serious issues with their responsive layout features that even manifested in their own website.
It's been around pretty much the same amount of time. BS was Aug 2011, Foundation was Sep 2011. BS probably got more mindshare early on because of the Twitter name/association, and that probably cemented some mindshare, but it was simply easier and more complete for more basic use cases out of the box.
Basic markup isn't THAT hard. I mean an architect knows how to swing a hammer, yes?
That said, I know what you mean, and that's the point of something like Bootstrap Studio. You don't markup, it does. So now the "web designer" (perhaps in conjunction with some who actually understands basic frontend) is building a live "pixel perfect" mock-up.
Photoshop is a proxy. A Photoshop pixel isn't a web pixel. It's like saying, "I'm going to give you a rubber doll. I want you to build an exact replica that's human." Really?
People who still say "pixel perfect" just sound silly. "Web designer" with no sense for the difference between a hammer and a shovel aren't real web designers. Especially when far better tools are available, if you're willing to move forward.
I hope they take your criticism constructively though, because I agree. I'm a longtime Bootstrap user but wouldn't be opposed to trying out Foundation...but I honestly don't know where to start.
Like Bootstrap, Foundation has a nice big "Getting Started" link to click on. OK:
Neither Foundation's or Bootstrap's "Getting Started" page is particularly interesting to me. But Bootstrap also has a "CSS" nav button that my eye naturally gravitates to, right next to "Getting Started". I click on that, and I see right away what opinions and conventions Bootstrap has, starting from the HTML5 doctype. The sidebar on the right makes it easy to get to specific topics of design, such as "Tables" and "Grid system".
Where is the corresponding overview page for Foundation? They also have a "CSS" link but it's not in the nav bar, it's nearly below the fold on Getting Started. And clicking that brings me to this Download page. Is that intentional? There's already a prominent "Download" link in the nav bar. I expect CSS to take me to some kind of page that demonstrates the CSS conventions. Clicking on "Sass" takes me to an anchor on the "Installation" page for the "command-line tool"...what does that have to do with how Sass is used?
And I get an alphabetical list of elements, the first one being "Abide", which...I have no idea what the name has to do with the element, whatever the element does. The Kitchen Sink page has two sidebars, and I'm not sure which one I'm supposed to focus on.
Maybe I'm an edge-case user, in that I don't really care to read tutorials to figure out how to use a front-end CSS framework. But that's what was appealing to me about Bootstrap from the very beginning. The design looked nice, the writeup of Bootstrap's most prominent elements and conventions had me sold right away. I didn't even know what a CSS framework was before Bootstrap, and had up to that point been satisfied with hand-coding CSS for every site. So whoever designed and edited the initial landing page for Bootstrap was doing something right, to so quickly make me realize my ignorance :)
Edit: Like the parent commenter, I regret my dickish tone of criticism and realize I need to take a nap. Not knowing much else about Foundation other than high praise from devs I respect, I would love for it to be as ubiquitous as a solution. Just pointing out that whatever technical flaws Bootstrap has, its introduction and overview docs are highly accessible and appealing.
FWIW, I don't think you had a dickish tone at all. I mentioned a couple of related criticisms in another comment - had I known the one above would have had so much activity I might have added it at the time.
"Tutorials" takes me to ... 20 videos? The first 6 of which have to do with email HTML/CSS, and "unsubscribe" is the first topic I see? Whether it's good or not, most projects I'm on I simply don't have time to dick around with so much ceremony up front in the hopes that this might save me time or give me a much better experience days/months in the future.
Again, Bootstrap is the "good enough" project. Even with more than a year of no real substantive activity, it's still more adopted and used and defaulted to than most other projects. It's the PHP of css/grid systems. It's the wordpress of css/grid/layout frameworks. There are many other platforms that are technically 'better', but none that are 'good enough' for a large number of use cases ('good enough' being, of course, in the eye of the beholder).
But no, you were not dickish. Your criticisms were pretty much just normal observations about why you can't get in to foundation.
> And I get an alphabetical list of elements, the first one being "Abide", which...I have no idea what the name has to do with the element, whatever the element does.
If you use angular 1.x a lot of 3rd party directives depend on bootstrap which is annoying if you're forced to not use it, current project would be 10x easier using bootstrap rather than materialize CSS especially since we have to over write materialize to make it look like bootstrap
The fact that it's somehow considered an insult to link to a CDN, rather than installing a gigabyte of tool chains that take years to learn, in order to achieve the exact same result... would be the reason nobody takes front end developers seriously.
Frankly, using Bootstrap from source is really easy, and tends to be my default path... I copy the bootstrap.less/scss as well as variables.scss to my project, update all the refs to the node_modules path(s), with the local variables... this way I can update said variables. I also create a local utils that includes the modules one... I'll add the local global styles to the lookup in webpack, and I'm off.
It's really nice, and allows me to comment out the bits I don't want/need and customize the few things I want changed (noto/consolas for fonts) and reuse the variables/fonts where needed.
Foundation, iirc originally required ruby, when I already was using node/npm for a lot of things... the better sass support via npm came later.
npm, bower, grunt, webpack and whatever is trendy right now, is the reason why some front development isn't take seriously.
Having the CDN link, or download with the js and css files is in my view a sign that you know what you're doing. Requiring me to use two package managers and a build tool that I didn't pick is uprofessionel.
I find it extremely powerful that major open source projects are calling the shots instead of the major browser vendors.
For some who may not recall, I think the most famous / historic move was when jQuery decided version 2 would deprecate support for IE 6/7/8.
Originally jQuery project would go out of their way to make sure all browsers were covered. Needless to say these days Microsoft is far more receptive to the needs of the open source community.
I apologize for not being more clear. I was thinking about the flexbox more than the IE9 deprecation. The jQuery story was only to reinforce the idea that open source projects are "at the negotiating table".
I don't think this shows the open source projects calling the shots, If anything my experience with jQuery since v2, was that we would use v1 instead of v2 in order to support IE.
Also when you consider how many changes were synced back to v1, I think it shows that at the end of the day, the user calls the shots.
It must be nice. I work in commodities and there are many plants and facilities that still only have access to IE8/9. It was a large struggle to even drop IE6/7 with a huge amount of backlash.
IT only pushes back because the business users who use old web apps push back. Gotta make sure that IT knows the MSFT no longer has their back and so they need to be more aggressive with the business users and their app vendors.
Those are extremely marginal as they're POS systems (+"Thin PC", I guess. I have no idea what that actually is.)
EDIT: I mean, I understand if you want to be able to keep using a JS/CSS framework, but it's not really reasonable to ask for upstreams to keep supporting such marginal systems.
I'm not sure what you mean, I think we were discussing upstreams (such as Bootstrap or whatever) supporting old browsers?
The old browsers are presumably (according to that page) still getting security updates by Microsoft, so I'm not what you're arguing. (Either way, if the browsers are not getting security updates, that's on Microsoft, not on upstreams.)
Can you explain what you mean?
EDIT: Hopefully to clarify what I'm puzzled about: How is having to use an old Bootstrap a security issue?
If you're thinking ATMs it's not such a problem because they are not connected to the internet and if bad guys get physical access it's pretty much game over regardless of the OS.
We sell an enterprise web app to insurance companies and only this month fully dropped support for IE<11 after a year long campaign to reach out to our large IE 8 customers. The official MS drop of support at the beginning of the year was finally the ammunition we needed to make it a reality (by framing it purely as a security risk), but even then it took us a year to be comfortable pulling the trigger. But from someone who knows how difficult it can be: there is hope.
That's fine if you're B2C and selling direct to that 1%.
But if you're B2B then, you're not selling to that 1%, you're selling to a range of companies.
So 1% of end users having IE9 translates to 10% of your customers having (some) users with IE9.
Sometimes you're not even selling to companies, you're selling to partners or resellers selling to companies, so now that 10% of companies translates to 60% of your partners / resellers having (some) companies which themselves have (some) users with IE9.
So what was 1% of users can translate to much more than 1% of revenue lost just by dropping support.
And that's before I get started on how general those analytics are rather than breaking it down to office workers during work. Again, if your business is selling SaaS that targets workers then you'll likely come across a client with a need for older IE support sooner rather than later.
There's another reason why B2C is fine to drop support:
People are resourceful, if you have a website which breaks in IE9 then they'll probably just switch to chrome and it'll work fine if it's something they really want.
Companies however tend to be less flexible, if they know they have IE9 installed they'll insist on having "IE9 support" in the acceptance criteria, even if it's only installed on a few machines which likely will never be used with your software.
I'm actually happy to see bootstrap, jquery etc drop IE9 support because it makes it much easier during negotiation to drop support and push back against such proposals.
IE9 is still in extended support until April due to the fact it's the most recent IE that can run on Vista, and Vista is still in extended support until April 11.
I've seen the details of quite a few B2B SaaS and Govt SaaS deals as of late, and most dev orgs are just not supporting anything other than evergreen browsers. If you don't have the latest browser version, your ticket will be closed since supporting browser based GIS with IE8/9 is a giant waste of money.
If they're using XP to work with protected health information (PHI), and aren't on an extended service contract with Microsoft, they're accessing PHI on an insecure system and are, at least to how my team would interpret it, in direct violation of HIPAA.
In fact – and I too am not a lawyer, so don't consider this actionable advice – you might do well to throw up a warning, if not altogether disable access, to whatever product it is your users are accessing on XP, just to make sure you have all your HIPAA bases covered.
Everyone interprets HIPAA differently and based on a statement like: "Continuing to use Windows XP after 4/8/14 (or other unsupported operating systems) becomes a HIPAA violation if it’s not addressed in your security risk analysis[0]." You can run XP indefinitely as long as your IT says it's OK and they've "secured it properly." However, if they do get hacked or whatnot, they can get a fine if their security analysis wasn't good enough.
I don't recommend it. I actually despise it and try my hardest to get people to drop it. But in the end, I've had to deal with a lot of XP running IE8 systems that need connections to the software I'm in charge of. There's nothing I can do unless I get rid of those users and most of the time I can't because I have to "support modern browsers" as noted in the contract and the contract is with the state, not the individual users. Yes, the contracts will get updated to be more specific, but most of the contracts are on 5 year cycles.
I bet you a significant portion of healthcare is running xp. This is not a fast moving industry, and "if it ain't broke don't fix it." Hypothetical security isn't something most healthcare workers will consider broke.
This isn't how you should drop support, it might be a good choice but can we at least have some discussion, maybe even an RFC, not just declare it be so within the space of 3 hours and lock the issue...
To be fair that discussion about dropping support for IE9 took place over 18 months ago — that is a long time in browser age. Bootstrap is following in the footsteps of a bunch of other JavaScript libraries and frameworks that dropped IE9 (so all the arguments are pretty much known), and by now IE9 is that much more of a marginal browser that supporting it is in no one's interest.
Ember certainly has a very pleasant way of discussing these matters, and for dropping support for IE10 or IE11 that would be a fair way to do it now at the end of 2016, but there's just not much to be gained from a discussion about dropping IE9 support at this point.
If IE9 support is part of your project's requirements, you would just use Bootstrap 3 or one of the many alternatives that provide that as a feature. For a "new" framework (as these major revisions essentially are) it shouldn't matter as there are no users/victims (aside from testers).
The argument just seems superfluous. No one cares about ie9, including yourself. That kind of drawn out boring conversation stifles progression for no other reason than to be proper imo.
mdo is one of the creators of bootstrap. I also feel it's probably time to move on from IE < 11, and possibly even then depending on your real needs. Even MS has worked pretty hard to get people off of IE and into Win10+Edge
Finally! Every other major framework needs to jump on this bandwagon and stop supporting IE9 and then the users will realize they are outdated...at least I would hope so. Every aspect of Frontend development adds a ton of extra hours when building around IE9's quirks. I had the same idea as Bootstrap building my own Flexbox based CSS framework Useful.ly
Ah the worst thing about Bootstrap is jQuery because it's a pain to integrate it into Single Page Applications properly. That's why I enjoy Bulma (bulma.io) so much - just CSS but still 90% of the stuff you get in Bootstrap.
I don't really understand whats so hard about using Bootstrap with it's JS in SPA. I've adapted BS components for Ember.js, I've did same with Mithril.js and then React.js, and I've never had problems.
My only pain points were lack of proper destructors for use in tests.
doesn't really work because webpack (what we use) moves all import statements to the top. That can be solved by import bootstrap with
require('bootstrap');
though.
However, the more challenging and annoying part are plugins because jQuery uses it's own plugin registry ($.fn). Most of the plugins are so nice to require it if require is available. But, the things you get from require are cached, thus, if you do
const $ = require('jquery');
$.fn.yada = ...
your registered function will not be available to other jQuery imports.
Long story short, what's so annoying about this technology is the fact that it does not fit the modularized setups very well but you are forced to find a way for it to work when you want to use bootstrap with the JavaScript additions.
You can inject window.$ and window.jQuery via webpack directly, making the inclusion implicit... there's a minor amount of additional script added, and it makes it unavailable to attach to the actual window, but I find the DOM interfaces sufficient in the console anyway.
I added it via expose-loader and with the ProvidePlugin but neither of it worked. Eventually some technique (loader, plugin and/or require()) made it work and I gave up and didn't touch it since then.
This is actually kind of nice. I hate frameworks like Bootstrap that try to make any design / styling decisions. It's my experience that unless you're fine with that out of the box styling, you'll actually fight the framework while customizing it.
A small, lightweight framework that focuses on the very basics, avoids styling and frees me from repeating boilerplate code in every project is most welcome.
traditionally the reason I've avoided flexbox for layout (fine for most items within that layout) is the wonky rendering on slower connections[0]. is bootstrap doing anything to get around this or did they really go "full flexbox"? since I use susy[1] I'll never need bootstrap for grids, but I'm curious about the flexbox adoption and tradeoffs.
The observation in the linked video is that, when the browser is incrementally rendering the page, a traditional "grid" layout will put the content in its final location, while a flexbox will render a box of content that's bigger than usual and shrink it later -- because the items that cause the content area to shrink haven't been loaded yet.
Neither do I. Unless flexbox's CSS weights a lot more than classical CSS, I don't know how could that be a factor to render slower. Does not make any sense.
I am really confused with CSS grid. How does it adjust to smaller screen sizes? My impression is that it is rigid like an html table, and we have mostly abandoned these for good reasons.
With flexbox I can make the sidebar float below the content at a certain screen size. Can I do this with grid?
So if anything, it seems to me that the global layout should be done with flexbox, and the grid is for smaller, more rigid elements that do not need to re-order on different screen sizes.
Most of the same tricks to flexbox reordering and reflowing for responsive layouts apply to CSS grid as well. You can use @media queries to switch grid layouts based on things like screen size. With more recent specs you get a further advantage in that where flexbox reordering is based on easy to mix up numbering (at this media layout this Div A is 1, Div B is 2, Div C is 3, but in this other layout Div A is 3, Div B is 1 and Div C is 2) for naming your grid sections (Div A is "sidebar" and Div B is "main-content" and Div C is "footer"); the names stay consistent and only your designation of which name goes where in the grid flow (which is managed at the parent container level) shifts with media query reflows.
For what it is worth, I built a complicated 2D, responsive layout for my blog (mostly to amuse myself). I allowed myself whatever tech choices I felt comfortable using and I wish I could have used Grid but browser support wasn't where I would have liked and neither was prollyfill support. The Flexbox version I built is a lot less simple to follow in the CSS media query switching than the Grid equivalent would have been (but Flexbox version has been quite reliable across browsers). Though the biggest loss in not having Grid support turned out to be what I wanted to do for DL (DD, DT) layout, since I tend to use those quite heavily, and neither Flexbox nor CSS Table Layout suffice (due to DT+DD[+DD...] sets lacking a wrapper element, per HTML spec).
Essentially, with what I've done with Grid, my opinion is Flexbox makes the 1D case simpler than the equivalent thing with Grid. AFAICT, this is the prevailing view the reason for the above.
Yes, but in my opinion, using media queries should be avoided. Media queries try to guess the screen size from the resolution, which is a bad hack in my eyes. And they imply assumptions about which screen sizes and pixels densities exist, something I'm trying to avoid when building truly responsive websites.
Media queries have been based on "effective pixels" rather than actual screen size since early in iOS/WebKit development and entrenched (or worsened depending on your perspective, I suppose) in the "retina" shift and other browsers following suit. It's a communal hack, but you can mostly assume that a modern browser is going to choose applicable media queries based on what it best thinks its pixel density and device form factor may be, rather than actual specific screen size. (Including things like Windows' Tablet Mode switch signalling to Edge to apply media queries differently.)
It might have been nice if CSS had more standard media queries that stated more explicitly what is desired (@media tablet-screen {} or something similar), but the compromise that remains is a solid one that mostly works and is adaptable/evolvable to potential future shifts in device profiles (both in browsers choosing different "effective pixel" ratings over time on the one side and CSS writers shifting breakpoints on the other).
Yes, new CSS standards like Grid/Flexbox could try to invent new wheels to deal with responsive issues, but it's easier for those standards to get adopted if they just subsume existing standards such as media queries.
I'm curious how you manage to avoid media queries while building "truly responsive" websites.
An unfortunate tipping point for accessibility. My personal project natUIve is full flexbox, supports IE8, doesn't require JS even for the slider. https://radogado.github.io/natuive/
The page background image makes the text completely illegible in several places, for me, in Firefox. It's so awful that I'm not confident it's supposed to look like this: http://i.imgur.com/lDuO3NA.png
Um... What's it supposed to look like? Looks the same on chrome on Android for me too. The background image jumps around when you scroll too. http://imgur.com/ctQzgdx
Hi, here is a Firefox shot. The page has white background except on the Fixed background section. http://imgur.com/k0KzQiL
I'll check on FF Dev/Nightly Windows, interesting.
The immediate visual difference with Bootstrap is square corners vs rounded corners. Buttons and other components look strange after years of Bootstrap and its impact on web design. There is probably a few rules to edit to fix that, still... why having to do the work?
Anyway, I'll try to remember natUIve if a customer asks me to support old (but not so old) browsers.
Hi, thank you. That's one of the biggest problems with Bootstrap – a framework should not impose design on the creators.
The issue isn't just about old browsers. IE8 might not matter, but by supporting 10 years in the past you also make sure it will work 10 years in the future, following the standards. Simple, accessible HTML is under attack by the JS frameworks and most of the industry. When the framework du jour collapses under its complexity in 5 years, we'll be back to HTML.
I'm a bit sad for the dropping of IE 9 support, if only because it was the first IE that had a "fast" JS engine and didn't take forever to render our JS heavy site.
For many of the components, it's easy enough to do the necessary styling via your own controls (tabs in particular) as opposed to trying to map the jquery + bootstrap.js... if you can avoid their JS, you can save some overhead. ymmv.
If you're going with React, you might want to look at material-ui[1] with a normalize css include and a basic (manual) flexbox layout to begin with. The components offered are really complete for a UI framework, and depending on your needs, working from dev branch may be a good option.
That's great. I wonder how much traffic will be saved worldwide without .col-md-6 html being sent around. Just straight up content HTML with minimal "boxing".
I'd love it if they had a things don't look broken promise for IE9. Seems like it should be relatively easy to sequentially layout the page in IE9 without flexbox?
Is everyone else dropping IE9 support at this stage...
I'm a bit out of the frontend developer loop these days being full stack and learning things like docker or elixir is more fun, and useful, than the vagaries of the latest promise library/CSS Pre processor/awful class naming scheme/etc.
Since Google, is essentially what everybody in the western world uses to search, ( Russia, China, Japan, Korea all gets their own search from somewhere else. )
I wish they could release some stats on browser usage. Otherwise i dont know where to get concrete information without substantial bias. Also the time which browsers are used. Since people are likely using different browsers in School / Work compared to at Home.
Vista extended support ends in April of 2017. It's the last holdout of Microsoft-supported mainstream versions of Windows (i.e., excluding fringe versions like Windows Embedded) that can't upgrade beyond IE9. Seems reasonable that the new version of Bootstrap (which you don't have to use--v3 still works fine) should not bother with support for a browser that will soon be no longer supported by the browser's own creator.
They should probably even consider dropping IE10 support if it is any sort of burden to them. IE10's marketshare is so tiny (smaller than IE9, IIRC). Windows Vista (i.e., "Windows 6") users used IE9 since MS didn't support anything beyond that for Vista while Windows 7 users mostly auto-updated to IE11.
Migration from 3 to 4 will certainly be a pain but then you're gonna love it. I love new cards, utility classes, better out of the box support for mobile browsers.
But beware of breaking changes between alphas, there are quite a few.
I'm presuming it's not a migration as much as a complete makeover/refactoring. Which could be interesting. Does that open the door to Foundation? That is, if you're going to more or less start over is now the time to jump the Bootstrap ship and climb on board with Foundation?
By migration I meant migration for a project that already uses Bootstrap 3 and considers using 4.
Speaking of Foundation, I dunno, it depends on one's needs.
Some people say Bootstrap is too big but I appreciate its vast collection of components. Especially when you do CMS / control panel kind of apps and you need to make them quick, Bootstrap is a saviour.
Also, aesthetically I like those rounded form controls, buttons and cards. Plus it takes only a few lines of scss to make bootstrap look branded, add custom fonts and most people won't even guess it's Bootstrap.
Yes. I got what you meant by migration :) My arc was that the difference from 3 to 4 looks to be fairly vast, and that you're all but rebuilding (i.e., it's a new site/application). Or darn close.
So if you've been considering Foundation this could be a window for Foundation to pick up some marketshare.
Why reinvent the wheel? Unless you've already created your own pattern library to draw from, you're not going to save time writing it all yourself. How are users going to benefit from your hand-rolled code?
There may be plenty of good answers to these questions but they should be asked.
I'm pretty sure using bootstrap is re-inventing the wheel more than hand coding is. Using a framework which when installed and configured gives you the end result of a "wheel", as opposed to just coding up the wheel using HTML/CSS. Let's also make it clear that hand coding doesn't mean sitting there repeatedly typing out every character on every new job. There is always previous jobs and code to draw on to flesh out the needs of a page or site build efficiently and reliably. The benefit for developers is that you have very detailed control and knowledge of the frontend, rather than some broad "does Bootstrap do this thing I want" buffer between you and your own work. Each to their own. No right or wrong.
I think they're saying Bootstrap's wholehearted adoption of flexbox is not an enticement to use Bootstrap, they'll stick with hand-coding designs, using flexbox where appropriate.
True. I think MS just gradually shifts the costs so that at a certain point the cost of upgrading everything to the latest OS version seems like a good deal compared with the support requirements of IE9.
This attitude is why more people are not software developers- far worse than pissing of you and your elitist friends.
Bootstrap's 'one-line-of-code-and-go' simplicity enabled me to make my first websites with no IT education on library computer in rural Australia [we didn't have one at home]. Today, I write code for a SF-based unicorn and whilst I don't use Bootstrap at work, I attribute my career to that CSS framework.
'Easier' tools enable more people to make use mankind's collective knowledge and change their lives for the better; I don't give a fuck if you're happy about it.
You don't "download a library" with popular bootstrap alternatives.
You look and see - "oh, this requires sass. sass requires some libs, or npm, or something else. Now I need to know how to go install those (assuming I'm on a machine I can install software on right now), then make sure it's all downloaded and installed correctly (because there are multiple ways to install it 'wrong'), then learn how to use those tools, then learn how to use them well enough to make something decent, the learn how to bundle/deploy that to my website."
You're not saving anywhere near "20 seconds" using bootstrap CDN vs the alternatives (and frankly, not even using bootstrap itself, if you pull it down and configure and compile all its options as well). You're saving hours or days of learning up front, and focusing on getting something basic up and running, then determining what style/ui changes are required later.
But keep making the false comparison between "downloading" vs "learning portion of multiple ecosystem and technologies" - you're coming across as quite learned here.
Since you mentioned the high status profession of surgeons. Surgeons regularly amputate the wrong leg or similar level blunders while nurses in the room know they are making a mistake. When they investigate these issues and why the right thing wasn't done, elitism is a prime culprit. But they don't always investigate, and elitism is a prime reason for that too, as who wants to blame surgeons for making stupid mistakes?
When the airline industry made a major effort to improve safety elitism was something they explicitly challenged.
>Then I started to grow up and accept that minor chores are part of life.
The entire reason why I got into programming was to eliminate the need for "minor chores". I want to tell the computer how to do it and then never think about it again (mostly). Bootstrap isn't perfect, but it's convenient and easy enough to use that I haven't dug too deeply into alternatives.
This ! It seems the coming IT generation got so much sucked into the current state of programming, few actually try to look at the big picture for some perspective on "why" are we doing things the way we are in the first place.
The way I think about it: any extra effort that has no direct impact in making my life "as a programmer" easier, is a bug that needs to be fixed. Same thing applies when designing for people (i.e non technical users)
> The way I think about it: any extra effort that has no direct impact in making my life "as a programmer" easier, is a bug that needs to be fixed.
And 20 years later I am able to differentiate between "minor chores" and real "real work savers".
And downloading something is definitely a minor chore, one that can be "fixed" by a few lines of code in your build pipeline. After having read a few discussion here on HN I totally get that this is "too much" for some (just revisit the discussion about the npm left-pad disaster where the consensus on HN seems to be that it "is ok to download code for that because writing your own routine for left-padding a string might take an hour"). When I was learning, I'd spend that our in my spare time because I'd be ashamed to have somebody pay me for this. Now that I am older, I'd just fire whoever utters such crap on the spot. To be perfectly clear: "I don't have to download the libs!" is NOT a valid reasoning for a technical choice. Not at all.
In the last 20 years of professional software development I've never ever encountered a situation where the time "downloading libraries" was worth more than a rounding error in a weekly budget.
PS: man alias. trust me, just a single line of config in your shell will save you hours, well minutes, well, maybe just seconds over your lifetime. But you can spend twice as much time to make the non-problem go away - and you qualify for a free shirt "for every solution, I have the problem!".
EDIT: sp4ke, I know this sounds harsh, but it is not, in any way, meant as a personal attack. Instead, please treat it as the ramblings of an old, misanthropic programmer ;)
so maybe everyone should just wait 20 years before they understand any differences, and then they're ready to go?
"one that can be "fixed" by a few lines of code in your build pipeline"
Why do I even need a "build pipeline" for some projects?
If you actually think much of this npm/gulp/sass/build stuff will age well, and you'll be able to go back to a "build pipeline" for a project 7 years from now.... it's very likely not going to work.
"In the last 20 years of professional software development I've never ever encountered a situation where the time "downloading libraries" was worth more than a rounding error in a weekly budget."
Hrm... just last week - "npm install" on a project took 45 minutes. Then... welp, gotta do it again on the server too. 345 meg of stuff, multiple dozens of which were complete duplicates of each other. That's 90 minutes waiting, 45 of which not even sure how much time is left (2 mins? 5 seconds? an hour?) while the machine slowed to a crawl.
"I don't have to download the source libraries, then make changes, then recompile, and build and publish and push just to get a half-decent default when I can just reference these over here from a CDN" - that certainly is a valid technical choice. You can spend hours downloading, configuring, learning something that wasn't bootstrap and delivering less than "way better than bootstrap" UI/UX... that's a bad technical choice.
You're right about aliasing commands, building stuff to save yourself time, but avoiding prebuilt stuff that is perfectly suitable for a project in pursuit of pixel-level control when it's not necessary (for most projects) is wasting time.
>I don't care about your problem with NPM, I neither mentioned it nor do I used it beyond amusement purposes.
The commenter who you said had "by far the worst line of reasoning I've ever encountered" was annoyed at having to use NPM to install a simple CSS library. Not only did you flat out insult the person, you did so without taking seriously the tech stack that caused the headache! How do you expect to contribute to a discussion of the pros and cons of new tech when you yourself aren't using it to do real work?
Give me Bootstrap over an in-house library any day. It makes hiring and onboarding new staff easier, speeds up prototyping, and introduces standards with minimal effort.
Of course it's not right for every project, but it's perfect for a lot of them.
And your mentality makes me want to do the same. Computers are hard as-is. Taking what could be a simple task and adding a bunch of extra unnecessary choices before I even have any context for understanding what those choices affect makes my life measurably harder. Worse, when other projects take this same approach the complexity isn't merely additive — it's exponential.
This is why yak shaving is a thing we had to name. In isolation none of these things is hard or even a big ask. In combination, you end up diving into how PATH is set in your shell because you added npm's bin dir to it but you've actually added the wrong one because you didn't realize you accidentally installed it through both curlpipe and homebrew and (add ten more steps of complications here) just to tinker around with a freaking static HTML template.
It makes stuff look decent when that's all I need.
I need a minimally responsive site that doesn't look like ass, where I can possibly change a couple colors, but things basically look good to go out of the box.
Bootstrap was a fucking godsend in 2011 compared to everything else out there at the time. I can have something up that fits a client's requirements (something that doesn't look ugly) and spend more time on their actual functional requirements vs spending bullshit time downloading 200,000 NPM files and fucking with dependency hell just to have grunt and gulp and sass and less and all that other bullshit work.
I delivered line of business apps that looked decent, and frankly still look pretty decent (BS2 has held up OK, and BS3 is still decent even without any tweaking).
And guess what? For many many many types of web software that's delivered, Bootstrap is GOOD ENOUGH. It's a 'minimum viable css grid', where "minimum" and "viable" include "not looking like crap that I have to spend hours tweaking".
I tend to agree. Aesthetic design is overrated. The average user won't care if they get the info/result they need. As long as you don't offend - and Bootstrap is above that fairly low bar - most visitors will be satisfied.
Furthermore more, Bootstrap made "mobile first" easy to embrace. It certainly helped to usher in RWD.
They're not trivial things if they're adding to the complexity already present there.
For example, you may not in fact use node for anything else in the project (eg. it's a Django or Rails project). If you now need to depend on node just for this one thing, the marginal cost/utility is non-trivial.
These things add up, and being aware (and aversive) to this is not whining.
"by far the worst line of reasoning I've ever encountered" is a tad rude. If you disagree with something feel free to explain why (which you did), but saying it's by far the worst reasoning ever on HN isn't really constructive.
All they're saying is that in terms of popularity, having lower barriers to entry helps.
I agree, its great to take that personal responsibility yourself. When it comes to software that others use, the easier you make it the more people use it. Isn't that a key part of why we use automation? Put work into setting it up once for end user simplicity and reap the rewards the next 10,1000,n times.
Bootstrap is really so far behind now I don't know why anyone even considers it as a viable option anymore. How long have they been in alpha/beta stage without a solid RC? It's legitimately pathetic and abysmal at this point.
I'm honestly really confused. I'd love to ask one of the devs how they've managed to literally do nothing while other, better CSS frameworks have been created AND versioned in the same timeframe.
Bootstrap 4 is just a sad attempt at preventing obsolescence. Time to let it die.
In a more substantive tone, I personally see little value in 5 alpha versions. If none of them progressed to beta or an RC stage, they don't really provide much utility. Why would I try to ship a product unsuitable for production? I fail to see value in a product promised, but as of press-time, yet to be delivered.
Regardless, we can simply look at other frameworks to compare. Foundation 6 is out and is pretty solid. There are various material-design inspired frameworks, and more barebone grid systems that do everything bootstrap 4 can do with it's grid system. Did I mention many are lighter-weight and also production ready?
Since some people take sense 2 to be the opposite of sense 1, it has been frequently criticized as a misuse. Instead, the use is pure hyperbole intended to gain emphasis, but it often appears in contexts where no additional emphasis is necessary.
Perhaps you could have given examples other than Foundation that met your later assertions. Personally I've used Bootstrap for years (2 and 3), tried Foundation back in 2.x days and it was pants in terms of default behaviour of its classes.
It's always looked worse IMO, and I grew used to Bootstrap's sensible (and modular I should say, w.r.t. your 'lighter' comment) ... Sass source structure and conventions, so never been tempted to try Foundation again.
I've seen a few of these 'light' flexbox-based CSS frameworks spring up, but they've always been inferior to Bootstrap 3's grid (e.g. Bulma, which has no support for multiple breakpoints in the grid out of the box).
For one thing, they're stable, have consistent progress between releases, don't take eons between releases, and provide pretty much the exact same functionality.
Perhaps the implementation is no better (since it's all just relatively simple CSS), but having timely releases is a big plus in my opinion, something which TB4 has failed to deliver for what, over two years now?
Why not just use flexboxgrid and throw a few quick base classes for buttons and whatnot together? It's smaller in size and provides equal grid functionality, which is really the primary value of CSS frameworks anyway.
We get it. You don't like Bootstrap. I love it, use it all the time, and am grateful for all the effort the developers are putting into it. Sure, I'd love v4 to be released more quickly, but since I have contributed nothing to it, I can't moan about how long it's taking.
Personally I've never understood why people would need bootstrap on a new project. Especially if you're able to use flexbox. If you have a decent practical understanding of CSS, you can write could use plain CSS and a couple of classes for various components with significantly less overhead than bootstrap. Its pretty similar to how I see jquery nowadays honestly.
With Bootstrap you can just pick the parts you need (so there is no practical 'overhead'), and most sites will at the very least need a responsive grid, and Bootstrap's (3's at least) is excellent. I don't know why you wouldn't want to use it, or something very similar from another framework.
Even with flexbox you'd still need to reimplement the 'different column behaviours at various breakpoints', which is non-trivial.
Also there's the whole other-devs-understanding-your-code scenario 'oh this is Bootstrap, I know this'. It gives you conventions BEYOND just what raw CSS gives you, e.g. the Sass variables it exposes.
Because using Sass you can reduce all bloat by commenting one file full of @imports, and it's easy to get up and running quickly. Depending on the type of site (I do e-commerce) EVERYone wants a modal, a tooltip, etc; it's much faster to just style components that have already been tested at all breakpoints in all browsers than write your own.
Well... maybe I'm out of the loop, but what's better? Everyone I know uses Bootstrap. Bootstrap 4 is progress, and I haven't personally seen anything dramatically better. There's 1001 clones, but none of them revolutionarily better nor as widespread.
"No framework" has become a reasonable alternative. Bootstrap and others got started because (a) the 12-column grid layout was incredibly nice to work with compared to the disaster that page layout was before and (b) they provided abstraction over differences in browser implementations.
CSS has come a long way since then. Flexbox is possibly a bit more complicated and powerful than .col-xs-12, but not by much. CSS support has largely converged.
Foundation 6, Flexboxgrid, MaterializeCSS, SemanticUI, Material Design Lite, etc, etc. Honestly, there are too many to count that are fully functional and similarly spec'd or more so.
http://foundation.zurb.com vs http://getbootstrap.com
Each has a link to 'download'.
Foundation's link takes me to a page where I have a bunch of options, and a bit "build a custom generated version".
Bootstrap's takes me to a screen with 3 options, but also - and this is key - CDN links. Right there. I can paste a few lines in my HTML template and start working.
I don't need to download/generate code.
I don't need to install node/npm/etc.
I don't need to install and learn sass stuff.
I don't need to make a lot of decisions or do a lot of extra unrelated stuff to get started.
Bootstrap is the PHP of the css/grid/framework world (for better and for worse).
I truly hope they keep the CDN hosted stuff for Bootstrap 4.
EDIT: didn't mean to pick on foundation specifically - this "take control of every aspect of all your layout/grid/css" that most other frameworks require works to their disadvantage when it comes to popularity and uptake.