MSFT needs more JavaScript expertise

winjsMicrosoft (MSFT) is moving to JavaScript (JS). Rewriting everything in pure JavaScript would be impossible. It would require a lot of JS expertise and MSFT lacks even now enough JS/HTML experts for this “moving to WinJS” mammoth task.

I am wondering where have all the MSFT JS people working on WinJS been until now and since when are they working under new WinJS + WinRT regime and instructions ? That is: when are the orders issued, to move everything to JavaScript? It seems JS.NET team was not enough. The result is that sometimes one can find herself faced with very large lack of JavaScript skills, while travelling around this new MSFT universe.

But, why do we care?

Because we have to use more and more MSFT solutions written in JavaScript. Like IE 10 samples or WinJS, or Windows Phone 8 solutions, etc. Give me your hand and let us dive in to the deep immediately :).

One can easily “feel” MSFT developers automagicaly (with tools) or manually transforming legacy J#, JS.NET and C# stuff and examples into the JavaScript. Remember J#? Philosophy behind J# libraries looks *very* similar to WinJS team apparent “wrongdoings”: just move it all to this new language and move it fast. And in the same time keep it tightly coupled with WIN32 too, of course.

The result is smell of fear and desperation. WinJS and teams arround it, are clinging to known concepts of statically typed and class based languages and forcing all of this onto the poor old JavaScript. Yes, like TypeScript does it exactly.

A lot of this poor(er) JS code in existence in WinJS has everything to do with unwillingness of jQuery team to submit themselves to the benevolence of MSFT dictatorship. So, now we have this new ideology about WinJS “promises”. A new “silver bullet” abstraction which  is now apparently necessary since (all of a sudden) nested callbacks are not good enough for asynchronous JS programming ? Hm, for me personally jQuery async solutions look much simpler and are doing the same job. At least in the presence of the DOM tree.

Here is one very illustrious example of what am I trying to say. Very recently this Mandelbrot on Canvas JS HTML5 example was brought to my attention too. It clearly shows both authors seniority and lack of advanced JavaScript skills.

A clear epitome of current situation around JS inside MSFT.

Update Sep 9 2014

This was originally posted Dec 16 2012. I was sure that sorry Mandelbrot on Canvas sample was updated and made into proper JavaScript etc. But I was wrong.

One example of many: For some reason author is giving a lot of space to a detail which is not direct subject of the article: Dynamic zoom box drawing? User operates the mouse and UI shows a “zoom box” of the future Mandlebrot set to be drawn. There is a diagram (twice?) of the logic and geometry involved and then this “solution”:

Code above is wrong on many different levels. From logic, over using globals all the way down to using if-else cascading. Instead of going step-by-step I will present the “final solution”:

I hope you do understand now what I mean when I say MSFT needs more JavaScript expertise.