The big Bootstrap front-end cleanup
Written by Devhouse Spindle on 26th July 2016
Ditching Bootstrap
In the last months, we’ve spent time on cleaning up the front-end of our telephony platform VoIPGRID. The project (we call it a milestone) initially existed of ditching Bootstrap because of the old Bootstrap version (V2) and related legacy code. This legacy code especially led to some issues in updating dependent libraries like date pickers, data tables, CSS-related work et cetera. As everybody knows you will eventually run into trouble while maintaining legacy code.
The main reason for cleaning up was to clear a path to a more modern and more easily maintainable front-end codebase. The two biggest issues being the fragmented JavaScript code and CSS hierarchy. As we eventually want to upgrade to a cleaner and more modern VoIPGRID design, we had to make the use of JavaScript (and related libraries) more consistently and remove unnecessary obsolete (front-end) code.
Cleaning up JavaScript
While I started cleaning up the LESS files, Jeroen started working on the JavaScript part: updating libraries, re-arranging our task runner (Gulp), concatenating files, and cleaning up fragmented JavaScript.
All custom JavaScript is now neatly organized in frontend/js/app/, where all the vendor JavaScript can be found in frontend/js/vendor/. The JavaScript files are organized in their own module folder. E.g., all the general form-related JavaScript can be found in frontend/js/app/forms/. This makes it very easy to find the relevant file when working on a specific part of the platform.
Babel and Browserify
Because Jeroen was working on our Gulp task runner, we decided to apply Babel (ES2015 compiler/transpiler), so we can write ES2015 in our source, while the final files are being transpiled to ES5 for backwards compatibility. While at it, Jeroen rewrote most existing JavaScript code in VoIPGRID to ES2015, for consistency sake ;-). He decided to move custom vendor code – we edited some libraries for our own purposes – to NPM as well. This makes it easier for us to maintain these packages and we now have a central place where the codebase lives.
Another nifty tool we started using is Browserify. Browserify allowed us to split the front-end code into several modules, greatly improving the readability of the code. Also, instead of checking in vendor-specific files into our project, we were now able to install third-party dependencies directly from NPM. This makes upgrading third-party packages a lot easier.
From LESS to SASS
With Jeroen plowing through heaps of JavaScript, I finished cleaning up LESS files: inconsistent use of selectors, concatenating stuff, removing double or overriding CSS, etc. Throughout this process, Jeroen wrote a task for our SCSS workflow. We rewrote all the LESS files to SCSS and included a node-bootstrap-sass package for the core files of Bootstrap we decided to keep using. Changing from LESS to SASS also means we can now use Libsass instead of LESSSC. Libsass is a lot faster in compiling style sheets, which in our case makes generating all the partner branding styles 100 seconds faster (from ~125s to about ~24s).
New form layouts
After spending some time cleaning up, I decided to rearrange the forms layout too. From now on all field labels are positioned above the field, instead of left (while floating right…). This improvement makes the forms less chaotic, resulting in a more clear and readable form. I – unfortunately – extremely underestimated the amount of work that came from redoing the forms but the result is awesome.
The before and after of a filter box. A little more spacing between labels to improve readability.
The before and after for the personal options form. Labels positioned differently and some general styling.
Before this milestone, the VoIPGRID forms and fields were build up with the Django Bootstrap-toolkit package (field|as_bootstrap). This package produced a lot of unnecessary HTML which could be rewritten in a better fashion.
Rewriting CSS and HTML
Ditching the Bootstrap-toolkit package resulted in me having to rewrite all the CSS and HTML for the forms. Because there are a lot of different forms, with just as many exceptions, I had to go through all these forms. Because all the form-related JavaScript was targeting the classes used by Bootstrap-toolkit, I had to go through these as well to make sure I didn’t break anything.
After redoing the forms I started cleaning up the Bootstrap core CSS. We wanted to completely ditch Bootstrap, but at this point, the platform itself relies too much on some core elements (the grid, tables, etc). I decided to leave it as is. This milestone cleared the way for a design upgrade, so as we are most likely going to redo a lot of elements because of the future new design we might as well rewrite the HTML at that time as well.
Paving the way for the future
As said before this milestone focused especially on better maintainable front-end code. Most of it won’t be seen or noticed by users. The most noticeable change that can be seen, is the slightly changed style of forms, fields, and widgets (e.g. multiple select fields). Because we also concatenated a lot of JavaScript files, the platform itself does fewer requests on several pages, resulting in a faster platform which is mostly noticeable on mobile.
The next step is to completely rewrite the core elements as well, to eventually ditch Bootstrap completely, or at least be up-to-date with the latest stable version. This will enable us to develop even faster and make our platform even more user-friendly.
Your thoughts
No comments so far