Fasten isn't a new framework. It's not a new tool. Fasten is simply a pattern. A pattern to fasten frameworks together and neatly integrate a project's theme in a maintainable, upgradable way.
Check out Fasten on Github.
One of the troubles with using an existing SASS/CSS/LESS front-end framework as a base for a project is that as the project evolves, it's code base gradually steps further and further away from the original framework. Whilst this isn't necessarily a bad thing, it becomes increasingly difficult to keep the framework up to date with the latest in features, and more importantly; bug fixes.
Realistically, the only way to achieve the goal of easy updating, is if the framework's codebase isn't touched at all; not even its settings file, which simply isn't practical.
Also there's the challenge of keeping everything as simple and lightweight as possible. Taking a step further, even providing the option of separating certain parts of t CSS into separate files.
Over the last few years, taking inspiration from other blogs suggesting similar patterns (I'll link to them if I can ever find them), I've slowly developed what I believe to be (as close as possible to) the best of both worlds - full customisation of your template, whilst maintaining the core of the base framework untouched.
Personally, ZURB's Foundation is my framework of choice, but the pattern could apply to any, or several, of your preferred frameworks - but I will use Foundation in this example.
There are several goals I wanted to achieve:
- Ability to keep Foundation updated via a package manager (read: Bower).
- Be selective with which features of Foundation we want to use.
- Provide a method of separating out CSS files into "modules", whilst maintaining full access to global variables, extends and mixins.
- Keep the CSS output as lightweight as possible (related to point 2 and 3).
Enter Fasten. As the name implies, the pattern fastens several parts together, however each of the parts can be upgraded with minimal hassle.
Fasten Structure Diagram
As a visual person, I sketched out a graph to try and piece the platform together, and identify any potential issues. This is the basic idea:
View the diagram SVG.
Fasten has several layers to pull everything together in an orderly, manageable manner.
The construct is responsible for keeping the project's Core and Modules consistent by providing access to common tools, assets and settings. The construct does not contain any styles which helps keep the modules clean of duplicate CSS.
To achieve this, it's broken up into three primary parts, plus a small configuration file:
The toolkit contains all the project's mixins and extends.
This contains both the framework's settings as well as the projects settings. Whichever takes precedence will depend on the project.
Personally, I prefer to use the Foundation settings as my primary settings file, using a theme settings file for any extra variables I may need.
The assets part enables Fasten to expose fonts, icons, images and anything else the project might need to share between the Core and Modules. It is important to remember that if the project is using icon fonts, to not include the classes, otherwise these will be duplicated between the Core and the Modules.
The config file sets where the project's assets are located using relative paths. This configuration is deliberately separate from settings as it's designed to be environment specific.
The core is the project's primary styles, including Foundation, any vendor styles, and all the custom theming.
As mentioned earlier, the project doesn't need to use Foundation. It could leverage Suzi or Bootstrap or whichever framework is best suited.
To keep things neat, and prevent temptation to edit the framework's source code, use Bower to pull down the framework into the project, and manually import the components it requires.
I suggest when starting out to include the absolute bare minimum (e.g. the grid), and only add the components you require as you need them.
By separating vendor code from your code, it will help save confusion among team members as to why the code style is so different, and even ignore those files from your linters until such time you're able to clean them up.
Vendor files could also import Bower components not dissimilar to how the framework is imported.
All the project specific code should be broken up into components within the theme directory. For more complex components, such as navigation menus, it may even be worth bundling these together in a sub-directory to help keep file lengths small and each file concise in its purpose.
Project modules will be generated into separate CSS files from the core. To help keep the core styles as lightweight as possible, more complex pages should have their styles separated from the core. Of course, if the project is an SPA, modules are probably redundant, and all styles should be included in the core.
However, say for example a "standard"website is having a mini web app added which may not always be accessed by the end user, then break that code away into a module.
The modules follow a similar pattern to the core. They are made up of vendor and theme code, with the exception of Foundation. However, as the modules do import the construct, they have complete access to Foundation's and your project's settings, toolkit and assets.
Fasten is a pattern (or framework) for neatly integrating your favourite front-end framework into your project in a manageable and upgradeable manner. It provides a method of breaking the project's styles into modules, without restricting access to common project settings and assets.
Fasten is available on Github.