The wonderful and terrible thing about front end development is that it's hacks built on hacks. Really pushing what browsers can do requires the acceptance of this and the willingness to put in even more hacks so you can package a relatively leak-free abstraction. It's that creation of abstraction that marks front end engineering and what we should be striving for. I work at a web shop of 30 where we have a dozen people who fit the criteria in your article more or less exactly...and they're our designers. What separates our front end developers is bringing algorithmic efficiency, knowledge of browser internals, separation of concerns, development methodologies, testability, etc. to the code our designers write. It's accepting and working with the instability while knowing and building towards the stable that makes front end engineering what it is. That and the intricicacies of how browsers interact with the standards and a working knowledge of the design disciplines.
I think the point where we can meet is that it's easier to teach a good web designer+beginning programmer enough software engineering to be useful than it is to teach an expert developer browser quirks and design.
I think a big part of the reason hiring for the front end is difficult on top of the wide skillset is the discipline didn't even have a name three years ago. I spent years ('03-'06) trying to figure out a job categorization for myself that wouldn't have me doing graphic design or writing stored procedures (I can do both competently but not well). For a couple years, just the fact that I knew "Ajax" opened doors and it took quite a bit of work to wrangle through the various browser quirks but as tools advance the discipline--and people expand their skillset--a much wider set of people have the page scripting skills that were cutting edge in 2005. Similarly, the rise of the second level of javascript libraries (KVO, MVC, MVVM, Modules, etc) will allow more people to build more stable solutions and the general practice will be what's cutting edge today. I expect this second stage will make it easier for the back end developers to transition over, though I suspect the dedicated static language people will continue to have trouble.
I think the point where we can meet is that it's easier to teach a good web designer+beginning programmer enough software engineering to be useful than it is to teach an expert developer browser quirks and design.
I think a big part of the reason hiring for the front end is difficult on top of the wide skillset is the discipline didn't even have a name three years ago. I spent years ('03-'06) trying to figure out a job categorization for myself that wouldn't have me doing graphic design or writing stored procedures (I can do both competently but not well). For a couple years, just the fact that I knew "Ajax" opened doors and it took quite a bit of work to wrangle through the various browser quirks but as tools advance the discipline--and people expand their skillset--a much wider set of people have the page scripting skills that were cutting edge in 2005. Similarly, the rise of the second level of javascript libraries (KVO, MVC, MVVM, Modules, etc) will allow more people to build more stable solutions and the general practice will be what's cutting edge today. I expect this second stage will make it easier for the back end developers to transition over, though I suspect the dedicated static language people will continue to have trouble.