Blame the implementation, not the technique

Stop me if you’ve heard this one before.

“Responsive design is bad for performance.”

“User agent detection is bad. Don’t segment the web.”

“Hybrid apps don’t work as well as native apps.”

“CSS preprocessors shouldn’t be used because they create blo…

Stop me if you’ve heard this one before.

“Responsive design is bad for performance.”

“User agent detection is bad. Don’t segment the web.”

“Hybrid apps don’t work as well as native apps.”

“CSS preprocessors shouldn’t be used because they create bloated CSS.”

If you create for the web you’ve no doubt heard at least a couple of
these statements. They’re flung around with alarming frequency.

There is a fundamental problem with this line of thinking: it places the
blame on the technique instead of the way the technique was implemented.
Generalizing in this way discredits the validity of an approach based on
poor execution, and that’s a very harmful way of thinking.

With any of the examples above, the technology itself wasn’t the
problem. CSS preprocessors, PhoneGap, user agent detection, responsive
design—these are tools. They are neither inherently bad or good. Their
quality depends on the way you wield them.

I’m not a carpenter. If you asked me to build a table you would end up
with a lopsided, three-legged abomination. That’s not because of the
hammer, or the saw, or the drill—that’s because I suck at using them.
Give the same equipment to a carpenter and you get something beautiful.

It’s no different with our own tools.

When someone builds a 4MB responsive site, blame the implementation.
There is no reason why a responsive design can’t perform well. If you
take the time to carefully build from a base experience up, only loading
assets as needed and using patterns like the anchor include
pattern
to
keep things light along the way, a responsive site can look beautiful
and load quickly.

When someone builds a site and uses server-side detection to exclude
some browsers or devices from the experience, blame the implementation.
There’s nothing evil about user agent detection. You don’t have to use
it to segment experiences. In fact, it’s quite handy as a compliment to
feature detection. Consider that some devices can make phone calls, and
that those devices don’t all agree on the same protocol. Start with a
smart default. Use server-side detection to try to determine which
protocol should be used. If a value is reported use that. You’re
enhancing the experience where you can and offering something usable
where you can’t. There’s nothing wrong with that.

The same goes for using hybrid applications, CSS preprocessors, text
editors or any number of tools. They’re only as good as the person using
them. If you get to know them, identify their strengths and weaknesses
and use them when appropriate, they can be really powerful and helpful
additions to your toolbox.

It’s all too easy to cling to the one or two tools we’re most
comfortable with and discount the rest. Luca Passani hammered (no pun
intended) this home in a recent
post
.
He was discussing the oft-mentioned responsive web design (RWD) vs server-side detection debate
and came to a very sound conclusion:

In this context, isn’t the discussion between RWD and
{device-detection} a direct corollary of the old “when all you have is
a hammer, every problem looks like a nail”? and of course, doesn’t
this apply also the other way around, with backend developers favoring
a solution to device fragmentation that leverages the tools they know
best?

Experiment with techniques before you condemn them. Find out for
yourself if the tool is really where the blame should be placed.

Building great experiences on the web isn’t getting any easier. We need
all the tools we can get. Don’t discredit them simply because someone
uses them poorly.


Print Share Comment Cite Upload Translate
APA
TimKadlec.com on Web Performance Consulting | TimKadlec.com | Sciencx (2024-03-29T13:55:36+00:00) » Blame the implementation, not the technique. Retrieved from https://www.scien.cx/2012/10/04/blame-the-implementation-not-the-technique/.
MLA
" » Blame the implementation, not the technique." TimKadlec.com on Web Performance Consulting | TimKadlec.com | Sciencx - Thursday October 4, 2012, https://www.scien.cx/2012/10/04/blame-the-implementation-not-the-technique/
HARVARD
TimKadlec.com on Web Performance Consulting | TimKadlec.com | Sciencx Thursday October 4, 2012 » Blame the implementation, not the technique., viewed 2024-03-29T13:55:36+00:00,<https://www.scien.cx/2012/10/04/blame-the-implementation-not-the-technique/>
VANCOUVER
TimKadlec.com on Web Performance Consulting | TimKadlec.com | Sciencx - » Blame the implementation, not the technique. [Internet]. [Accessed 2024-03-29T13:55:36+00:00]. Available from: https://www.scien.cx/2012/10/04/blame-the-implementation-not-the-technique/
CHICAGO
" » Blame the implementation, not the technique." TimKadlec.com on Web Performance Consulting | TimKadlec.com | Sciencx - Accessed 2024-03-29T13:55:36+00:00. https://www.scien.cx/2012/10/04/blame-the-implementation-not-the-technique/
IEEE
" » Blame the implementation, not the technique." TimKadlec.com on Web Performance Consulting | TimKadlec.com | Sciencx [Online]. Available: https://www.scien.cx/2012/10/04/blame-the-implementation-not-the-technique/. [Accessed: 2024-03-29T13:55:36+00:00]
rf:citation
» Blame the implementation, not the technique | TimKadlec.com on Web Performance Consulting | TimKadlec.com | Sciencx | https://www.scien.cx/2012/10/04/blame-the-implementation-not-the-technique/ | 2024-03-29T13:55:36+00:00
https://github.com/addpipe/simple-recorderjs-demo