To Bootstrap, or not to Bootstrap?
Back in June, I was working closely with another designer/developer on the front-end build of a sizeable website, when we came upon a tricky hurdle: a request to use Bootstrap.
For this particular project, we both felt that Bootstrap was not the best way forward, and wanted to understand why the request had been made and what we could do to recommend otherwise.
The below is taken from an email discussion I had with the other designer/developer, prior to discussing with the client - and which I thought might provide a useful insight not only for dev teams, but also clients when it comes to making decisions regarding the use of frameworks.
1) The code provided for the previous build of the site had created additional and on-going work for the in-house team with regards to browser/device support.
2) They are keen to avoid this happening again and believe Bootstrap could help prevent so.
3) They find Bootstrap reassuring because it is well-tested and appears predictable, reliable and robust - and has detailed documentation.
So, as you said, we need to reassure them that our approach will deliver good, solid, reliable code that will not cause problems for integration and support.
I think it would be good to show some examples of style guides and pattern libraries to demonstrate that our approach involves creating a bespoke f/e framework that is fit for the specific purpose. This is aligned with the goals of Bootstrap - except ours should be leaner, faster and simpler.
Whilst we will not have time to create exhaustive documentation, like Bootstrap, we will be providing developers notes and liberal code commenting which, coupled with the use of BEM (which Bootstrap does not use), will mean the code is easy to understand. My approach is heavily geared towards clarity for future development/developers - both front-end and back.
The browser support offered by Bootstrap is really not any wider than any good developer should aim for - so we will be aiming for a similarly high level of compatibility and quite possibly more. In particular, our compatibility will be further informed and led by stats from the previous site.
Whilst theoretically Bootstrap gets us off to a flying start with browser support, a good developer is conscious of this from the outset and, because the code is likely to be slimmer and more specific to the project, bugs can be more easily identified, understood and fixed.
It is also worth noting that whatever approach/framework we use, there will always be some level of custom code that requires the same level of testing, especially across mobile devices.
We also need to make it clear that the convenience and predictability of Bootstrap for developers is not necessarily in the best interests of design, front-end or, most importantly, the end user.
Bootstrap is very opinionated and may require us to heavily customise and reverse engineer aspects of it - or simply deviate from it entirely for much of the build. This could result in slower progress in development and bloated, poor performing code for production.
The alternative is keeping more aligned with Bootstrap's opinionated UI patterns which could lead to restricted design choices and 'Bootstrap clone syndrome'.
With regards to the in-browser, agile design/dev process proposed, flexibility is of utmost importance. Bootstrap simply does not offer us this.
For example, I would intend on using a grid system that delivers fixed-width rather than responsive in IE8 to avoid the (albeit small) JS overhead of respond.js.
This is just one of the many decisions about implementation and performance that a flexible, bespoke approach will allow. Bootstrap will already have an 'opinion' on things such as this which may not be aligned with the requirements of the project.
The unknown risks of a framework present the most significant worry because so much has already been assumed and built. Admittedly, there are inherently more unknown risks with a framework when the developer/s do not know it intimately.
Will it be flexible enough? Will it result in reverse engineering? Will the code be less performant? Will the site end up looking like yet another Bootstrap site? Will it slow progress rather than speed it up?
I cannot predict or negate these unknown risks - however, when coding from scratch, a much greater and more intimate awareness of risks can be cultivated, and greater freedom/flexibility is offered to counter them. I have many years of experience informing this statement - but I do not have the same experience and confidence using Bootstrap.
I am a front-end developer of 12+ years and my experience and instinct is telling me that Bootstrap is not the best way forward for this particular project.
This is based on the knowledge I have gained in my career, on having used Bootstrap in the past, and on what I have seen of the project, design and timeframe.
This topic is, of course, subjective and the finer details of a build can often only be known in its undertaking. However, in my personal experience, frameworks can limit the flexibility we have available to adapt to issues from all disciplines (design, build and backend).
Will what you provide be 100% cross-browser?
We will test x-browser/device based on the analytics. 100% is a not a realistic goal, even for a framework. There are too many browser, operating system and device combinations to ever deliver such. Instead, we will take an approach of progressive enhancement and ensure that the site is as usable as possible even when certain technologies are unavailable. When it comes to testing, the level of support depends on the time available to spend on quality assurance.
Will you provide updates / fixes for browser incompatibility as and when new browsers are released / issues discovered?
Depends on service level agreement. No code is future proof (inc. Bootstrap) and not code is infallible (see previous answer). We would always aim to discover and fix as many bugs as possible for delivery, but this will never be watertight - with or without Bootstrap.
Bootstrap (or other such third party libraries) are robustly tested to a degree that is hard to match with something custom especially across mobile devices?
Yes, so long as we do not deviate from the Bootstrap UX/design/patterns. Customising, expanding and adding to any framework will require the same level of testing (see points 3 and 4).
I guess we’re bootstrap neutral as well so what I’d like to understand more is what we would be using instead?
- We will be creating a bespoke framework that is fit for purpose.
- It will make use of standardised coding conventions outlined by BEM (http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/) and SMACSS (http://smacss.com/)
- The code will be focus on leanness, performance, compatibility and clarity, with specific consideration for both backend integration and future development.
- Sass and jQuery will be used to supercharge the development of CSS/JS.
- The build will be highly modular, allowing for components to be tested in isolation and highly reusable.
We’d always opt to build onto a third party (open source) framework where we can, because you have a greater level of compatibility with less risk.
See previous thoughts on risk. A benefit of a framework is definitely in the documentation, testing and community support - but we have presented counter arguments to this.
Our current site is currently not using any obvious front end framework and so a lot of our time is spent “making it work in IE” or “sorting it for iPad" and other such scenarios.
So let's build it better! :)
We discovered in due course that the desire to use Bootstrap was actually masking a different issue entirely - the in-house developers had been let down by the previous team and build, and were understandably worried about history repeating itself.
Thankfully, we were able to allay their concerns and we received the go-ahead to proceed without Bootstrap. We also made the codebase available to them throughout the entire build process and this level of transparency helped build on both trust and understanding of the code.
After delivery, we received some great positive feedback - they were absolutely over-the-moon with the build and they really took to our approach - so much so that they went on to integrate it into their own internal processes.
In closing, the question of front-end frameworks is a common and tricky one, and not without contention.
I do, however, want to make it clear that I am not against frameworks - many extremely talented people have kindly clubbed together to produce some excellent stuff - and for free.
For some scenarios, they can be absolutely superb. For others, an absolute pain.
Ultimately, it is not just about choosing the best tool for the job that matters but also demonstrating a willingness to explain and justify that choice.
Special thanks to Gary Lake, Mark Skinner, Andy Mantell and Joel Mitchell for their input.
