FireMonkey, or another failure monkey? (http://www.sandon.it/node/72)
It's now confirmed and made public that FireMonkey (let aside its ill-fated name, for now) will be the Delphi cross-platform GUI framework. FireMonkey, aka KsDev VgScene/DXScene is a vector based GUI framework. So it looks after two attempts failed to build a cross platform library first on Qt (CLX) then on .Net (VCL.Net) Embarcadero selected the Java Swing approach and decided to develop its own proprietary GUI framework. It's a dangerous approach, for several reasons.
First, it needs a strong committment to expand it and keep it up to date with operating system changes. Being a new library, they may not rely too much on third parties to augment it quickly. They may be hesitant to invest to develop libraries requiring a new skill set (vector development is different than raster one), and with a yet unknown market. Thereby it should be an Embarcadero responsibility to invest a lot in FireMonkey development, and given their record of "unfinished" libraries (look at how long they are taking to make Datasnap an usable library in real applications), I am not optimist at all.
Second, there is the user perception issue. Applications developed with FireMonkey force an "alien" interface to users. It can try to mimic the host platform experience, but trying also to be cross-platform it could miss the target, thre could be many subtle (and no so subtle) issues to take care of. The other option is to deliver your own "experience", as Swing did, but that could not be appreciated by a lot of users. It could work with applications with simple interfaces (i.e. a media player, or a home user backup application), but could not work with more complex ones, especially if you have to bring in other modules (i.e. ActiveX) with a standard interface, and anyway standard OS items will pop up here and there (dialogs, messages, etc.), telling your application is "different". Such solution asks for a "all or nothing" approach - unless you can accept an interface that looks like put together with cellotape. Thus we return to the first issue, how extensive the library is.
Third, vector GUIs work best when hardware support is available. Remote connections and VM may not support hardware acceleration.
Last but not least, maybe one day not too far vector GUIs will become the OS default. Which framework would one use then? The OS optimized library, or the Embarcadero one? Should an application include all the widget drawing code, or use system libraries? Would be able Embarcadero to cope with Microsoft and Apple GUI departments?
FireMonkey could be an interesting solution for a class of applications, those needing "sweets" to attract their users, but I wouldn't bet on it as the definitive cross-platform solution for Delphi. Swing wasn't for Java, too.
Update: as forecasted, Developer Express will wait to support FireMonkey (http://community.devexpress.com/blogs/ctodx/archive/2011/08/18/rad-studio-xe2-what-we-re-doing-about-supporting-it-and-when.aspx): "The other problem is that, to be perfectly sanguine, we’ve been down this path before. There is some history here—ancient it may be—but, like it or not, we have been badly affected by it. Consequently, we’re going to take a long term view for our support for FireMonkey. We will not support it immediately". Guess the path before was CLX, and they will wait to see if FireMonkey gets momentum or not. Let's see what will be TMS approach.