jQuery UI versus custom development

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.

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.

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 :

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

A standards-compliant alternative to target=”_blank”

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 :

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

In bulk #3

• A great tutorial about vertical centering in CSS
• An interesting article about the “em” unit in CSS
• jQuery for designers, an interesting resource about jQuery, oriented to UI
• ProcessingJS, the John Resig (author of jQuery) project about porting the Processing language to Javascript
• UseIt.com, the website of Jakob Nielsen’s, a very famous expert about web usability
• A very interesting article recommended by Steve Krug about web accessibility and how blind users really use the web
• Script#, a free tool enabling you to compile C# code into regular JavaScript
• And to finish, an interesting article (in french) about SEO

In bulk #2

• A very interesting article (part 1 & part 2, in french) about continuous integration using Visual Studio Team Foundation Server , written by Pierre-Emmanuel Dautreppe
• The Agile Manifesto, a reading I truly recommend for those who’re working like me with an Agile methodology
• The Let’s make the web faster initiative of Google, or how to code so we’ll browse the web as fast as books in the future
• A very good article explaining the difference between the ASP.NET callback framework and ASP.NET AJAX
• A nice collection of MSDN articles about developing custom ASP.NET server controls
• RegExLib, an interesting resource about regular expressions
• The jQuery ThemeRoller, an application enabling you to customize your controls
• And to finish, a big collection of “Follow me” Twitter icons and a large set of Twitter graphics

Javascript - précis & concis

Javascript - précis & concis (in french) is a little, yet very interesting book for the beginner as well as for the expert in javascript. This multi-purpose book enables you to discover or improve your javascript knowledge in a fast and effective way. Covered chapters include the following : Introduction to Javascript (syntax, instructions, object oriented javascript, regular expressions, …) Client-side Javascript (the Document and Window objects) The DOM DHTML Event handling Dealing with security issues A reference of the Javascript API

Pros

• A small book enabling you to cover the main parts of Javascript in a fast way
• Very concise but well explained
• Useful for the beginner (intro to Javascript) as well as for the expert (API reference)
• Variety of the topics, giving you a nice global knowledge
• A reference of the Javascript API, which is very useful for further consultation
• The kind of book I like to read now : concise, fast and great added value. Because technologies are a vast and ever changing domain, we don’t always have time to read bricks of 2.000 pages

Cons

• Might not be easy for the new comers (shows code but won’t explain to them how to create the HTML document to contain it, doesn’t define some abbreviations such as API, …). Ok for the beginners having basic Javascript notions
• Some errors of translation (some Javascript functions or reserved keywords are translated into french)
• Don’t expect from each chapter to dig deep as this is a small book (but not really a con in itself)

Conclusion

Definitely an interesting book from which anyone will learn. Serves as a training book as well as a reference but of course won’t replace a bigger, more complete book, but who will also take much more time to read…

What’s wrong with innerHTML ?

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

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.

Back from the Techdays

Here is a summary of the sessions I assisted at the Techdays on Wednesday 11th.

Introduction

• Evolution of software : SOA trend and cloud computing advent
• Demo of Blend : the graphist and the developer work at the same time on the same project, the graphist makes some modifications and the developer gets the result when launching the app the next time (and vice-versa)
• Demo of Surface : very impressive, visit the official website to watch the videos. Easy to make apps for surface as that’s WPF with just one lil’ layer onto it
• Video of Microsoft’s future vision for apps in 2019

.NET continuum: ASP.NET, AJAX, Silverlight and WPF (by Laurent Bugnion)

• From the less powerful to the most : ASP.NET, AJAX, Silverlight then WPF
• Shows how to interact with a WCF service with ASP.NET MVC (postback), ASP.NET AJAX (asynchronous, better UI reaction), Silverlight (only asynchronously, subset of .NET power) and WPF (asynchronous or synchronous, full .NET power)
• Description of the Model/View pattern
• Introduction of Dr WPF, a blogger very active in the WPF world

Silverlight CoreCLR: Bringing the power of .NET to the net (by Andrew Pardoe)

• Demonstration of the performance of Silverlight, compared to a Javascript application. Chess game, averaging 420,000 nodes per second in Silverlight vs. Javascript at 23,000 nodes per second in the search tree. Complete source code is available for the doubtful guys
• Anything that can host ActiveX can host CoreCLR
• Sandboxed execution : one execution domain per Silverlight app. Security increased
• Same application model between browser and desktop : very easy to port a desktop-WPF app to a browser-Silverlight one
• Dynamic Language Runtime (DLR) : language interoperability. App written in Python or Ruby can interact with the CoreCLR. Ex : IronPython or IronRuby

WPF performance & best practices (by Dirk Primbs)

• First advice about performance : focus on scenario and customer expectations. Do not try all the new visual effects on the same page or it obviously risks to slow down your app
• The visual tree (containing all the controls and parts of them) can become too large. Use Snoop, a very powerful tool, that enables you to visualize that tree
• Use optimized controls. For example, the VirtualizingStackPanel instead of the StackPanel, will render its content only when visible (suppose you have a lot of elements, and only a portion of them are visible through scrolling, rendering all of them in your page load isn’t a good solution)
• Picture processing : try to avoid using large pictures and use caching options such as BitmapCacheOption
• WPF Performance Suite : great tool for measuring performance of WPF apps
• Hardware acceleration : 3 tiers (tier 0 : old pc, < DX7, tier 1 : between DX 7 and 9, tier 2 : DX >= 9). App can be set to run at a determined tier to simulate behaviour of less powerful machines and thus tune the perfs of your apps

Under the hood in Silverlight’s controls skinning framework (by Gill Cleeren)

• Speaker showed how to create a skin for a button (a purple ellispe with gradient brush)
• Styling vs. skinning : styling is limited, skinning is completely new look, visual tree and properties
• Parts & states model : separate logic from visual, contract between coder and designer, supported by Blend. Enables you to add new properties to existing ones on a control
• Part : the working thing. Eg : a button has no part since the button is itself the part, but in a slider, the part is the little thumb that can be dragged
• States : the different states of a control, such as mouseover, pressed, etc

Windows 7 for developers (by Katrien De Graeve)

• New features for consumers but also for developers
• Showed the new features for the consumer (the docking features, etc, many articles available on the web about that)
• Developer point of view : multi monitor support, even when remoting. Problem step recorder : screenshots of every steps of a bug reproduction are taken and then submitted to the developer
• Compatibility : what works on Vista will work on Win 7 almost for sure

And that’s all about this very interesting day. See you next year