A Baseline for Front-End Developers

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.

I hope I gave due credit to the possibility that part of what's changed is me when I said in the next sentence: "Maybe it’s the result of people starting to take front-end dev seriously, maybe it’s browser vendors mostly getting their shit together, or maybe it’s front-end devs – again, myself included – coming to see some well-established light about the process of software development."

I do think the profession of "front-end development" has grown up a whole lot in the last couple of years. There have been front-end pros since long before I was even in the business, but I think the profession as a whole is being taken more seriously, and a set of baseline expectations for people in the profession is solidifying.

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.

Well it's a good list, I guess it would be most useful to student looking for a career in front-end, you got the next couple of years of skill required right there.

Then I agree with you, web publishing did not change that much, 3 years ago it was a bunch of js plugins together + nice html templates and well, it is still that currently. And I know loads of front-end that only know basic js with a svn client and get by.

Then you got js web apps. There you got a world of difference. It is limitless and evolving like crazy

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.

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

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.

Maybe you should take your opinions about not using client-side code back to 1998

So are you suggesting we give up entirely on single page apps and go back to a full refresh of the page whenever the search terms change on a page?

I am not quite clear of what you are suggesting here. How do you build a system like gmail with it's great response times without innerHTML at some step?

So what's the big difference of doing it on server side v/s client side? You can get it wrong on both sides.

Especially what's wrong with a templating system? A templating system on server side can help avoid casual escaping bugs by doing automatic escaping of everything by default. Exactly the same thing can be done on client side.

OK, I think I found the quote that is troubling you:

> It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers.

So basically we are talking about the case where users machine has been compromised? In such a case I don't really see how you can be sure of anything - that user is screwed.

At the same time the article suggests multiple ways of encoding the data on client side... I'm a bit puzzled.

Maybe what they really meant was that you shouldn't hope at server side that the client side correctly performed the encoding, like hoping the client will escape you database query arguments... but that's just basic everyday knowledge.

comp.lang.javascript was a very inhospitable place. David Mark's touted his "My Library" as the holy grail of libraries while bashing any others, yet kept it closed source (now abandoned).

> an unstable "fragment builder" or `innerHTML` calls. Both are neither stable nor secure

They are as stable as the code using them, just like their server-side counterparts. The parser isn't any less stable when called from innerHTML. Would you mind expanding on security?

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.

I'm a "corporate" windows-based front end developer at a large non-IT organization that employs hundreds of developers. I'm more up on this stuff than most of my co-workers, but I've never used git, requireJS, node, any css pre-processor, or any automated javascript testing.

Some notable things that are common around here that aren't on the list are creating WCF services and sharepoint web parts, and various Microsoft stuff like that. It's a whole different world.

I do front-end development on Windows, and yes, it is a liability (though I'm also not a fan of command-line apps, regardless of platform, which is another liability, since it's much easier to build powerful tools that only expose the crappy, but efficient UI of the command line than it is to develop robust and efficient GUIs).

- Git on Windows is (finally) not bad. You've got Git Bash, Git GUI, TortoiseGit.

- I don't see why the author thinks the CLI is vital for these:

* ssh - Putty

* scp - WinSCP

* ack, grep, find - I like IDEs, when they fit the job, but while I haven't found any suitable for web dev, most handle this task easily. I use Notepad++, which has a decent selection of plug-ins, including one to quickly find and open files in a project.

I do frequently see Windows support as an afterthought, or a non-thought, in the fast-paced world of web dev tools - code linters, compressors, languages/compilers (Coffeescript), build tools. With a decently powered workstation VirtualBox and a Linux VM help ease the pain a bit.

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.

rsync has a few quirks. scp is more-convenient for many people because it shares almost identical options to cp.

The most frequent cause of grief with rsync, in my experience, is presence or absence of a trailing / on the source argument. Many users aren't even aware of the difference in meaning, and even those that are aware still get it wrong sometimes, primarily due to tab-completion.

I personally use rsync frequently, but for newer users I recommend scp, unless they're dealing with a very large volume of data where rsync would provide significant benefit.

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