
The boring front-end developer - edwinjm
http://thebfed.com/
======
cnp
I worked for a few years at an agency that adhered very closely to these
principles, and you know what? When things started to rapidly change around
2013 everyone was consumed and overwhelmed, and when it came time to
_necessarily_ onboard them on new technologies such as build systems, css
preprocessors and the like, the skepticism was so profound, and caused such a
problem for those of us looking to make everyones life easier, that the
process took way longer than it should have taken with loops and hoops that I
hope to never have to repeat.

After that experience, I fully equate the BFED with someone not ready to
handle the incredible momentum of the industry and, for better or for worse,
would never consider hiring them. There are too many good ideas being born
right now to risk falling into rigid patterns of thinking.

~~~
copperx
> There are too many good ideas being born right now to risk falling into
> rigid patterns of thinking.

The problem is that there are too many ideas out there, period. It's almost
impossible to separate the wheat from the chaff. See: JavaScript libraries.

~~~
nkassis
Definitely an issue but it shouldn't prevent you from using some tools. For
example, I've mostly stayed away from compile to JS languages except for
ClojureScript (for personal project) and TypeScript because I see real value
in both of them. TypeScript has been a massive boon to help with the largish
client side app I work on professionally. Helps keeps the code base somewhat
sane and easy to develop in.

CSS preprocessors have been similar, cutting down on duplication that leads to
potential bugs is hugely useful.

Obviously taking small steps and sticking to things as long as there is no
major benefit from switching helps. No reason to jump from Angular to React or
whatever is new if it's fulfilling your needs.

~~~
omouse
I wish I was using TypeScript right now; we're using babel for ES6 transpiling
and I've found a situation where a particular importing of a module doesn't
work correctly. It appears correctly when I run it through the eslint tool and
babel/webpack don't seem to complain when compiling, but in the browser it
doesn't work.

When trying TypeScript and CoffeeScript I never ran into issues like that.

~~~
cnp
OMG, Webpack... you love it and you hate it.... and it never gets easier!

------
j_baker
Blah. Yet another "new-fangled technologies have no place" post. Granted,
there's a grain of truth to the core thought. As I've become more experienced,
I've seen more frameworks and libraries that re-invent the wheel and solve
problems that have already been solved long ago, albeit in a trendier manner.

But at the end of the day, software engineers are technologists. Our job is to
create and consume technology. Being afraid of new technology is counter-
productive.

~~~
JustSomeNobody
I didn't read that in the article. Being a technologist means know when NOT to
use a technology as much as knowing when to use it. There're way too many
developers who read links from HN and try and push the javascript framework of
the weak on everyone at their job without fully comprehending the consequences
of their decision. That's not being a technologits, that's being stupid.

~~~
0xdeadbeefbabe
> and push the javascript framework of the _weak_

(emphasis added)

~~~
ericson578
freudian typo, is there such a thing?

~~~
JustSomeNobody
Haha, maybe...

That was bad. Normally I try not to have such typos, but it is Monday.

~~~
0xdeadbeefbabe
It was brilliant!

------
smacktoward
_> “As a Lead JavaScript Engineer, I try to get my team to write as little
JavaScript as possible.”_

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

~~~
akilism
double edged sword though right?

we should be striving to write the most readable and easily understandable
code. neither the most lines or the fewest but what can be easily proven and
reasoned about.

~~~
marcosdumay
Yes, ok. Some lines are more of a liability than others.

------
vilmosi
Good article, I agree with a lot of this, but I can't help myself from
commenting.

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

Really? You will ignore the many many advantages of pre-processors because it
will be harder to train new people? Come on...

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

That's a bit one sided. There's a time and place for SPAs, you can't just
dismiss it entirely. Every web app today should be an SPA.

Edit: I should clarify that by webapp I don't mean website. There seems to be
some confusion.

~~~
vezzy-fnord
Controversial opinion, but I myself use CSS preprocessors quite sparingly. I
actually see nothing wrong with the CSS syntax. I _like_ the fact that CSS is
(almost) nothing but a bunch of named key-value pairs. The real issues have
always been semantic, in the subtleties of the box model, which Flexbox is
addressing somewhat, though more daring ideas like constraint-based styling
are still niche.

Just look at the LESS example on the front page. The compiled output is
simpler than the source you're writing. I find having some code duplication to
be an acceptable trade-off for turning a basic declarative configuration
language into a chimera DSL that must be incorporated into the build process.

The more a configuration language strays away from being declarative, the less
desirable this becomes.

~~~
sanderjd
I think "some code duplication" massively understates it. Being able to use
named variables for colors is on its own enough of a win to make up for
whatever truth there is in the "harder to train developers" downside. The many
other wins make it a no-brainer.

~~~
thebfed
It's not the only downside to consider. [http://adamsilver.io/articles/the-
disadvantages-of-css-prepr...](http://adamsilver.io/articles/the-
disadvantages-of-css-preprocessors/)

There are a lot of advantages to them that need consideration too granted.

~~~
sanderjd
Certainly, everything has trade-offs, but CSS pre-processors are more heavily
weighted toward the positive side of the trade-off calculation than pretty
much anything else I can think of, especially in the "web technologies" space.
I found lots of the arguments in the OP to ring true – things often feel far
too fancy, and the more "boring" stuff has major appeal – but I found the
arguments against CSS pre-processors there and in the article you linked
_very_ thin relative to my experience with them after years of using raw CSS.

------
xb
Boring has its place, and certainly can add a lot of value to a project. If
everyones goals are aligned in creating a rock solid web site or app that
never needs refactoring and has 100% legacy browser support, then boring is
great.

Some of us are attracted to new technologies, and appreciate learning the
lessons of what advantages or disadvantages come from building the same type
of site or app with a different framework or technology stack. Especially
those of us who aren't yet mature enough to write our own apps without the
guidance of frameworks, and have not had a chance to work with all of the
different possible approaches.

I think a healthy balance can be struck between the type of stability gained
from the 'boring' approach, and the types of gains that can be realized from
newer 'non-boring' technologies. Sometimes supporting IE6 is not a concern at
all, and learning new language features from ES6 is an attractive proposition.

If doing front-end development were boring, I don't think I'd be as interested
in doing it.

------
alanh
First things first: This article presents a lovely sentiment — although any
argument against CSS preprocessors is a losing one — and is a timely reminder
to focus on the things that matter.

However…

When was this published? There’s no date anywhere on the page or even in its
source code, but he mentions supporting "IE6 and below". This is actually no
longer possible if “HTTPS” is a requirement, as the best version of SSL
supported by IE6 is SSL v.3 which suffers from a fatal vulnerability and
supporting it on your servers puts your users at risk.

There’s also no need to support IE6. Now that XP is this-time-we-mean-it
officially dead and unsupported, you can't even run a fully patched OS with
IE6 on it.

 _Edit:_ Via another page on the author's site, I was able to find a
publication date of 1 October 2014 for this article. (This just barely gets
Mr. Silver off the hook, as the final-nail-in-IE6's-coffin SSLv3 bug POODLE
was announced a mere 2 weeks later. That is, if we ignore the "and below"
remark. No one has tested their site in IE5.5 in damn near a decade now.)
Please, authors: Include the full date with your written works. (Leaving off
the year is a shamefully common anti-pattern, as it's the most important
part!)

~~~
osconfused
This makes me wonder if there is a SEO bump/penalty associated with article
dates.

~~~
alanh
Doubtful – i think it's mostly oversight, but I’d be curious to hear from
those perpetrating the trend!

------
aesthetics1
While interesting, we cannot _all_ be BFEDs. The reason the BFED exists is
because the non-BFEDs pushed the envelope years ago to make what the BFED now
relies on _standard_.

------
serve_yay
A nice thought, but front-end tools are not really mature enough to be boring,
sorry. I mean one could credibly say "oh I'm so boring, I use jQuery
everywhere" but... that's not actually going to be a boring development
experience. It will be exciting, in the bad way.

~~~
hiphipjorge
The problem with jQuery is not so much jQuery itself, it's the architecture of
sites/apps written with many jQuery plugins and no code organization. I wrote
many apps using simple JS modules (with browserify) using jQuery for DOM
manipulation and the approach worked great. While I don't really use jQuery
anymore, it's great for what it aims to do: DOM manipulation.

The point is that exciting development experiences (in the bad way) are
usually due to developers not really not knowing what they're doing. Picking
your tools is part of that and no tool will, inherently, provide a bad
development experience.

~~~
serve_yay
> The problem with jQuery is not so much jQuery itself, it's the architecture
> of sites/apps written with many jQuery plugins and no code organization.

Yes, precisely. But you could conceivably call such a ball of mud "boring"
because there's nothing cutting edge about it.

------
JamesBarney
"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."

The power of popularity should not be underestimated, there are very large and
powerful network effects that popularity brings to the table.

Popular code

    
    
      -has more tutorials/blog/books written about it
    
      -has more Q & A on Stackoverflow
    
      -is easier to hire for
    

All frameworks have problems with better designed frameworks having less. For
popular frameworks you're in luck, because somebody has already figured out
all the work-arounds to common problems. But on an unpopular one you have to
figure out all those work-arounds yourself.

~~~
thebfed
McDonalds and Coca Cola is very popular - is it good for you?

------
omouse
Boring front-end developers also aren't involved in the project planning or
design process so they're low-status. Of course I expect them to follow the
spec and do things the boring way, because that's what they're paid to do. New
tech? That's a new risk, better find someone else who will do exactly what we
ask and not try to "improve" things.

What I see from the frontend developer community with all these new frameworks
and tools is a rebellion against project managers and clients and the whole
agency model which makes creating websites the most bland process imaginable.

Every single thing listed in the article is _more fun_. Being boring is fine
but you better be paying the dev either very little because you don't really
value them, they're simply a machine for turning your ideas into code; or you
pay them a lot because you know if you don't they'll leave and take their
great ideas and work for a competitor or start consulting and stealing
clients.

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

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.

~~~
minitech
It’s not so much about supporting legacy software as having something that’s
likely to show something in any browser, from Firefox to IE6 to Dillo to Lynx.

~~~
akilism
Am I supposed to worry about IE6 when Microsoft doesn't? Can we draw the line
at supporting things when their creators give up on them?

~~~
minitech
The point of my comment was to say you don’t have to support old or obscure
browsers specifically; just have proper content in your HTML and everyone will
be satisfied without additional effort on your part.

------
carsongross
_“As a Lead JavaScript Engineer, I try to get my team to write as little
JavaScript as possible.”_

Yes.

Let me show you mine: [http://intercoolerjs.org/](http://intercoolerjs.org/)

Not mature enough yet to be completely BFED, but that's the goal.

~~~
serve_yay
So you move the JS into the markup, with special attributes. Hmmph.

~~~
carsongross
Hmmph, indeed.

However, it is a much simpler conceptual model than doing it w/ javascript off
in some jQuery onLoad function: web requests just hit URLs like they always
have, download HTML content like they always have and swap it into a
rectangle, like they always have. It's just that the rectangle doesn't
necessarily have to be the entire screen like it always has.

The behavior of a given bit of HTML is fairly localized, which makes it easy
enough to understand what, say, a button does, and the server side controllers
and templating work like they always have.

So, all in all, I'd call it maybe a 7/10 on the curmudgeon scale.

~~~
jdsampayo
I think you will like Angular.

~~~
woah
I think that OP likely knows angular and dislikes it.

------
stupidcar
The boring front-end developer doesn't get paid very much.

~~~
teacup50
Neither does the exciting front-end developer.

~~~
atinoda-kestrel
Oh he does. Just only while the VCs are writing checks. ;)

------
vlunkr
I don't see the need to be so one-sided. You can be "boring" in some ways and
still use new technologies when it's appropriate.

------
awkward
This article is terrible. It argues for awful web and UI development, and
seems to be doing it entirely out of some kind of perverse pride.

The first item in this list recommends support for IE6 or below, a decision
which will massively balloon your project budget for a shot at roughly %1 of
the total browser market. Microsoft itself has launched multiple campaigns to
get developers to stop supporting IE6.

Charitably, I'll assume the author doesn't want to lump javascript compilers
in with preprocessors, although his arguments against seem like they might
suggest he does.

Following that, he recommends development using progressive enhancement, which
was developed as a best practice largely to wiggle out from the constraints
imposed by IE 6 during the eight years where it was crushing the shit out of
the web industry.

As a closer, he suggest that you not learn "buzzword" technologies in order to
increase your day rate.

In summary, he wants you to target ancient technology, eschew any front end
build process, live in fear of the ancient technology you've agreed to
support, and then not get paid for it.

~~~
michaelbuddy
Yeahhh, you've not written a very good summary of what he wrote. But I hope it
felt good to get a word in at least.

~~~
awkward
Acceptable risk levels vary from project to project, and often it is a good
choice to de-risk your UI so that you can budget risk to something more
important to project success. I am currently working on a manufacturing
support project that uses jquery in a progressive enhancement style, for
instance, because that's the most comfortable level for the team, and we
prefer to have the risk in the part of the code that gets into the business
processes. This means we use a framework, LESS (for bootstrap UI) and we
support web standards. We do not support IE6 because one cannot legally
purchase a computer that runs IE6 in 2015.

The article is making statements that claim to be conservative, but were too
conservative for businesses supporting them to survive. In 2006.

This is a bad article. I had trouble finding the date on it, but on the site's
index it states that it was written in 2014. This makes it violently out of
date at the time of it's writing. You should not treat it like a good article
because it flatters your prejudices about new-fangled web development, because
most of the content of the article is flattery. Not only that, it flatters you
for not paying attention to what is going on. That should be a bad sign.

------
kdamken
Anyone who's ever actually written a website using vanilla CSS and then gotten
to write a site with Sass knows that not using a preprocessor in this day and
age is insane. It makes things 1000x easier to write and more importantly to
maintain.

Writing vanilla CSS after using a preprocessor is torture.

------
EnderMB
For those of us that work on bog-standard websites for clients, I definitely
agree with some of the points. I've worked on numerous projects where the
latest and greatest tools at that time were used wherever they could have been
used, and more often than not six tools are being abused to do the work that a
reasonably simple build script would have achieved.

With that being said, all tools have their place, and it's all about realising
what that place is. For example, using Foundation when your client has
expressed a desire for their site to work in IE6 because their clients all
work in large law firms and are limited to XP and IE6 (a genuine use-case I've
had to build for about three years ago) your tool will probably fail you.

For me, it's less about being a "BFED", and more about planning your solution
before you build it, something that increasingly few people seem to do. In a
lot of cases where people do plan or spec work before they start it, it's done
in a tool-oriented fashion. A developer will tell the client that they will
build their site using AngularJS, but when the client says "I've tested this
page in IE7 and it doesn't work. Please fix." they realise that a task they
thought about take n hours will actually take a fair bit longer.

A boring developer gets the information they require first and picks a
suitable tool for the job. If the requirements change, so be it. A boring
developer will get the new requirements, and will adjust their solution
accordingly. This is the kind of boring developer to be, not the kind that
doesn't pick a tool because it's new.

------
roneesh
When I teach HTML/CSS/JS, I tell my students this: "put as much functionality
into HTML/CSS as you can, and use JS as a frequent, but last resort". I think
that sums up the benefits of this article without carrying along any of the
needles anachronisms (use pre-processors, they're great). With animations,
transforms and html5 form validations, you can avoid JS for longer than you
think.

------
Sakes
Front-end is crazy, so I can sympathize with the author's desire to use it
minimally.

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.

------
Animats
There are times when you need heavy machinery running in the browser. It's
impressive to see a water surface simulator or some live graph running in the
browser. That's rare, though. Many sites that would work perfectly in HTML 3.2
have way too much machinery behind them.

Much of the heavy machinery is there to support two simple functions -
adapting to screen size, and scrolling. That's because the HTML5/CSS model
does not natively do either very well. Other machinery is there for form input
validation, which HTML does not support directly.

There is, of course, the other major use of Javascript - silently obtaining
information about the user and sending it somewhere to be "monetized".

------
Wintamute
Hmm. There is truth to some of this, but like everything moderation is key.
Use your experience to pick new tech that meaningfully improves UX, DX,
maintainability or some other metric without creating problems. It does exist.
Likewise, don't be the boringest of boring developers because you'll miss out
on key innovations and your product will suffer. Unless, that is, you want to
make a name for yourself as Supreme Leader of BFEDs for career advancement
purposes, in which case host a clickbaity blog about it and argue from a
highly polarized position ... oh, wait

------
hlfcoding
The irony is implementing progressive enhancement and accessibility is
anything but simple, and probably just as big a maintenance burden as custom
form controls, and comes with debatable gain.

Each project and team and project is different, there's no constant
requirements in frontend, in tools or features. Some teams may be super
unproductive without Sass. This post is very much written from the bias of
older trends, and from a time when the frontend had fewer real concerns other
than styling a document.

------
scelerat
In my experience, any learning curve for the popular CSS preprocessors (SASS,
LESS) is dwarfed by the maintenance and productivity gains. The only downside
to them is that thoughtless use of them can lead to very bloated CSS builds.
But onboarding? LESS and SASS, fundamentally, provide what CSS should have
provided from day one: nestable rules/statements, macros, and variables.

Other than that, +1, good read, will share.

------
kylnew
Hmm pretty broad strokes. I think its constantly important to scrutinize
ourselves and our tech decisions like this though.

I don't think I'd ever take a front end job that doesn't use a CSS
preprocessor, though I understand it was part of a larger example.

It seems like the best product might come out when a BFED and CED need to work
together and have the appropriate chemistry not to kill each other.

------
at-fates-hands
The debate on preprocessors should be moot. As an agency, you can hire people
who already know and use it everyday - thus the onboarding and debugging costs
become irrelevant.

If you're not learning or using preprocessors, the only person you're hurting
is yourself. You're just self selecting yourself from future work considering
so many places use these now as a standard.

------
crucialfelix
Moderation in all things. Don't be boring, don't be trendy.

------
caltonji
reminds me of
[http://motherfuckingwebsite.com/](http://motherfuckingwebsite.com/) (NSFW
language)

~~~
keithpeter
I always hear that page in Gil Scott-Heron's voice. But then he was very
sparing with the bad language indeed so that when used it meant something.

I do miss the fast-web (you know, text and pictures)

------
atom-morgan
This may all be true but at the end of the day a lot of companies aren't
looking to hire a BFED.

~~~
michaelbuddy
yes they are, all over the place.

~~~
atom-morgan
My own experience on the job market is largely the opposite even if they say
otherwise.

~~~
thekingshorses
I am hiring. [http://interana.com/](http://interana.com/)

~~~
atom-morgan
Unfortunately I just accepted a job offer about a week ago. Thank you though
:)

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

~~~
vdaniuk
This "manifesto" doesn't even try to consider tradeoffs. There is no analysis
of stakeholder preferences or path-dependent UX/UI evolution or personal
projects for fun and learning. It doesn't consider neither business
requirements nor developer satisfaction.

However, the article is quite good at hipster shaming, so it gets upvoted to
HN front page. A classic example of link bait tailored for its audience.

It's telling that your comment with point by point discussion of BFED
propositions is at the very bottom, btw.

>He/she will not just use [insert buzz word here] to improve his/her chances
of finding another job based on the current technology fad in order to
increase their day rate.

And this quote is just... wow.

~~~
michaelbuddy
what is "path-dependent UX/UI evolution" ?

------
comrade1
I always tell my guys that I don't want them to think outside of the box. We
should be firmly inside the box. (This is our inside joke, but there's also
truth to it).

------
curiousjorge
WISYWIG UI builders that are slowly picking up momentum will eventually end up
commoditizing this role. There will come a day when a product designer can
just create the UI from mockups, generate tested, clean plumbing code much
faster and more reliable than getting a front-end developer to do it. I would
start learning to get proficient with upcoming UI builders and whichever
framework it ends up supporting (most likely React).

~~~
minitech
Yes, I remember when FrontPage achieved this very same revolution.

