Current Techniques
To date (July 2017), the following approaches have been used but subject to change given the rapid pace of change in frontend compared to other areas.
Using the latest standards
Be open to utilising the latest technologies but consider support for older browser and devices. Use a tool like caniuse.com to check percentage support and discuss with other team members where possible. Likewise look to improve, reduce or tidy up code on older projects where redundant fallbacks have been applied such as extensive hacks for IE6 support (which we no longer support).
Task runners
With the exception of email or very simple static builds, all projects should use a task runner such as Grunt, Gulp or more recent node-based examples like Webpack. If you are not familiar with these or their purpose then make sure to read online articles and documentation on their setup, features and benefits.
Node and NPM
Essential to the management of most projects is the use of Node for plugin dependencies. Typically this involves using Node Package Manager (NPM) that's a centralised resource for finding different packages.
Returning to projects after a long period it may be necessary to remove the folder node_modules and run npm install from fresh. Older packages may contain security vulnerabilities and functional bugs so it's recommended to keep packages updated regularly. Make a backup of the old folder locally if you're unsure about requirements for older dependencies. Also check for a file package-lock.json, as this may prevent updating older dependencies, so may also need deleting before running npm update or npm install. Remember to ignore node_modules from Git backups or deployment through adding it to .gitignore as it's both unnecessary and consumes a lot of storage space.
CSS & Preprocessors
Usually this will be determined by the project’s framework or existing setup but in all cases we use Sass method. Unless there’s a substantial reason otherwise then always use Sass for preprocessing your CSS. At the time of writing the CSS variables specification is coming on as a potential replacement for this, however, this is not confirmed.
When writing Sass use the BEM methodology to its full capacity ensuring that properties aren’t deeply nested and others can understand where to find different code blocks. Try to keep components, layout and plugins separated and as modular as possible over separated files and folders.
JavaScript
To date most of our projects have included jQuery as the primary framework as many of the plugins used depend on it such as Slick carousel, WordPress plugins and jQuery UI features. This is a perfectly acceptable choice for many existing projects however it would be encouraged to move away from jQuery dependency where possible in future projects.
ES6 and later versions of pure/vanilla JavaScript (non-framework-based) now provide comparable functionality without too much extra complexity. Unless the project includes predefined features like carousels then consider using ES6 or later for simple toggling state functions and verification features.
As part of the task runner setup, any aspects of the script should be included in the setup with linting and minification as part of the process to check for errors and reduce page weight.
Testing
At the time of writing we support all major browsers from IE11 upward, Chrome, Safari and Firefox. Likewise where applicable the main mobile browsers include Safari on iOS and Chrome on Android.
Use a tool like WAVE for checking principle accessibility requirements are met. Treat this aspect of testing with as much focus and time as cross-browser testing.
On Mac use the VoiceOver utility to test and experience navigating each page with just voice to confirm if all the parts you can see can be accessed. To access this feature press Command + F5 then use just the keyboard. Confirm also that the structure of the page is logical closing your eyes to navigate the website without vision.
Approach testing as much as possible from the end-user perspective to confirm the overall user experience is being met. In some cases it may be necessary to go back to the design and discuss changes where the conflicts or challenges in using features over different browsers or devices.