If you’ve scoured web developer vacancies lately, then you might have noticed most opportunities are in web application and database development (as opposed to website development). The coding expertise needed for those endeavors pertain to manipulation of server-side lists independent of style or user-end presentation. PHP is now being paired with a polyglot of other codes such as Ruby on Rails, Java, and the ASP.Net languages (VB.Net, C++, and C#) -- all server-side and therefore requiring a compiler-compatible server on which to test. The latest version of client-side markup, HMTL5, is occasionally seen listed after the more prominent server-side languages in the required job skills.
This marks a drastic departure from HTML-JavaScript-CSS-PHP-Perl quintivium of quality from the 1990s. What could have been the primary force in that migration of business web technology preferences when each of those technologies enjoys continued developer support?
In his 2010 book Joomla! Bible, Ric Shreves explains how content management systems (CMS) have eroded demand for front-end developers (Section 1.1.1 of the eBook edition):
Managing a static website also locks you into hiring people with coding skills to perform content management tasks...In contrast, if you use a content management system...[then] anyone with basic skills can make changes to the web page.
It hence appears on the surface that a CMS would increase staff flexibility by allowing virtually anyone with permissions to alter the organizational website without having to deal with the IT department after having attained login credentials. If everyone making online content or files reproducible in an online environment may upload his or her addition, edits, and deletions, then it would logically follow this empowerment of the workforce would save time.
I have to question the validity of any claims to increasing efficiency, however; too many contributors can make a website into a disorganized mess or at least dilute the style. Some CMS packages such as Joomla! do not allow differentiation of permissions by username yet permit simultaneous login of multiple users, thereby inviting transaction gridlock and remote read/write conflict.
Also, books on learning a particular content management system often number in the hundreds of pages, thereby implying a learning curve and the added cost of training. If you're in management, then which would you prefer to do?
1) Pay your $20-an-hour communications specialist to read a book on Joomla! or some other CMS and have him or her update the requested pages within the off-the-shelf limitations of that CMS; or
2) Pay your $20-an-hour web developer to update the requested pages using the code-rich knowledge he's developed for years to make pixel-perfect customization of each page such as by ground-up PHP template.
Not only will Option 2 provide greater possibilities and fidelity to your vision, but the web developer will be quicker than the non-coder learning the CMS and just as quick as the non-coder who knows the CMS inside and out. Not to mention, the glut of under-employed web developers means you'll likely be able to score a seasoned developer for a mere $18 an hour for additional savings.
A web developer can do many things which a typical CMS cannot. To wit:
Web Developer | Joomla! |
Add a JavaScript event listener on the fly | Wade through over 4,500 extensions to maybe find a way |
Communicates 108.2 standards | No |
Domain name server forwarding | No |
Fully customize URLs and file names | No |
Leaner development via concise code | Bloated framework via redundant “spaghetti” code |
Mentor to others | No |
Metacognition of troubleshooting | No |
Possible political ally / mouthpiece | No |
Translate business requirements into code | Pester the online support community about how to |
True model-view-controller (MVC) separation | Entire MVC is encapsulated by CMS framework |
If you readers think of any additional advantages which a manually-coding website developer provides over a non-coder wielding a CMS, then let the world know in the comment section!
No comments:
Post a Comment