One thing Foundation is doing that I haven't seen done anywhere else is Foundation for Emails (http://foundation.zurb.com/emails.html). It's a build process that lets you design responsive HTML email templates that will work in most clients. There are so many quirks in Outlook, Gmail, etc that its nearly impossible to keep up, so it's great to have a team of people dedicated to abstracting it away for designers.
You do not need to include the whole javascript, you can include just the things you need. However, there have been problems with webpack and Foundation javascript developers seem to have no clue about what is going on in the JS frontend world, acting like isolated on a moon station, disconnected, what leads to problems with integrating other things.
Very problematic is they still have FOUC problems - you have to look for various workarounds, but FOUC out of the box! The menu components and everything related to responsiveness suffer from it. I do not understand how this ever got released.
Foundation 5 was ok, but this 6 release is disappointing. The modular handling of menus is a good idea, but overall execution is bad, lots of micro-problems everywhere, it feels not even pre-alpha. Also very monolithic and non-cooperative, ugly to integrate with anything else.
I would recommend looking at semantic ui instead, which also has a good react integration, something Foundation designers do not have ever thought about.
About the community: the people are great, but Zurb gives them only a totally annoying "forum" that is not able to filter for versions, so when you are searching for things you get all the stuff from previous versions, an information design nightmare, that would be easy to fix, but they do not even seem to have a problem with it - this says a lot about the agency behind it.
Also be careful with installing foundation globally: it will overwrite your Foundation 5 binary, if you are using this, be careful. Not a serious problem, but when you still want to use F5 you have to prepare for it! Even with version 6 they still do not have a clue how to handle versioning, this tells a lot about the code quality you will be confronted with.
But they have great marketing, the site and everything around F6 looks really great!
It's 2016 and Bootstrap still doesn't have native RTL support. Foundation had it (excellently) since 2013.
When I'm building something for the local market, this has a major affect on my decision.
There was an attempt to do so. They were using an RTL-flipping tool and it all looked pretty cool (I built something with it) but then one of the people who manually flipped Bootstrap basically accused them of being culturally insensitive by trying to automate this task and they abandoned it.
"Culturally insensitive" wasn't part of the discussion. He listed specific technical and UX issues with their approach. Another commenter in this thread posted a link to the github discussion.
Having re-read the thread, I stand by my "in-a-nutshell" summary of it.
I don't think any of his technical arguments hold up. I'm also not sure that he would have convinced the Bootstrap team to have dropped this based on technical arguments if he hadn't seemed so annoyed, and made repeated references to how only people who speak the language should make certain decisions.
Some examples:
* the bug report is a command: "Stop developing RTL for Bootstrap!"
* the bug report ends with an exclamation point!
* the bug starts "I'm really annoyed..."
* "use cases that only natives can understand"
* A second command, bolded: "Remove it!"
I personally was inconvenienced by this because I was writing lots of bootstrap based .less, and if twitter and Bootstrap had worked together on an auto-flipping rtl system for Bootstrap then all the RTL users of my code would have got a far better service. Instead only those who use the Bootstrap CSS essentially as-it-comes get a manually RTL'd version from a 3rd party. A tool that can automate that work sounds like a far better deal for the RTL world, even if it would have annoyed this particular person.
I note that his argument against automated flipping included the fact that you really need one for farsi, one for arabic, etc. Yet he only manually produces one. Maybe with the right tooling he'd have got to where he wanted to be faster.
A link to such a tool: https://github.com/MohammadYounes/rtlcss (note how it documents various solutions to the 'problems' listed in the original bug report, like changing the font stack when in RTL mode)
Agreed that it wasn't raised very diplomatically. That's part personality/choice, part what happens when English isn't someone's first language. Comes with the localization territory. That he produced a coded alternative, regardless of its merits, puts him in good faith in my book.
There's no shortage of insufferably squeaky wheels who aren't acquiesced to, and I don't see any ways this one was treated exceptionally. It looks like the maintainers worked to understand the root of his frustration despite his abrasive style. Kudos. The Bootstrap team acknowledging it's a complex issue (rather than the solved problem they thought it to be) and changing their release plan accordingly seems a reasonable way to handle it, and one I'd encourage for maintainers of widely used projects. Finding the right effort/quality balance is tricky. That some of the issues could be relatively trivial to address (font stack) doesn't invalidate the category.
In particular, the distinction between RTL and “flipping” does seem to be a meaningful one, and fraught with unexpected issues. Eg, next=right and prev=left as a cultural convention that doesn't directly translate. As you note.
Frankly, if tasked with supporting RTL I'd probably start with a repo like the one you linked to, but fully expect it to fall down in a number of ways that could only be identified by a native user. Whether those issues get addressed would be a pretty clear statement on how much those users are valued.
Just to note, flipping and contributions by native RTL speakers are not mutually exclusive. (I'm guessing that the author of the flipping tool I linked to falls into both categories for example).
This appeared to be the crux of the original complaint/misunderstanding too. The assumption that the core BS devs would auto-flip and leave it at that. But all but the most basic of rtl-flippers allow for case by case overrides to add the final 5% that the simple rules can't handle. Finding and fixing those requires people with an understanding of RTL and Bootstrap could easily have recruited that effort. It's just that they only have to do the last 1/20th of the work, and even without expert input devs building on top of Bootsrap can automatically get 95% for free on any extensions they build themselves.
It's not true. The user didn't accuse them of being culturally insensitive. Rather, he argued that that automating the conversion was fool's errand, partly due to the differences between the various RTL languages. He suggested that the Bootstrap team point users to quality RTL themes instead of releasing a shoddy built-in RTL implementation.
Perhaps this should be added to the list of instances of people dismissing valid arguments by labeling them polical correctness.
I currently use Bootstrap, but have been looking at Bourbon recently along with it's suite of components (Neat, Bitters and Refills). It offers a nice set of mixins for semantic grids and common components. My only concern is working with other developers where Bootstrap is almost a common language.
Something I'm missing on Foundation and Bourbon[0] website is the self explanatory documentation. It is something that is very useful for me as I play around with Bootstrap, because I can find the section of functionality I need and then almost copy and paste their example code or inspect the element to understand it better.
Did I just miss something obvious or does it not exist?
As Bourbon is just a collection of Sass mixins, I think the intention for the source to be self-documenting. The docs for Bitters [0], Neat [1] and Refills [3] are a bit closer in style to Bootstrap, since they are more opinionated add-ons to the base Bourbon base.
I skipped Bootstrap in favor of Foundation in their earlier days, but like you I've settled in to using Bourbon mixins when I want to get my hands dirty, and Bootstrap when I just want to get up and running (and possibly hand off the project).
The key unanswered question, and for me the fundamental reason I switched from using Bootstrap to Foundation at work, is how designer friendly the two are.
Bootstrap is fantastic when you want a site that looks like Bootstrap, these tend to be put together by developers. Foundation (at least was) much less opinionated and therefore when you're given a PSD by a designer much easier to implement.
Have things improved on that front? Is it easy to override Bootstrap's defaults?
Yeah I cringed hard when the author said Bootstrap wins the design side of things. Yeah, sure, a Bootstrap site that looks like Bootstrap looks better than a Foundation site that looks like Foundation.
That's because Bootstrap piles on a whole load of stuff that are really just annoyances for anyone who wants to make their site NOT look like it came off the same assembly line as millions of others.
Bootstrap has moved towards Foundation's more barebones method, but still not there.
I agree with Andy here. I am finding more and more instances of bootstrap in the wild where I need to double check the source code to figure out whether or not it is Bootstrap. Most instances are obviously bootstrap but mostly because the developer doesn't have a designer involved and doesn't need one which is the beauty of it.
Can you explain or give any examples where this is the case? At my work we build totally bespoke designs with Bootstrap and are having a good experience.
I personally find that if I'm spending time overriding a framework's defaults for literally every single thing I do, that it's a badly designed framework.
Maybe there's some sort of Bootstrap "reset.css" type of thing now, but I couldn't handle it back when I tried Bootstrap.
In Bootstrap 3 you shouldn't have to override anything.
I think I've found one exception which is the toggle button in the navbar element that seems to have some annoying defaults I have to override every time, but that's it.
(If your experience was with Bootstrap 2, then that explains your feelings, but that situation was pretty categorically fixed with BS3).
Ancedotal evidence: My company recently switched https://m.curiosity.com to Bootstrap from custom CSS, and spec'd the design almost entirely by PSDs. I don't think the site looks particularly Bootstrappy nor did it seem especially challenging to customize.
I've been a big fan of bootstrap, but I find that these CSS frameworks are becoming more and more irrelevant in the age of widespread flexbox support. CSS modules do put the last nail in the coffin.
I don't find this to be the case. There are a ton of conventions in Bootstrap, an obvious one being its variables, that are very useful when working in a team, and (in our experience) with outside contractors. I couldn't imagine giving up Bootstrap simply 'because flexbox'.
Also flexbox support in IE is still terrible, so for those of us building sites for the open-web it's a non-starter for things where a 'just doesn't work' fallback is unacceptable, such as the main site structure and alignment of core elements.
Currently I only find flexbox useful for things like vertical centering, where it's not the end of the world if the element doesn't center in IE.
I disagree. Flexbox is a little buggy in IE11(and IE10 with auto-preifxer and the old spec) for almost everything it's fine, you just need to remember to set widths on column layouts, which is just one extra line.
Not to say it isn't frustrating, especially since it works extremely well in Edge but MS said they won't port the fixes over.
Yes, flexbox is not supported in IE8 & 9, wrong spec in 10 and buggy in 11, therefore the 'terrible'. I'm talking in the context of websites that have to work on the open-web (where unfortunately a lot of people still use those versions of IE).
For contrast if you work against a framework like Bootstrap 3, sites 'just work' all the way back to IE8.
By variables do you just mean the CSS pre-processors? My reason for asking is that it's not unique to Bootstrap at all (and, if they just use the default build, many designers will never even see them).
If you think about the grid-systems of those CSS frameworks, you're probably right.
But Bootstrap has a nice "out-of-the-box" experience. I know much about usability engineering and user experience, but not so much about graphic design. And bootstrap fills this hole for me. Getting something out fast that doesn't look like 1999
This is Danny here. I didn't expect this much traffic so I am sorting out the database connection issues. The server is overloaded. Sorry for the inconvenience!
Thanks for a great writeup, and fyi there's something up with your banner/header code on iOS - scrolling causes the header to drop down, slide up, drop down, again and again (typically 7-10 times)
My concern with both of these is that I'm slapping classes on all of my UI everywhere. Why can't a button just get all of the bootstrap btn styles automatically? Why not have forms look right just by selecting the elements that make them up? This is a problem for Foundation too. Does anyone know why they have chosen to do this?
Both Bootstrap and Foundation support using their styles with SASS mixins, so you can create your own semantic classes, rather than slapping their classes on your markup.
It seems fairly over-opinionated for the framework to declare every button as exactly the same. What if a developer needs one orange square button and one normal, greyish-silver boostrap button. If every class is automatically applied to each button, you're going to need to override the styling for that specific orange, square button.
That's how e.g. Bootstrap 2 worked. It sucked. Bootstrap 3 moved to opt-in styles and it is way better. If you really want all buttons to be BS-like you simply write (in Less -- I cba to look up the Sass but it's similarly trivial):
I quite frequently use Bootstrap but with almost all of it paired down to the absolute minimums. Bootstrap 3 (at least) was comprehensible and easy enough to whittle down by commenting out large swaths of UI. Usually, I simply use the Bootstrap grid since we have contracts who dance in and out of projects or new developers. Everyone can safely assume that they have "col-sm-" classes and know how they work.
I usually mimic bootstrap classes too like btn even if I can't recall the last time in the last 3+ years I've left any of its buttons/forms etc in tact.
It's a choice between opt-in and opt-out; sometimes you don't want the framework styles applied and you need a way to control that. The drawback to opt-out is that you may not control the markup where the styles shouldn't apply.
Having used both, I find that although Semantic UI has a lot more pluggable components, documentation on anything beyond simple examples and one sentence descriptions is severely lacking. Some components are just plain buggy, and the developer is not very fast at fixing them. It's got a lot of features but the lack of polish and development speed makes it hard to recommend for a larger team.
I think only having a single developer has had mixed effects on the project, which is a shame because it's so close to being great.
Meanwhile BS4 has solid built in components that are just documented enough to be usable despite not having as many. Issues get fixed quickly and it feels easier to follow its conventions. The JS APIs are simple enough as well, and the code behind it is much easier to follow than in Semantic UI.
Yes Semantic UI has come a long way and changed since I first used them 1-2 years ago. I have just tried it on a new project their annoying build process and lack of official SASS support the style and out of box components are really great.
Semantic UI looks the best, but once you start to do your own things, you end up fighting it. I'd love to see some of the stuff Semantic UI does just as an add-in/theme for Bootstrap (Forms are beautifull).
I created an app for a customer in it, and while it looks shiny, it would have been more cost-effective to just have used bootstrap.
I've been helping out a developer that has been building sites with Semantic UI and it's making my skin crawl.
It seems like a good start for prototyping and admin interfaces, but for anything else it just adds too much styling and classes that need to be overridden.
The name seems poorly choosen, since you're constantly adding classes that reference styling decisions making it everything but semantic (ui very wide, ui very thin, ui three column doubling grid, …).
Nobody should be using Photoshop nowadays to design a website. A competent web designer knows about html and css and - most importantly - has a good understanding for how a website behaves, especially regarding responsiveness and animations.
It is a good reason to leave the room / team / project when "design a website" means "open photoshop".
Not a fan of Photoshop, but people should be using whatever tools help them to build good products.
Maybe a simple canned marketing website can be worth skipping the planning phase, but good luck doing anything complex without some mocks. As a designer who can code, I usually skip the hi-fi mockup stage myself, but that's because I do it instead on paper.
So, I'm not a web designer or developer (anymore). But.. This strikes me as being the same line of though as "Leave the team when your new coding project starts with a whiteboard rather than text editor". Sure, we can just start coding, but the result is rarely as clean.
It's worse from a work perspective. Designers end up with multi-hundred MB PSD files where multiple people cannot work with the same document concurrently.
It does nothing to help their consistency, since you cannot define common styles to be reused.
And it has a trickle-down effect, where any developer working with the files now needs a license to open the document.
Wow an alpha version is recommended for production. What world are we living in?! :D
I tested BS4 but the alpha tag makes me too nervous to use it in production. Things will break and some things are still not there yet (talking about navigation in bs4).
Foundation 6.1 was worse than Bootstrap 4 Alpha. They are still cleaning up and completely changing things with 6.2 totally breaking your setup. Boostrap alpha is more stable than Foundation "stable".
To be fair, using an alpha version in production isn't always that rare. I mean, back when I used forum scripts like vBulletin, people ran alphas and betas and release candidates on live sites all the time. Were there sometimes issues? Sure, but a lot of the time, they worked fine.
And that's not even getting into games and online services, where 'beta' never ends and you end up paying for alphas and early betas of things all the time.
Do you know where I can find a compiled version of bootstrap 4? I am on boostrap 3, but am about to roll out a site in a few weeks, so I might as well put 4 on if it's that stable.
I prefer Foundation because I think the grid system is superior as suggested by the author and I think it's much easier to style in such a way that the site looks like your own. As many have pointed out, many 'Bootstrap' sites look like 'Bootstrap' sites. My biggest gripe about Foundation is that beyond Mad Mimi's Foundation 5 port there aren't as many high quality tools to use Angular with Foundation compared to all the Bootstrap Angular tools.
Foundation dropped it at V4. It's 3 years ago (https://github.com/zurb/foundation-sites/releases/tag/v4.0.0). I don't think that's the right time. Interestingly, as my own experience small business websites always asking for IE8 supports. They found their website doesn't work in their office's IE8!!!
Vendors like Zurb (or in-house team for their own company site) usually working on large projects and able to make every decision clearly and fixing any problem they facing. However, for most of developers, they can't afford the cost of it. While there's Boostrap exists, why do you put yourself into risky?
A lot of backend developers using Boostrap. They even don't understand basic CSS.
Problem is most (European, e.g. less donation-financed) non-profits have a cash flow fundamentally different to that of a company: Most of the budget comes from a foundation, the government etc. and is tied to a specific use.
So if the non-profit got funds for a specific project, they have e.g. full wages for 3 persons, much money for train tickets/renting of cars, food and accomodation, renting of kit, paying people like me for needed solutions, office rent and so on - but with fixed budgets for each! Stuff the non-profit could use after the funded project is finished (like modern computers, office inventory, cars) is much harder to get funded.
This setup is meant to prevent corruption, not save the foundation money. The foundation usually has no qualms to grant 10k for renting cars, but will refute 5k for buying a car.
In short, freely usable funds for upgrading IT equipment can be scarse even in well-financed non-profits.
What is the incentive with staying with IE? Do they anticipate that the app might one day be used outside of the non-profit and therefore can not be written for Firefox or chrome?
Sometimes switching to Firefox or Chrome works, sometimes not. The more technically literate orgs often don't use IE anyway. The problem are the technically illiterate people.
I'm wary to not inadvertently fall into the IT support role by advising not to use IE. If a bunch of really unskilled folks switch to Firefox because I say so, whom will they call if something doesn't quite work as before? :) I can (and do) say no to calls like these, but I'm always wary it taints the relationship a bit.
An approach that usually works if I explain the reasons beforehand is transparent pricing: The solution costs $x for all browsers incl. IE9+, or more if IE8 has to be supported. That way the argument is about the org being able to afford IE8, not about me being the picky geek.
I've been using it for about a year now, and have come to prefer it over bootstrap and foundation (it's grid system in particular). It's also well-documented, and has a clean/well-organized codebase.
Skeleton isn't a framework. It was a set of opinionated CSS styles and a basic grid built by one guy. It's been unmaintained for years but it still works fine. This is my favorite fork of it- https://github.com/whatsnewsaes/Skeleton-Sass
I am a big fan of creating my own framework, but I have used Foundation in the past due to their earlier adoption of SASS mixins. However, I am just now hearing of Foundation for Emails and that looks like could save a lot of headaches
IMO, Bootstrap v4 is much stronger than Foundation for many reasons. Here's one...
b4 has a much stronger "foundation." What do I mean by that? Well to be honest if you actually look at the HTML structure of both frameworks, you'll see that b4 is not only utilizing more modern techniques but that they have reduced and simplified their markup. ie, navigation items. b4 uses <div>'s for each nav element which allows for more control while foundation is using an older technique of unordered list items.
This is just one example of how b4 takes a more wholistic approach to every aspect of their framework. I don't fault foundation at all and it probably has to due with the talent of the core b4 team as well as the massive community that they have, but I can't see a use case where I'd choose foundation over b4.
