regular Javascript v. AJAX for dynamic content insertion
Recently for work, I’ve had cause to write functionality so that a certain chunk of a form can be inserted again, over and over, by the user. The form involves data about course equivalencies between schools, and the user might need to submit data for multiple courses a student has taken. Hence, the user needs to be able to add extra course sections on the fly, as they’re necessary.
I decided to do this with Javascript, but the question was:
- Should I dynamically generate the extra form fields with Javascript before stuffing them into the DOM,
or
- Should I have a separate page, containing the form fields written in plain HTML, that I dynamically insert into the form page via an AJAX call?
Contemplating the idea, I decided the best route would be to use AJAX. Here are some guidelines for making such a choice, based on the logic I used:
- Are you generating a lot of code?
- If you’re going to be generating a lot of code each time, like in my example, the AJAX route makes more sense because you can have a separate page (PHP for me, but you could use a straight HTML page) to write that content in HTML, then use an AJAX call to include that page in your main page. See, if you were to use Javascript for dynamically creating elements (
document.createElement()
andelement.appendChild()
are your friends here), you’re going to write a lot more code in Javascript than the straight HTML it takes to create various elements and their attributes. In my case, with Javascript I would be generatingli
’s,span
’s,fieldset
’s,input
’s, andlegend
’s, then several of those had the attributesrel
andclass
, not to mention the normal attributes associated withinput
. It’s simpler to write out the HTML for this in a separate page, rather than have lots of Javascript functions for creating those elements, applying attributes to them, assembling them together, then stuffing the result somewhere in the existing page. - Does the dynamically added code replicate content already in the main page?
- In my example, the main form page started out with one course section already showing up. If I were to use straight Javascript DOM manipulation to allow the user to insert extra course sections, I would be replicating the same content in two ways: in the main HTML page, and in the Javascript necessary to generate a new course section. Being a Ruby girl at heart and a big supporter of the DRY principle (Don’t Repeat Yourself), it hurts something deep inside of me to duplicate that much functionality in my application. Well, maybe I’m exaggerating a bit, but I gotta stress this, because such replication leads to harder-to-maintain code. Any time you want to change the teensiest thing, you have two places in which you need to change it: the original HTML, and the Javascript that creates the same chunk of HTML before inserting it into your page. Going the AJAX way here would be best.
- Are you adding only a small piece of HTML?
- If you want the user to be able to dynamically add a single link or something equally trivial to your existing page, the AJAX route might be overkill. The Javascript necessary to generate one or a couple HTML elements isn’t overly complex or lengthy, and so it makes sense to use Javascript element generation followed by DOM manipulation to add your new content. I think it would be more trouble than it’s worth to have a separate page containing just a link or two, and then use AJAX calls to stuff that snippet page into your main page.
- If your dynamic content isn’t complex now, do you foresee it becoming so in the future?
- Maybe for the time being, the user only needs to insert a couple of elements into the page at his or her whim, but in the future, you think your application will expand such that large chunks of HTML will need to be added at a time. In this case, you might start off with the AJAX route just for your future convenience (or the convenience of another developer—be considerate of the next guy, right?). It’ll make your page easier to expand in the future, since you won’t have to remove all the Javascript content generation code, create a separate page to hold the content to be dynamically added, then write the AJAX calls to include that content as the user desires.
- Are you using a PHP (or similar server-side language) back end?
- The site I was creating my example form for uses PHP, so the AJAX route especially makes sense here, since I can make the dynamic addition of content be available for the user even if they have Javascript disabled. I’ll just use PHP to parse a POST request and decide how many course sections to include (using a loop and PHP’s
include
on the separate snippet page of content), based on how many they currently have and how many extra they want to add. With the Javascript content generation route, this sort of thing is impossible, because Javascript is entirely client-side, and if the user doesn’t have it enabled or their browser doesn’t support it at all, they’re up a creek. Oh sure, you could have the non-AJAX version for those with Javascript, then write functionality in a server-side language to allow the user the same functionality without Javascript enabled, but there you go again with the replication of functionality—bad programmer! If you’re stuck with just HTML, though—which I have to guess is unlikely in this day and age, what with every Tom, Dick, and Harry of hosts supporting PHP, Perl, JSP, and Ruby—you’ll need to determine whether to go AJAX or Javascript-content-generation based on the other questions raised above.</dd></dl>
comments powered by Disqus