jQuery vs Standard Backend Programming

Question

I'm curious to know people's preferences...

I've recently gone head-first into jQuery and I am loving it. However, I'm finding that I'm replacing a lot of (somewhat trivial) backend (tech: ASP.NET) functions with tiny jQuery functions. For instance, rather than assign a navigation button as a back-end control and change its class when its page is landed on (ie, highlight the "about" button when on the about us page), I simply parsed the URL and added a class to the button:

var pathname = window.location.pathname;
if (pathname == "/about/") {
    $("#nav-about").addClass("selected");
}

Solutions like these seem rather simple (maybe too simple), but I am always wary to rely too heavily on JavaScript. Does anyone else do similar things to this, and if so, how do you maintain code like this? How do you know where to strike the balance between good ol' trusty server code that works every time and fast, fancy, shiny jQuery that works pretty much every time, except when the user may have JavaScript turned off?

EDIT

I'm not really speaking of this particular instance... I'm talking about little enhancements like this. What is the line you draw when it comes to jQuery enhancements or just do it on the server? Thanks :)

Answer 1

My past few projects I have had the luxury of knowing that 100% of the users would have Javascript enabled. In that case, I actually did something very similar to what you have to save myself from having to highlight the current page in the navigation server-side.

Without that luxury, however, I consider shortcuts like this to be "pushing it" as far as using jQuery - sure, you can just say "if they have Javascript disabled, then they just won't see the navigation page highlighted, it's not a big deal" - while that may be true, it is a big deal to have the mentality to shun a more robust, reliable way of doing it server-side for no particularly good reason. It is important to stop yourself short of replacing battle-tested server-side solutions with "easier" code in the client. It is tempting, but not always the best thing for your project and your users, some of which will have JS disabled and may look at the navigation wondering where they are and find themselves "lost".

All in all, I would recommend you switch back to server-side code for this one. There's just no need to throw it away.

Answer 2

I've felt that the main problem is for search engines, as they don't parse js. Any content type stuff I always make sure works without, but little designer touches I think are OK.

Answer 3

Javascript is an extra layer on top of HTML and CSS. When you're building an accessible website, everything should be available in just the HTML. Both CSS and Javascript should only be used to enhance the user experience.

I would even go as far as to say that for every single page interface or RIA, there should be a multipage alternative.

So, to answer your question, this is definitely something you'd want to code on the server, not the client.

Answer 4

The problem with jQuery is that it fires on document ready. Not a big deal early on, but if you have a heavy page, none of this highlighting stuff is gonna appear until the rest of the page is done loading. This means you could see a "pop", as all the jQuery enhancements fire off.

Better just to do this kinda stuff server side (especially when .NET has the Sitemap already built for you)

Answer 5

How do you know where to strike the balance between good ol' trusty server code that works every time and fast, fancy, shiny jQuery that works pretty much every time, except when the user may have JavaScript turned off?

It may sound blunt, but favoring to less than 5% of users (and declining) is unfair. It will just be the cause of a user-interface nightmare for you as well.

Just remember to draw the distinction between server and client. Server-side code is just that: Code that belongs on the server and doesn't affect how the client sees the end-product; let's just say that it is immutable for the client. Displaying the end-product is mutable and at times is encouraged to change rapidly to provide a more in-depth user experience.

Answer 6

If it is significantly easier to do things in jQuery, rather than server-side, it sounds to me like you are using unwieldy server side technologies.

For me, server side programming should be at least as simple as client-side.

Answer 7

I like jQuery myself, but there can be issues of accessibility and functionality that I have to worry about. I frequently test pages with Javascript disabled to make sure it will work with that audience (public terminals frequently have Javascript disabled IMHO), and in Lynx to get an idea of how a screen-reader will see my page.

You can verify your page against a number of tools here:

http://www.w3.org/WAI/ER/tools/complete

to help ensure that your pages are still accessible.

Answer 8

I tend to go for graceful degradation in terms of behaviour, I'm not so bothered with what stuff looks like on the client side, as long as the system works and can deliver in terms of its business requirements. Styles and colours and all those pretty things belong only in the text that is served to the browser, and not in the the back-end code, unless the goal of a stylistic element is to provide functionality that is required (such emboldening a link to show that we are on that page).

That said, I realise that at the same time I love using jQuery and the fact that it gives me license to perform all manner of cool client-side antics in a very short space of time. So what I tend to aim to build is a system that is solid (like in the good old days before all of this scripting nonsense :) and that does what it is supposed to. Having achieved that, and for extra pats on the shoulder (and real rep), I will use jQuery to jazz up the whole user experience, in a non-compromising way. To provide a simple example:

<a class="pageNo" href="/?p={$pageNo}">{$pageNo}</a>

is a page link, clicking on it will load some results into to a div, the implementation is something like:

jQuery('.pageNumber').click(function(e) {

            //stop the link from firing
            e.preventDefault();

            //steal the page number from the tag
            var pageNo = jQuery(this).text();

            //assign it to a hidden field
            jQuery('#pageNo').val(pageNo);

            //use $.load to fill up a div with the results
            loadPage(pageNo);


        });

The link points to a resource on the server that looks like www.random.com/things/?p=2. jQuery's $.load function fetches this page and inserts it into a div, ajaxily. If Javascript fails, or is not available, it's no big deal because the link fires as normal and the page is visited, just like in the good old days. Furthermore, the server is set up to differentiate between an XHTTP Request and a normal one, and respond accordingly. jQuery, in this case, made for a really neat enhancement that did not at all compromise on the service delivery aspect of the project.

These days I frequently find myself designing things in terms of how I might use jQuery to do this, that and the other, and that's where I have to take a step backwards and remember that the important stuff has to be got right before the experimental and controversial 'enhancements' can start to be rolled out.<sigh>

Answer 9

Since I can't leave comments here (yet), I'm entering this as an answer, even though it's more of a comment. (Although probably wouldn't fit in a comment!)

For the example you give in the original post, (and I know you said you are asking more out of a general sense rather than this particular sense, which is why I'm answering with a general solution) I prefer to do this "nav highlighting" with pure CSS.

For example, you could have an "about" page as follows:

<body class="about-section">
  <h1>This is a page in our About section!</h1>
  ...
  <ul id="nav">
    <li id="nav-home"><a href="/">Home</a></li>
    <li id="nav-whatever"><a href="/whatever/">Whatever</a></li>
    <li id="nav-about"><a href="/about/">About</a></li>
  </ul>
</body>

And your stylesheet:

    #nav a {
      color:#00F;
    }
    body.home #nav-home a,
    body.whatever-section #nav-whatever a,
    body.about-section #nav-about a {
      color:#F00;
    }

Adding and maintaining pages is handled by the one CSS declaration. It doesn't require any javascript NOR server-side programming; you just marry up the body class (or other identifier) with the items you want styled differently.

Best of luck!
-Mike