qtbrowserplugin vs flash/silverlight?

Question

Our team is looking for alternative to ActiveX for our browser based client. So far flash, silverlight, HTML5 are being considered. Since I have some prior experience of Qt I am thinking of suggesting Qt. From documentation it seems QtBrowserPlugin is req for our purposes. There are three criteria that any alternative must satisfy

1. Must support IE
2. Performance should not degrade (unreasonably ?) over present ActiveX
3. Other browser support.

Considering above

First Q: How does Qt fare compared to other alternatives

Second Q: Around 2012 Microsoft will stop supporting Active X. Also at present QtBrowserPlugin support for OS other than Windows is experimental. Is it expected that it will be further developed to address these issues i.e. can it be considered for future development.

Answer 1

(Hmmm - maybe I should have posted this as a 'comment' rather than an 'answer' - sorry, still getting the hang of the board...)

QT is working on providing a full web application framework, but it's very, very embryonic. You can find out more info, here: http://labs.qt.nokia.com/2010/07/19/the-qt-web-runtime-journey-begins/

The plugin technology is mature - based on the NetScape plugin protocol - and works well, but, of course, you have to have separate plugins for Mac/Win/Linux, other OS's. Qt helps a lot in that regard, but you will have to maintain separate builds and deliver them appropriately. You'll get the best performance with Qt since it, like Active X, is C++ based.

Flash/Flex is a good development environment (Eclipse-based), ActionScript is kind of a funky language - it's essentially an ECMA-based language (JavaScript-like) with stronger typing. It's ok. You really have to get the event sequence down to know when you can rely on sizes - Flash defers everything it can until later. Flash is ubiquitous (unless you're a iPod/iPad devotee....) The big downside of Flex is the executable images are HUGE, no matter what it does...

Silverlight uses C#, which IMHO is a really good language. The executable images are much leaner, presuming you're not using the entire SDK. Downside is it's not available on a lot of devices, AFAIK.

Don't know much about HTML5 - it's ultimately a good direction, but you'll have to deal with browser support. If you have a requirement to support old browsers, it will be an issue. But, you'll be able to support a lot of devices, particularly iPod/iPad, and will be well positioned for the future.

Not providing a choice, here - just bringing up some issues you may or may not have already considered...