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 ;)
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.
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 ) :
// legal IE script tag
<script lang="JScript" ></script>
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.
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.
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.
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 ?
Of course there are good things. MSFT resources first of all. Provided they don’t cost jQuery core team anything. In money or otherwise.
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.
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.