1. Helps you separate the presentation (XHTML) with the client side logic – following the “Unobtrusive JavaScript” principle.
2. Let’s you forget about having to code like “if (IE) write_yet_another_hack()”. It abstracts 90% of code that needs to be browser-specific and smart enough to catch the different browser divergences (especially the “blue e” on your desktop).
3. Makes your code fly with its fluent design – chaining methods like $(“.nav”).show().addClass(“red”) – can the code be more beautiful ?
4. Writing your own plugins is extremely easy. This is why you have tons of extensions to choose from if what jQuery offers to you out of the box is still not enough.
5. Rounding corners, adding animation effects, working with ajax and other popular client code tasks haven’t been that easy before.

I’m currently finishing reading the “jQuery in Action” book and I can tell that I definitely fell in love with this framework and I am more than sure that I will never go back and write plain old JavaScript when I only have a choice.

There was actually one drawback – the lack of intellisense. If it is a drawback indeed, because simple JavaScript intellisense support in VS hasn’t really blown me away either. However, since recently intellisense for jQuery is available to download as a standalone .js file, that you need to reference inside your script files.

Intellisense in jQuery

Sweet! isn’t it?  Check for more information about intellisense support on Visual Web Developer Team’s blog.

When you application uses string frequently, and I’m 99,9% sure it does, then think about how much memory would be wasted if the same strings that appear in your application repeatedly had been memory allocated every time they are used? CLR has it’s remedy for that situation. Once the AppDomain is being loaded, CLR creates an internal hashtable which keys are the actual strings and values are pointed to the objects on the managed heap. This hashtable is initially empty, and is being populated with new string entries that come while the program executes.  This means that no longer duplicated string objects are created on the heap. You may wonder, “hey, but what if I modify one instance of that “grouped” string objects? Will it affect the strings in other places that just before a while were identical to the modified one? The answer is of course no. Remember that strings are immutable - which means that you are not allowed to modify the string instance (unless using unsafe operations). Once you “modify”  the string object, the new instance is created and returned under the hood and the previous instance is now ready to be GC-ed (of course the condition for this is that the “old” string was unique in the AppDomain).

When you are using the 2.0 version of the CLR (remember, please distinct the CLR versions from the .NET Framework versions) you should get the String Interning mechanism working  by default out of the box. However, there is some weirdness behind it.

Assemblies under CLR 2.0 are by default marked with the System.Runtime.CompilerServices.CompilationRelaxations.NoStringInterning flag value. According to what ECMA specification says, because of that the CLR may choose not to intern all of the strings defined in that assembly metadata.  That would seem that we have to control the interning mechanism by using the Intern or IsInterned methods manually. Finally, let me say that 2.0 version of the CLR ignores the mentioned flag that is produced by the C# compiler. Pretty confusing, isn’t it? All this mess is because the concerns about performance. By default, when an assembly is loaded  CLR interns all the strings that exist in an assembly’s metadata. This process can hurt the performance significantly, that is why Microsoft choosed to “turn this feature off” by default.

Concluding, you can design your CLR 2.0 applications with the string interning mechanism provided by default, so this code:

private static void Main(string[] args)

{

    string firstReference = “D’oh!”;

    string stillSameReference = “D’oh!”;

    // True – under CLR 2.0

    Console.WriteLine(ReferenceEquals(firstReference, stillSameReference)); 

}

This code snipped should be predictable under the CLR 2.0 and print “True” to the output. However, as Jeff Richter in his fantastic book explains, you should not rely on this mechanism and leverage string interning manually by using the appropriate methods (Intern, IsInterned) because we do not know how the next versions of the CLR will interpret the NoStringInterning flag.

I’ve just managed to install this new wordpress (thank you,  smashingmagazine for the lovely theme) blog and hope you and I will learn something new everyday (probably to be updated to every occassion). Yes, you should comment as much as possible here, because I am always willing to be proven wrong, frankly.