Microsoft WPF WPF/E and XAML for Java People
Stop Press: Everything below is TOAST.
As it turns out, I was wrong, and Google has right. Who would have thought? :-).
I wrote the following when "Rich Client Platforms" (remember RCP) were all the rage. My concern was that Java didn't have one, and Microsoft was about to have a really good one.
I later added a comment "To my relief JavaFX was released a few months after I wrote this." -but we all know how jfx workled out (how jxf2 workds out remains to be seen, but what on earth will it run on when every windows client comes from the windows store?).
Hell, I have even ended up using GWT (which I rant about below as a dangerous diversion for the java world).
With the benefit of hindsight:
Rich Clients lost, HTML and native "apps" won.
BUGGER!
I'm actually pretty sad about this. I would
far prefer to work in Flash, Silverlight or JavaFX2 than (bleech!) javascript+DOM.
Those ol RCP plugins really seemed to have "the best of both worlds" to me:
-
Performance and tools on par (or nearly on par) with platform specific environments.
-
Platform independence. I was hoping to see Silverlight, Java and Flash plugins installed in everyone's browsers.
-
Clean, purpose built infrastructure (esp graphics and UI frameworks) that were NOT the result of "starting with hypertext and then trying to morph it into a serious client platform on a committee basis".
Bummer. It wasn't to be.
I blame Apple
Well, that is a little tongue in cheek -but by banning Flash et al, they killed the platform independant benefit of richer clients.
It seems to me that the new world order is a class structure that suits Apple, Microsoft and Google better than rich clients would have:
- First Class: Apple, MS and Google compete for the cream (ie "apps" from "app stores" (paying 30% "app tax" thnakyou very much)).
- Second Class: Web Apps
Not quite as slick, not sitting there on the desktop.
Original Article Follows...
---- Draft (v0.93)----
9.4 Made the distinction between WPF and WPF/E more explicit. 9.3 Counter argument and modified abstract 9:2 abstract 9.1: fixed most eggreejuice spelling errors.
Abstract
Right now, the web application world is in harmonious balance. Java and .NET compete, but browsers are written in C etc, so no one has an advantage.
The competition right now is to see who can wring the most out of the rather limited, but (somewhat) common denominator that is the JavaScript/DHTML browser.
The Java community obviously see this balance continuing.
Microsoft plan to unbalance the equation -by introducing a pure .NET browser, for Windows and other platforms so fundamental and powerful that it doesn't even look like a browser.
WPF makes messy things like Javascript+dhtml go away. More important, it makes practical something that isn't possible with any one of the handful of alternatives supported by Java -the intersection of applications, content and multimedia.
Ultimately, there will be a Java technology that looks a lot like WPF and XAML. How much lead does the Java world want to let Microsoft get?
So what is this WPF, WPF/E and XAML stuff anyway?
Here is one way to approach WPF and XAML:
Suppose you were going to re-implement HTML and its browser -and make these more useful as a web application platform for a web2.0 world.
Obviously you would NOT want to lose the good stuff..
- Ease of Deployment. We don't want to install applications -we just want to send out a page of markup and sandboxed code.
- Data as interface. Amazon is an application, but it sure isn't battleship gray forms. In many ways web application UI's have generation-gapped desktop UI's
We would want to lose...
- Old pre-style junk, even though lazy people like me use it all the time.
- All those IMAGES. On the web, we do stuff with images that we would do with vector graphics on a desktop app. Images don't resize well, apps built around arrays of images don't resize at all. Images are only crudely dynamic at best.
- All those horrible inconsistencies between browsers. OK this an implementation and standards issue -but we don't like it.
We would want to add...
- Serious Multimedia support
- Vector graphics -to solve the images problem, but also for all those occasions where we use SVG. (Yes we would be adding directly functions that XHTML promised by virtualising the browser)
- All those desktop UI elements and paradigms currently not available in HTML markup -eg menus, and tabs.
- We might even decide to add 3D graphics
Implementation
Being Java people (well I'm not, but you are), of we would go and write a Java browser. The very fact that the implementation was in Java would get us some important wins:
- A respectable development environment. Look at the incredible lengths that Google are prepared to go to just to get a Java development environment (ie with their web toolkit). Never mind that they are prepared to throw it away at runtime!
- All elements created by our markup would be first class Java objects, ready to be manipulated by client side Java code (yes we have been skirting the issue of where the app runs)
- The elements and framework would of course be extensible in Java
- We would have the whole Java API (cw Google web toolkit), the whole Java language and Java speed.
Deployment
We would obviously have several choices re deployment.
- Our Java browser might be deployed as a plugin in a traditional HTML browser. The WPF
- Our Java browser might be, "the browser".
- We might deploy uder a model like Java web start -with as many or a few hooks into the OS as we could negotiate with the user or her IT department.
But also... ***We might decide we liked this stuff so much that we built an entire desktop around it.***
Does this all sound good to you? Well this is what Microsoft are doing!
Except of course it is all .NET based. XAML is the markup, and WPF (Windows Presentation Foundation) is the um browser (as it were). And the /E means Everywhere, meaning not just on windows. OK, this is not going to be easy -but Microsoft have the resources. Maybe Windows will become the desktop, not the whole OS...
WPF itself is fundamental to Vista and potentially tightly coupled to the OS. WPF/E, is a cut-down, more browser centric, cross platform subset. Significantly, it does run IL.
In some respects WPF/E is like an Applet or Flash. It will run in a browser and provide an external JavaScript interface.
It can sit in amongst other content, or like Flash, effectively operate as a browser within a browser.
"Yeah yeah, replace HTML? Ha ha. The game Bill can't win, but can't stop trying. Just more Passport."
Well maybe, but keep in mind...
- Microsoft control the game. Because of the market share of IE, they can stall HTML development. Anything they do for HTML now is a gift to Google
- They don't need general adoption. They can just keep growing slowly. They don't need to attempt to replace static content (yet).
- This time the browser really is embedded in the OS, and it will become as ubiquitous as Windows (and yes there is a strong case that the model breaks at this point because security becomes impossible)
- Windows desktop apps will be the same thing as windows rich client apps, and that is a powerful base to grow from.
- WPF/E fits the Ajax model. It isn't an all or nothing model of browser based content or WPF content.
- It isn't really about replacing HTML -it is about making the platform so compelling that say Google, can't ignore it.
- And don't forget the /E. That has been Java's turf until now.
But what really Freaks me out
Is the lack of response, or even awareness in the Java community. There are a few projects out there (including someone implementing XAML) but nothing aimed directly at this middle ground between the web as we know it and old fashion rich clients.
"But we got applets"
- Have you? What are the numbers like compared to say Flash? The REALLY bizarre thing for me is the way Java people have cheered Flash on as it pushed Java out of browsers. And while we are talking Flash, have a look at Flex. Sound like anything we describe above? I figure that only Microsoft, MacrodobeMedia and Sun would have a chance at deploying a new browser of this kind -only Sun doesn't seem interested.
- More importantly, Applets lack all the browser functionality. They are after all, not exactly the latest technology. They share this limitation with RCP's (below).
- I personally want to see "Java Client Edition" -with a download size that stacks up against Flash. Download more classes later.I want this sooner rather than later.
"But we got Rich Client Platforms"
What you got, is client server over the internet. This certainly has its place, but warmed over IDE's(or rather "stick a badge on it and call it an RCP") just don't do the content centric thing. The same is true of the various initiatives that provide markup for GUI's (or for forms) -they don't go anywhere near far enough towards documents, content and graphics. This discussion deserves much more attention than I'm giving it -but it's late.
"But we got AJAX"
Make Ajax hay while the sun shines!
It strikes me that Ajax technology is a lot like fax technology. When fax became popular, it was horribly crude compared to paper -but paper was so ubiquitous that semi-electronic paper was a killer app.
Compared to Java and .Net, Javascript+DHTML is horribly crude -but the browser is so ubiquitous that Ajax is a killer app. It will rise fast, but just a fax inevitably gave way to real digital technology, Ajax will give way to real rich web technology.
It seems to me that Java people are so enthralled by Ajax, that they aren't considering what comes next -and how short term Ajax may be.
What Google are doing (compiling Java to JavaScript) is mind-boggling (will we see a C# equivalent from someone??) -but if you stand back a bit, what it really says is "boy, what would we give for a Java browser!".
In this sense, Java and .Net have both been seriously *but equally* handicapped. Neither had a browser with any significant deployment. .Net will have a really powerful one soon. So Ajax boils down to this, do Java programmers really want to duke it out with .Net, when the .Net people have their complete arsenal, and Java people have... JavaScript. This is plastic fork at a knife fight country.
"But Java still wins on the Server"
True. If Bill Gates ever says to you "well yes I guess you could implement the services on a non windows back end", what he is really saying is "you're my little puppy-dog now!".
Do we want to live in a world where .Net can get the job done, and Java can get the job half done?.
[This is why I was interested in Sun's announcement re Visual Basic on Java. I'm hoping this pans out as a way to write cross VM code (well a statically typed way -Python is probably there now and Ruby isn't far off). If Visual Basic is the only way to allow (mostly) one codebase, with XAML on the front end but with a JVM option on the back -then I will check my pride at the door and get on with it.]
Then there is that whole web2.0 thing.
But I'm running out of steam here (not the argument -just me).
There is an implicit assumption in this essay that the future is indeed rich clients calling web services.
I think the client is a good place to wrangle services. Multiple services (breaks Applets -Ajax??).
I also think that Microsoft (for once) has the moral high ground. The more that happens on my PC the more power I have. I would also bet money that tomorrow's big scary companies will be much scarier than Microsoft ever was.
The counter argument.
It seems to me that there is *something* in Java that will do more or less all the things that WPF and XAML do (maybe not the multimedia).
The Java strategy is to cover the bases with multiple technologies. If webforms run out of steam, use Ajax. If Ajax runs out of steam use Ajax and Applets. If that is too messy, use a single Applet or a web start app. It you want more desktop infrastructure use an RCP.
This is a pretty solid strategy. The down-sides are:
- You have to pick a technology.
- None of them allow you to really combine applications, content and multimedia.
The (massive) up-side is, these are all doable today.
(It is worth noting that slightly fewer choices are available to .Net developers today, but it isn't like ASP.Net doesn't do Ajax, or you can't write a rich client on winforms.)
By comparison, Microsoft are building a single, unified platform that will do it all. This approach faces some big hurdles:
- It needs a new runtime. Users have to install something (or let update install it for them), or buy a new computer running Vista.
- It is a brand new technology for developers to learn.
- Security. The browser has obviously become a kind of firewall. WPF/E has fine grained security, but ultimately it can't leverage the parent OS without exposing it to the big bad internet.
- It is new ground, and Java will be able to learn from Microsoft's mistakes. Java may get to pay WPF/E the kind of complement that C# pays Java.
And in conclusion your honour
I have been writing web apps for nearly 10 years. Like lots of people I used DHTML and "out of band" calls from the browser (using an Applet before XML Dom) to do what is now called Ajax. I wrote a web framework to try to abstract-away the web.
All the time, I felt I was faking something. It wasn't quite faking the desktop because I certainly didn't want to do "forms applications".
When I saw XAML, I immediately recognised it as the thing I was faking. The intersection of applications, content and multimedia.
The fact that there is nothing in Java to match it, simply means I can't swap to Java right now, even though I like the feel of the Java world. .NET feels a bit like my local shopping mall these days -everything is nice and shiny, but I feel a bit out of place.
In the bigger picture, I am a bit worried that the Java world doesn't seem to be planning for this new battle with Microsoft.
Ultimately, there will be a Java technology that looks a lot like WPF/E and XAML. How much lead does the Java world want to let Microsoft get, especially given how fast Microsoft can move when it needs to.
Right now it's still a fair fight for space on IE, Firefox and the rest. I once met a battle scarred bouncer (at of all places, one of those Welsh Holiday camps that is the size of a small city with too many pubs). Of fair fights he said to me "oh it's not our job to fight fair -we just tool up". Microsoft are tooling up. Java isn't.
Make my day! Mail me and explain why I am completely wrong and can safely abandon .Net for Java. 
Pete F