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.
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).
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.
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.
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.
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.
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.
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.