There’s recently been a bit of hype (RoughlyDrafted.com) for Charles Jolley’s Sproutcore, yet another JavaScript framework, mainly because Apple is using it as its “Cocoa for the Web”, according to AppleInsider.
I tried the sample controls demo in IE7 but it didn’t work quite right. For example, the Picker pane opened but would not close. Tried again in Firefox 3.0 and everything was fine.
I’ve got no idea what the problem is with IE7; it is probably because of weak standards support in IE. However, it illustrates the advantages of a plug-in like Flash, Silverlight or Java. With these platforms, the application is largely insulated from differences between browsers.
The snag with the proprietary plug-in approach is that the vendor may not support every platform equally. Microsoft is entrusting the bulk of Silverlight Linux support to a third party. There are also issues of control. Apple most likely does not want any runtimes on iPhone because they open up a route to application deployment that bypasses its App Store and 30% revenue share. Google seems wary of Flash; RoughlyDrafted says that is because of the risk of content being turned into “opaque binaries” that are beyond the reach of its contextual advertising analysis, but it may just be reluctance to cede such an important part of its platform to a third party.
Still, as a developer in search of a predictable app platform I’d rather target a plug-in than trust the browser vendors to be sufficiently consistent, and the Javascript libraries sufficiently smart, to enable my code to run reliably everywhere. It is easier to get away with a requirement for, say, Flash 9, than to insist that users choose a particular browser or operating system.
There are other factors of course. On the Javascript + HTML side, there are advantages in that it extends rather than replaces the HTML model. Things like clipboard support just work. Plus, it runs on iPhone.
On the plug-in side, you get the fast execution of a JIT compiler, and easy use of graphical and multimedia effects that take effort to do in JavaScript, or can’t be done at all.
I would be interested in comments from developers about what RIA platform you are choosing, and why.
I’m sticking with HTML and family. In part because it’s what’s worked for me since 1997 and keeps getting better. If I need “richness”, I go desktop with Delphi. For bare functionality, HTML works with whatever server side environment. Incompatibility is not so bad as it used to be.
I guess I’m not their target of Flex or Silverlight, but they’re more aimed to Flash types. The only job offers that contain “flex” or “silverlight” are still the ones that mention them at the end of a very long list of “desired” instead of “required”.
Nico – I expect that Silverlight will climb into the “required” section fairly quickly after the release of v2. It is much more of a tool for developers than Flash, and every .net developer I have discussed this with has embraced it as a better more productive and powerful way of creating web ui than html/js.
Silverlight can work with any server environment too by the way, and can use ajax/rest etc to communicate with any platform…
Ian, Silverlight seems very cool. And I’m sure you’re right. Microsoft is behind it, so it will be more demanded soon. But there are powerful forces out there against a single-vender platform. ActiveX failed. Internet Explorer achieved more than 90% market share but pressure has made it more compatible.
It’s a really interesting discussion. Aside from the proprietary/open arguments, Silverlight and Flash have the issue of supporting some expected features of [most] HTML such as hyperlinks and bookmarks. And it’s not that those are features that can just be added; they are fundamental differences.
Looking from high up, one may have expected all web apps to be written in Flash long ago, but that hasn’t happened. It’s not totally clear to me why, considering it has 95+% penetration.
A few days ago I wrote a post related to the cyclical nature of the application platform; it seems to apply here:
http://blogs.msdn.com/avip/archive/2008/06/17/the-computing-client-s-yo-yo-diet.aspx