Tim Anderson’s ITWriting

I’ve just come across riastats.com which has statistics on which RIA (Rich Internet Application) plug-ins are installed on which browser.

The stats are from a relatively small sample: it claims to have analysed 1.5 million browsers across 42 sites at the time of writing.

The headline: Flash is on over 97% of browsers; but only 52% are at version 10. Java is on just under 75%, while Silverlight can only muster 20% penetration.

I also noticed that Firefox (25%) users are more likely to have Silverlight than IE (20%). Maybe all those locked-down corporate desktops.

Another snippet: less than 30% of Linux users have Sun’s Java plug-in installed.

Microsoft can take some comfort from the direction of the graph. In December 2008 only 15% of browsers had Silverlight. That’s pretty fast growth.

Still, the bottom line is that if you want to be fairly sure that your users have nothing to install in order to view your RIA content, use Flash. But stick to version 9.

Indeed, will it do so? I like Silverlight a lot; though I appreciate that to a Flash developer it may seem pointless. It does a lot of stuff right: small download, powerful layout language, cross-platform (with caveats), rich media, fast just-in-time compiled code.

Still, what intrigues me is how Silverlight has come from nowhere to what seems to be a central position in Microsoft’s product strategy in just a few years. What’s the business case? Or is it just that someone high up experienced a moment of horror – “Flash is taking over in web media and browser-hosted applications, we gotta do something”?

Let’s eliminate a few things. It’s not the design and developer tools. Making a profit from tools is hard, with tough competition both from open source, and from commercial companies giving away tools to promote other products. I don’t know how Microsoft’s figures look for the Expression range, but I’m guessing they bleed red, irrespective of their quality. Visual Studio may just about be a profit centre (though the Express series is free); but Silverlight is only a small corner of what it does.

Nor is it the runtime. Adobe can’t charge for Flash; Microsoft can’t charge for Silverlight.

I asked Twitter for some ideas. Here are some of the responses:

migueldeicaza @timanderson, my guesses:WinServer built-in-steaming;Strengthening .NET ecosystem, and client-server interactions;Keep share in RIA space

IanBlackburn @timanderson Isn’t Silverlight going to become the "Microsoft Client" and central to s+s?  Apps built with it can be charged in many way

harbars @timanderson no doubt with annoying adverts

mickael @timanderson isn’t silverlight a defensive move against other RIA platforms (like Adobe’s one)? They might only plan selling developmt tools

jonhoneyball @timanderson In the long term by hosting tv stations’ internet traffic and providing the charging/hosting/download/player model.

jonhoneyball @timanderson ie azure cloud + silverlight + someone elses content = ms revenue. no, it wont work, but its not unexpected ms-think.

jonhoneyball @timanderson why no work? price war to come on cloud host/delivery etc Someone will host BBC for free. Game over

There are two main themes here. One is media streaming; as the Internet takes over an increasing proportion of broadcasting and media delivery (note recent comments on Spotify) Microsoft plans to profit from server-side services. The challenges here are that there may be little money to be made; Adobe has a firm grip on this already; and Apple will do its own thing.

The other is about applications. This is the bit that makes sense to me. Microsoft knows that the era of Windows desktop clients, while not over, is in long-term decline; and that applies to applications like Office as well as custom business applications. Silverlight is a strong client platform for web-based alternatives. So I’m voting for Ian Blackburn’s comment above: it’s the Microsoft Client.

If that’s right, we’ll see Silverlight embed itself into more and more of Microsoft’s products, from desktop to server, just as Adobe is gradually remaking everything it does around Flash.

The difference is that Microsoft has far more invested in the status quo: selling Windows and Office. I’m guessing that there are heated internal battles around things like Web Office. The briefing I attended at the 2008 PDC on Office Web Applications was fascinating in respect of its ambivalence; for every web feature shown, the presenters wanted to emphasise that desktop Office was still the thing you should have.

Some members of the community around Adobe’s open source Flex SDK are fuming at a decision made by Adobe back in October 2008, to prefix the new skinnable components in the forthcoming “Gumbo” release with Fx. This means you can disambiguate old and new components such as Button without relying on namespaces. On the other hand, what is wrong with namespaces? The issue has provoked a lot of debate, partly on the merits or otherwise of the Fx prefix, and partly on the open source development process itself. The Fx decision was announced rather than discussed. Simeon Bateman, who is now all-but proposing an Fx-less fork of the SDK, says:

Creating an open source project is about openness in planning and development. Not just about giving people the right to do with the code what they will. And this part of the Flex project is a complete failure … The current Flex SDK team has about 20 developers and they are fiendishly working on the code for the next version of Flex, version 4 code named Gumbo. And they are doing all that development in private, behind closed doors with nothing but commit logs for us to know what is happening. This is an open source project and we have no idea what is going coming or what the timelines are for milestones. What the hell are the milestones?

Manish Jethani argues that Fx is a sign of haste and corporate pressure:

Even though Flex is an open source project, it is very much run per corporate interests. In a truly open source project like the Linux kernel, there are no deadlines — it’s ready when it’s ready. That’s how research departments work. But Flex is no research, Flex is business. Why, wouldn’t the ‘Fx’ prefix give Flex Builder yet another advantage over competing IDEs? Think about it.

Ben Clinkinbeard has created a survey to allow Flex developers to express their opinions, though as a commenter notes, it is more of an objection petition than a survey.

Adobe responded with an online open meeting to discuss this and other matters which took place this morning – you can play the recording online. It may have been frustrating for those who felt strongly about it, since after presenting the reasons for the change the presenters deferred further discussion to the online forum. As far as I can tell, the Fx decision is unlikely to change.

Well, there is open source, and there is collaborative development, and they are not the same thing. Adobe retains tight control over Flex for the sake of its commercial interests. It is a reminder that although the Flex SDK is open source it is not a community property in the same way as Apache.

Once crumb of comfort for Adobe is that this kind of intense debate shows the high value of Flex to its developers. It would be far, far worse if nobody cared.

Update: you can vote against the fx prefix or discuss it in Adobe’s bug-tracking system here.

The Java runtime used by Sun’s JavaFX is mature and well optimized, which means that non-visual code will generally perform well. I’ve just spotted that Josh Marinacci at Sun put up a version of my countprimes test to illustrate this. Here’s the JavaFX version. On my system JavaFX and Silverlight are neck-and-neck for this – sometimes one is faster, sometimes the other. Flash is much slower, and Javascript not in the race.

Next stop: an Alchemy version.

Sun has launched JavaFX.

 
Sun’s Eric Klein, VP of Java Marketing, explains JavaFX

What is it? Sun says:

JavaFX is a rich client platform for building cross-device applications and content. Designed to enable easy creation and deployment of rich internet applications (RIAs) with immersive media and content, the JavaFX platform ensures that RIAs look and behave consistently across diverse form factors and devices.

What is it really? A new script language called JavaFX; a compiler that turns JavaFX script into Java bytecode; a runtime that includes new media codecs; converters that turn SVG, PhotoShop or Illustrator graphics into JavaFX format. JavaFX also requires the JRE (Java Runtime Environment). Currently only Windows and Mac OS X are supported; Linux and Solaris support “will be provided in a future release”; mobile is also on the way, promised for Spring 2009.

A variety of video and audio codecs are supported, but unfortunately these vary by platform. For example, WMV plays only on Windows; H.264 runs on Mac but on Windows only “as an update”, whatever that means. However, there is a specific “cross-platform” codec, which is VP6 from On2. Snag: you need On2’s commercial software to convert to the required .FXM format.

What’s good about JavaFX? Sun claims broadest market reach; but this is nonsense – I presume it is counting every device with a smidgen of Java installed. There are some advantages though. JavaFX can run Java code, and there’s plenty of that out there. The Java VM is mature and fast. A neat feature is that you can run JavaFX applications outside the browser by dragging them onto the desktop. Even in the browser, Java FX are not confined to the browser window, but can create graphics that appear anywhere on the screen. Java SE 6 update 10 or higher is required for these features, which depend on an out of process Java applet plugin in this update.

What’s bad about JavaFX? There are several reasons why Sun will find this a hard sell:

• Large download size. Flash and Silverlight are self-contained browser plug-ins; Silverlight is larger than Flash, but still under 5MB. I’m not sure exactly what size JavaFX is on a machine without Java. I tried visiting javafx.com on a new XP install, and was directed to the main Java download site which recommended a JRE of about 7MB; I suspect it might do further incremental downloads after that, since the full JRE is more like 15MB. Once the JRE is in, you still need to install the JavaFX runtime, though is done automatically and I imagine that in time JavaFX will just be part of the JRE. Right now, the process is less smooth than for Flash or Silverlight.
• Lack of design tools. Adobe has its fantastic Creative Suite, most of which now seems to target Flash. Microsoft has Expression. Sun is offering converters for Photoshop and Illustrator or SVG. These applications know nothing about JavaFX, and there is no visual editor in NetBeans 6.5.
• A new language. Although JavaFX script does not look particularly difficult to learn, it is friction for developers wanting to give it a try.
• Signs of haste. I’m seeing this now. When I saw the JavaFX announcement, I went to the site and successfully installed the runtime and played the introductory video, which itself uses JavaFX. Soon after, presumably as word spread, the launch site became unusable for me. Videos do not play; samples do not download. The spin will be that this shows the high level of interest; but vendors like Sun are meant to understand about scalability.

   
  JavaFX.com showing signs of stress on launch day

• Late to the party. Adobe is well entrenched with Flash. If Microsoft is late with Silverlight, Sun is very late with JavaFX.
• Limited features. I’m just back from Adobe MAX, learning about features like Pixel Bender in Flash Player 10, and its new text rendering engine, and new audio API. The JavaFX API looks limited by comparison. There is no 3D support yet.
• Lack of compelling reasons for adoption. You can run Java code; but then again, Java applets and desktop Java clients have been around for many years. I can see the value in both Flash and Silverlight, but what is the must-have feature of JavaFX?
• Platform variation. It bothers me that JavaFX supports different codecs on different platforms. What happened to write once – run everywhere?

What else? It’s early days. I’d like to hear from Designers whether JavaFX does what they need. JavaFX will improve, and it does have obvious value for Java developers who want to code rich internet applications. Sun’s commitment to open source may make JavaFX interesting to those who find Flash and Silverlight too tightly locked to single vendors.

Some details above are drawn from the JavaFX FAQ.

One OS – one device – one AppStore – easy over-the-air purchase for end users. Apple’s development and deployment model delivers results, despite mutters about lock-in and Apple helping itself to a generous slice of the revenue.

Here at Adobe MAX Europe we’ve been hearing about the future of Flash on mobile devices and even seen a demo of what many would like to be able to do: simple over-the-air download of both the Flash runtime and Flash applications. Flash is a great runtime for a mobile device. A while back I reviewed the LG Viewty phone, which has a Flash UI, and despite some imperfections it convinced me of the potential of Flash for mobile devices.

Even so, it will be difficult for Adobe to create an application platform that works as well as Apple’s AppStore. Here are some of the problems.

• Device-specific APIs. I spoke to the folk on the Sony Ericsson stand here at MAX. If you want your Flash application to do things like talking to the GPS, or integrating with the PIM (Personal Information Manager) on the phone, then you have to write a device-specific version of your Flash application. This adds to the development effort and creates friction in the deployment process. Will Adobe wrap device functions in Flash APIs? I asked about this at the press briefing today. The answer from Senior Principal Scientist Mark Anders was yes … maybe. He mentioned that API bloat became a negative for Java. It really is a difficult thing to get right.
• Operator interference. Apple has bullied the operators it works with into doing things its way, and gets away with it because the device is so desirable. The operators though are reluctant to be no more than data carriers. They lock down devices, run their own application stores or music services, and make it difficult to mount a convincing challenge to Apple’s single store.
• Diversity of devices. Diversity is good, sure. It’s tough for developers though. Maybe there’s a keyboard, maybe there is a touch screen, maybe there is a joypad, maybe the screen is big or small. Your app has to work well in every scenario, or else limit the number of devices it supports. Much easier with Apple, just one device to target. That will change somewhat as Apple bring out new iPhone variants, but there will always be more consistency from a single vendor.

It was similar factors that caused Microsoft to abandon its third-party vendors and create Zune, in an effort to compete with the iPod. Microsoft was too late. I am sure we will see increasing use of Flash and Flash-based applications on mobile devices; but it will be hard to displace Apple’s iPhone as the foremost mobile platform for downloaded applications.

Flash in the mobile browser is another matter, of course. If Apple continues to exclude Adobe’s runtime – which I guess it does to protect its application business – then it makes a nice selling point for competitors which do support Flash.

New post over at itjoblog.

I love the careful wording on Adobe’s Alchemy site:

The purpose of this preview is to assess the level of community interest in reusing existing C and C++ libraries in Web applications that run on Adobe® Flash® Player and Adobe AIR®.

It needs to be put cautiously, because Alchemy – unlike Google Web Toolkit, which handles Java to Javascript – is not intended to become a general-purpose alternative to ActionScript. Rather, the idea is to enable existing C/C++ libraries to work within Flash applications. Examples given include transcoders, cryptographic algorithms, and XML parsers. Performance is said to be 2-10x slower than native code. Alchemy was demoed today at Adobe’s MAX conference.

Possibly a Java to ActionScript compiler would be more useful to most of us; though for new code ActionScript 3.0 is close enough to Java that it should not be difficult for most developers to learn.

News from the Adobe MAX conference this week in San Francisco: Ensemble has developed an add-in for Visual Studio for Flex development, code-name Tofino. It’s currently in beta and available for download. Flex is Adobe’s developer-focused SDK for Flash applications.

I installed it this morning, and so far it does not impress. There is zero documentation (just a few links to the standard Flex docs on Adobe’s site), and it lacks even MXML Intellisense, let alone a visual designer. When you go to project properties, there is nothing to configure. The toolbox is also empty. On the plus side, it successfully invoked the Flex compiler to build the project, and managed to open it as a static file in Internet Explorer when I clicked Debug. I’d prefer an option to use Visual Studio’s built-in web server for debugging. There must be more to it than this; then again it is advertised as a beta which is meant to mean well advanced (ha ha). I suggest sticking firmly with Flex Builder for the time being.

Adobe has largely ignored .NET in its Flex and AIR technology, though it does support SOAP. I am not sure whether this is caused by aversion to Microsoft, or an assumption that Microsoft developers will use Microsoft technologies like Silverlight or Windows Forms, or a bit of both. Integration with Visual Studio and server-side .NET could be significant for Flex adoption, though it would be better if Adobe itself were doing the add-in.

You can see the same thing happening on Microsoft’s side, with a half-hearted Silverlight project for Eclipse (which only works on Windows), or the well-regarded Teamprise which integrates Eclipse with Visual Studio Team System. In both cases Microsoft keeps itself at arms length, which does not have the same impact as in-house support.

There are always concerns about the quality of third-party applications. I am sure Adobe itself would not have put such an inadequate preview up for download, as Ensemble has done for Tofino.

The route to dizzying riches in this industry is to own the platform. Look no further than Microsoft, which not only sells the operating system, but also dominates the applications which run on it, from Microsoft Office on the desktop, to server products like Exchange and SQL Server, and network management software like System Center. Anyone can build applications for Windows, and plenty of third-parties have done so successfully using its free SDK (Software Development Kit), but somehow it is Microsoft that profits most.

Microsoft is still doing its thing, but attention is turning to the next generation of Internet-based computing. I touched a nerve when I asked Google’s Dion Almaer about Adobe Flash: it’s not open enough for Google, he told me. I put this to Adobe’s Dave McAllister, director of standards and open source, who assured me that Flash is all-but open, excepting (ahem) the source code to the runtime. Then he surprised me (considering he is an open source guy) by accusing Mozilla of bad faith over Tamarin, the source code to its ActionScript 3 runtime and just-in-time compiler, and remarking that Sun’s efforts to open source Java had mainly helped its competitors. I wrote this up for the Reg.

The problem is that these companies want the best of both worlds: the widespread adoption and community contributions that open source can generate, but the control and profit that comes from owning the platform.

If you can’t own the platform, the next best thing is that nobody owns the platform, which is why IBM worked to hard to get Sun to open source Java, and deliberately muddied the waters by sponsoring the Eclipse tools platform and alternative Java runtimes and GUI libraries.

Why is Google wary of Flash? Simply, because it is risky to build your own application platform on a runtime that belongs to another company. It is not enough for Adobe to say it will never charge for the runtime, any more than it is enough for Microsoft to give away the Windows SDK. Google is watching Adobe, and seeing how it is building online applications like Buzzword which competes with its own Google Docs. Companies with their own platform ambitions (Apple also comes to mind) are more likely to be averse to Flash. Oh, and look who else is building its own alternative to Flash? Yes, Microsoft with Silverlight.

Like Google, Mozilla is trying to build a browser platform that has less need of proprietary plug-ins like Flash. Although I was surprised that Adobe’s McAllister said Mozilla was using its open source contributions in the wrong kind of way, seemingly missing the whole point of open source, I was not surprised to find tensions. I quizzed Mozilla’s John Resig on this exact subject one year ago, when I wrote that Adobe and Mozilla were on course for collision.

As McAllister points out, open source also has risks, particularly the danger of fragmentation and multiple incompatible versions. Maybe Flash is better as closed-source. Still, let’s not pretend it is really all-but open source. The real issue is who owns and controls the platform, and in this case it is definitely Adobe.

Advertisement Click here for special offers including free magazine subscriptions,white papers and ebooks.