Writing Apps Part I: WINJS, Web Apps and JQuery
April 4, 2014
Lost in Translation: WinJS is a New Country With the Same Language.
Jquery doesn’t work. Let that sink in a bit.
There are work-arounds though. According to what I read, Jquery 2 is supposed to run in WinJS with no problems, but I never experienced that success. Instead, I used a work-around that MS built into their security model: the ‘MSApp.execUnsafeLocalFunction” method.
I modified my local copy of Jquery to wrap every “appendChild,” “insertBefore,” etc, call with the unsafe wrapper. In all, there were 8 locations. Let’s be clear here though: I don’t recommend hacking the standard libraries like Jquery on a production application. It incurs a lot of risk. However, it seems I’m not the only person who arrived at this solution. We also implemented the Telerik charting library in the app: low and behold they implement their own modified version of Jquery, with all the appends, and inserts wrapped in “MSApp.execUnsafeLocalFunction” goodness.
After that, Jquery worked like a champ. Unfortunately, other libraries that do similar things will encounter the same pain. In particular, Angular.js, but we’ll get to that in another post.
To be fair, MS implemented their own patterns for developing apps in WinJS, but that’s completely beside the point: if you want web developers to use your stuff, let them use it their way.
It’s not a Web App.
There are a couple of problems though. Implementing promises and forcing async programming are good decisions, but how its enforced leaves a little bit to be desired. On the C# side, it enforces an abstraction/wrapper pattern that seems a little “kludgey.”
There are two functions in this graphic: the first exposes the second as an IAsyncOperation of type “Settings.” The “Settings” object is merely a C# class with a few properties. The problem is that WinRT cannot expose Settings, a Task, or even an async method. You have to wrap it in another method call that casts it to an exposable WinRT type. Any time you wish to return data from disk, or use any other method that is async, you are forced into this pattern. In order to consume the WinRT async method, you must invoke the “await” keyword, which requires that the containing method be marked async, which requires that it return a Task
A Burning Bridge Over Trouble Water.
And that brings us back to a recurring point: MS has provided a great set of tools, but they aren’t the tools that programmers are using elsewhere, and they probably aren’t portable to the web. Web developers are probably not going to write a WinJS app in the MS style (MS namespaces, no Jquery,etc) and port it to the web. One might write a WinJS app with Jquery and port it to the web, but it’s painful. So why build a bridge between desktop and web development if it’s already on fire?
I think the short answer to that nearly-hypothetical question is that this is version 1.0. MS usually gets things right in time, and this is brand new stuff. Besides, software is (and always has been) a moving target. In a year WinJS might be significantly less painful, or it might be deprecated. And we might be talking about some brand new type of device that is neither a web browser, a desktop, a tablet, or even a phone. the technology is changing so fast, and it seems that only the web has been able to keep pace with devices.
Tune in next time as I talk about developing a WinJS application using Angular.js.
Stay up to date with our email updates!