Once upon a time, the notion of delivering application functionality over the web seemed fanciful. The misguided thinking of some web zealots. I should know, having worked in shops that did both client/server and portal/web development. Shops that left me similarly skeptical (in the distant past).
But of course that was then, and this is now. The application landscape circa 2007 is, of course, heavily web oriented. As some of the gray beards in our midst have pointed out, it’s as if we’ve come full circle back to our green screen mainframe days. The more things change, the more they stay the same. And so on.
Over the last quarter or more, however, we’ve seen a resurgence in interest in what are often termed Rich Internet Application technologies, or RIA. Between the high profile vendor announcements (Apollo, JavaFX, and Silverlight) and some lower profile alternatives (RCP, XULRunner), the number of available paths for would be web application developers to walk down are proliferating rapidly. That much is clear.
What’s less clear is where some of these paths might lead to, the degree to which they stray from the major web thoroughfare, and what it might cost over the longer term to walk them. Or, in some cases, why there’s a separate path in the first place.
While I’m certainly not in a position to answer all of the above, perhaps by exploring some of the questions in more detail we can make tracks towards some answers. To the Q&A.
Q: Before we begin, anything to disclose?
A: Lots, in this area. All of the vendors behind the “high profile” RIA offerings mentioned above – meaning Adobe (Apollo), Microsoft (Silverlight), and Sun (JavaFX) – are customers in some capacity. As are backers of some of the “lower profile” technologies, such as Eclipse (RCP) and IBM (RCP, XULRunner). I think that covers it.
Q: Just to set expectations appropriately, what are your thoughts on the need for RIA technologies in general?
A: I’m a confirmed skeptic. Are there areas of opportunity? Sure. The JavaFX focus on mobile devices, as an example, I think is one area of significant opportunity because a.) the browser paradigm isn’t cemented on mobile devices, and b.) it probably is not the best usage of limited screen sizes. Likewise, there are things that HTML, CSS, Javascript and so on simply can’t deliver without some help – things like video.
But overall, I’m less convinced than many that we actually need some of the technologies being offered.
Q: Why is that? Some of the demos, after all, are very cool.
A: Well, let’s set aside my concerns with the ulterior motives and agendas at the moment, and just focus on the actual use cases. Ultimately, I come back to something Tim Bray wrote nearly four years ago. In part, he said:
On more than a few occasions—most recently in the context of Avalon—I’ve observed here that both IT admins and end-users prefer browser-based apps to traditional compiled clients, for everything except content creation. Every time, I get emails and incoming pointers from people saying “You just don’t get it, the Web interfaces are so tired, we really need a richer UI paradigm.” The interesting thing is that these reactions are always—every time, without exception—from developers. Not once has an end-user type person written in saying they wished they could have a richer interface like the kind they used to have in compiled desktop apps.
I agree with this. Forget the fact that I spend better than 95% of my day in a browser – yes, even for email and so on – because I’m as far from the typical user as you’re going to get.
Just consider your family and friends: are they mostly working off of network based applications? Webmail? Search? Banking? And so on? If yours are anything like mine, the answer is yes.
Cue Joel Spolsky:
“Users don’t seem to care about the little UI glitches and slowness of web interfaces. Almost all the normal people I know are perfectly happy with web-based email, for some reason, no matter how much I try to convince them that the rich client is, uh, richer.
So the Web user interface is about 80% there, and even without new web browsers we can probably get 95% there. This is Good Enough for most people and it’s certainly good enough for developers, who have voted to develop almost every significant new application as a web application.”
Q: But still, there are things that rich clients can do that thin clients cannot, correct?
A: Of course. Just as there are things that thin clients can do that rich clients cannot. Or, as in the case of cross platform compatibility (try and find Linux support for Apollo or Silverlight) choose not to.
But the thing I find fascinating about the capabilities question is how quickly that’s changing. A few years ago, it would have been ridiculous to suggest that CRM could be delivered via the browser. Now? Saleforce.com and SugarCRM seem to be doing fairly well at that, and we at RedMonk are very pleased with Highrise. Even applications that have been held up as canonical examples of applications that can’t be delivered via the web, like Photoshop, are going online.
As Bill de hÓra says:
The real question is, what requirement cannot be met by a browser based app, *especially* if you include XUL? I mean fundamentally can’t be met or utterly pointless, not just “difficult” (difficult is merely motivation). The benchmark used to be a word processor, now it seems to be Photoshop.
That is indeed the real question, as far as I’m concerned.
Q: So you’re not convinced, in other words, that the extra bells and whistles are going to compel adoption?
A: In some cases, they certainly will. But ultimately, history seems to indicate that ubiquitous availability trumps functionality. The browser is available on any platform; at this juncture, at least, many of the aforementioned RIA technologies are not. Which is not to mention that the functional gap has narrowed dramatically over the past few years: application responsiveness was addressed in part by Ajax, offline capabilities are in the process of being solved by a variety of approaches.
Q: What do you think the market opportunities are, then, for the RIA technologies mentioned?
A: Obviously, I think the individual technologies will start from their respective ecosystems. Apollo will appeal to Flash/etc developers, JavaFX to Swing/etc devs, Silverlight to .NET folks, and so on. And to be clear, those respective ecosystems are nothing to sneeze at; they’re very sizable in their own right. Each technology, in effect, has a built in opportunity in front of it to leverage.
The question will be, in my mind, to what extent each can grow beyond its own developer base. Can they, in other words, begin to poach some of the developers that today are developing pure web applications. Can they persuade these independent developers that a.) there’s a volume audience waiting for the type of internet application that cannot be delivered using today’s pure web technologies, and b.) that their respective infrastructures are the right path now and going forward.
Q: What do you think the answer is?
A: Reactions, as you’d expect, depend largely on who’s doing the commenting. If you’re a Flash developer, or a Java developer, or a .NET developer – what Tim would refer to as a sharecropper – the odds are you’re pretty excited. And that’s probably a good thing; more capabilities for those platforms is certainly welcome.
But amongst folks that I read, what I see is substantial and mounting concern over, potentially, a threat to the web.
“The answer to the question of Mozilla’s direction seems dependent on what one sees as the proper goals of Mozilla. Is Mozilla simply a browser company? Is it broader than that: a platform for internet applications? Or broader still, as the central front and last best hope for a free and open web?”
Coté:
“To cut to the chase: the growing Flash/Flex/Apollo RIA reach rankles me.
It seems like a direct threat to the web.
The path that I’ve seen Adobe going down is creating their own networked platform. As I think of it “the web without all that web.” Instead of using the web, you’d use the Adobe client, be it Acrobat to edit forms or one of the RIA clients, or, at least, an HTML page with an embedded Adobe RIA.
There is no single vendor that’s created and provides the platform of the web: as you may recall, Netscape and IE tried the proprietary lock-in gambit. And then were were Java applets, ActiveX, and all manner of other end-routes around plain old HTML. In the end, no vendor or approach has been able to shove the web off into a corner and treat it just a back-end.”
“The browser is the new desktop and Microsoft is hoping that the CLR and Silverlight in general will be the new Win32 API and/or virtual machine. And they’re doing it in a way that only Microsoft can: by delivering full documentation, debugging tools, very large partners, and a world-wide network of trained evangelists and support staff. Say what you will about the company, but they know how to roll out software to developers. They’ve been doing it for a very long time.
That’s really what this is about. It’s not about competing with Flash. Microsoft is thinking much bigger than people seem to be giving them credit for.”
“I don’t think you should need to buy, or even use-for-free, any given tool to build the web, and by using and helping to drive open web technologies Mozilla lets people choose the tools they want to use. We don’t force you to use the ones that we make money or marketshare on: you can use Eclipse or Firebug, Rails or J2EE, Komodo or Notepad, YUI or Dojo. If you ask the people who are building the exciting and significant apps on the web today, be they gmail or eBay or twitter or facebook or flickr or even Windows Live Search, I bet you that vanishingly few of them use IDEs. They use the tool that works best for them, for a given problem, sometimes using a bunch at once. I would be very surprised to discover that all of a given team even uses the same text editor, to be frank.”
“Play with your vendor-specific runtimes. Don’t call me when you wake up one morning with a pink line in the round window and your BFF vendor won’t return your calls. If you need me (but of course you won’t), I’ll be holed up in my drab unpainted toolshed around the corner, quietly building applications on the web that works.”
“These latest announcements are a continuation of the great history of vendors trying to get people to abandon HTML in favor of the proprietary flavor of the month. The most successful attempt has been Flash, but it hasn’t made significant inroads against HTML. Most Web sites built using Flash are derided as useless and idiotic. Java Applets, ActiveX controls, and all other attempts along those lines have been failures. The title of this post refers to one of the original threats to the Web — Microsoft Blackbird. Back in 1995, everybody was talking about it as a richer, more powerful platform to replace HTML. (Check out this Byte article for a breathless preview that contrasts it with Java.)
Needless to say, I’m still betting on the web. I imagine the latest generation of proprietary web-based platforms will wither on the vine just like their ancestors.”
“A worst case scenario may very well be that, over time, increasingly more and more content gets rendered by a common plugin that is closed source and controlled by a single vendor.”
“The fawning over Silverlight and Apollo is incredibly short sighted.”
“In the end, though, I probably won’t be doing much with Silverlight, for the same reasons that I’ve written about before. The technology has definitely gotten stronger, but the other issues haven’t really changed much: there are no tools for the Mac or Linux, and as far as influencing the technology, you’re just standing outside the Big House, pressing your nose up against the window.”
Q: Most of the concern, then, seems to center on the vendor oriented initiatives: what of the alternatives?
A: Glad you asked. Back in March, Anne posited that the real threat to Apollo was Firefox, not Silverlight. I think she’s correct in her assertion that Mozilla is the real player here, but to me its the combination of Firefox and XULRunner that’s the real threat. One of the more perplexing developments in all of the discussions of Apollo, JavaFX, Silverlight, and so on to me has been the glaring omission of XULRunner. For the unfamiliar, XULRunner Wikipedia defines XULRunner as “a product in development which will serve as a runtime environment for XUL applications. It replaced or renamed the Gecko Runtime Environment.”
In development it very well may be, but the projects being built on top of it are interesting. Mitchell mentions Joost and Songbird, but I’m far more intrigued by its usage within IBM’s Lotus portfolio. Faced with some of the same challenges application development wise as Adobe, Microsoft, and Sun – but without the same need for platform relevance – IBM chose the Mozilla route. Along with, of course, their RCP foundation.
As James Andrewartha has very kindly kept me appraised of, there’s considerable upheaval within the Mozilla community at the moment concerning XULRunner, so that may be playing a role. See, for example, Chris Brentano’s comment from here:
I think that despite what Mozilla and Co think their obligation to the community is, the community obviously has a different perception. Chris simply stepped up to say what many people I’m certain were thinking. Mozilla took millions of users under their wing, offering a “Better, More Secure Web Experience”, and while they’re giving away their product for free, they still have to support their customer base, and part of this (as Chris described) is to keep the web open and free by stepping up to the challenge of proprietary and closed frameworks such as Apollo, Silverlight and Java FX. By failing to do so they fail the millions of people they liberated from closed proprietary products such as IE that they worked so hard to free people from.
You don’t criticize if you don’t care, as the saying goes, and I think Mozilla’s moves to address the specific issues here are almost besides the point.
What’s far more relevant, and far more interesting, is the importance a number of developers are beginning to place on what was once little more than an interesting project. In a strange way, the introduction of Apollo, JavaFX and Silverlight have galvanized interest in the Mozilla based project, and compelled it in some fashion to (willingly?) become the standard bearer for a multi-vendor controlled future.
Q: How do you mean non-vendor controlled? Aren’t we likely to see open source implementations of JavaFX and Silverlight, at a minimum?
A: Indeed we will. The open source JavaFX project page is already up, and Miguel and his intrepid band of Mono developers have committed to implementing an open source version of Silverlight under the project name of Moonlight. And while Apollo isn’t open source, Adobe is releasing the Flex technologies.
But while these are commendable decisions on the parts of the respective vendors, open source does not in this sense equate to independent. In some respects, it’s akin to the difference between the open source Linux and MySQL projects. You can freely obtain the code for each project under the same license, but the former project is contributed to and driven by a number of parties while the latter is maintained and developed solely by a single entity.
Q: The motives, then, are what you are questioning?
A: In part. Consider the shift to web applications, from a vendor perspective. At one point, you needed expensive tools to design me an application that I needed to a.) pay you to run, and b.) pay someone else for an operating system to run it on. That’s good for vendors.
For the general computing public, that’s still largely the case, but the trend is clear: applications are increasingly being developed using free tools and delivered via a medium that is indifferent to my operating system, and I may or may not pay you for the application. That’s good for customers.
There will be, rightly or wrongly, concern on the part of developers that the RIA technologies are little more than an attempt by vendors to stave off a future in which they’re significantly less relevant. Hence the increased attention to technologies like XULRunner.
Q: What about choice? Isn’t it good that developers have more choices for designing richly functional applications?
A: As mentioned above, I do think it’s a positive for the respective communities that these technologies are made available to them. But, like many of the folks above, I’m concerned at the larger ambitions harbored by some of these technologies. A proliferation of content delivered in Silverlight, as an example, would negatively impact me as a Linux user. Ditto for Apollo.
But I’m also concerned that the task of web development – already non-trivial even with a handful of viable browsers – could get even more difficult. Beyond the technology implications, the Paradox of Choice is sure to be operative.
Q: Considering the above, then, what lies ahead for the mentioned technologies?
A: Keeping it conservative, as I dislike intensely the business of prediction, I’d say the following: Apollo will capture the attention of the Flash/Flex crowd, but have difficulty displacing XULRunner for applications such as Joost or Songbird. Silverlight, will initially gain traction as a Flash alternative for Microsoft-heavy shops, and build from there. JavaFX, meanwhile, will build out from its mobile story, which is quite strong, but have trouble with desktop penetration. RCP will remain buoyed by IBM’s dedication to the platform, while XULRunner – depending on how the community perceives their response to recent criticism – will pick up momentum not because it’s a platform of choice for ISVs small (Joost) and large (IBM) – but rather the fact that it’s not the competing technologies. Beyond that, it’s too difficult to say.
Q: So in short, your views are…
A: If you’re working with the web, and staying true to the path of platform independence and compatibility, you’re with me. If you’re not; if you’re trying to replace and/or subvert the web, you’re against me.
