
A Baseline for Front-End Developers - thisisblurry
http://rmurphey.com/blog/2012/04/12/a-baseline-for-front-end-developers/
======
blauwbilgorgel
My baseline tools and resources for front-end development:

\- Page speed <https://developers.google.com/pagespeed/>
<http://developer.yahoo.com/performance/rules.html>
<http://developer.yahoo.com/yslow/>

\- Valid HTML <http://validator.w3.org/> <http://html5.validator.nu/>

\- Usability <http://www.userfocus.co.uk/resources/guidelines.html>
<http://www.useit.com/>

\- Accessibility <http://www.w3.org/TR/WCAG10/>

\- On-page SEO <http://www.seomoz.org/>
[http://static.googleusercontent.com/external_content/untrust...](http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/en//webmasters/docs/search-
engine-optimization-starter-guide.pdf)

\- Design for the web <http://www.usabilitynet.org/tools/webdesign.htm>

\- Cross-browser compatibility <http://browsershots.org/>

\- Mobile ready <http://www.w3.org/TR/mobileOK-basic10-tests/>
<http://www.marketcircle.com/iphoney/> Modify Headers add-on

\- Progressive enhancement
[http://www.alistapart.com/articles/understandingprogressivee...](http://www.alistapart.com/articles/understandingprogressiveenhancement/)

\- Metadata <http://schema.org/>

\- Conversion Optimization <http://www.conversion-rate-experts.com/>
<http://www.google.com/websiteoptimizer>

------
beseku
You know whats absolutely stunning about this baseline and every discussion on
here about it? Not a single mention of any kind of understanding of design.
Thats nothing short of ridiculous.

I'd take ten front-enders who knew about baselines and typographic rhythm,
relative font-sizes etc. before I took one of these guys. Why? Because these
are the people translating your designs into the final medium, so you have to
be damned sure they will get it right. Without knowing how to use CSS to
represent designs you are pretty much useless to me.

If you've ever had to hold an HTML guys hand through properly aligning the
type or matching up colours then you would understand how painful it can be,
and how vital this knowledge is.

------
justinph
I agree, but would point out that this list seems a bit more oriented to the
type of folks doing web application development, rather than web publishing.
Not every site or job demands knowledge of the latest tools or techniques. Is
it good to know they exist? Sure, but I wouldn't count someone out who does't
actively use git or only knows JS by way of jQuery.

One thing I would add to the list is a conceptual understanding of how a web
page gets to someone's screen. E.g., how a webserver works, what headers are,
how DNS works, caching, general CMS principles, etc. Perhaps that's implicit
in the list, but I've been amazed sometimes by other frontend folks that
didn't have knowledge of some key piece of that pipeline.

~~~
billpatrianakos
The lines are starting to blur though. These days a good generalist with a
penchant for the front end is probably more desirable than a pure frot end
design person. If you're working with teams then version control is mandatory.
JavaScript is now being used far more beyond just DOM manipulation,
SASS/LESS/Stylus are, for many, required knowledge even if you're just doing
static sites, etc. Point being, the lines are blurring the the skillets are
breeding with each other creating a need for generalists more than ever.

You're right when you say this is probably more useful for web apps than
static sites but even static sites are starting to become more app-ish. More
emphasis is (rightly) being placed on things like server optimization and load
times which requires just a bit more knowledge of what's going on in the
backend than before. Take HTML5 Boilerplate for example. Their Apache
.htaccess file is something that the front end guys should understand and even
if you're working alone buildin a static site you should start getting into
setting up those rules correctly and putting a lot of that stuff into Apache's
httpd.conf. Basic CMS knowledge _is_ required. Everyone ends up working with a
CMS eventually unless your entire career is based on building single page
static sites editable in Dreamweaver alone or something. Then there's new toys
like Jekyll. Jekyll and its beginner friendly cousin Octopress require you to
know a few things about the backend too and in fact require most of the skills
the article describes.

So you're right to a point but it looks like as we move forward even web
publishing will start to resemble web app development more and more as far as
tools and workflows go. Gosh, even FTP is starting to go the way of Gopher. I
hope I see the day that even shared hosts start allowing and encouraging SSH
usage over FTP as the norm almost like MediaTemple does.

~~~
jenius
Totally agree here. While I hope youre right, it's very tough to push these
ideas right now. I've been trying to teach advanced front end technologies to
front end guys for a while (haml & ruby logic, sass & sassscript, controlling
and compiling files and projects through command line), and generally people
have a very tough time picking it up because as "front end devs" they don't
really know any programming beyond a bit of jquery.

The popularity of twitter bootstrap pretty much proves your point. With better
technology (like sass), it would not be difficult to make a framework that's
smarter and more flexible than bootstrap. I made one, it is better, and I have
been writing about it and talking about it as much as I can, but NOBODY CARES.
Bundle install? Mixin functions that take parameters instead of putting a
class on an html element? No curly brackets or angle brackets? Too difficult,
too different. Front end devs _don't get it_. What they do get is "here, paste
this stylesheet into the head and everything will automatically look nice." -
and now bootstrap is the most watched repo on github.

As much as it drives me crazy right now, I'm hoping that eventually people
will start to realize that a truly efficient front end dev needs to know how
to program. If you pit me against a dev who is using straight html and css,
making the same website, I bet I could double their speed. That counts for a
_lot_... especially when someone's on payroll.

~~~
robin_reala
In my experience Bootstrap is a saviour to backend debs who don't want to
think about the front end if they can get away with it, not something that
particularly interests FEDs.

------
recursive
> Something has changed in the last couple of years

I don't think there has been nearly as much change as Rebecca suspects. It
sounds like her skills have improved significantly, and that she's projecting
this onto developers at large, but I doubt there has been much of a change in
general.

~~~
cygx
No, Rebecca is right - the game changed for front-end developers when client-
side scripting became ubiquitous, which is a somewhat recent development:

For example, while XMLHttpRequest was introduced in 1999 (IE 5), it took years
to gain traction (XHR support was added to Opera with version 8 in 2005), and
incidentally, JavaScript frameworks (Prototype 2005, jQuery 2006) and
distributed version control (Mercurial, Git 2005) entered the spotlight at the
same time.

While serious JS-based applications were definitely around before the advent
of Web 2.0 (you can go a long way with hidden iframes, long polling, chunked
transfer, forms, 204 status code), these were the exception, front-end work
was mostly about layout and code-reuse virtually nonexistent.

------
tomkin
I often read these types of articles and wonder if the author considers that
there are many flavours of what one might consider a "baseline". While I have
cloned a repo or two, I wouldn't say that it is a mainstay of how I evolve my
abilities.

I could interject all sorts of other expertise that I must use on a daily
basis, where my lack of knowledge of such would render me unemployed. My skill
set has evolved into what someone might call a _designineer_. Do I think
everyone has to be a hybrid designer/developer to get the job done? Of course
not. However, I wouldn't gather those skills and conflate that my skill set is
necessary to getting the job done for someone else.

It reminds me of the _purist argument_ , where the evangelist will protest
against web fonts, frameworks and the like. In 2001, if you were using CSS or
JS you _were not a purist_. We can see that labels like these are to serve a
purpose and it seems to be little more than an exercise in pedantry.

At the end of the day, it's about providing quality work and getting the
respect you deserve for your work.

~~~
rmurphey3
The exact set of skills that one needs in order to do one's job will of course
vary from person to person. What I have tried to point out in this post is
that these _topics_ are ones that anyone who calls themselves a front-end
developer will need to be familiar with; if they are not familiar with them,
then they risk being unable to keep up with the new information that is being
shared about the front-end dev profession. This is based on my observations as
much as my beliefs -- the set of things that you're expected to know in order
to actively participate in the open-source front-end dev community is growing
and changing, and this is my attempt to catalog those things in a way that I
wish someone had done for me in the past.

~~~
tomkin
> ...is that these topics are ones that anyone who calls themselves a front-
> end developer will need to be familiar with

I don't know about that. With Github you profess that experience with git is
necessary to take advantage of "the rich open-source community that has arisen
around front-end development technologies" – but that's not true. Explain how
downloading the repo as a zip is slower or less advantageous than opening
Terminal and typing commands – while I'm already looking at the Github project
page in the browser? How would a purely front-end developer tell the
difference?

> At the very least, you should be aware of tools like UglifyJS or Closure
> Compiler that will intelligently minify your code, and then concatenate
> those minified files prior to production.

In what world? This grates on me because it looks to be little more than
grandstanding. And I hate grandstanding. What if you're coding with RoR or
_any other language with a sophisticated asset pipeline_? Ugh.

50% of the techniques/tools you mentioned could be replaced or removed
entirely without much issue in any front-end developer position I've
encountered – in fact, this rigid brick layering of relative experience may
even be looked upon as negative to an employer as it's clear that you are
unwavering.

> that I wish someone had done for me in the past.

I think it's great for you to catalog and share, but to declare your list as
the defacto baseline is ridiculous and presumptuous.

> _Good front-end devs_ know to prefix any search engine query with mdn

Yeah, not an ego-derived rant at all.

~~~
rmurphey3
I won't address the rest of your comments, but please note that I said "tools
_like_ UglifyJS or Closure Compiler" -- if the RoR asset pipeline is taking
care of this for you, then good! The point is that good front-end devs should
be aware of the need for tools that address the various high-level topics I
listed -- I just mentioned some tools that fill those needs _for me_.

------
mkmcdonald
> This might go without saying, but simply knowing a JavaScript library isn’t
> sufficient any more. I’m not saying you need to know how to implement all
> the features of a library in plain JavaScript, but you should know when a
> library is actually required, and be capable of working with plain old
> JavaScript when it’s not.

I'd like to think this is because ideas of proper scripting have slowly
propagated from goldmines like comp.lang.javascript and into the mainstream.
People like David Mark have pulled back the jQuery curtain and shown
developers that education really is the solution, not mindless abdication of
responsibility.

> It wasn’t so long ago that it was entirely typical for servers to respond to
> XHRs with a snippet of HTML, but sometime in the last 12 to 18 months, the
> front-end dev community saw the light and started demanding pure data from
> the server instead.

Client-side templating was and still is a sham. It requires either an unstable
"fragment builder" or `innerHTML` calls. Both are neither stable nor secure
(IE is very strict with `innerHTML` in particular). I've dubbed `innerHTML`
the "eval" of the DOM as it exposes an external parsing engine to do the
developer's dirty work.

Server-side processing is still the best option, particularly because of
powerful parsers and the ability to hide domain logic. OWASP has an article[0]
that covers XSS and DOM scripting that's fairly interesting.

[0]:
[https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Che...](https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet)

~~~
chc
I'm confused by the contrast you're drawing. Aren't you going to be using
innerHTML if the server sends back HTML? That's how I always remember seeing
it done.

~~~
bmelton
I'm not terribly plugged in to the front-end developer community, so don't
take this as authoritative, but _my_ preferred (and more reliable) method of
handling server input is generally to append new elements to existing,
'container' elements already present on the DOM.

In context, I might have a 'tweets' div on the page that is empty on page
load, but which will be populated by appending new div or li elements to.

~~~
chc
But how are you doing that if the server sends back HTML? Like, say you ask
for a tweet, and the server sends back the following:

    
    
      <div class="tweet"><div class="header"><div class="username">rihanna</div><div class="retweet"><img src="retweet.jpg" alt="retweet"></div><div class="tweet-body">Check out my new tattoo of a woman getting a recursive tattoo!</div></div>
    

You can't send that to document.createElement. Your only options AFAIK are
innerHTML and writing your own DOM parser to build up a tree and use the DOM
API to create the elements one by one (which will be OMGslow).

And of course appending a new element doesn't make a lot of sense if your
changes are transformative rather than additive (e.g. collaborative editing).

------
wrs
Years ago there was a job title at Microsoft called "Web Developer". I refused
to give people this title or hire people into this role, because it was
clearly a dead-end job.

The era of "Web Developers" -- people who can make an HTML page work but don't
have fundamental software development skills -- lasted only as long as the
Great Wheel of Client-Server Development took to make half a revolution.

Now the client has software on it again, and...surprise, you have to be a
"Software Developer" to work on it, not a "Web Developer".

~~~
prawn
See, I'd call those types "Web Designers" and use "Web Developer" for someone
who does a mix of frontend/backend for the web.

~~~
wrs
To be clear, I'm talking about how someone defines themselves and their
profession. Be a "software developer" or a "software designer". Don't put
yourself in a "web" box, because the web will be implemented differently in a
few years...like software always is.

There's a professional skillset that developers and designers should have that
is far deeper and more general than this year's popular web technologies. If
you have that skillset, your career is a lot more secure.

If you're a software developer/designer, and you think of yourself as a "web
developer/designer", you're selling yourself short. And if you're beginning
your career, know that you'll need learn how to develop/design software, not
just "web".

~~~
prawn
Might be different in different regions and sizes of business - I don't work
for a large business, I run a small business. I have called myself a Web
Developer (if anything; usually I don't give myself a title) since 1995 and
got by OK. There has been more than enough work for 15+ years. If the
technology changes a bit, we either adjust or we don't, right?

Maybe it's a lot different in large corporations?

------
robin_reala
I’d be interested to hear from Windows developers. I do most of the stuff on
this list already, but I’m on a Mac and have been for a few years. Are the
ecosystems noticeably different?

~~~
billpatrianakos
I'm not a Windows developer but I've tried my hand and work with a lot of
people who are getting into the things described in the article using Windows.

Things really are harder and it's something I've been trying to explain to
people I'm mentoring and they're finding it out the hard way. The thing about
that statement is that a lot of times people will start a holy war over it. No
one is saying Windows sucks here. It may or may not suck but that's beside the
point. The reality of the situation today is that the majority of the open
source community is creating things that will eventually be running on a Linux
server. IIS is just not used all that much at all outside the corporate space
and even they are moving toward Red Hat these days.

But any time I explain to someone that they'd have a much easier time on a Mac
or Linux distro they start an argument and give me that "you're an elitist"
look. I'll tell them to use Git but they need a special program for it. I show
them SSH and they need another app for that. Same for Ruby, most local dev
servers, etc. and then every mundane command for me turns into twice the work
for them because they have to do what I'm doing plus whatever extra steps plus
configuration on their machines.

It's really frustrating for them and they give up. A lot of times a person who
has learned some basic HTML and CSS who wants to level up and start doing some
version control and set up a remote server ends up giving up on the whole
thing.

So the whole ecosystem really is different as everything is built with a _nix
environment in mind. I'd been working on a Mac for a long time and needed a
laptop. I got a cheap Windows laptop and thought I'd dual boot with Xubuntu so
that I could deal with certain Windows file types and have an easy way to test
sites in IE. Well, I ended up booting to Windows less than 10 times in 6
months and eventually got rid of it altogether because there was nothing
Windows did that my Mac or Xubuntu couldn't. I even tried to write so,e
desktop software and do some web dev and found that Windows is awesome for
desktop apps... If you're only developing for Windows... and Windows is great
for web development... if you plan to use an IIS production environment and/or
you're going to program in ASP.net or C# exclusively.

But again, this isn't a Windows bashing party here. It's just the reality of
working with open source and web dev in 2012. There are certainly things that
make _nix systems difficult to work with depending on the context but as it
stands we're living in a time where *nix is the default platform for web
development.

~~~
MatthewPhillips
Unfortunate truth. Microsoft made a major error in abandoning the command line
so many years ago and it is crippling for developing in not-.NET. powershell
isn't the solution. Windows doesn't even ship with an unzip cli tool It
doesn't ship with a curl equivalent and to get curl you have to go to a page
with pop-up ads and download some other dependencies on top of it. Windows
doesn't ship with a Screen or Tmux equivalent. All of these things are
unacceptable.

~~~
MattRogish
Played with Win7 today in a VM, trying to test IE stuff - you can't even drag
the command line window handle to make it bigger. Your options are taller
window or full screen, but the text just gets larger. Pure garbage. Glad I
switched to OSX a long long time ago (Linux is also equally awesome, but I
like the hardware/software integration Apple gives me).

~~~
jaredsohn
This is possible to do, but you need click on the icon in the top left corner
and then properties. Full instructions here:
<http://stackoverflow.com/a/319317/478893>.

You can also do this by running a third-party console app.

As a post earlier in the thread indicates, you can often do the same things on
Windows but it requires a little extra work.

~~~
eropple
Literally every third-party console app sucks, though. Making it even harder
is that the terminal emulators available through cygwin are bad, too.

Last time I needed to use Windows, I installed sshd in Cygwin and used
Penguinet to connect to localhost. It was that bad.

~~~
mquander
For what it's worth, I find Console2 tolerable.

<http://sourceforge.net/projects/console/>

------
lukevdp
This sounds more like the author is saying "this is where I am at with my
skills, and so everyone should adopt them as a baseline".

Maybe for his particular job what he describes is the baseline, but it's much
too specific for a general baseline

~~~
puppybeard
You have a good point. All the skills listed are good things to have, but you
wouldn't look for half of them in my current job, a lot of it would be
useless.

And an understanding of design and usability is vital, even though we're not
the designers, and most jobs I've seen require that, but it's not even
mentioned in the article.

------
MortenK
This is not a baseline of any sorts, it's a list of tools and techniques
preferred by the author. While a personal list of preferred tech is fine, it's
by no means a standard established baseline, without knowledge of which you'll
"feel more and more left behind".

This should be titled "My top x tools and techniques for front-end
development".

------
saltcod
Where is the boundary for JavaScript.

Is it:

1\. Just jQuery—some hide/show/toggle/etc

2\. That combo of "real" JS and jQuery—writing your own functions and calling
them later on

3\. "Real" Javascript—knowing Node.js, writing plugins and the like.

I'm somewhere between 1 and 2, and I suspect most are. The jump to writing
"real" Javascript is just huge—in fact it requires actual programming
knowledge.

If you get to stage 3, are you still a front-end developer or are you a
programmer now? And the question I'm really curious about, should I invest all
that time learning to program actual Javascript, or should I focus on all the
other stuff?

------
SkyMarshal
_> scp to copy files to another machine or server_

Shouldn't that be rsync? I was under the impression scp has been fully
superseded by rsync. Secure, more efficient, basically only transfers diffs
instead of whole files.

~~~
mattbriggs
when I want to grab the latest version of a 30gb database dump, I think rsync.
When I want to grab a file off my desktop when I am in a meeting, I think scp

~~~
SkyMarshal
Interesting, why not rsync for the desktop file too?

~~~
mattbriggs
It's mostly inertia, I know the scp command way better then rsync, and for
small things (which are the majority for me),it doesn't matter so much what I
use.

The other day, a coworker freaked when I searched for a file using find . |
ack file,instead of just using find properly. I gave pretty much the same
argument, so he measured it, and found I was losing about 0.002s. He basically
said it was he principal of the thing, but for command line tools I really
need a good reason to learn something new without any noticble benefit 99.9%
of the time

------
feralyn
This is a fantastic list of great things to know. Right now.

However, I wouldn't consider this a "baseline" as A) all of it can be quickly
learned by an experienced dev and B) not all environments are rails/node.

This industry changes languages/platforms/techniques like I change my socks.
The key is not to memorize this list and use everything on it, it's to
understand what's on this list, what else is out there, and _use the right
tool for the job_.

------
Loque_k
Less talk more action, posts like this are great as most devs will know most
of it - and for those that dont, they now do. Just keep doing what you do,
improving your skills and bettering yourself as much as possible.

Surround yourself with great people, share, discuss and don't be afraid to ask
silly questions. Everyone is a noob in some aspect.

------
Garbage
Am I the only one who is wondering why the hell Firebug is missing from the
list of "In-Browser Developer Tools"?

