>The BFED realises that while not all experiences will be identical, all browsers can be used to consume a website, even gasp, IE6 and below. I don't understan

>The BFED realises that while not all experiences will be identical, all browsers can be used to consume a website, even gasp, IE6 and below. I don't understand this point. He must be speaking of degrees, not a binary decision, right? Surely he wouldn't advocate supporting Netscape 1.0? >When given the choice to add a preprocessor (e.g. LESS, SASS, CoffeeScript etc) to the technology stack, the BFED realises there is a deeper impact beyond just "writing less code". Will it be harder to onboard developers? Will debugging code be more difficult? If the answer to any of these questions is yes then the BFED will say no to preprocessors. Covered by another commenter, this is way too simplistic. There's a tradeoff between the benefits of a technology and the increased complexity of your app and increased training time for new hires. I highly doubt a great BFED would refuse to make any tradeoffs that might increase complexity or require more training. We are professionals after all, some learning of tools is expected of us! >The BFED realises that users have different abilities and preferred ways of using a device, whether its a mouse, finger, thumb, screen reader, keyboard or a combination of all, websites should be consumable no matter the audience, screen size or capability of the browser. Yep, though this seems more like a point in the cool front end developer's camp. A healthy percentage of the huge amount of JS libraries that are released all the time these days (and bemoaned on HN and blog posts like this one) have to do with accessibility and responsive design for multiple interfaces. >The BFED embraces the constraints and limitations of the browser so that he/she doesn't find him/herself in a world of Adaptive Design and UA sniffing because that world is horrible, ill-advised and costly. Due to my own inexperience I'm not quite sure what they're on about. >The BFED will also suggest the use of native form controls realising that browsers will enhance the experience where possible, particularly on mobile, and doesn't try to control the look and feel too much as he/she knows that the brand will not suffer because of that decision. A good point, and I tend to advocate for those too. But it's sort of a call that gets made above the code monkey's pay grade in my experience. >The BFED will also suggest that links are styled as such, and with underlines, so that users can identify them within copy. Subjective. Seems like engineers tend to prefer this style and assume everyone else does too. >The BFED will carefully select third party code based on the quality of the code itself by reviewing source code, not based on the popularity of said code. He/she favours reliability over popularity every time. Fair enough. >The BFED will adhere to the following quote (by Anon): “As a Lead JavaScript Engineer, I try to get my team to write as little JavaScript as possible.” I agree. >Furthermore, the BFED realises that Single Page Applications cause severe problems and that by avoiding them and leaning on the server appropriately provides a better experience and reach. Definitely disagree, but to even start on that discussion is way beyond the scope.