Front-End Framework or Rolling Your Own

Introduction: A Shift in the Way We Code

Over the past year or two there’s been a relatively large shift in the way we, as web developers, write and organise our front-end code, mainly HTML and CSS. No doubt it’s thanks to languages like Sass and LESS.

Someone I’ve followed and admired for a long time (as well as mentioned here on IP) is a man named Harry Roberts, better known as CSS Wizardry. He’s a big believer OOCSS (object-oriented CSS) and is one of the industries best brains on front-end architecture. He also has his own framework called InuitCSS.

The big shift in the way we code has been to take the standard of coding page by page and start coding piece by reusable piece. Instead of have a load of home page related CSS and also a load of about page CSS etc… We make our code more modular and maintainable by using components and modules so all pages use the exact same HTML markup for certain areas, which then results in only one piece of CSS per component. So instead of thousands of unneeded class declarations we only have one.

This all leads us to a big question, do we go with preset front-end framework or roll our own?

---

When to Use a Framework or Roll Your Own

In general frameworks like Bootstrap and Foundation are great. I’m not here to bash them or tell you not to use them. However, please keep in mind that they’re NOT the final solutions. They’re merely an idea which we as a community of front-end developers can use to fuel our own creations.

If you or your team is short on time and you need to have a working, usable prototype ready in a few days then go straight to a framework like Bootstrap or Foundation. It will save you time on the front-end architecture but it’ll also take a little time to get used to and feel a little foreign when you start using it.

Pro Framework

A designer coding a portfolio: If a designer decides to create themselves a new portfolio and they’re not used to dealing with code then a front-end framework is probably the best option. Why spend extra time coding something that doesn’t need the extra time because you’re only going to use said code once or twice.

A company with low-level front-end developers: I used to work at a company which had a very large site. There was a big problem with the front-end code, it was outdated by four or five years. Bootstrap was an excellent option in this case since 1.) The site was so big that rolling a custom framework would’ve wasted too much time and money. 2.) There were only two front-end designers working on the site. Yes you read that correctly, only two designers, I couldn’t believe it at first either. Not to mention the two designers weren’t exactly high-end CSS architects themselves.

Pro ‘Roll Your Own’

A front-end developer making anything: So you make sites everyday. You love to code with Sass or LESS and enjoy the challenge of making your code modular and maintainable. If you’re making sites all the time then rolling your own framework may be the best option because you’ll never know any framework as good as you know your own. Which has a host of benefits like development time and bug fixing.

Creating from scratch with time to spare: If you’re creating something from the ground up and you’ve got the time to do research on best practices, setup files and folders and any dependencies then go for it. Start from scratch. Like I mentioned above, an individual will never know a framework like their own and that also goes for a team. However with a team things like a style guide and extensive documentation are especially important.

---

Rolling Your Own: Guidelines

I’ve touched above on why or when you should use a front-end framework and when to roll your own, now let me talk about how to actually roll your own.

Here are my best tips:

• Hire someone to manage the front-end architecture full-time (large sites).
• Create a style guide with extensive documentation on how and when to use every component and/or module (medium to large sites).
• Take ideas from everyone. Going all in with a single mindset is only going to be destructive in the long run.
• Research like you’ve never researched before.
• Make sure every team member understands what it is, how to use it and what it will achieve.

There are other factors to consider, like time and money which are usually the biggest, but taking that time and money to invest in the future of your site will pay off dividends in the long run because updating the site will take A LOT less time and money than it otherwise would have.

A Style Guide with Docs

A great example of a style guide is the recently released A Pattern Apart, which is the pattern library (basically the same as a style guide) from the people over at A List Apart. You can read more in it here.

Everything needs to be in the style guide or pattern library. I mean everything. One of the biggest benefits of having such a section of your site is to see every single component at a glance without having to search high and low to make sure everything works. Think about this: You make a change to paragraph styling. It’s going to take a long time to check the entire site for bugs. It’ll only take a second to check the style guide page which is a list of everything.

Good Research is Paramount

The best thing you can do for your custom framework is research. There are many different front-end coding principles out there like BEM and OOCSS to name a few.

The worst thing you can do for your code hierarchy is to mix and match different coding styles without fully understanding them. It’s a bit of a grey area when it comes to mixing code styles, so it’s generally best to stick to one and do it well, rather than five and mess them all up.

Once you (and your team, if there is one) understand exactly what it takes and how to get there, then all you need to do is start walking the path. (I sound like a fortune cookie, I know).

---

Conclusion

Creating a custom framework can be a daunting task and if you do it before there’s enough evidence from research to support going that way then it can be disastrous. The same applies to choosing a pre-built framework. If your project doesn’t require it or will be held back by it then don’t do it. I’m a big believer in doing what is right on a project-by-project basis. Not just picking something up and rolling with it forever. A great quote says:

Anyone who stops learning is old, whether at twenty or eighty. Anyone who keeps learning stays young. The greatest thing in life is to keep your mind young.

Henry Ford