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.
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.
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.
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.
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.
It sounds like you're confusing front-end developer with designer who knows a bit of javascript. I think there is a burgeoning group of developers who build javascript/client side applications. These people aren't really designers, and have programming chops.
> 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.
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.
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.
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
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.
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.
I found your list to be spot on. I certainly have my weaknesses from that list, but I'm familiar with everything you mentioned. I've been making Websites for around eight years, but really only the past four have I considered myself a front-end dev.
It seems like every month there's a new fron-end trend that needs to be experimented with and learned. It gets a little daunting at times (hard to find the time, really) so I'm glad effort is being put in to lists like yours. I think it would be invaluable to a beginner.
> ...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
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.
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".
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".
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?
> 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.
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.
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.
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.
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).
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?
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?
> comp.lang.javascript was a very inhospitable place.
To novices and the weak of heart? Sure. I've yet to find a greater source of technical depth regarding JavaScript.
> David Mark's touted his "My Library" as the holy grail of libraries while bashing any others, yet kept it closed source (now abandoned).
It seems that you've turned a blind eye. His code's been available in a multitude of ways (I've used it myself as a learning tool). There's a GitHub repository[0] as well.
> They are as stable as the code using them, just like their server-side counterparts.
The prime difference here is that most browsers do not throw markup errors or halt execution upon a bad tag; they're extremely lenient. Conversely, direct parser access via JavaScript can throw a host of errors and halt execution (as I noted with IE). Fragment builders are hampered because they're either too dynamic for their own good or need to keep a laundry list of valid attributes.
> Would you mind expanding on security?
Apart from the OWASP article I linked earlier, it's more of a statement towards older environments. Browsers today escape input nicely, but that's meaningless for Joe Smith, government bureaucrat on IE 6. I prefer direct node creation patterns via `createElement` et al. for this reason (especially text nodes).
> The prime difference here is that most browsers do not throw markup errors or halt execution upon a bad tag; they're extremely lenient. Conversely, direct parser access via JavaScript can throw a host of errors and halt execution (as I noted with IE).
In practice, this just isn't really a problem. The situations in which it can happen are specific and limited enough that I don't know if you got really unlucky sometime or if you're exaggerating for effect, but I've been writing JavaScript since the '90s and have never found this to be much of an issue — particularly since libraries can easily smooth over it.
And if you think innerHTML can throw errors, you should check out the DOM API. The set of valid inputs to the DOM API is far more limited than for innerHTML. document.createElement("oh no") will throw an error in every browser around.
To novices and the weak of heart? Sure. I've yet to
find a greater source of technical depth regarding
JavaScript.
I agree with you about the usefulness of comp.lang.javascript, but I disagree regarding David Mark's contribution to education. I had to killfile him years ago, mostly due to his use of sockpuppets. Here are just two of his Reddit sockpuppets that I made note of years ago when I still visited Proggit:
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?
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.
It is. Microsoft development shops that d0 websites for businesses still primarily use WebForms even though it has been essentially deprecated for a few years now. Creating controls is a common paradigm in windows programming going back to the Delphi days so WebForms is easier to learn (even though the html it produces is sacrilege).
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.
As someone who works with Linux and Windows, I agree with what you're saying here.
I hate Putty though.
I use Aptana for writing my code, and quite like the built-in terminal in that for SSH.
You may already have tried Aptana, but I find that I use Notepad++ only for quick jobs these days, rather than longer coding sessions, so it seems to make my life easier.
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 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.
Oh, God, yes.
I teach a class of aspiring hackers on the weekends, and they're all gamers and they come in with their windows laptops. Every once in a while I'll have a piece of a lesson where they need to install some dependency or compile some code they wrote in a text file, and it just brings the lesson to a screeching hault.
Having them download a python cli so I could show them how to use python as calculator in one of our earlier lessons ended up being more trouble than it was worth.
Windows is just not developer friendly if you're working in anything but .Net - and I think C#-.Net-Visual Studio programming for windows desktop applications is the best programming experience there is. I just don't have many clients asking for that.
Ruby and Python take like 10 secs to install on Windows these days. Not sure what you're doing wrong. The only annoying thing is occasionally you come across a python library that needs compiling and that turns into a veritable nightmare.
Simple trick I do on my windows machine is to create a bin folder and add it to the PATH settings so you can just bung things like curl and sqllite in there without faffing around.
I'm not saying it's great and windows is definitely cli hostile, but you're exaggerating the problems.
Just teach your hackers win key+r or on win 7 they can just hit the win key, type cmd, press enter. Then type irb or python, enter. Done.
It may take you or me only 10 seconds to install python on Windows, but my students need my help for every step. Even if I tell them to get up and I do it myself, it's still 10s X N students to get everyone up to speed.
Compare that with zero seconds for Mac or Linux, both which come with python installed.
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.
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).
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.
First thing, if you're required to use a Windows workstation, is install Cygwin, and I really like puttycyg[1] as a terminal.
One fairly simple install gives you all the basic unix utilities, and almost anything else, yes even X11 stuff, is available in a fairly usable click-to-install management interface.
I installed Octave on my windows machine last year in order to participate in Stanford's Open Classroom Machine Learning course and was surprised to find all of the gnu-tools installed (MinGW) and that they worked seamlessly in the Cmd console or in Powershell.
As much as I love Linux and find that I learn much more about C and computers in general by using Linux, it isn't as difficult to go back and forth as you say.
While MinGW is great for some things, I prefer Cygwin, which is more complete and the package manager is a particular godsend.
It's common for Windows ports to package their own MinGW version (Strawberry Perl, MSYS-Git, ...), which is less than awesome, but you can compile the things you need from source. It's often a bit tricky, though (I used to compile Git and Perl from source because at the time the Cygwin packages were either non-available or outdated, but it's not for the faint of heart).
As Cygwin comes with MinGW cross-compiler packages, I no longer keep a separate MinGW/MSYS environment around, and I'm reasonably happy with this setup.
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.
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".
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.
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
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
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?
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.
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.
- 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...
- 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...
- Metadata http://schema.org/
- Conversion Optimization http://www.conversion-rate-experts.com/ http://www.google.com/websiteoptimizer