A potential future for the Xojo team

I do a lot of thinking, some of it good and some it… well…

It’s clear that the Xojo team can’t keep up with the industry, but what if they sidestepped and transitioned instead.

IMHO The future is Declarative UI, describe the UI once, and let the compiler spit out native apps, less work, more targets.

While most already cover the major platforms, SwiftUI covers everything Apple, but not Windows, Linux, GUI web apps, and Pi. Xojo has the necessary tools, to take Swift/SwiftUI code and spit out native apps for the missing platforms.

I know they’ll never go for it, but I thought its an interesting concept and I suspect they could easily ship many magnitudes more units than they do now. They could drop the other targets, the IDE and just focus on doing this one job and doing it well. They could continue to chase Android, even though it’s not needed.

2 Likes

Thats what Microsoft thought as well…

Until they realized Windows Forms just would not die thats where the developers are. Causing them to have resurrected Windows Forms in .NET Core, making it first class citizen again.

Not everyone likes the concept of declarative UI.

I have worked with Declarative UI in WPF and in some mobile work, I cannot say I am fan of it.

And you in general need better programmers to be able to use it, which would cut off much of Xojo’s user base.

3 Likes

Declarative UI is a mind phuck, especially coming from Xojo, but the concept and potential is staggering. One project, multiple devices. I’m excited at the thought my Mac apps could (with some effort) run on a phone or VR goggles, looking, feeling and smelling like native apps for their platforms.

With traditional methods, you’d need to design and build for each device, and with Xojo’s approach, you’d have to build a MVC model yourself to be able to separate the logic from the UI code.

Not to mention that the concept of Declarative UI, reduces the need for a lot of boiler plate code. An example is the app I’m working on now, auto manages Undo and “Versions” for me (it’s not perfect, there are bugs) but at a concept level, this is an incredible time saver.

After the information I’ve received this past week, I’ve realized how many folk don’t believe that Xojo can reverse the decline in their user base. A number of people whom I assumed were avid supporters, are working on “Life after Xojo plans” and investing in alternatives before its too late.

There are other tools doing that with ZERO declarative UI…

As einhugur said, there is HUGE chunk of developers that dont want to use declarative UI and xojo could have being their niche…

The problem is NOT the paradigm, is the stupid decitions and the quality of the product.

2 Likes

Imo going native was one of Xojo’s original mistakes. Way back when Xojo Web and iOS were in their infancy I suggested on TOF they should target Apache Cordova for mobile so there would be more in common across the platforms.

Many years have passed since and all three targets are still incomplete / dysfunctional to some degree.

3 Likes

That sort of the way I went. One UI to rule them all. Once defined, then you just work on the business of the app. :slight_smile:

1 Like

Would result in a declarative UI with a complete similar language use and the compiler decides also which exact coding variant for which target. Also the differences have to be reviewed. Could be done in a ver, very hard wa. Decide to leave the path of alwas native gui. Wh? While that makes it complex to have declarative gui for all platforms with one code. Xojo shoult and could think about it. But their decision was and is native UI in all cases. And I believe that ou ma have no success with this Idea while it is not native UI. The think so and they act so.

Especiall the abilities of Kotlin are a good way to build that up without any problem. Not Xojo’s actual techstack. They where almost crashing with Xojo Android what was and is a construction area builded up on Kotlin technology.
As both of us know there was and is no way for them to do that. Declarative UI is the future. Since JavaFX came with the fxml Model even Java programmers started to love declarative languiages for UI description. In JavcaFX case also with the scenebuilder where ou can still generate drag and drop UI’s and use the fxml language for directl write declarative UI.

Looking on Xojo I can see onl: the are far awa from a solution like that while stilll hangin on the native gui train which makes that too complex. If the would have something like the Kotlin Multiplatform stack they could but they haven’t and the did not want to do anything like that.

2 Likes

I think Xojo’s lowest hanging fruit to get them closer to cross platform is supporting multiple targets in the same project. It’s not the solution to all their problems, not by a long shot, but I think it would be the biggest bang for their buck. Declarative UI, regardless of whether or not it is something you want, is a much bigger project, and they’d need multiple targets anyway.

This really is my biggest complaint with Xojo right now. I could be targeting mobile, but Xojo doesn’t give me practical a way to share logic. I could live with building mobile views. In fact I’d prefer that to having one UI for any screen size. But not being able to share logic is brutal and the biggest roadblock to calling Xojo a cross platform tool.

1 Like

I was working on just this very thing

Lots of details to sort out but certainly plausible to do

https://www.great-white-software.com/blog/2019/08/15/the-universal-project/

https://www.great-white-software.com/blog/2019/08/19/universal-project-ii/

Fixing it would mean reverting API2 for a start.

How do you figure?

API2 enforces individual projects for each target type.

The class names have nothing to do with the ability to have multiple targets in a single project. That’s an IDE design issue.

How would you fix it?

It’s a bit of a challenge, and Norman spent more time on the task than I did - especially since the amount of time I spent on it was zero - but you essentially need a blessed app class per target, the ability to add targets to a project, and build steps for each target. The library would be tricky, since its contents displayed are based on the project type. For a project that has no type, it would need to display everything sometimes, but possibly be filtered depending on the selected view class.

None of this has anything to do with the framework.

In general thats the right gist
Presenting everything and making it not confusing as heck is probably THE biggest issue

Not impossible but challenging

1 Like

Working along

#if os = desktop
Desktop.Button()
#else
Mobile.Button()
#endif

for standard features of a GUI is a waste of time and nonsensical for a so-called RAD tool.

2 Likes

Yes, you would need to use conditional compilation if you need to load controls into variables. Luckily, that’s not very common.

Right, that’s declarative style. Admittedly, I am already too far away from Xojo.
A lost customer, one would say.

2 Likes

In the last few days, two competing apps have announced their new versions and they’re both built using Declarative UI frameworks.

OmniFocus 4 is SwiftUI.

SuperList is Flutter (made by Wunderlist peeps).

1 Like