The boring front-end developer

> Will it be harder to onboard developers?

No. LESS is similar enough and we've automated the build process, so it will not be harder. People that can write CSS can learn LESS easily.

> Will debugging code be more difficult?

No. Again, the similarities are already well established, and most debugging will happen within the browser. The tooling already exists to make this easy.

To me, harder doesn't mean you won't have to learn something new, but it's actually more difficult. And that entirely depends on how you have things setup and what tooling you have. This does mean that if I invite LESC and want to use that instead of LESS, it will be harder to use precisely because the tooling isn't present.

I would argue that the wisdom of this goes beyond JavaScript to all programming.

Or, to put it slightly differently: how can you tell the difference between an inexperienced programmer and an experienced one? The inexperienced programmer thinks of every line of code as an asset. The experienced one thinks of every line of code as a liability.

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.

Where would we be if we supported all legacy software? Does there not come a point where cutting support for a class of platforms is a good thing? This article makes some good points, and I think a lot of frontenders (myself included) would benefit from being a bit more "boring", but this article is going a little too far the other way.

I think if this really is your perspective, and you are waiting for the front-end chaos to settle before investing heavily in front-end development, you should just stick to server side pages and use jQuery to sprinkle in some JS sugar.

>>> Be a great front-end developer. Be boring.

I think you could rephrase this to...

Be a great front-end developer by being a server side developer.

His arguments:

Browser support - me: situational but makes very good points.

Preprocessors - me: completely disagree

Accessibility - me: very good points but not restricted to any one type of developer (web apps, spa, server side templates, native mobile, native desktop)

UI design - me: totally agree with his point on browser sniffing, a dangerous game

Third party CSS and Javascript libraries and frameworks - me: seems like he should avoid these altogether

UI architecture - me: this really seems like an opinion that is easily debatable

CV - me: a good voice to have on your team regardless of tech / project requirements.