Some thoughts on the New Xojo Framework
By Thom McGrath on
This is going to be a difficult entry for me to write, because I'm still on good terms with Geoff and I want to remain civil and fair. I'm not looking to undermine or belittle anybody's work. But I've got some things I want to write down regarding the new Xojo Framework.
Work on the new framework began while I was still with Xojo, but I had practically zero input on it. By this point in my tenure with the company, some of the engineers were largely ignoring my input so when the API proposals came around, I rarely contributed or even read them. So my involvement with the new framework is about equal with the rest of the community, aside from the fact that I was arguing against it for much longer.
Despite my concerns, the new framework has happened and there is no going back now, so I'm making every attempt to learn and adopt it. There's no sense in sticking my head in the sand and pretending it isn't happening.
As a whole, I believe the new framework was a bad idea filled with lots of small good ideas. Asking us to replace our entire codebase is a very bad idea, even if we've been given an indeterminate grace period. I know the intention is to keep the classic framework around as long as possible - ideally at least ten years - but at the rate Apple deprecates and moves forward, I fear the classic framework will reach its end-of-life moment sooner than preferred. In my mind, the classic framework is already end-of-life and we're on borrowed time.
The problem is that porting classic code is no simple task. It's a time-consuming task that requires analyzing and understanding every line of code. You can't just swap Mid(String, 1) for Text.Mid(1) because you'll get an incorrect result that can't be caught by the compiler. This becomes especially complex for lines such as Mid(String, InStr(String, "@") + 1).
Porting was and still is my primary concern. The Xojo IDE, for example, is so large and complex that it is likely impossible to port to the new framework. Even if done in smaller chunks - which is probably what will happen - it will require months of work. That's months that, quite frankly, Xojo can't spare. And the community is expected to do that for their own projects too. It isn't reasonable. This isn't just theoretical. Jared and I have spent a few days porting a medium-sized project and eventually just gave up. It's just too much work.
So if you have to rewrite your whole project anyway, why not look into alternatives? Xojo (the tool) is probably still your best choice if you need cross platform, but Xojo (the company) should not be giving their users an excuse to look at the competition.
So why do it?
The classic framework has a number of problems. The most common example is FolderItem.Item being a 1-based index. This can't simply be changed to a 0-based index because it would break code silently. There are a number of problems like this. String can be a particular mess, which is why Text was introduced. The new framework is very, very explicit. There is very little in terms of implied conversions. For example, Text into String has an implied conversion, but going in reverse requires an explicit String.ToText. This is because Text-to-String will always work, but String-to-Text will fire an exception if no encoding is defined. Still, it feels inconsistent.
Unfortunately, the chosen solution is very much "throwing the baby out with the bath water." Rather than introduce an alternate API for FolderItem.Item - such as FolderItem.Child(ZeroBasedIndex As Integer) - it was decided to ditch everything.
It would have been much more challenging to come up with ways to deprecate and fix the classic framework. Xojo took the comparatively easy way out at our expense.
There are two kinds of feature parity in this case: framework-to-framework and platform-to-platform. Both are lacking currently.
The new framework is woefully far behind the classic framework, but I'm not too concerned with this. It is to be expected. What is not to be expected is the rate of improvement. The new framework was introduced in 2015r1, gained some platform feature parity in 2015r2, and sat largely unchanged for 2015r3.
Platform parity is a bigger concern for me. If I'm trying to write universal code, there is currently a lot of features available in the new framework that is only available in iOS, such as Xojo.Threading and Xojo.Net.TCPSocket. This means if I want to write universal code that even touches TCP, I need to write a universal wrapper class to unify Global.TCPSocket and Xojo.Net.TCPSocket behind a single API.
For me, this is not okay and severely limiting my adoption of the new framework. At the moment, there is little point to writing new framework code if you need threading, sockets, or databases. For each of those (on Desktop, Web, and Console) you'll need to drop back to the classic framework, which imposes all sorts of conversion costs.
I was very grateful that platform parity improved dramatically in 2015r2. I was expecting that momentum to keep going. I'm concerned that these missing pieces won't be revisited for a while.
What's done is done. Odds of Xojo doing an about-face on this is as close to zero as mathematically possible. For the time being, the new framework is too immature for practical development on any platform that isn't iOS. All we can do is wait. I don't like writing code today that I'm certain will need to be ported in the future, but that's best course of action at the moment. I hope 2015r4 (or 2016r1, however it is named) improves the platform parity issue.
I'm sorry for such a negative entry. Usually in cases like this, I like to offer solutions rather than just complaints. I think the only "solution" I can offer is this: try it. Try to port some of your production code to the new framework, see how you feel. If it isn't good enough, speak up. Put pressure on Xojo to keep progressing the new framework if you feel as I do.
If they want us using the new framework, it needs to be better.