No one likes change. I know I don’t. It introduces an unknown element and unknown equates to scary.
Xojo has been around for over fifteen years. I think anyone that’s been using the product for any length of time can say it is not a static product. It supported 68k Mac’s back in the day, then PPC Mac, then Universal Mac apps, then Carbon, and now Cocoa. For Windows there’s been a bit more stability but things have changed from Windows XP to Windows 8. Linux, well, it seems that there’s a new Linux distribution every month that are slightly different from each other.
Xojo introduced the ability to create web apps that ran on Mac, Windows, and Linux and introduced a new framework for the controls and for web specific things. Overall, however, the web framework was exactly the same as the standard framework even when it didn’t make much sense (e.g. web controls having drag events when there’s no way they’d work like the desktop version).
And now Xojo is working on an iOS version (due out soon) which uses an entirely new framework. iOS is a completely new beast. It most definitely is not a Mac, Windows, or Linux desktop or console app. When you think about it, making web apps is really just a console app so it wasn’t a big stretch since Xojo has been doing console apps for a while.
iOS is very different. It uses a completely different processor which requires new system calls. Heck, there are no ‘windows’ but has ‘views’ that are sort of, kind of, like windows. The metaphors between mobile and desktop (and web) are completely different.
For 15 years the Xojo framework has had a lot of new stuff bolted on. Different Xojo developers did different things but for the most part it’s just worked. It was wildly inconsistent and every developer, like myself, that has spent a lot of time working with the language still has trouble remembering which framework calls used zero or a one index. Names weren’t always consistent and some things were simply harder than they needed to be.
So Xojo is making a new framework that eliminates the confusion. All indexes are zero based – no exceptions. Methods and properties are consistently named so (theoretically, at least) if you are using an object you’ve never used before you should be able to make reasonable guess at what the method you want is. Obviously, there will be exceptions to this rule but the goal is to make it easier on us developers in the long run.
In the long run…That’s that key phrase. What we’re finding out is that it’s generating a bunch of concern amongst Xojo developers. I get it. Change is hard and it’s scary. But it’s not that bad.
Here are the facts:
1. The existing framework isn’t going away. It will be around for many years (if not forever). Xojo has said the existing framework will be 64bit and will be released sometime in 2015.
2. The new framework is only required with iOS. There are zero Xojo iOS customers right now. All desktop, console, and web applications, are okay and need zero modifications in Release 3 to work. NO CHANGES REQUIRED!
3. You will be able to intermingle the new and old framework. Xojo has introduced a Using keyword that allows you to use both at the same time.
Xojo isn’t forcing you to use the new framework in Release 3. Your apps will still compile and work just like they used to (the compiler does find new types of bugs so don’t be surprised if you have to fix a few things).
Should you start looking at the new framework? Absolutely! Should you start converting code over to the new framework soon? Well, I would hold off a release since the new framework is still in some flux (I think).
Porting code to the new framework isn’t all that difficult. Is it work? Yes – especially if you have extensive code libraries that are shared between console, desktop, web, and iOS. Co-mingling new and old frameworks will be painful for a while but the nice thing is that the new framework (that parts that exist, at least) will work on all platforms in Xojo 2014 Release 3 and beyond.
The new framework is different. You might have to looking at every line of code. I personally won’t do this with existing code but certainly all new code will probably use the new framework. It is the future and I hate coding things twice. The biggest problem is legacy code and that the new framework is not backwards compatible. As a 3rd party controls and library developer this has the potential to mess up development for a while.
The new framework is coming and it’s not all that scary – really. iOS users will bear the brunt of the changes, at first, but everyone can start using it now and I encourage you to start looking at it.