Are frameworks right for you? - CSS Tutorial

- [Instructor] Every developer has their own style and preferences, so naturally there's a debate among developers as to whether or not frameworks are even worth using. Some people absolutely swear by them and wouldn't start a project without them, while others think that they add unnecessary overhead and maybe too many constraints for their project. So, 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 a framework, I find it helpful to think about why they were created in the first place. Let's think about it. Developers often use the same code over and over again from one project to another. I'm sure you can relate to this. If you've spent hours and hours crafting a set of form styles, why on earth should you have to recreate them in every new project you do? By reusing code, you ensure that you're using code that works, and you get the benefit of being faster with each new project. Over time, most developers identify the code and patterns that are most common to their projects and begin to create templates and starter files around them. So that's how the majority of frameworks are born, and I think it's pretty cool that so many developers and agencies, and companies, have made their frameworks available readily to all of us in the web community. Of course, this very process points out one of framework's biggest problems. Their workflows don't match mine and my workflow probably doesn't match yours, so if you use a framework created by someone else, in a way you're committing to working in the same way they like to work. Also, you're gonna have to spend time familiarizing yourself with how they like to structure content, and how to best apply your own visual preferences to their styles. That said, there are still some benefits to using frameworks so let's take a look at some of the pros and cons. Probably the number one 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 a lot of the time that you need to spend debugging and testing. Another reason to use a framework is for the structure and consistency that they give to your project. What do I mean by that? Well, in order to use a framework, you need to use the naming conventions in place for class and ID values, and the underlying code structure. Since many frameworks are built around specific web standards and best practices, this means that your own projects will be properly structured and have a certain degree of consistency that makes them easier to update and maintain. If you're working in an agency, or with a team of developers, choosing a framework as a base for all projects makes it much easier to step into your coworker's code and know what's going on. In other words, it make team development easier if everyone's working from the same set of standards, and a structure that a framework can provide. Perhaps my favorite reason for using a framework, education. A nice high quality framework is the result of hundreds or even thousands of hours and lessons learned the hard way by other developers. By using a framework, you're not only benefiting from their knowledge, but you're able to dig into what makes that framework tick, and figure out how to approach different design issues. By experimenting with multiple frameworks, you can get a fairly broad overview into how the professional web community tackles common problems. This all 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 that might happen in the browser. This means that it will be a very rare project that uses everything a framework has to offer. So, unless you take the time to go through and strip out all that unused code, your projects will have a little 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 might end up having to spend a lot of time modifying the framework for a particular project. So if a framework isn't right for a particular project, you may feel like you're trying to shoehorn it in. So that's what makes choosing the right framework so important. While it's really nice to have a head start, you don't want to spend twice the amount of time in overwriting or modifying a framework's styles, so whether or not you should use a framework, well, it's entirely up to you. What I do recommend however is that before you commit to using one, research them, experiment with the ones that seem like the best fit, and once you've had some hands-on experience with them, you'll be better prepared to determine whether or not they'll work for you.