Microsoft + jQuery = Love

Yesterday (on MIX10) Microsoft has re-iterated and strengthened its commitment to jQuery.  This is certainly (very) good news for jQuery (and John Resig) : http://visualstudiomagazine.com/articles/2010/03/16/mix10-jquery-announcement.aspx

Very cynical geek (what, me ?) can appear very clever and write :

What’s next ? jQuery VBScript version ;)

So, this is good news. Some might even say: jQuery has “officialy won”. It is officially adopted by the largest and most important software house on the planet. It is selected to be “the only one”, among all the other JavaScript libraries. But. I would suggest caution. Allow me to go beyond and outside, of all inevitable “open source project with Microsoft inside”, torrent of discussions which is starting right now. I am thinking of wider Microsoft (MSFT) agenda. There is an elephant in the room, and I think I will mention it.

And now is the right moment to write (yet another) little disclaimer : I have nothing against MSFT. I do focus on MSFT tools and technologies in my career , for last (cough,cough) 15+ years. Also, I am not affiliated in any way with any of MSFT competitors. Clear? Thanks. Now allow me to go back to useful content. What are the issues MSFT is facing every day, in the context of it’s own software development tools and technologies ? And how that/this affects what it does (vs what it says?), and possible reflections on the jQuery relationship.

Legacy

Undoubtedly the MSFT issue “numero uno”. Whenever you get enraged and disappointed with some “bug” inside IE, or some strange construct in the .NET ocean, just stop and think: legacy. And calm down. Just imagine how many legacy technologies live and work together in the same time, in the MSFT universe? Have you ever heard of “Visual Fox Pro” ? When was the last time you have seen VBScript in the html page? Or WSF file? Probably HTA “applications” you did see? Last three actually with JSCript inside? Speaking of witch when was the last time you typed (if ever ) :

[sourcecode lang=”jscript”] // legal IE script tag
<script lang="JScript" ></script>
[/sourcecode]

I am sure You understand how long this list will be if anyone finishes it off one day. Now. MSFT needs to take care of all this. Each and every of this legacy acronyms, has thousands of long standing and very vocal users.  But in the context of this text we can focus on MSFT scripting environments “only”.

So the first question I have is: How much of its own scripting issues & solutions, MSFT will try and “bring” to the jQuery ? I like this use of the word “bring”. If someone is “bringing” something, you should appreciate the effort, do not be critical of the package content. It’s a gift. Be nice.

For example, yesterday on the MIX10, it was immediately announced: “Microsoft will contribute the templating engine to the jQuery JavaScript Library Team.” …  Thanks a lot. But, wait ? What “templating engine” ? Why? Are we talking jQuery core or some plugin here? I certainly do hope so.  Where is this “gift” coming from? My opinion. MSFT web app client philosophy, and its AJAX “next release” is based on custom html tags (with namespaces). “next” MSFT AJAX is a complete standalone browser based solution. Some MSFT HTML “head honcho” has decided this is a “good thing” to base MSFT HTML and AJAX solutions, on custom tags and also to use the jQuery too.

I am sure at least half of wider jQuery community will disagree on this idea. In case you think it is not an big issue, you should know that this is the first proposal MSFT has put forward after recently re-joining the W3C HTML5 effort. Custom tags and namespaces in HTML5. Now. what will happen if jQuery core team starts thinking that this is a “bad idea”? What worries me here that MSFT might be influencing the jQuery direction , only so that it can solve some its internal scripting problems. Like HTML5 not supporting namespaces and custom tags. And thus jQuery not supporting them too.

There is also an issue of MSFT scripting evangelist, who (all?) belong to that part of JavaScript community that believes: “OO === Classes”. That part which just “can’t get it”. There are no classes and there should not be classes in JavaScript. Ever. Fortunately John Resig “got that one” right. And this is one of the main reasons I am using jQuery for last 2 years. It is completely prototypical. It is pure JavaScript. I am slightly worried what will happen when jQuery core team gets involved with MSFT scripting “well wishers”, who are (for example) blogging about their excitement, because they achieved: “.NET reflection implemented in AJAX library” … Ugh, why ? For me this auto-magically spells: javascript “classes” and the lot. Definitely “not-a-good-thing”. I hope these MSFT JavaScript-ers will not “bring” the Class “gift, to the table” ?

Furthermore. XML is also an “legacy”, I am affraid. “XML everywhere” is not very popular mantra any more. If any body can even remember it? For AJAX Web Applications , JSON is clearly better solution, at least as internet messaging vehicle. It naturally and nicely fits into browser JavaScript side. Server side JSON+JavaScript solutions are brewing nicely, soon to be reaching the point of maturity. Again, the question is what are the MSFT plans for the XML in a browser? jQuery JSON is really easy and everybody is doing it as a primary mechanism for communication with the server. While on the other side of the jQuery core team we now have a vendor, whose browser has non standard  &lt;xml&gt; , tag and xml dom element. And they want not and can not just “drop it”.

HTML5

This is the second question I have. How will MSFT jQuery developers relate to their new jQuery colleagues when talking of, or implementing jQuery HTML5 solutions in the jQuery core? Each and every new piece of jQuery will be evaluated by MSFT against its core issue: the MSFT legacy.  HTML5 is definitely not a priority for MSFT. While in the same time it is a priority for everybody else.

The whole Google, soon to be released, client is based on HTML5. For Windows Phone 7 this is decidedly not the case. To display a list of things coming from some database, behind some web server, on WP7 platform you are encouraged to use SilverLight, C#, Linq2Xml and the rest of “just to be released”  tools.  For my taste way too complicated and time consuming, and thus inferior when compared to pure Web Browser solution : just a jQuery and HTML (5 or not). Completely browser, OS and device agnostic. Simple, effective and working today. While (right now) WP7, has some IE “mobile version” that scores 5/100 on Acid tests. Which decidedly looks as an afterthought.  Right now many well known, paid for, commercial jQuery based solutions will not work on WP7 devices.  Simply there is no browser which is good enough.

Even if it might have an WP7 version planned (unclear), IE9 is “months away” as it was explained only yesterday on MIX10.  When we will have HTML5 enabled browser on the WP7 platform? Companies using jQuery need this. Otherwise they will  stay on the “other side” (Android?). I am wondering how is this interesting subject, going to be debated between MSFT and not-MSFT developers on the http://forum.jquery.com ?

And what about MSFT still “sitting on the HTML5 canvas fence” ? Yet another MSFT jQuery, debate I would like to be present at.

“Other” browsers

Today jQuery is completely and successfully cross-browser. True, this is also one of the main reasons MSFT has selected it. Because it very nicely supports IE6 to IE8. But there are other browser too. Not to mention the fact that jQuery project, is actually hosted and aided and paid by the “Mozzila Inc”. Ok, these days MSFT appear to be benevolently adopting HTML5 direction. There is again a buzz, about “browser harmony”, and so on. But. How long will it last? And what will be the jQuery position after it is seen as “working with Microsoft”? Sounds stupid, but many anti-MSFT zealots will see it exactly like that. Mr Crockford for example. Even now he calls jQuery, Dojo and the rest : “AJAX libraries”, and their starlets : “JavaScript Ninjas”.  Which I actually think is a healthy dose of detachment.

And there is this thing called: Google.  Google will release this year the full technology stack based on browser and HTML5 as the only client  side enabling technology. It is Rich Internet Applications (RIA) nirvana. It is the environment where jQuery (and few other competitors) really shine. All on Google mobile devices. That will go head-to-head with MSFT WP7 mobile devices, by the end of this year.  Of course do not forget Apple iPhone and iPad, and the near future HTML5 Web-Kit offering.

The issue, I have here is that jQuery might be cut of from Google,Apple, Yahoo, Amazon, etc. platforms.  It is not in direct use today on any of them. It is made available on Google Content Deliver Network (CDN), true. But it is not used by Google to develop any of their complex and comprehensive browser side solutions. Neither is jQuery used by Yahoo for the same purpose. All very relevant players.

I am sure all those big names have been contemplating jQuery, for something at least. But now, how is jQuery MSFT cooperation going to be interpreted in these coming days? Or months , or years ?

Good things

Of course there are good things. MSFT resources first of all. Provided they don’t cost jQuery core team anything. In money or otherwise.

Than there is the whole IE9 drive. MSFT has decided obviously to “catch up” with Chrome and Mozilla. Expect very complete ECMA Script 5 implementation in the new JavaScript engine. And expect it to be properly tested and most importantly MSFT has (at last) acknowledging the purpose and value of ACID tests. So jQuery team should (or will?) have easier time to push the jQuery into full ES5 compatibility direction.

Then there is the Windows Phone 7. Let’s hope MSFT will produce HTML5 browser for WP7 and thus allow jQuery to shine there too. With the help of some MSFT plugins written for that platform.

Also do not forget that SilverLight works “naturally” with JavaScript. I am sure that MSFT will “bring to the table” same very nice jQuery+SilverLight+WP7 ideas and plugins.

To summarise, I do think jQuery MSFT “marriage” appears to be a “good thing” right now.  But. There are (perhaps many) grey areas, in there, which I hope jQuery team (read: John Resig) should be very clear about.  I am sure that MSFT is. And of course, it is very important that jQuery community has this relationship,  clearly explained too.

–DBJ

 

7 Replies to “Microsoft + jQuery = Love”

  1. Grand article. There’s a lot of good info here, though I did want to let you know something – I am running Ubuntu with the up-to-date beta of FireFox, and the look and feel of your blog is kind of rakish for me. I can understand the articles, but the navigation doesn’t function so great.

  2. What “full technology stack based on browser and HTML5 as the only client side enabling technology” from Google are you referring to?

    I’d like to read more about it.

    1. @Alexei : Google Chrome OS, where front end is nothing but HTML5 browser, leveraging HTML5 to the extreme. And the back end is a Linux variant, with a single task to support this front end. Perhaps the good place to start is this overly simplistic article on Wikipedia.
      This article is not just simplistic but somewhat naive, because of the sentences like : “…Google Chrome OS is aimed at users who spend most of their computer time on the Internet…” Which certainly is not a Google idea. Google plan is simple: Google cloud + Google Chrome OS screens = Computing. This is where I am citating myself ;) Although this Google idea is born from very simple fact, mentioned by many:

      “..to go forward we need better browsers..”

  3. It is now 2015 and I just had to chirp in folks :)

    It seems, five years ago, we have been (very)(right about HTML5 and of course jQuery. Focus on these two is almost extreme. Microsoft EDGE is here, Google is pushing NOW so hat Applets as we know them will become obsolete … jQuery and HTML5 are working behind 99% of pages we visit every day.

    (Of course I was somewhat wrong about Silver Light :) )

Comments are closed.