Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.

Which Responsive Design Framework Is Best? Of Course, It Depends.

In 2017, the question is not whether we should use a responsive design framework. Increasingly, we are using them. The question is which framework should we be using, and why, and whether we should use the whole framework or just parts of it.

Responsive Framework1

With dozens of responsive design frameworks available to download, many web developers appear to be unaware of any except for Bootstrap. Like most of web development, responsive design frameworks are not one-size-fits-all. Let’s compare the latest versions of Bootstrap, Foundation and UIkit for their similarities and differences.

Further Reading on SmashingMag: Link

Three years ago, I wrote an article for Smashing Magazine, “Responsive Design Frameworks: Just Because You Can, Should You?6” In the article, I argued that responsive design frameworks should be used by professionals under the right circumstances and for appropriate projects. Custom design still has its place, of course. However, a fully customized approach is not appropriate to every website, under every timeline, every budget and every set of browser support guidelines.

Since that time, the industry has evolved at its typical breakneck pace. Sass, the CSS preprocessor, has become standard to most workflows. We’re more accustomed to adjusting Sass variables to customize existing code. We confidently work with mixins, building our own styles. We’ve even got Sass formulas for generating color schemes7 that we can incorporate in our work.

Workflows themselves have become standard, making use of technologies such as Node.js, Bower, Grunt, Gulp, Git and more. Old browsers continue to fall away, allowing front-end developers to confidently use more features of HTML5 and CSS3, with fewer worries about significant cross-browser compatibility issues.

Revisiting the 131 comments on my 2014 article, I saw readers suggesting a number of approaches to making use of responsive design frameworks:

  • Some suggested using part of a framework with your own custom code.
  • Several developers plugged their own framework, either written from scratch or with code forked from another framework.
  • Several developers suggested frameworks that I did not cover, including Susy, Singularity, Breakpoint, UIkit, Pattern Lab, Toolkit, Pure, Cardinal, Skeleton, ResponsiveBP and many others.

All of these are legitimate approaches. Hundreds of frameworks are available. Many who have been in the business for some time have a favorite, whether it’s an established framework or one they’ve created.

However, increasingly, I see students, clients and web development firms defaulting to Bootstrap as their starting point, often with little critical evaluation of whether it’s an appropriate solution to the task at hand. Clients hire me for training in Bootstrap, for example, and then ask how they can add functionality that’s native to Foundation. When I ask, “Why not use Foundation?,” they tell me they’ve never heard of it and didn’t know there are options beyond Bootstrap for responsive design.

There is no way I could review the dozens, if not hundreds, of responsive design frameworks. However, given that Bootstrap is the 500-pound gorilla of responsive design, I’ve chosen two other frameworks to evaluate compared to Bootstrap8: Foundation9 and GetUIkit10. I’ve chosen these three frameworks based on the characteristics they share, in that they are full-service responsive design frameworks. They offer grid systems, SCSS with piles of variables and mixins for customizations, basic styling of nearly all HTML5 tags, prestyled components such as badges, labels and cards, and piles of JavaScript-based features such as dropdown menus, accordions, tabs, image galleries, image carousels and so much more. All three frameworks offer ways of reducing file sizes to just those styles and functionalities needed to work on a given website. They are all in active development.

Again, I am not suggesting that these are the only responsive design frameworks, nor am I implying that they are the best frameworks. These are, however, popular frameworks with piles of features out of the box, making them attractive to many development firms wanting to work with “Bootstrap or a close equivalent.”

Background Information Link

To start the discussion, let’s examine some of the basic background features of each framework.

Bootstrap 4 Foundation for Sites 6 UIkit 3
Current version, release date 4.0.0-alpha 6, released January 2017 6.3.0, released January 2017 3.00 beta 9, released February 2017
Owned by Originally developed at Twitter by Mark Otto and Jacob Thornton, now an open-source project ZURB, a web development company in Campbell, California YOOtheme, a WordPress and Joomla theme development company in Hamburg, Germany
Website Bootstrap11 Foundation12
Standard distribution package includes Required CSS (1 minified, 1 standard, both with .map files); required JavaScript (1 minified, 1 standard). Former theme is incorporated in Sass files, activated by variables. (Glyphicons are not distributed with Bootstrap 4.) Also contains two additional sets of CSS files (1 minified, 1 standard, both with .map files): bootstrap-grid, which appears to be a flexbox-based grid system, possibly redundant at this point; and bootstrap-reboot, based on normalize.css. A CDN is available for standard distribution files. Four distributions13: Complete, Essential, Custom, Sass. Complete version includes compiled CSS (minified and not), plus compiled JavaScript, including individual vendor files. Essential includes typography, grid, Reveal, and Interchange only. Custom can be customized on the website for downloading, and the developer can choose elements to include and change a few variables. The Sass version can only be downloaded using the command line, Foundation CLI or Yeti Launcher. A CDN is available for standard distribution files. Distribution includes a single minified CSS file, a single minified JavaScript file and 26 SVG graphics. LESS, CSS, and JavaScript source files are available via Bower or npm. A CDN is available for standard distribution files.
Additional JavaScript libraries required? Yes, you must download or link to a CDN separately: jQuery 3.1.1 Slim, Tether 1.4.0. Files are linked to just before end of body element. All dependencies are bundled in the distribution. jQuery is required, but it is part of the distribution. Files are linked to just before end of body element. All dependencies are bundled in the distribution. jQuery is required, but it is part of the distribution. Linking to files in the head is recommended.
Browser support Latest versions of: Chrome (macOS, Windows, iOS and Android), Safari (macOS and iOS), Firefox (macOS, Windows, Android, iOS) (latest version of Firefox plus Extended Support Release), Edge (Windows, Windows 10 Mobile), Opera (macOS, Windows), Android Browser & WebView 5.0+, Windows 10 Mobile, Internet Explorer 10+ Last two versions of Chrome, Firefox, Safari, Opera, mobile Safari, Internet Explorer mobile, as well as Internet Explorer 9+ and Android browser 2.3+ Latest versions of Chrome, Firefox, Opera, Edge, Safari 7.1+, Internet Explorer 10+, No mention of mobile-specific browsers
Internet Explorer support Internet Explorer 10 and higher (Bootstrap 3 recommended for Internet Explorer 8 and 9) Internet Explorer 9 and higher Internet Explorer 10 and higher
Other browser support notes “Unofficially, Bootstrap should look and behave well enough in Chromium and Chrome for Linux, Firefox for Linux, and Internet Explorer 9, though they are not officially supported.” (source14) “JavaScript: Our plugins use a number of handy ECMAScript 5 features that aren’t supported in IE8.” (source15)
License and copyright Code and documentation copyright (2011 to 2017) of the Bootstrap authors and Twitter, Inc. Code released under the MIT License. Docs released under Creative Commons. MIT license, no mention of copyright MIT license, copyright of YOOtheme GmbH
Build tools “Bootstrap uses Grunt for its CSS and JavaScript build system and Jekyll for the written documentation. Our Gruntfile includes convenient methods for working with the framework, including compiling code, running tests, and more.” (source16) To access Sass files17, you must install using the command line, the Node.js-powered Foundation CLI, or with its Yeti Launch application (Mac only). “Foundation is available on npm, Bower, Meteor, and Composer. The package includes all of the source SCSS and JavaScript files, as well as compiled CSS and JavaScript, in uncompressed and compressed flavors.” Other versions of Foundation are available as simple downloads without using these tools, but without SCSS files. Bower and npm. Offer a SublimeText plugin and an Atom plugin for working with UIkit 3 as well.

In general, all three frameworks are in active development (all were updated in January or February 2017) and are mobile-first. All generally have some type of CSS preprocessor. UIkit version 3 beta currently only offers LESS. It will offer a SCSS port, as it’s offered in previous versions of UIkit, in future releases.

Bootstrap transitioned from LESS to SCSS as part of its version 4 update. Foundation has always been written in SCSS, because ZURB is a Ruby on Rails shop, and Sass hails from the Ruby on Rails world.

There are notable differences with the build tools. Foundation is extremely picky about you using its workflow when working with the framework, if you wish to work with SCSS files. Unfortunately, Foundation offers few choices in tools. Bootstrap is much less picky about workflow, offering several options, including no workflow at all, even with its SCSS files. All frameworks offer at least one distribution ZIP file, containing all elements of the framework. Foundation offers a way to choose only certain elements in a download. Bootstrap 4 alpha and UIkit 3 beta do not offer this functionality currently, but they have previously offered this in older Bootstrap and UIkit versions. We can assume that once these frameworks reach their stable releases, this functionality will be offered as well.

Grid System Link

Each framework comes with a grid system, as one might expect. Bootstrap and Foundation’s grid systems include multiple breakpoints, nested grids, offsets and source ordering (i.e. changing the order of content on collapse). Exact breakpoint values vary, but the breakpoints are generally customizable with SCSS. UIkit’s grid is radically different and is described below.

With the most recent alpha 6 release, Bootstrap features a flexbox-based grid system by default. (This is partly the reason for its Internet Explorer 10+ browser support.) By default, Foundation features a floated grid system (which helps, in part, with its Internet Explorer 9+ support). Optionally in Foundation, you can compile a flexbox-based grid system by toggling an appropriate Sass variable and recompiling to CSS. Foundation notes that flexbox is not supported in Internet Explorer 9, so keep this in mind if this is a target browser for you.

Foundation offers a few more grid features than Bootstrap, including centered columns, incomplete rows, responsive gutters, semantic grid options and fluid rows.

Equal-height columns are a common problem when working with float-based grid systems. Foundation includes a JavaScript component named Equalizer. Because UIkit and Bootstrap are based on flexbox and not floats, equal-height columns are built into the grid system and are never an issue.

UIkit has a very different grid than Foundation and Bootstrap. Rather than a standard 12-column system, UIkit has broken its layouts into three components: grid, flex and width. Starting with the grid component20, you can create as many columns as you wish:

To create the grid container, add the uk-grid attribute to a <div> element. There’s no need to add a class. Add child <div> elements to create the cells. By default, all grid cells are stacked. To place them side by side, add one of the classes from the Width component. Using uk-child-width-expand will automatically apply equal width to items, regardless of how many there are.

As implied in the documentation, grid sets up the boxes that might be next to each other in some layouts, while width determines the width of those boxes, and flex determines the layout within each box, using flexbox properties. Finally, unlike other grid systems, UIkit offers a border between grid columns.

Foundation's equalizer demonstrated.21
Foundation’s equalizer is designed to create equal-height columns. (Image: Foundation Docs22) (View large version23)

CSS And Default Styling Link

All three frameworks come with some level of CSS styling. The styling can be changed through an overriding style sheet or by modifying the provided SCSS or LESS preprocessor files. Generally speaking, basic styling is provided for all, or nearly all, HTML5 elements. All frameworks provide some quantity of utility classes, generally used for printing, responsiveness and the visibility of elements. Foundation and UIkit offer right-to-left support for languages written in that direction. UIkit states that it will feature a RTL version and the option to compile UIkit with a custom prefix.

It is unclear from its documentation whether Bootstrap 4 is offering RTL support, but it has been available in previous versions. It seems like this might be part of a future stable release26. There is much interest in including this feature in the Bootstrap community.

The framework with the least out-of-the-box styling is Foundation. This framework has long assumed that its users are more advanced developers who will want to write their own styling for their projects. Therefore, ZURB has always provided less styling out of the box by design, meaning there will be fewer styles to override later.

UIkit offers two color options, accessible via the Inverse component. They include the standard scheme (light backgrounds and dark text) and a contrast scheme (dark backgrounds and light text). UIkit also offers some unique styled components, such as Articles and Comments, as well as Placeholder, which provides an empty space for drag-and-drop file-uploading interfaces. If you recall YOOtheme’s WordPress and Joomla theming roots, these features make perfect sense. Neither Bootstrap nor Foundation includes this styling specific to content management systems, so this is a distinguishing characteristic of the framework.

UIkit's comment styling.27
UIkit offers comment styling out of the box, one of its unique styling features. (Image: UIkit Docs28) (View large version29)

Bootstrap offers much more than Foundation. Indeed, Bootstrap’s distinctive look has permeated websites for several years. Bootstrap 4 has a similar look to Bootstrap 3. Bootstrap still offers several colors, such as “warning,” “danger,” “primary,” “info” and “success,” and it typically offers a few variations on styling certain HTML elements, such as tables and forms.

It’s also worth comparing the CSS units in each framework. Bootstrap 4 uses rem as its primary CSS unit throughout. However, it states, “pixels are still used for media queries and grid behavior as viewports are not affected by type size.” Bootstrap also increased its base font size from 14 pixels in version 3 to 16 pixels in version 4.

Foundation says30, “We use the rem unit nearly everywhere in Foundation, and even wrote a Sass function to make it a little easier. The rem-calc() function can take one or more pixel values and convert them to proper rem values.”

Finally, UIkit seems to use pixels as a primary size unit, although occasionally uses percentages and rems in a few places in its LESS files. Its CSS size philosophy is not addressed in its documentation.

All three frameworks ship with responsive navigation elements. All include some fairly common navigation components, like formatted breadcrumbs, tabs, accordions and pagination. There are minor variations between these, but they all typically work as expected.

All three frameworks ship with dropdown menus. In general, these dropdowns may be used in several scenarios: with standard responsive navbars, with tabs, with buttons, etc. All three include vertical dropdowns. Foundation and UIkit also include horizontal dropdowns, in which the dropdown is displayed as a row rather than a column.

Navigation bars are present in all three frameworks. Each navbar can accommodate website branding and search and can be made sticky, and elements can be aligned left or right in the bar. All navigation bars collapse, but they may present collapsed content differently (some via a hamburger button plus a dropdown, some via an off-canvas menu). The navigation bars also have a few differences among themselves.

Bootstrap's nav demonstrated.31
Bootstrap’s iconic navigation bar now comes with easy color options by combining class names, or an inline color option. (Image: Bootstrap Docs32) (View large version33)

Bootstrap offers some basic horizontal and vertical navigation bars with different styling options (tabs, pills, stacked pills, justified or plain styling). It offers a separate horizontal responsive navigation bar, which creates a hamburger button on collapse. Two color schemes are available, with colors and breakpoints customizable through SCSS.

Foundation had a responsive navigation bar in previous versions similar to Bootstrap’s. In version 6, it has turned several navigation bar treatments into individual elements that can be combined. For example, on collapse, the navigation may be hidden behind a hamburger button, behind an off-canvas treatment or behind a drilldown menu, in which the user loads screens of menu items. These types of navigation treatment may be changed at specific screen sizes. For example, the full navigation bar may be available at desktop dimensions but switch to a drilldown for mobile.

UIkit’s bar offers functionality similar to Bootstrap’s. By default, it does not have a built-in toggle, but this is easily added with the appropriate CSS classes and JavaScript. Collapsed content is typically behind a hamburger button, and it may be coupled with off-canvas functionality. UIkit also specifically offers an icon-based navigation bar (iconbar). It ships with 26 SVG icons, which can be integrated in this bar, with the promise of more icons in the future.

JavaScript Components Link

All three frameworks depend on jQuery for their JavaScript-based components. Foundation and UIkit ship with a copy of jQuery, while Bootstrap relies on connecting to jQuery via a CDN or a download.

All three frameworks contain similar types of functionality: tooltips, modal windows, accordions, tabs, dropdown menus, image carousels, etc.

Foundation has two handy components that set it apart. One is Abide, a full-featured HTML5 form-validation library. It can handle client-side error-checking of forms. The other is Interchange, a JavaScript-based responsive image loader. It’s compatible with images and with bits of HTML and text. It loads the appropriate content on the page based on media queries. Despite the fact that one of the defining characteristics of responsive design is images that resize, neither Bootstrap nor UIkit offers similar functionality.

UIkit combines its styles and JavaScript components in its documentation, calling it all “components.” Some of the unique JavaScript-based components currently available in its beta release include Scroll, which allows smooth scrolling to other parts of the web page, and Sortable, which enables drag-and-drop grids on the page.

In future versions of UIkit34, we are promised many components from UIkit 2, including “Slideshow, Slider, Slideset, Parallax, Nestable, Lightbox, Dynamic Grid, HTML editor, Date- and Timepicker components.” It’s worth highlighting HTML Editor, and the Date- and Timepicker components, because these are typically used in administrative interfaces and in applications. Remember that YOOtheme creates Joomla and WordPress themes as part of its business, so these are important components for it. Neither Foundation nor Bootstrap includes these admin-friendly widgets, so this is a distinguishing characteristic of this framework.

One of UIkit’s most distinguishing JavaScript features35, however, is this:

UIkit is listening for DOM manipulations and will automatically initialize, connect and disconnect components as they are inserted or removed from the DOM. That way it can easily be used with JavaScript frameworks like Vue.js and React.

So, Which Is Best? Link

It depends! All three projects are actively maintained and have devoted followers. In the end, the right framework for you will depend on your project’s requirements, where you need help in programming (making it pretty? coding functionality?) and your personal coding philosophy (rems versus pixels? LESS versus Sass?). As with all technology, there is no perfect choice, and you will have to make compromises on features, functionality and code styles.

With this in mind, here are some points to weigh in making your decision.

  • Browser support
    The framework versions reviewed here support similar browsers. However, going back one framework version, or following the instructions for incorporating polyfills, might increase support for important browsers. In particular, if you need Internet Explorer 8 support, you might want to look at Bootstrap 3.
  • CSS unit differences
    Foundation keeps nearly all of its units in ems and rems. Bootstrap uses mostly ems and rems, with pixels for media queries. UIkit uses mostly pixel measurements. Some developers have strong opinions about these approaches and might choose a framework based on them.
  • Quantity of styling
    UIkit has a lot of out-of-the box styling. Foundation has much less. Bootstrap is somewhere in between. How much styling do you need to override? How much styling do you want to be present already? Do you want to write very little or none?
  • CSS preprocessors
    Foundation was written in SCSS natively. Bootstrap had a port from LESS to SCSS in version 3, then rewrote its SCSS in version 4. UIkit continues to work in LESS while in beta, but it will offer a SCSS port in future releases. This could also affect your choice of framework.
  • Workflow
    If you wish to modify SCSS files, know that Foundation will lock you into a fairly rigid workflow. Bootstrap and UIkit offer a workflow, but you can choose a different workflow or no workflow at all.
  • JavaScript components
    Foundation offers form validation and responsive content management. UIkit is specifically built to work with reactive JavaScript frameworks, and it includes components for building an admin interface. Depending on the components you require, this could sway your decision.
  • Grid differences
    Bootstrap and Foundation offer 12-column grids. UIkit offers a very different approach to grid layout, with very different styling. Foundation’s grid can easily be modified to greater or fewer columns with SCSS, and it can be made semantic as well. Grids for UIkit and Bootstrap are flexbox-based by default, while Foundation’s are float-based, but convertible to flexbox through SCSS.

(da, al, il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35

↑ Back to top Tweet itShare on Facebook

For more than seventeen years, Jen Kramer has been educating clients, colleagues, friends and graduate students about the meaning of a "quality website." Since 2000, she has built websites that are supportive of business and marketing goals in a freelance capacity and as part of an agency.

Jen is a Lecturer at Harvard University Extension School in the Master's of Liberal Arts in Digital Media Design, teaching five courses per year, advising students, and assisting in curriculum design.

Jen is also a prolific video author, creating 27 training courses for, O'Reilly Media, and Aquent Gymnasium.

She is also available for individual private tutoring, customized classroom training, and occasional freelance web design work.

Jen earned a BS in biology at University of North Carolina at Chapel Hill and an MS in Internet Strategy Management at the Marlboro College Graduate School.

  1. 1

    Michał Sadowski

    March 20, 2017 11:57 am

    It’s 2017 and the question whether we should use responsive framework is more important than ever. Seriously.
    If you are a designer, now you have actual css grid (with some polyfilling needed), mixed with flexbox can give you a hand-crafted, actually flexible layout in no time. If you are a back-end developer who was forced to work with the front end? Well, go ahead and use bootstrap or whatever, it doesn’t matter. From my experience you won’t read the documentation anyway and you’ll get a layout breaking apart everywhere because you incorrectly set classes/structure/whatever.

    • 2

      This was about to me my comment as well. These overly opinionated frameworks have far more going against them than for them.

    • 3

      Thanks for the comment.

      We in the tech community need to be more aware of the Pareto Principle, or the 80/20 rule.

      What you say is absolutely correct. You, as an experienced front-end developer, have no issue piecing together your own code, or bits of other people’s code. You know exactly what’s supported by which browsers off the top of your head, and if you’re not sure, you know exactly where to look to find out or how to build in browser support automatically.

      You are the 20% working in this field. This article isn’t talking to you.

      The other 80% are people from a variety of backgrounds, but they’re not spending 40 hours per week writing HTML, CSS, and Sass, let alone JavaScript. They may not even write front-end code every week. There are professional web developers who work for companies where the website is a communications tool, not the focus of the whole company. These developers are much less up to date with the latest spec. They may only redesign their site every other year — or every 5 years. They work in government, at universities, even at large corporations. They have bosses that tell them what technologies to use, or tell them that technologies must be documented and reusable, from “proven sources”.

      These developers, as well as those in the back-end communities, are target audiences for responsive design frameworks. There are a lot of these developers out there.

      They need to assemble something in a hurry, and they don’t want to spend a huge amount of time (a) learning something new, (b) configuring the latest workflow, (c) worrying about browser compatibility and testing, and (d) documenting what they build.

      Finally, when you make sweeping statements like “you won’t read the docs anyway” and “you’ll break everything”, you discourage many people entering the field, because they don’t have your background and years of experience. Be kind, understanding, and take the time to educate and encourage the new people in the field.

      • 4

        Bram Smulders

        March 20, 2017 5:00 pm

        Isn’t this something you should’ve explained in the article? In the first paragraph you clearly state “In 2017, the question is not whether we should use a responsive design framework” implying that everyone should and is using a framework.

        Let’s say a newcomer in our field is visiting smashing magazine and reads this article. He is pressed on his heart that using a framework is advised, and starts learning the framework. He is learning the framework, not the eastethics of the web and thus missing all information about why and how things are implemented. In my opinion this is basic and vital information for a newcomer to understand the web platform and by that make the decision on wether the project he is working on even “needs” the framework.

        Also I’m very curious about where the 20/80 devision lies in our field, do you have any stats on that? In my direct environment(work, front-end gatherings, friends, workshops, conferences, etc.) more people are working without a design framework than with a framework.

        Side note: i think the word framework as used in this article and the start of my reaction is wrong. In my eyes Foundation & Bootstrap like projects should be called UI-toolkits.

        I agree there are use cases for frameworks, there are use cases for UI-toolkits & there are use cases for custom implementations. But in my eyes this article is coming across biased and makes unfunded assumptions.

        • 5

          @Bram Smulders

          Jen is totally right, while you’re a front-end developer, I’m a backend developer, and I don’t have time to learn absolutely everything with CSS / SASS and Javascript. UI-Toolkits are an absolute MUST when shipping products fast, and that’s what counts, not creating your own custom CSS framework and layout.

          That’s like saying, hey there’s already design patterns for code, why aren’t you creating your own custom framework?

          The answer: time-consuming.

          It makes no sense to take something that’s maintained by thousands of individuals (for FREE mind you), and then say, nah, I’ll code something myself which will take way longer.

          • 6

            Bram Smulders

            March 20, 2017 7:39 pm

            Oh hey, I don’t recall myself saying that using a UI-toolkit is wrong. I never go against the arguments of Jen, and actually I agree with her comment. There are reasons for using a toolkit; like the reason you have.

            But I’m against the tone of the article saying that everyone should use a toolkit. And I’m curious for the statistics of the 20/80 “rule”. It is quite the thing to “prove” something with unfunded statistics.

          • 7

            I’m very curious about where the 20/80 devision lies in our field, do you have any stats on that?

            @bram an individual such as yourself with exhaustive amounts of knowledge should be quite familiar with the Pareto principle. I’m sure you temporarily forgot about it.

        • 8

          Even for front end developer, you wanna say that it’s better to reinvent the wheel? To write a grid system from scratch for each project? Sure, just tell me what the point? What’s the benefits? Person working on the project fter you instead of reading proper docs, should dig in to pickup your code, and learn your semantics? Bringing some code-semantics standard to the project using framework isn’t good? You haven’t said the reason why not to use a framework, you don’t have to be a genius to write grid in css, but why?
          And no, those are not ui toolkits, they are frameworks. And name “framework” is actual terminology used, not only in this article. Im not sure if you came from mars, or you just finished your css course, but whole your comment is a bounch of bs.
          To sum it up, i completely agree that “In 2017, the question is not whether we should use a responsive design framework”, and have nothing to do with knowing to write your own css grid or not, but with productivity, semantics, standard… Main problem is that noobs learn a bit of css and they think they are geniuses and even questioning terminology…

          • 9

            Bram Smulders

            March 20, 2017 9:33 pm

            Do you even read? I never say that i’m against the use of UI-Toolkits. I’m saying that there is a use case for UI-toolkits, the same as there is a use case for not using a toolkit. Every solution has it’s pro’s and cons.

            The problem I have with this article is that it is implying that everyone should be using UI-toolkits. That is simple not advisable. You need to check on a project by project base if you want to use one or not(a bit exaggerated, in real life “it depends”):

            Fast time to production, a lot of generic UI-components? Use a UI-Toolkit.

            Long running projects, lots of A-B tests, challenging/unique UI, performance, control? Make things custom.

            And i’m not even talking about the bloat & complexity these UI-toolkits pose when you need to override something.

            Harry Roberts is explaining things in a really good way: What is a CSS framework anyway and even points out why he thinks the term “framework” is misused.

            But why would I think you would watch this talk from a “noob who learns a bit of css and think he is a genius and even question terminology”.

          • 10

            @Bram Smulders
            Nope, I’m not watching anything related to “ui-toolkits”, and not interested in discussing anything related to made up terminology.

          • 11

            James Saunders

            March 21, 2017 11:25 pm

            We front-end developers don’t re-invent the wheel. You really think we write all our stuff from scratch? We have already written our own grid system over the years. The same as we have already written our own navigation, tab, accordion, etc. HTML/CSS/JS components/patterns. We collected these code snippets in a library system already long before there were frameworks, so that we didn’t had to write them from scratch. We add our components with a few clicks into our HTML when we need it instead of loading the whole shabang of a framework and fiddle with classes (we use the cascade and inheritance in our stylesheets properly).
            No… I will not need a framework in 2017!

          • 12

            @James Saunders
            So what you saying is that you are using code and coding standard from years ago? Is that what you are doing sir “we front-end developers”? In 2017?
            To be honest, you and the other guy (if not the same) seem like a noobs with some html/css course done, trying to make ur self look good in comments but you just been lame.

          • 13

            James Saunders

            March 29, 2017 1:53 am

            @Ivan – Nope, you just don’t get it!

      • 14

        Michał Sadowski

        March 21, 2017 12:53 pm

        Yeah, you’re right, I’m just probably unnecessarily angry at people I work with and the statement was a sweeping overstatement and a hurtful generalization. Sorry. But every single time I got a CSS framework based page made by a back end developer I had to redo almost completely to mach it to the specs.
        But, truth be told, I’m not really sure that the learning curve for frameworks is that much better than pure css. Say, if you use bootstrap, you need to remember to learn classes for the grid system and understand how they work, you need to remember the exact html structure to get a decent-looking form field and so on and so on.
        I work 40 hours a week with css, I made some bigger projects based on bootstrap and I still have to keep documentation open while working with it. It’s just not some holy grail for people who need something simple. Most layout problems can be resolved with simple flex, margin:auto and max-width. Maybe that’s what we need — a simple “framework” — a documentation on the most common ways of creating a layout.

        Once again, sorry for the harsh statements, but I still can’t agree that the question is not whether we should use a framework.

        • 15

          Hey Michał — there is no need to apologize. I feel your frustration, too.

          In my courses at Harvard Extension, I teach students CSS from the ground up. Only after they learn custom responsive design and Sass do I introduce responsive design frameworks. Once they know CSS, they can read the docs and understand what’s happening. They can make informed choices about which is a better approach in which situation. They also learn to read and understand Other People’s Code. That’s why I incorporate them in the curriculum.

          When I got started in this field 17 years ago, the debated question was, “We have Macromedia Dreamweaver writing all of this HTML for us. Why do we need to learn to code?” My argument then was that DW was a great productivity tool, but it was no substitute for learning HTML. (CSS wasn’t supported by browsers then.) Responsive frameworks are in somewhat of the same place today. They can be a productivity tool, but they are often used as a crutch by those who don’t know HTML and CSS in enough depth.

          In my experience, there are two big challenges that these inexperienced coders are trying to solve. One, they don’t have any sense of design, and the framework offers something that looks reasonable. (A later commenter talks about frameworks killing branding — I hear you!)

          The second is that layout isn’t easy to master. It takes a while to really understand how floats work — and as we move to Flexbox and Grid, it will take some time to understand them too. It’s easy to understand color: red. It’s hard to remember that if you float, you must also clear, when it seems like floats are inconsistent in their behavior. (They aren’t inconsistent, of course, if you understand what’s happening.)

          To quote myself from the above article, “Custom design still has its place, of course. However, a fully customized approach is not appropriate to every website, under every timeline, every budget and every set of browser support guidelines.” (I talked more about these issues in my previous article:

          I’m glad custom works for you, though. Good luck in your work!

      • 16

        James Saunders

        March 21, 2017 10:48 pm

        Sorry, but your example has nothing to do with the Pareto Principle.

      • 17

        This is spot on. I have quite a few designer/artist/developer/marketing specialist friends here in Seattle who fit exactly what you are talking about with the 80/20 rule. Most of my friends are the 80. We are expected to dabble in and understand web development while wearing many other hats. These frameworks are great for that. Well said and great article, cheers! m/

    • 18

      Pierre Balian

      March 20, 2017 5:46 pm

      You will constantly see people shitting all over design frameworks, bitching about the the overhead, base styles, etc. but the fact of the matter is that using a framework allows you to rapidly build and prototype designs, as well creates some “standardization” of code as it pertains to layout. If you know bootstrap you can jump into anybodies bootstrap based project, look at the code and instantly know what everything is doing.

      Be as much of a code snob as you want – but frameworks aren’t going anywhere anytime soon.

  2. 19

    Thank you for this article, it’s a nice comparison.
    However, I think it’s not fair to have included in the comparison Bootstrap v4 that is still an alpha version, meaning that when the beta and the final version will be realised there will be breaking changes.
    Also, the v4 development seems to be not so active, the first alpha of v4 has been released almost 2 years ago (19 Aug 2015 ) and still no beta is available, and that is a huge timeframe considering the evolution change of front-end techs.
    There’s a lot of fuss about Bootstrap v4, but since it’s way far from a stable version it’s only good for experiments, not for serious development in production (what about the support of broken changes?).
    Probably you wanted to make a comparison between these frameworks based on their main features, anyway I think you shouldn’t have considered an unstable framework.

    Just my 2 cents.

    • 20

      Fair enough. However, I imagine if I compared Bootstrap 3, UIkit 2, and Foundation 6, I’d get a similar comment asking me why I’m not using the latest versions of everything.

  3. 23

    Hi Jen,
    Thanks for the writeup! This is a great overview of all of these frameworks! I’m the lead on the Foundation project, and want to follow up with a couple of notes, as well as to offer to answer any questions you or others may have.

    First off, on the workflow front – Both the CSS and SCSS version of Foundation is easily installable in any workflow – there are packages for npm, bower, rubygems, nuget, and others. We *do* offer a particular stack (the ZURB stack) that has the workflow that ZURB uses in house for client projects, however it is by no means required, and there are folks using Foundation across many many different environments. We definitely need to get better at explaining how to do this in the documentation, but if you or others would like help getting Foundation working in your workflow don’t hesitate to reach out.

    Looking forward, we really see responsive components as the future. In Foundation 6.3 we added some amazing new responsive components in, a responsive tabs/accordion, cards, and a fully re-worked off-canvas joined the responsive navigation and responsive menu. We’re also super excited about the possibilities in this area opened up by CSS Grid, to create components that can totally restructure themselves to optimize for every screen.

    Thanks again, and happy to answer any questions about Foundation.

    • 24

      Hey Kevin — thanks so much for jumping in here. I have met several on the Zurb team, but I don’t think we’ve met before.

      I am glad to hear you’re supporting lots of workflows. I had a very bad experience with this last year while teaching, and it’s the reason I didn’t include Foundation in my course this year. Students had to do a ton of command line stuff to get Foundation running… and students plus command line just equals chaos, tech support nightmares, and lots of tears. I don’t recommend it. I’d love to see the docs clarified about this. If you want someone to review it, please let me know. I’d be happy to read whatever you’ve prepped and give you feedback.

      I’ve been a Foundation fan for a while (among other frameworks), and it’s always great to see how you’re doing.

      • 25

        I download Foundation from GitHub and pop it into my project folder. Am I missing something here as to what benefit there is of using the command line, Yeti Launch etc? I use Prepros to compile SCSS and JS generally but have been learning Gulp lately and haven’t needed to change that part of my workflow.

        • 26

          I think using Prepros or CodeKit (Mac Only) is fine as long as you enable autoprefixer. There are advantages to using the Gulp based (command line) build process, specifically the ZURB Template, but there are many ways to use the framework.

          The ZURB Template adds livereload, a static site gen (similar to assemble) which supports partials, conditionals based on pages, data that can be loaded via YAML front matter (at the top of your files), a series of specific helpers to build prototypes (repeat blocks), a production build process, and a styleguide generator that makes it super simple to have code example pairs.

          Alternatively, at its simplest form you can just include the CSS and JS file from a CDN. This is just to get started.

          Eventually you might use a tool like Prepros or CodeKit to gain access to the power of Sass/Scss. If you are working with the framework a lot across a lot of projects (like an agency) soon you will find that the features in the ZURB Template really speed your workflow. If used properly your front-end code can much more closely resemble the back-end implementation.

      • 27

        Great article. Somewhat off-topic but feel compelled to respond to what Kevin from ZURB even points out, the need for improved documentation. As someone who is relatively new to web development, I can only imagine how many other aspiring web devs have also wasted hours and hours on poorly written, unintuitive documentation that seems to have been made for developers that already know how to use and deploy the framework. I can only hope that framework authors view the structure and content of their documentation as important as the structure and content of their packaged workflows.

        • 28

          This issue of documentation is not exclusive to ZURB Foundation, but really is an issue with all of the frameworks discussed above. There are many ways to use a framework, from just including it via a CDN, to using a CSS preprocessor such as Sass/Scss/Less or otherwise.

          Furthermore, there is a bunch of tooling that has become popular on the front-end, such as grunt and gulp. So you have these much more complicated systems that are often advocated as the way to work with the framework (grunt or gulp). Sometimes that is the best solution. Sometimes you can get by with a simpler solution.

          For example, for most of these frameworks, you can just use the CSS if you decide not to use any of the JavaScript based components (interactive things like tabs, accordions, modals, etc.)

          In other cases there are bolt on alternatives to the jQuery. These are 3rd party and cater to a JS framework such as Angular.

          And then you have 3rd party platform integrations of these frameworks. For say WordPress, Drupal, etc. This list can be large.

          I think there are some great tutorials online to get started with the basics. Include the framework and start plunking down components. There are also more advanced tutorials that make an assumption (as do many of the 3rd party integrations) that you know what a lot of this front-end tooling is, and how it works, and already have it set up.

  4. 29

    I am a designer and also love to develop stuff, both front- and backend. I’ve been using both UIkit and Bootstrap a lot in the last few years, because when I’m using these frameworks I know I at least have a ‘stable base’ for my project.

    In most cases I love using UIkit. The flexibility, simplicity, and quality of coding is superb. It’s also the ‘prettiest’ right out of the box, especially v3. (But that’s just my opinion, of course.) It’s also really fast, since the creators chose to make ‘heavier’ things like date-pickers and parallax optional, so that code is only there if you choose to include it. Since my clients love using CMSs like WP, UIkit is also a perfect fit for that.

    Some (bigger) clients ask me to use Bootstrap specifically, since their own developers use it as well. So it’s more universal, I guess. The best thing about Bootstrap is that there’s a LOT available for it (themes, code snippets, topics on stackoverflow haha, you name it) which enables me to create things quickly.

    I haven’t really used Foundation, but ZURB makes Fantastic products in general – so I’m sure Foundation is great too. :)

    Say whatever you want about frontend frameworks – All I can say is, I’m just really happy they exist!

  5. 30

    William Nilliams

    March 20, 2017 8:59 pm

    In my experience, you can have a site that:

    is quick to prototype/develop
    looks good
    has clean, efficient code

    Choose two. No one denies that a framework introduces a slight learning curve and some unwanted overhead to a project, but it’s ultimately the time savings that makes a framework worth using. A framework also enforces a degree of consistency among your components, which is an added plus.

  6. 31

    Thanks Jen nice article.
    I just wanna know what would you recommend to make very customized websites?
    I ask because the feeling is that the top frameworks offer too much features you don’t need, which translates to heavy load on websites.
    I don’t feel confident with the usage of js tools like uncss or purify mostly because you need to know how to configure those tools really well to not get into problems with your final styles.
    So what do you think? Nowadays there’s still space for minimal frameworks like skeleton or pure that can be relevant as bootstrap or UIKit? Thanks again

    • 32

      Alejandro, there’s no one answer for everything.

      I would consider the following questions:

      1. What do you need help with, in terms of writing code from scratch? It sounds like you’re not much of a JavaScript guy, so maybe there’s a framework here that might help you — even starting with jQuery. Some people aren’t good at CSS layouts. Some people can code anything, but they can’t pick two matching colors.

      One of the advantages of these “heavier” frameworks is that they come with a ton of stuff that’s all guaranteed to work together. If you have concerns about taking a grid from here, an image carousel from there, and making it all talk to each other, one of the frameworks here is a good choice.

      Other people have plenty of experience, and making things work together isn’t an issue.

      2. What do you need documented? Think about the maintenance and hand-off of whatever you make. Who will be in charge of keeping it up to date? What is the maintainer’s skillset? What’s easiest for them? Even if the answer is you’re the maintenance person, you should be documenting your own work. (One day, you will revisit a site featuring your older work, and you won’t remember what you did or why — if it hasn’t happened to you already!)

      3. What kind of content are you working with? There’s a whole UX process that should happen before you start picking your coding toolkit, so make sure you have a good idea of what you need to produce. This will help you identify areas where you’ll need help as well (back to question 1).

      4. What browsers do you need to support? (Maybe this should be question #1, as this potentially could limit your toolkit!)

      5. If you build a site with your chosen technology, and when you redesign the site in 2-3 years, you discover the technology you used the first time has disappeared, would that be a tragedy for you? Would you be able to find a replacement?

      This speaks to the stability of some of the products. We all love open source, but projects do tend to come and go. The larger projects have greater stability. I expect Bootstrap will be just fine in 2-3 years, but I’m not sure about Joe’s Responsive Design Framework and Tire Emporium. (Maybe that’s not a thing, but it should be.) If stability is important, then you should look to the better known products, rather than those that are new releases or don’t have a huge following.

      I’m sure there’s more considerations, but these are the big ones that come to mind quickly. Good luck in your work.

  7. 33

    Matthew Trow

    March 20, 2017 9:15 pm

    Great writeup! – useful to see some well researched comparisons.

    The debate will always rage on over css frameworks, largely because many often miss the leverage points they offer.

    For the experienced CSS developer, they are an exceptionally useful reference or starting point. You can lift parts of a framework for use within your own. You can use the same design patterns to create extensions or entire new ‘modules’.

    For less experienced developers, it’s difficult to pick through the history of why they came into being in the first place – and it’s easy to dismiss the many lessons learned by those who work to maintain and develop these frameworks.

    For backend developers, frameworks *can* be useful, but I’d exercise caution in the belief those who don’t do frontend code can just roll their own websites – a frontend dev will still be required to document project specific code snippets or cast an eye over the potential soup that can result.

    For designers, frameworks are a great way to prototype – but again, an experience frontend dev is very useful.

    Finally, frameworks are fantastic for quite prototypes – and often, the resulting HTML code that created those HTML prototypes can be used as production code.

    It’s all about Leverage.

  8. 35

    Sebastián Zahn

    March 20, 2017 10:20 pm

    I´ve been using UIkit for some time, i love it! And since the v3 version i love it more! :) It´s light, modular, simple to adapt to your design and structure ( crucial point to me ), powerful but lightweight, clean and neat. I use it with less, totally customizable, excellent.

    Well, about the arguments with pro and cons to use a framework, frameworks are not an excuse for not learning html css and js, you should learn it and get better in every way! You have to know what you are doing.
    In my case, i get better in css with this frameworks because i see diferent practices, and learn less too, to better structure a project and be more efficient in time and code.

    In short, it is great to have this kind of frameworks, they are a great tool that gives us a hand to carry out the projects. I doubt that there are strong arguments for not using them (depending on each case of course, generally speaking).

    Those who do not want to use it, go ahead, you are free to use or not to use what you want, enjoy …

    Very good article, thanks!

  9. 36

    Antonio Balderas

    March 20, 2017 10:30 pm

    There’s nothing wrong about using frameworks at the end if you don’t use bootstrap or foundation you still need your own internal stater kit to avoid wasting time rewriting the same code for every new project. And another reason why we use frameworks is because this is a business and everything that saves you money and time is very welcome!

  10. 37

    As a UI/UX Specialist I rally against the use of frameworks for enterprise level applications. I mirror some of the comments above that developers misuse frameworks, especially when it comes to responsive, so much so that I usually have to rework all of the HTML in order to get a baseline architecture working. Its time and effort spent foolishly.

    If a framework like Bootstrap is used correctly from the onset of a project then it can save a lot of time and effort and developer learning curves down the road. I don’t see a problem with small to mid-level styling efforts using a framework. They can only afford to hire generalist full-stack developers, maybe the company gets lucky and finds a unicorn that can excel in the full stack, but its a very rare find.

    For enterprise level efforts, put the frameworks in the trashcan please because…

    frameworks kill brands!

    Most enterprise efforts have the resources to bring in UI/UX specialist to roll a custom styling architecture. It produces a more unique brand and experience. Throw in a pattern library and the developers have less of a chance to “get off the rails” as they would with an open framework.

    On a side note, frameworks produce so much HTML class selector bloat (I am looking at you specifically Material Design) that it becomes very hard to read the HTML code. By dropping frameworks and brining the class selectors back into the CSS the HTML class selectors are reduced to a minimum. The HTML code can breath again.

    So to cap, if you are a full-stack developer shop you basically have no choice but to go with frameworks… please use them properly… ESPECIALLY for responsive. If you are a larger corp developing an enterprise level solution spend the dough and get a UI/UX specialist on the payroll, it will pay off in spades.

    • 38

      Sebastián Zahn

      March 21, 2017 7:01 pm

      If you gonna talk about Brand killers, maybe you should fire first against WordPress , and the 5 minute website online working with some cheap or free template, and of course templates used thousand of times for distincts kind of projects but with the same look…

      Sorry, i don’t agree, a good framework helps you to make real a project, an idea, a purpose, but if you don’t have one you will see a lot of projects looking the same, Bootstraped, but this is not because of Bootstrap, is due to a lack of effort.
      Of course I respect your way of thinking, and if it works for you, I’m glad for it.

      • 39

        Andrew Beevers

        March 22, 2017 1:46 pm

        Fair comment, but there comes a point where the effort expended in overriding a framework is greater than the effort required to simply just build what you need.
        Where precisely that point is depends on the project and the people working on it.

        • 40

          Sebastián Zahn

          March 22, 2017 11:01 pm

          Agree! The framework should work for you, not against you… if you fight with it, it´s not the right choice. In this point play several factors, but the truth is that there are no frameworks that apply for 100% of the cases.

  11. 41

    Roll your own framework if you can. It’s the best scenario.

  12. 42

    UIKit is just awesome. I’m web designer. As a web designer I work with all type of css framework (such as bootstrap, foundation, blueprint etc) and i love them all. But if you say which is best so i tell you UIKit. There are many reason to say it is best. Who don’t use it he don’t know how smoothly work it is? I am so much happy with UIKit (UIKit 3 is more awesome).

    Just try it i hope you also love it :)

  13. 43

    Thank you very much for sharing the article! We use Bootstrap for our Web Development projects

  14. 44

    Reseau Solutions SL INC

    March 21, 2017 12:31 pm

    It totally depends on which you are handy on. someone like bootstrap and someone foundation.

  15. 45

    Marija Zaric

    March 21, 2017 3:35 pm

    Choosing the right responsive framework depends on the type of the project. I use Bootstrap and Responsee framework that are very good for the creation of the websites, themes.

  16. 46

    Uikit is simply coolest… Give it a try

  17. 47

    Andrew Beevers

    March 22, 2017 1:38 pm

    Monolithic CSS frameworks have lost momentum over the past couple of years. Sure, they still have their uses, but they are increasingly caught between 2 extremes.
    For non-designers/non-coders, there are plenty of great website builders and templates.
    For designers and coders, there are visual tools like Sketch and then flexbox, CSS grid, Reactjs, Vuejs …
    Sorry, but although the body of the article is fine, I think the introduction strikes the wrong tone. “Just use a framework” is not the message that Smashing mag should be sending out to the legions of professional web designers who visit the site in order to expand their knowledge.

    • 48

      Sebastian Zahn

      March 22, 2017 3:44 pm

      Sorry, i don’t get your point…
      Where do you find the message “Just use a framework”??
      Why you face Sketch ( i use it ) against a css html js framework? Sketch doesn’t generate one single line of code… in fact, Is perfect for working in conjunction.
      Vuejs? I think you are comparing apples and cars.

      • 49

        Andrew Beevers

        March 23, 2017 11:53 am

        The intro states:
        “In 2017, the question is not whether we should use a responsive design framework…The question is which framework should we be using, and why…”

        The trend in front-end in 2017 is the opposite to what the intro to this article implies.

        I agree 100% with Bram Smulders’ points earlier in the comments.

  18. 50

    I like that your tables are cut off on mobile screens in an article about responsive design.

    • 51

      Curtis Wilcox

      March 29, 2017 1:07 pm

      There’s a control at the top of the table to change which columns are visible on narrower screens (you actually have to have a pretty wide viewport to *not* have at least one column off-screen). I assume the control is a part of the site’s design and not specifically made for Jen’s article. Having a control like this is unusual and therefore easier to miss but it’s an interesting method of handling data tables responsively.

  19. 52

    As I read the comments it looks like you hit a very controversial topic :)

    To make this article complete it must have a performance comparison. Otherwise it’s just a summary of the documentations front pages.

    Something that is inherently wrong about all of these solutions is they are massive in terms of footprint but don’t really contribute to a better behaving web page. All this added bloat in terms of CSS and JS just doesn’t make sense.

    If you need a responsive grid system – make one that works for you … it’s not going to be much more than 50-60 lines of code, even less with pre-processor.

    • 53

      Thanks Martin. Yes, I did not address performance.

      Your example of only a responsive grid system makes my case from the beginning of the article:

      “I’ve chosen these three frameworks based on the characteristics they share, in that they are full-service responsive design frameworks. They offer grid systems, SCSS with piles of variables and mixins for customizations, basic styling of nearly all HTML5 tags, prestyled components such as badges, labels and cards, and piles of JavaScript-based features such as dropdown menus, accordions, tabs, image galleries, image carousels and so much more. All three frameworks offer ways of reducing file sizes to just those styles and functionalities needed to work on a given website. They are all in active development.
      Again, I am not suggesting that these are the only responsive design frameworks, nor am I implying that they are the best frameworks. These are, however, popular frameworks with piles of features out of the box, making them attractive to many development firms wanting to work with “Bootstrap or a close equivalent.”

  20. 54

    I love Foundation! ;-)
    I don’t like some uses of CSS in Bootstrap. Not the same logic as me ^^
    UIkit… never tested!

  21. 55

    Thomas Mølby Egebæk

    March 27, 2017 1:32 pm

    I’m not saying it’s the only right thing to do.

    But you can write a grid system in less than 40 lines of scss or less…

  22. 56

    Bootstrap’s grid column count (and a plethora of other variables) can also be adjusted if you opt-in to preprocess the package locally with SCSS. All variables are stored in a lengthy _variables.scss file.

  23. 57

    Victor Castrejon

    March 28, 2017 7:45 pm

    One thing I would include on the comparison is the accessibility support .

    In the case of bootstrap is well know for including accessible techniques, you can see just hit when you enter the docs page.

  24. 59

    I just starting about 6 months ago diving into responsive frameworks – I’m a front-end developer for more than 10 years. I’m using bootstrap but they’re are a lot of annoying things I hate about it – font size. I can never get it to look look right within the different views. And then the blocks are headaches cause they look right in a desktop but in mobile, they look crappy. I had to create my own css style sheet for blocks and font sizes. I looked at foundation and passed on it because it didn’t have a lot of nifty components that bootstrap has. So I’ve been looking for another framework that can replace bootstrap and has the same support that bootstrap has and components I can work with. Materialize looks pretty good but unsure if I should start over and continue on with bootstrap through the headaches. I’m not back-end developer but know enough to slap in code where I need it. But I have started looking at different javascript plugins like Angular but not sure what it is capable of doing with regards to being responsive. But then again, I’m not a back-end developer so don’t have the time to hack my way through setting one up. This is one of the reason I partially jump ship with regards to developing – too many headaches within developing and maintaining sites. I recently graduated nursing school and waiting to take the boards. I’m only staying within the field because I’m dedicated to maintaining a website.

  25. 60

    I love Uikit! It is easy to learn and to apply. It works in many platforms and browsers, it is responsive and it looks great. I recommend it specially to anybody who are not a full stack developer and has a passion for coding and want to deploy functional and good looking digital products.

  26. 61

    Great article with interesting content.
    It is really nice to be able to see the different types of design frameworks being compared side by side like this.
    Learned a lot.


↑ Back to top