Making the Framework open source would be awesome. Xojo Inc could still have a (bigger) income on licenses bought for the IDE/Compiler etc…
That’s a win-win situation for sure. I see no obvious reason not to consider this.
I agree that it’s not good for Xojo as a platform to keep everything proprietary. See how big platforms got big in those days. Take into consideration that the Xojo inc. R&D team, keeping everything under the hood, is much too small to cover everything their customers find naturally to be in. Xojo must have or develop a clear mission and focus.
Personally I never believed in Xojo for iOS. Remember the massive amount of time the team had to invest in it, at the expense of the mainstream, and the knowledge they will never be able to compete with Swift for example. So, the only good reason to do iOS I can think of is making codebases reusable from one platform to another, which just did not work out well due to issues Phillip described in his plea.
If one should only target Windows, for now and forever, I would not recommend using Xojo. But for me, targeting Windows, OSX and a little bit of Linux, it a great tool. I do believe web is going to be an important platform for applications, but its not clear to me if Xojo will be able to provide the newest techniques used with modern browsers.
Next I have also experienced to that it’s a good practice to keep a copy of the Xojo version used for project next to the backup of it. Imagine you have to extend and recompile your project in about 3 years from now in order to make a very little change to it. I assure you that you don’t want to deal with all the incompatibilities made in Xojo over the years.
I don’t think Xojo has much hope of survival if they skip iOS and especially Android. For better of worse, Mac and Windows are not the future anymore.
Problem is, the company is much too small to correctly maintain and improve iOS, while following Mac and Windows evolutions. I fear with Android on top of it, their small boat will take water.
The culture of proprietary has a lot to do with their issues, though. Instead of bringing in exterior help, like they could have done with iOS, they insist on developing everything, at the risk of falling gravely behind.
I just wish they hadnt spent so much time re-inventing the whole language to get an iOS release.
It was late, (still) feature-poor, and incompatible with existing code.
‘Compatible if you change all your existing code’ isn’t what ‘compatible’ means.
And while I applaud the change to Direct2D on Windows if it helps avoid flicker, I’ll be happier when it works, and wonder why it isn’t a compile option until proven, like Cocoa was for a very long time.
There is a serious business model for mobile, so it would be imaginable to find shareholders to set up “Xojo-mobile.inc” . New licensing model, A LOT of brute marketing- and development forces … and within 10 years thinking about bringing our own hardware to the market. Oh… just a dream.
[quote=333893:@Phillip Zedalis]Part 2 of my series on Xojo in the year 2017 and my thoughts on the challenges facing the tool and its framework(s) moving forward including my suggestion to help us all.
Badly written review Phillip, the first paragraph, which should provide the crux is incomprehensible. I simply don’t understand what you are trying to discern. The rest of your writing suggests that Xojo’s cross-platform framework should be open source, but as far as I can judge it is from the viewpoint of a web developer. There is more stuff going on in Xojo, other than what Swift, Go or Erlang accomplish. Open-sourcing the Xojo framework might kill Xojo-inc. I am posting here because the remarks on your review appear here, which I think is, for all good reasons, inappropriate. Because this occurred, I felt I should respond.
Thanks for the feedback. I’ll be honest I can’t actually comprehend what you you mean. Xojo has many parts:
The corporate entity
The support and marketing infrastructure
The language syntax and core data types
The “framework”, “new framework” which I described as the standard library and compared to standard libraries of other programming languages that offer similar capabilities.
The plugin SDK to add additional features to the standard library.
The IDE that allows you to develop Xojo code in an easy and approachable way.
The compiler toolchain which is closely tied into the IDE that makes compiling your code for multiple targets very easy.
I have advocated the open sourcing of the standard library or the basic classes we use on a daily basis. There is no mystery there as I indicated in my review part. The crypto functions come from Crypto++, the HTMLViewer is a Chromium Embedded Framework implementation, there are several others.
Lastly this is just one part of a large review series I am doing this year to express my desires for Xojo’s future.
Ultimately I agree with Michel. Xojo had to embrace mobile. Now whether they bolted on overloads to their existing classes, created new classes, created new data types, there are pros/cons for each path. However that has already been decided so here we are.
The two frameworks are so dissimilar once you actually start using them. The “classic framework” is extremely forgiving and easy to use. The “new framework” is extremely specific in some areas like text encoding and moving bytes from Text to MemoryBlock while in other areas the compiler refuses to help you at all with the Auto type leading to unknown runtime errors in production.
This desire to change the language in subtle but important ways and then doing it in a not complete and bug ridden fashion spells doom for the new framework. I’d like them to refocus their efforts on their strengths: the IDE, the compiler, the community, the documentation, etc. and let the community take a larger part in maintaining the bits that have already been developed and are not secret sauce.
Lastly I really get disappointed when the IDE has capabilities that it does not expose to us. One example is the remote debugger will compress your app before sending it over the wire to the remote debugger. Why is compression faculties not built into the standard library then?
The new framework has different underlying philosophy than the ‘classic’ framework. As mentioned the Classic frameworks focus was PRIMARILY easy of use and SECONDARILY helping us not to shoot ourselves in the foot, with formal rigor in 3rd place.
That combination along with the IDE what attracted us Xojo… It made coding feel more like fun and helped encourage creativity rather than having a get lost in minutia. Most things are reasonably intuitive once you get some basic ideas down. Yes that lack of rigor resulted in some unfortunate edge cases, but the overall experience was fun AND productive… that framework has the soul of an artist…
The new Framework seems to be focused first and foremost on rigor, secondarily not letting us shoot ourselves in the foot… Working with it feels like well work! The joy is gone… It’s soul is that of an accountant…
So yes it may be technically superior and yes it eliminates some problematic edge cases so in theory one might be more productive … but it also eliminates the fun and makes coding much more of a slog…
I’ve been using Xojo since v1 and these are my two biggest irritations. I think my third is not being able to have one project for multiple targets.
Not being able to copy and paste controls between Desktop, Web, and iOS makes developing an app for different targets is maddening. I was glad to hear that Xojo is working on something to address this problem.
The new framework definitely lost its forgiveness. One example is date math. It used to be so easy to add days to a date. I know I can make my own class to do the same, but why should EVERY developer have to do that? It just makes the Xojo language not so friendly.
Developing one app and compiling to more than one target is harder than it needs to be. The Xojo website states on the homepage ‘Code once then deploy on macOS, Windows, Linux, the web, iOS and Raspberry Pi.’ That’s not true. You code for one target, let’s say Dekstop, then you have to make another project and recreate all the controls for iOS, then you have to make another project and recreate all the controls for Web , then in iOS and Web go and update all the code to deal with the differences in the controls and frameworks.
Don’t get be wrong, I LOVE, LOVE, LOVE Xojo, but these issues kill productivity.
[quote=333977:@Phillip Zedalis]The “new framework” is extremely specific in some areas like text encoding and moving bytes from Text to MemoryBlock while in other areas the compiler refuses to help you at all with the Auto type leading to unknown runtime errors in production.
The new framework is indeed more rigorous, but then, it makes it a whole lot less logical that the main implementation, iOS, is so incomplete, the smallest tasks become a huge burden of declares. One would have thought controls would be homogenous with Desktop. With the same set of properties and events, within the confines of the specific platform. Unfortunately, that was largely botched in favor of a minimal, toyish set.
That is exactly where IMHO Xojo if failing the cross platform promise. Plain and simple. Cross platform from a single source is true only between Mac, Windows and Linux desktop. Anything else requires an inordinate amount of adaptation.
“In a larger project of mine with multiple executables (multiple Xojo projects unfortunately as mentioned in part 1 of my series) must use different Xojo versions for the same ultimate deliverable! Absurd.”
And a consequence of the Rapid Release Model which turned Xojo into a perpetual beta where functions might or might not work.