Ready to watch this entire course?
Become a member and get unlimited access to the entire skills library of over 4,900 courses, including more Developer and personalized recommendations.Start Your Free Trial Now
- View Offline
- Understanding boilerplates, grids, and frameworks
- Choosing a framework
- Building your own framework
- Crafting a deployment strategy
- Modifying files
- Customizing typography and color
- Filling in framework gaps
- Exploring grid-based syntax
- Nesting grids
- Using mobile grids
Skill Level Beginner
There's a fair amount of debate among designers as to whether or not frameworks are worth using. Some designers absolutely swear by them, and wouldn't start a project without them, while others see them as adding unnecessary overhead, and too many constraints for their projects. Whether frameworks are right for you is going to be driven largely by your personal preferences, and your approach to coding. When deciding on whether to use frameworks or not, I find it helpful to focus on why they were created in the first place? Designers often use the same code over and over again from one project to another.
I mean, if you have spent hours crafting a set of browser reset styles, why should you have to re-create them in every new project that you do? By reusing code, you ensure you're using code that works, and you're getting faster with each new project. And over time, most designers identify code and patterns that are common to most projects and begin to craft templates or starter files around them. This is how the majority of available frameworks are born. I have always thought that it's a great testament to the web community that so many designers and studios have decided to share their frameworks with the rest of us.
However, that very process points out one of framework's biggest flaws. My workflow is unlikely to match yours, and how I prefer to solve problems might not be the way you would do it. So, if you use a framework created by someone else in a way, you're committing to working the way that they like to work. What's more, you're going to have to spend time familiarizing yourself with how they like to structure content, and how to best apply your own aesthetics to their styles. Still, there are tangible benefits to using frameworks.
So let's look at some of the pros and cons. Probably the foremost reason for using frameworks is to speed up your development time. With a framework, the markup for typography, columns, alignment, units of measurement, and the element styling are already worked out, perhaps most importantly, cross-browser compatibility issues are addressed throughout most frameworks eliminating most of the time spent debugging and testing. If a layout grid is included, the designer can align elements to an underlying grid, and create rows and columns by simply applying class names to page elements.
In that sense, designers can rapidly create style prototypes or even finish sites without having to author a ton of separate styles. Another reason to use a framework is for the structure and consistency that they give your projects. In order to use a framework, you need to use the constraints in place for class and ID values, and underlying code structure. Since many frameworks are built around web standards and best practices, this means that your own projects will be properly structured and achieve a degree of consistency that makes them easy to update and maintain.
And perhaps my favorite reason to use a framework is for the education they provide. A high-quality framework is the result of literally hundreds or even thousands of hours of lessons learned the hard way by other designers. By using a framework, you are not only benefiting from their knowledge, you are able to dig into what makes the framework tick and figure out how to approach different design issues. If you broaden your horizons and experiment with multiple frameworks, you can get a fairly broad survey into how the professional web community tackles most problems.
It sounds good, right? Well, there are some negatives. Perhaps, the most frequently cited negative is that your projects will undoubtedly suffer from some level of bloat. To one degree or another, frameworks try to provide options for almost any situation the authors can think of. This means that it will be a rare project that uses everything a framework has to offer. So, without taking the time to go through and strip out all that unused code, your projects will have a bit more bloat than they actually need. You're also restricted to working based on the way the framework is constructed.
This isn't always a negative but if you don't choose wisely, you could end up with a framework that doesn't really fit your own personal workflow or standards. Also, if the framework is too restrictive, you end up having to spend an inordinate amount of time to modify the framework for that particular project. That's what makes choosing the right framework so important. While it's nice to have a head start, you don't want to spend twice the amount of time in overriding or modifying the framework's styles. Most frameworks use non-semantic class names for page layout and styling.
While this might not be a problem for some designers, for those that are concerned with creating clean semantic code, it can be a bit of a deal breaker. Does this mean the frameworks are right for you or not? Well, I can't say. That's entirely up to you. What I do recommend, however, is that before you commit to using one, you should research them and experiment with the ones that seem to best fit your needs and philosophies. Once you have had some hands-on experience with them, you'll be better prepared to determine whether or not they'll work for you.