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
Once your framework is downloaded and unpacked, you then have to decide exactly how that framework is going to fit into your development workflow and how you're going to deploy the framework at runtime. This is going to largely depend on the structure of the framework, how you like to work, and the constraints of systems like content delivery networks and content management systems that you might be working with. Here are some key things that you need to think about when integrating a framework into your site's development. First, you need to decide whether the related framework files should be kept separate from additional styles and scripts or integrated into them.
Take a look at the Foundation files here, for example. Now there is an external folder for both the scripts and the stylesheets that make up the framework. So if you already have an existing site, do you merge these files and folders with your existing site structure or do you keep them separate? Now merging them is going to be more efficient from a performance standpoint, and it's going to reduce calls to the server, but combining them could be tricky, and if you integrate them, it could take a significant amount of time.
It could even create maintenance issues as it might not be clear whether you are updating framework or a native site code. Integrating them also makes it harder to update the framework if a new version of it is released. So there are pros and cons for both approaches and in some cases the systems that you are working with might dictate whether they should be integrated or not. In the end, it's probably going to come down to your personal preference and what you'll find to be the easiest to maintain in the long run. Another thing to consider is whether or not the framework's naming convention fits your site or project.
If it doesn't, renaming the files and folders isn't that difficult, but remember that many of the files are referencing assets from those external files and directories. If you don't have a program that can handle resolving those changes for you when you rename them, you are going to need to do it manually. Since it's easy to miss one or two resources or mentions, you are going to need to be extremely vigilant when testing your renamed files and directories. Many frameworks come with sample files that you use to start building your site. If you decide to use these, you need to carefully examine the structure of the page and make sure it meets the coding standards of your site.
This, for example is the sample index.htm page that comes with Foundation. Note that there is extensive structure already added to it, such as calls to external resources, meta tags, and conditional comments for Internet Explorer. If you choose to use this file as a starter file, you might want to modify these settings to better match your own project, add content or markup that your project needs, and then save your own custom starter file once you're done modifying it. Coming up with the development and deployment strategy for using a framework is perhaps the most important part of the process.
If you don't think it through, you could get halfway through the project before you realize the site structure and coding standards are wrong for your site. To prevent that from happening, make sure you spend enough time with the framework to become familiar with how it works and then start crafting a strategy for how it could best fit within your overall site deployment.