Are Mashups a Threat to Web Application Developers?

I read a blog post or an article the other day (can't remember where) in which the author stated his belief that soon mashups would be the biggest job security threat to web application developers instead of outsourcing. His reasoning was that as IT departments leverage existing/external web services to compose their applications, they won't need as many internal developers.

There is some logic to that, but web services and mashups--heck, any existing code or algorithms--can only get you so far. If there's something out there that's exactly what you need, you just acquire it, and there's no need to do any programming of your own.

Recently a client and I discussed redoing an application for them in order to make it more flexible and open to expansion. They don't have any internal programmers, so I've been thinking about how to write administrative tools that would allow them to create new data sets and the interfaces to allow the users to enter data. After spending several hours over the past few days working out the different variations and the complexities involved, I realized today that it wasn't going to happen. There's a point of complexity and customization where no tool is going to let you cover all the bases: you need a programmer to deal with it.

So no matter how sophisticated and easy-to-use these web services and APIs become, someone with some programming-savvy will always be needed to fully leverage those assets and customize the end-result to the needs of their users.

Advantages of the jQuery Ready event

I've been working with jQuery for a few weeks now as part of a project, and I love it. I've always preferred to roll my own JavaScript, but from now on I plan to write all of my JavaScript utilizing the features provided by jQuery.

One of the most significant features of jQuery is it's document ready function:

$(document).ready(function(){
   // Your code here
 }); 

It allows you to assign functions that will execute when an event like a mouse click occurs on the selected HTML element(s) (hyperlinks, divs, buttons, etc.). This allows you to separate the JavaScript calls from the HTML code itself--instead of writing:

<input id="mainLink" onclick="showPic();" type="button" value="Show Picture" />

...you can assign the click event to the mainLink button in a separate JavaScript file (referenced by the HTML file)...

$(document).ready(function(){
   $("#mainLink").click (function () {
     showPic();
   });
 });

...and leave the button free of that markup:

<input id="mainLink" type="button" value="Show Picture" />

The other benefit to this technique is that if you have a client that likes to alter the HTML code of the pages you wrote for them, but you're afraid they might screw up the JavaScript calls in the page, you can use jQuery to create all of the event handlers and the client won't have to worry about avoiding JavaScript code in the document.