(Preface: This post is my opinion only. It represents some thoughts I’ve had rolling around in my head for a while. To free up some space in my brain, I’m draining this thought pool now. I’m in no way trying to tell anyone what’s “right†or “wrongâ€â€”those are decisions based on your own set of circumstances. I could be totally wrong here. Wouldn’t be the first time, won’t be the last time. Feel free to leave polite comments.)
Since last October I’ve been giving a talk on using jQuery in a Metro JavaScript application. It’s been well attended and well received, and it gave me a good opportunity to work with Win 8 through its various releases. After we first finished the sample, I sat there and thought “that’s cool, but who would do this?†Let me explain.
It’s not that I think Metro is going to flop. I don’t—I think consumers, especially those with a Win 8 tablet, will go nuts for Metro apps. Enterprises overall will be slower to adopt Metro, but you can bet we’ll see the best of the best as we approach RTM and GA. I just think most of the Metro apps will be written in XAML, not JavaScript. Microsoft did a fine job with the capabilities of WinJS libraries (especially feature parity between XAML and JS), and when combined with the tooling, Metro JS app development is relatively painless. I proffer two reasons why I feel adding a JavaScript option isn’t as important as it first seemed.
First, there are far fewer web devs in the world than people think. Most of us who call ourselves web devs actually are writing native applications, the UI of which is merely a final output which is displayed in a browser. Most of us have a heavy reliance on a server side framework, be it ASP.NET, Ruby, PHP, Java or whatever. In Metro apps, there is no server framework available to us. I consider “pure†web development to be based on client side Ajax calls and DOM manipulation, coupled with SOA, which is the architecture of a Metro JavaScript app. Ironically, some of the “purest†“web development†you would ever do is writing a native Windows (Metro) app.
Secondly, I’m of the opinion that web devs don’t write native apps not because they can’t, but because it offends the sensibilities that their app won’t (at least in theory) run everywhere. It’s not enough that an app will work on all Windows machines—there are Macs, Linux, tablets and (with a little extra work) smartphones out there. One codebase to rule them all! Remember, web devs obsess over a 1 pixel difference in how FireFox and IE render inputs. To us, the browser is the OS, and is the device. We care not whether Chrome is running on Mac, Windows or Linux (as Chromium). In fact that’s what we find appealing. While an attractive option at first, I think the realization that these are OS-specific apps will slow the adoption of Metro JavaScript.
None of this is not to say that there won’t be some great JavaScript apps produced for Windows 8. There will be. I’m just of the opinion that over time the numbers will favor XAML apps.
I’m not sure if I agree with the outcome of your argument. Time will tell that tale. It will probably be more akin to the old C++ vs. VB days. VB was used for rapid prototyping, then it was ported to C++ for serious production. Metro will probably be the same. HTML will be used for rapid prototyping and XAML will be used for production.
However, I do supremely agree with one of your premises. Most developers are NOT web developers. I look to look at it this way, if you use jQuery, Node.js, modernizer, et al, then you are not a web developer. If you took the time to actually learn to DOM and use actually calls to the framework, then you MIGHT be a web developer.
To display this point, I was once involved with an interview for a developer who claimed to know C++. We asked for a code sample and got something that looked like Pascal. We said, “No, we want to see an C++ sample,” and was informed that he gave us C++. On further inspection, we discovered that he was using a library that had #DEFINEs that translated the Pascal into C++ (poorly.)
If VB was ported to V++, then there are a heck of a lot of prototypes still running in production! I’m not sure if HTML will be the rapid prototype or not. XAML and HTML are still a little mutually exclusive. It’s not significantly faster to develop Metro apps in HTML than in XAML, so a prototype could just as easily start in the same technology.
I don’t discount devs who use libraries such as jQuery or modernizr as not being web devs–quite the opposite, in fact. Part of the reason is that calls to the DOM (both which and how) depend on what browser a visitor is using. jQuery encapsulates the browser specific logic, and modernizr aids detection of features. If you were to write all the DOM calls yourself, you’d end up with an immature form of jQuery after some time. Use what’s there, but make sure you know how it works–if you don’t, you will eventually learn through debugging. I think of web devs as those who do manipulate the DOM, even using libraries. My point was that a lot of “DOM manipulation” takes place on the server, compliments of a framework.
When talking to ASP.NET devs, this blog post is a bit like ‘preaching to the choir’ 🙂
I have to think there are non ASP.NET devs that this stuff is for?
Even still, I don’t foresee a mad rush of Ruby or PHP devs wanting to build native Windows apps.