Chyrp: How Not To Use jQuery

Chyrp, a recently dugg blogging system, looks like a very good and clean blogging system. I strongly agree with Alex's (the author) philosophy about Ajax: no overajaxifying.

Because we've all seen AJAX abused too many times, Chyrp is made to use it only where it works good. For example, creating a new post uses AJAX, because it's already definite where it's going to end up (the content, with all the other posts [unless you made it a draft, in which case it goes in to "Your Drafts" and tells you so]). However, for creating a page it uses regular old form submitting. This is because pages are meant to be their own section of the website. There's no point in having it fade in to the content or do anything fancy, because you'll end up going to its own page anyway.

Chyrp uses jQuery; a good choice. Inferring from most of the Ajax-pushing code, I can see that Alex has made the JavaScript as clean as possible. There are still some room for improvement, however, as seen in this:

if ($("#admin_bar").css("display") == "none") {

It would be better to do this:

if (!$("#admin_bar:visible").size()) {

CSS styles are also littered throughout the code; they should be moved to classes in stylesheets so that their respective classes are applied when needed. This separates presentation from logic, which is ideal. But the most horrible sight is perhaps in activate_feather_tab:

function activate_feather_tab(id) {
	$("#text_form").css("display", "none");
	$("#audio_form").css("display", "none");
	$("#chat_form").css("display", "none");
	$("#link_form").css("display", "none");
	$("#photo_form").css("display", "none");
	$("#quote_form").css("display", "none");
	$("#video_form").css("display", "none");
	$("#"+id+"_form").css("display", "block");

"Why?!" cried the anguished voice in my head. Other than that this might be generated on the server, I can think of no other explanation. This is what it should be:

function activate_feather_tab(id) {
	$("#nav_text, #nav_audio, #nav_chat, #nav_link, #nav_photo, #nav_quote, #nav_video").removeClass("selected");
	$("#text_form, #audio_form, #chat_form, #link_form, #photo_form, #quote_form, #video_form").hide();

A server-side code-generating mechanism should have no problem generating this. Better yet, if all of the elements that need to be processed follow a certain naming pattern, the JavaScript doesn't even need to be generated on server-side, all it needs is pattern-matching CSS selectors:

function activate_feather_tab(id) {
	$("#" + id + "_form").show();

Aside from all this, what's up with directly setting the CSS display attribute when you can use show() or hide()? This is a nice example that shows how jQuery can be underutilized.

Hey, thanks for the tips. I

Hey, thanks for the tips. I admit I'm not the most handy with jQuery, I'm still getting my head around some of it, especially the small things like that. Apologies for the mess, I'm usually the one who's totally obsessed over stuff like that.

As for the activate_nav_tab stuff, that's just me porting old code over and forgetting to optimize it. :P Regardless, I'll update it all right away.

:) When I looked at

:) When I looked at activate_nav_tab, it looked really out of place compared to the rest of your JS code, I almost had the same feeling when I look at Rails applications and I see this ugly stub of onclick="" when Prototype is supposed to be unobtrusive. So I figured it must have been some sort of "migration" going one :|
Normally I'm sort of lazy whenever I see shuddering code like this, first I feel like I need to blog it, then I get too lazy to provide constructive criticism (real code snippets and how they should be fixed), and in the end I simply get too lazy to do the whole post and I just trash it. Constructive criticism really is a good thing, I guess.