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:

1. Ability to keep Foundation updated via a package manager (read: Bower).
2. Be selective with which features of Foundation we want to use.
3. Provide a method of separating out CSS files into "modules", whilst maintaining full access to global variables, extends and mixins.
4. 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.

1. Construct
2. Core
   1. Foundation
   2. Vendor
   3. Theme
3. Modules
   1. Vendor
   2. Theme

Construct

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:

Toolkit

The toolkit contains all the project's mixins and extends.

Settings

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.

Assets

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.

Configuration

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.

Core

The core is the project's primary styles, including Foundation, any vendor styles, and all the custom theming.

Foundation

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.

Vendor

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.

Theme

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.

Modules

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.

Conclusion

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.

Github

Fasten is available on Github.

As a web developer, my typical reaction to such an idea is "I can just build it!" However fortunately of late, I've been more and more looking for existing solutions to solve the problems I face.

Naturally my first stop was WordPress. Why wouldn't it be? WordPress is synonymous with "Blog". I had even gotten as far as arranging a cheap host and installing WordPress! Since I already owned the domain I wanted to use, I just dialled in the name servers, sat back and waited. And waited.

After a solid 6-7 minutes of waiting (yes, I am well aware that name servers take up to 24 hours to resolve, I'm impatient), I decided that I was sick of waiting so Googled "blog platform". Straight to result #1 Best Blogging Platforms of 2014, which had a convenient list of modern blogging platforms with their pros and cons. Lovely! The fact that the article was hosted on one of those platforms was quite fitting, and a little meta.

I opened various links in new windows and started to sign up for a couple of different platforms - but it was Silvrback which caught my attention for a couple of reasons:

• I was able to sign up and start writing this very blogpost within minutes (so meta).
• I love a nice clean UI, and even though I actually found the lack of options jarring at first, I'm already starting to warm to it.
• Markdown.
• Code examples are demonstrated on the introduction page, which is what I intend to use my blog for. Sold.

Yeah okay, I'm probably an easy pushover - but I found myself looking for the path of least resistance, and Silvrback is able to provide me with exactly that.