Monday, January 30, 2012

Firemonkey: Promise and Limitation

Firemonkey is amazing, when considered as a platform with a future. As a product, as it ships, it's a strange mix of odd capabilities, and unusual gaps.

For example, it's cool that everything in Firemonkey HD (formerly 2D) can be rotated and scaled. The scaling is practically useful, more than the rotation, but who knows... Maybe rotation of 90 degrees can be useful for charts or other diagrams, or in combination with animations, but I have yet to see animation used in business applications for much.

Scaling may not matter to you today, but if you have ever cared about supporting high-DPI displays in Windows, or on Mac, you need Firemonkey, not the VCL. The VCL will never be as High-DPI friendly as Firemonkey. It was a brilliant move to name Firemonkey "HD" instead of calling it "2d". The other mode in firemonkey is 3d, and so obviously the "HD" mode is 2 dimensional, but by explaining that the purpose was to be "high def" it very clearly reminds you that classic Win32+GDI is "non-high definition".
If by some chance an update to Firemonkey was to provide GDI+ back-ends on Windows, in addition to the current DirectX (win) and OpenGL (mac) back-ends, so much the better. The VCL can include GDI+ elements, such as the fine GDI+ based controls from TMS Software, but no complex VCL application I've ever written or ever will be able to write, will ever seamlessly blend GDI and GDI+, and support HIgh-DPI awareness, to my satisfaction. I've met people who claim to write Win32 applications that perfectly work at high-DPI values other than 96 DPI. I don't buy it though. Either their applications are ridiculously simple, or they have done a ridiculous amount of grunt-work to make it all work. Either way, it's hardly the low-friction "it just works" experience that Delphi users crave.

Firemonkey doesn't quite look native on Windows, or Mac, but it does provide a reasonably modern UI. It's a bold, impressive move, and it's clearly ahead of its time. The value proposition of "one app that runs natively on mac and pc, with differences between platforms either abstracted out by the framework, or IFDEFd when necessary" is convincing. And Pascal is a better language than C++, C# or java, for such an endeavor. Native code with a compile time code optimization is always faster than JIT. It's a no brainer. Delphi and C++ apps spend zero cycles doing JIT-code generation. Delphi and C++ Apps are compile time analyzed and compile time optimized, and compile time linked to strip out unused code. Delphi and C++ will always be faster and provide a smaller size application with less runtime to setup, or none (in Delphi's case). And Delphi will always be a simpler, easier to learn and more orthogonal language. It will also be less feature-complete than C++. It will fit in your brain better than C++, although C++ 2011 is an amazing language, it's still full of complexity and warts that make me none to eager to work all day using C++.

There are huge challenges ahead for Firemonkey on Mac. If you think about it, Firemonkey offers a way onto Mac for Delphi fans, and as a combo Mac and Delphi fan, I'm very happy about that. However, there is a principle of "least common denominators" that is the bane of the cross-platform developer's existence. Mac OS X is built on Cocoa+Objective-C frameworks, and anybody who doesn't write their app on Mac, using native Cocoa, will not be able to use the new frameworks. So, for example, just try to make an app with Firemonkey, and have it use OS X Lion's new document model. If you try to write an app and have it accepted as good enough to count as a Mac app instead of a "lame port of a windows app", you need to observe the platform conventions and rules as set out by Apple, as implemented in their Document Model. The easiest way to be sure you're following all those rules is to write your app in Objective-C with the Cocoa frameworks that implement it all for you. Frankly, if all you want is just a Mac app and you don't need it to run on Windows, then it's a no brainer; Learn objective-C and cocoa. But if you (like me) would like to write an app and spend a bit more effort to get it working on both Windows and Mac, then Apple doesn't care to help you.

The only real alternatives I see to Delphi + Firemonkey, for native application development, are QT and C++, or other similar frameworks, like wxWidgets and C++. There is also an open-source Pascal flavor, "FreePascal", and an IDE project "Lazarus", but if you thought Firemonkey looked "beta", well, then, I can only describe Lazarus and its LCL frameworks as "alpha level". They provide something less than VCL 1.0 level experience, and although I hope that they grow and improve in the future, they are of little interest to me, aside from one thing; Lazarus IDE actually runs natively on Mac OS, Windows, and Linux. For that alone, I should give a little nod to the geeks who built this thing and made it open source; Way to go, good work. But I'm not all that interested in LCL, and I don't think it's nearly as promising as "Firemonkey" and Delphi.

I have been developing some test applications, and trying to learn Firemonkey on Windows. I am disappointed that you can't skin the non-client areas of a window, or the Main Menu area. I'm disappointed that there is no ActionList or ActionManager yet, and that as yet there is no printing support in Firemonkey, however I am confident that they will add all those things, and much more, and that by the time Firemonkey reaches a "2.0" designation, it will hopefully be at least at the point where most of us will be seriously considering starting our next big application in Firemonkey.

I plan to write a serious text editor for Mac + Windows in firemonkey, and add printing support to it once Firemonkey supports it. I plan to investigate Document Framework classes that will run atop both Mac and Windows versions of Firemonkey, and offer a native document experience on both platforms, including operating system search and indexing, spotlight and quick preview on mac, and start-menu and task-bar integration on Windows. Just because you're cross platform doesn't mean your users will let you get away with inferior platform integration. Delphi should let you go deep, and now, wide, at the same time.

The future is Delphi on Mac OS, iOS, Windows, and hopefully some day, Android and Linux. I'm not even going to mention Windows Phone, or Blackberry, because they are dead already they just don't know it yet. Oh wait, I did mention them. Forget I mentioned them, they're dead.


  1. Its the same thing with C# and mono. Last fall, before i got fed up and started tinkering with OP4JS, i learned C# and made a couple of iPhone apps. But you can forget about using the Apple developer forums. Everything went fine until i mentioned C# rather - then i was stonewalled.
    I even wrote a letter to Apple about this - but I havent heared from them since.

    This reminds me a bit of the "unwritten rule" of unix and linux gurus (well, some of them). They somehow measure their value in terms of how much knowledge they have of the kernel, and it would probably lead to a full mental collapse to help people outside their inner-circle of initiates.

    Thankfully spartans have an edge, and that is that freepascal have mapped much of the territories delphi users are now venturing into - and white it feels a bit unfair, delphi can now capitalize (again) on the hard work of the FPC/Lazarus team.

  2. Here's another view of RIM and Microsoft's slow slide into NOTHING.


  3. >This reminds me a bit of the "unwritten rule" of unix and linux gurus (well, some of them).
    >They somehow measure their value in terms of how much knowledge they have of the kernel, and
    >it would probably lead to a full mental collapse to help people outside their inner-circle of

    This is a completely incorrect characterization of Linux users. On the contrary, the support received on Linux is first class. Power users gladly spend their time on forums to help users (the primary support model of most Linux distros) and many distros even include a link to an appropriate IRC channel where new users can get real-time help from not only power users but many of the actual developers! Bug trackers are not secret (like Opera's) where you submit a bug and don't even get confirmation if it's accepted as a bug or not. Bug tracking and development are done in the open and users who submit bugs get put in contact with actual developers when necessary for follow-up and testing of fixes. There are no "patch Tuesdays" either; it's often possible to have fixes in a day for minor problems or security issues. Numerous websites, video tutorials, manuals, etc. are also developed by volunteers to help get new users up to speed. Many distros also have systems where users can submit suggested improvements and the community can vote on them. Of course, anyone can submit code and some distros even have collaboratively-developed mission statements, elected boards, etc.

    I daresay contrary to your belief, Linux is one of the most friendly, readily-supported OSes in existence today. Rather than experts being unwilling to help new users, the non-commercial distros depend on this model to survive and thrive.

  4. I agree with Alcade, actually. Open Source is not about creating castles and guarding them, it's about a free and open exchange of intellectual capital. If anybody is creating and guarding islands in a crumbling castle, it's RIM and Microsoft, but certainly NOT the Linux community.


  5. ydk2: Have you followed FIremonkey development? The earliest (FM1) version for iOS was a preview technology, which was yanked and replaced by a completely new iOS implementation in XE4. Freepascal is no longer used or supported for firemonkey iOS on XE4.