Whilst on your development career path, you’ll no doubt work on websites that have been built by others. Some might use front end frameworks like bootstrap. Others might be completely bespoke. Your knowledge of one framework may be better than another. Either way, somewhere you’ll end up thinking “how on earth can I work with that?”.
When I take some time to consider how I use frontend frameworks, it can help mitigate any pain I encounter when I come across projects that use them.
Wading through the bloat
When I say there’s generally bloat to be found in a front end framework, I’m probably being a bit harsh. What you’ll more likely find, is with whatever framework you work on, it’ll have more bundled features than you need. On top of that, you’ll sometimes need to become familiar with the build tools used in a particular framework.
You’ll probably find a whole assortment of options and variables to configure, if you’re using a less/sass compiled framework. The documentation will end up being your best friend when it comes to working with a framework. And it will always be a deciding factor when, and how I use frontend frameworks going forwards.
File and folder structure is key, if you want to be able to add custom styles within a framework. Ideally it should be done in such a way that it doesn’t interfere with the core framework styles. You may want to apply fixes and upgrades to a framework you’ve used further down the line too.
With regards to javascript, you should be prepared for a bunch of ways to use those components, how to apply them to your build and so on. This may also play into how you apply your own custom code.
Your first hurdle – getting it to run
This is based on the assumption that you want to create your own build, rather than just link up to an external CDN of your framework. Obviously it’ll give you more freedom and control, but mighty also give you some more work to do.
I’d be the first to admit I’m not familiar with webpack or yarn, which became a problem for me when working with the uikit framework. To be honest I didn’t really want to take on board what’s essentially another package manager, so after some wrangling I got it working with something I have used before, namely NPM.
Was it worth the effort? I like to think that if you can fit something into your regular workflow, you should. I figured it would be less overhead to go with NPM, and use NPM scripts for my automation. Luckily the build tools provided with uikit, specifically for javascript, continued to work within my own setup.
Re-factor where you can
If there’s room for improvement, and helps development workflow in the long run, then refactoring can be helpful in working with frameworks. Obviously you might need to diverge from the original source code, something which we’ve done at my company for one particular framework. We basically picked our favourite, and refactored it to work within our other processes. We have changed/added/removed functionality, classes and so on, but it still smells like the original framework.
With this approach, you have the best of both worlds. There are still familiarities with the original source. This is useful for sometimes fixing issues. You can dip into the community, or other online resources, to address bugs you might come across. Some might even have bugfixes. It’s not a bespoke in-house framework per se, but it’s not a vanilla framework either. We use this custom framework for most, if not all, of our projects. How I use frontend frameworks can be best applied with my own methods of web development.
Take note of the framework version being used
If you’re taking on a project that has a front end framework, and you’re pushed for time, the version it has will be handy to know. I’ve had situations where something has broken in the framework, only to discover that said bug had been patched in a later version of the code. This seems like a no brainer, but is easily forgotten. Especially when a breaking change comes in via another third party, for example when you introduce a new version of jquery. I had a problem like this happen on a WordPress build. The setup required a different version of jquery-migrate. A built in WordPress core script that conflicted with the front end framework the theme was built on.
Don’t be sad if your code isn’t exactly how you want it
Usually when you inherit a project based on an existing framework, you’ll need to think like a ‘bootstrapper’ or *insert framework here*. However, when you’re also pushed for time you’ll need to cut some corners.
Obviously how the site has been built will reflect on how you modify it before it gets moved on. If it’s bad, then sadly you’re probably going to be bad too, for the sake of coding consistency. So that means being aware of how the markup has been constructed.
One example I had was with a button element inside a link. It was plain wrong of course, but this same button markup was applied throughout the site, classes and all. This was in dire need of a refactor, but for the sake of time it seemed more prudent to keep things as they were, to avoid anything potentially breaking. This was already a live site after all, and the changes were simple maintenance.
These are the silent pitfalls you need to keep an eye out for when working on an inherited framework based project. Chances are the previous developer hated working on it as much as you’re about to. If you’re lucky, they might leave you with some dev comments, but most of the time you’ll need to fudge it as best as you can. In that case, I’d refer to the original framework docs for support, whilst taking note of the framework version you have.
Picking up a framework to use can also help with sharpening your coding chops. Digging into a well developed framework can really help you to learn about general practice and techniques used by other developers, and is another hidden benefit for how I use frontend frameworks.