Some stuff about Web and .NET development
RSS icon Email icon Home icon
  • jQuery UI versus custom development

    Posted on July 17th, 2010 Thibaut No comments

    During the development of People & Business Development – my latest web project (related post) – I used the great jQuery UI library for some visual components such as the carousel or accordion. For some reasons I’ll discuss below, I also implemented those features by myself and I thought that giving my experience feedback could be useful.

    The carousel

    The landing page of the website presents the logos of the clients, which was done using jCarousel (jQuery UI). It needed somme little tweaking but was done in a reasonable amount of time. The jCarousel file contains 878 lines of code, which is quite heavy for me because I only needed a basic behavior.

    Carousel

    Considering all that richness I didn’t need and the fact that it always takes some time to adapt the library to the project, I decided to implement my own carousel for the twitter widget in the sidebar. Not only is the file way smaller (41 lines, I actually copy-pasted the code below so you can take a look at it), but it also took me less time to develop this custom version from scratch than adapting the jCarousel library to fit my project.

     

        1 $(document).ready(function() {

        2     var widgetWidth = 180;

        3     var animationSpeed = 700;

        4     var easing = "swing";

        5     var itemCount = $("#twitter_widget_list li").length;

        6     var currentItemIndex = 0;

        7 

        8     if (itemCount == 1)

        9         $("#btnTwitter_next").addClass("disabled");

       10 

       11     $("#btnTwitter_previous").click(function() {

       12         if (currentItemIndex > 0) {

       13             $("#twitter_widget_list").animate({

       14                 left: "+=" + widgetWidth

       15             }, animationSpeed, easing,

       16                 function() {

       17                     if (currentItemIndex == 0) {

       18                         $("#btnTwitter_previous").addClass("disabled");

       19                     }

       20                 });

       21 

       22             currentItemIndex–;

       23             $("#btnTwitter_next").removeClass("disabled");

       24         }

       25     });

       26 

       27     $("#btnTwitter_next").click(function() {

       28         if (currentItemIndex < itemCount - 1) {

       29             $("#twitter_widget_list").animate({

       30                 left: "-=" + widgetWidth

       31             }, animationSpeed, easing,

       32                 function() {

       33                     if (currentItemIndex == itemCount - 1)

       34                         $("#btnTwitter_next").addClass("disabled");

       35                 });

       36 

       37             currentItemIndex++;

       38             $("#btnTwitter_previous").removeClass("disabled");

       39         }

       40     });

       41 });

    The accordion

    I also used the jAccordion plugin to display the list of trainings and services the company provides (can be seen on the website here and there). The file contains 477 lines of code because you can, once again, customize a lot of things that most of the time you’ll don’t need. Integration time was very small and it perfectly fitted my needs, at least for the regular version of the website.

    For the iPhone/iPod touch optimized version, I simply couldn’t use it anymore : jAccordion sometimes creates a scrollbar into the sections that the iPhone and iPod touch won’t display. There is only one main scrollbar on those devices, resulting in a cropped content. In that case, I could either adapt jAccordion, take the time to dive into the code of the plugin or develop again a custom version from scratch. I chose the latest option, which took me 10 minutes to implement and test :

        1 $(document).ready(function () {

        2     $("div.accordion h3 a").click(function () {

        3         // Update arrow icons

        4         $("div.accordion h3 span").attr("class", "closed");

        5         $(this).prev().attr("class", "opened");

        6 

        7         // Show/hide sections

        8         $("div.accordion > div").slideUp(600);

        9         $(this).parent().next().slideDown(600);

       10 

       11         // Prevent default behaviour for href="#"

       12         return false;

       13     });

       14 });

    Conclusion

    So now you understand why I thought talking about this could be interesting as the difference between the 2 options is big. First : jQuery UI is a great library. You can do a lot of cool stuff with it, there’s plenty of documentation and the community is huge, so you’ll always find what you’re looking for.

    But in some cases (like mine), using those plugins is not always the best option. First it took me less time to develop a custom version than adapting the code of the plugin to fit my needs. Second, it’s way lighter (I got 41 lines of code instead of 878 for jCarousel and 14 lines instead of 477 for jAccordion).

    Although there’s no point comparing the amount of lines of code here (jQuery UI does provide much more options than my custom controls, so obviously code files are heavier), what should be remembered is : if you’ve got a good knowledge of jQuery, sometimes you’ll go much faster developing custom controls than using plugins, so think about it ;)

    Share/Save/Bookmark

  • Why you should use a CDN for your website ?

    Posted on May 3rd, 2010 Thibaut 1 comment

    What’s a CDN ?

    CDN stands for “Content Delivery Network”. It’s a system of strategically placed servers around the globe so the client can access to the requested file from the closest server.

    In this post, I’ll discuss the benefits of CDNs for Javascript libraries such as jQuery, MooTools, …

    The benefits

    Typically, you place your javascript libraries on the FTP hosting your website. CDNs allow you to host these files for you, and benefit from the following :

    • you’ll optimize the client-side experience of your visitors as the libraries will be delivered faster to them, because they’ll get the files from the nearest server
    • it falls back on other servers if ever one of them would be down
    • you’ll save the bandwidth of your webserver as it won’t be hosting those files anymore
    • you’ve got less files to maintain on your server

    How to use a CDN ?

    It’s very simple, you just have to include one or two javascript tags on every page you want to use those libraries (if you’re working in ASP.NET, you’ll typically place these tags on the MasterPage).

    Resources :

    See you ;)

    Share/Save/Bookmark

  • A standards-compliant alternative to target=”_blank”

    Posted on March 28th, 2010 Thibaut No comments

    1. The context

    At least once in every web developer’s life, the target attribute of an anchor link (<a>) was used with the “_blank” value to tell the browser “open this link into a new window”. The problem is that this attribute is deprecated and thus doesn’t pass the W3C Validation.

    Although it’s considered a usability error to force that behaviour (the user should be the only one take that decision) and usability experts such as Jakob Nielsen totally agree with this, it’s sometimes a need to control this. It can be within the context of a web application to satisfy a customer request for example and I think a lot of people needed to use this once for a good reason.

     

    2. The alternatives

    • Add a “external” css class to the anchors links in the server-side code, and in javascript open those ones in a new window
    • In javascript, find links having a URL starting with “http://” and open them in a new window

    The first solution isn’t ideal according to me :

    1. You don’t always have access to the server-side code
    2. If the website uses a CMS, you don’t wanna force your users to add these classes by themselves
    3. It generates a heavier markup (with useless “class” attributes)
    4. It requires a manual intervention to add these classes and is thus error-prone

    The second solution is better but yet imperfect :

    1. It’s better because it’s an automatic process
    2. It works quite well as internal links are relative paths (ex: “products.aspx”) so URLs starting with “http://” will open in a new window
    3. Sometimes you have absolute paths who are not real external links. It’s sometimes the case for websites with a CMS. Example : you have a website, “http://mysite.com”, you don’t want a URL “http://mysite.com/products.aspx” to open in a new window, even if it’s starting with “http://”.

     

    3. The solution : target_blank.js

    With all of this in mind, I created a target_blank.js file that does the job, using the great jQuery library :

    $(document).ready(function() {

        $("a").filter(function() {

            return this.hostname && this.hostname.replace("www.", "") != location.hostname.replace("www.", "");

        }).click(function() {

            window.open($(this).attr("href"));

            return false;

        });

    });

    1. When the DOM is loaded (document ready)
    2. Find all the links having a hostname (thus not links such as “mailto:” etc) and having a hostname different from the one of your website (without the “www.” as you want to consider “http://mysite.com” and “http://www.mysite.com” as the same domain)
    3. When clicked, open that link into a new window (passing the href value as argument) and return false to cancel the standard behaviour (which would have been to change the URL within the current window)

     

    4. Conclusion

    We’ve seen here a standards-compliant alternative to target=”_blank” using non-obtrusive Javascript (it degrades well as a browser with javascript disabled simply won’t offer that functionality without crashing the whole thing) and that requires no manual intervention from the developer or the user (case of a CMS). Just keep in mind that it’s not a good usability practice and thus this technique should be used for a good reason (eg : within the context of a web application for a particular need).

    Make good use of it ;)

    Share/Save/Bookmark

  • What’s wrong with innerHTML ?

    Posted on April 24th, 2009 Thibaut 1 comment

    Every javascript developer knows innerHTML, that famous DOM property that allows you to set or get the HTML markup string of an element. It’s easy, it’s fast but it also kinda sucks. Here’s why :

    • It’s not a standard (it was originally introduced by Microsoft some time ago)
    • innerHTML is only a string with no structure. On the contrary, the DOM is a structured tree that allows to manipulate elements in a way cleaner manner. And you can put plenty of errors into that string without even getting a single warning from the Javascript
    • Maintenance is way much complicated if you have to dig into a complex HTML string than just inserting your line between the right CreateElement() methods of the DOM

    // Note how it’s easy with innerHTML to introduce errors

    // In this case, the div tag is not properly closed

    document.body.innerHTML = “<div>Some text</div”;

     

    // Now with the DOM, in a cleaner and more secure way

    var elt = document.createElement(“div”);

    var txt = document.createTextNode(“Some text”);

    elt.appendChild(txt);

    document.body.appendChild(elt);

    But… innerHTML isn’t completely bad though. In fact, it’s way faster than the DOM and is pretty well supported by browsers. So what should you do then ? There are loads of discussions on that topic on the web. In my opinion, you should always strive to respect the standards, which are primordial when you’re working for the web, but this must not slow down productivity either (by making some libraries or helpers for example). Now the big question : What are my alternatives to working with innerHTML ? This very interesting article will perfectly answer to that.

    Share/Save/Bookmark