Hello Again - A second look at Xojo

Getting Started
1

Hi everyone, it’s been a while since I have been on the Xojo forum. I was looking at Xojo back in 2020, which seemed like a time of big change (and somewhat confusing deciphering the differences between old and new ways of getting things done - especially when starting out).

At the time, I ended up deciding on waiting out the updates to API 2, and checking Xojo out at a later date once the dust settled.

Looking at what has been accomplished with Xojo in the last couple of years seems very impressive. Congratulations to @Geoff_Perlman and the rest of the team (trying to catch up on posts, I did see that @Greg_O_Lone announced in February that he was leaving Xojo after many years, which was sad to see, but I am happy for him to get to start a new stage in his professional life). During this time, I also noticed that there was a price increase, but coming from a developer looking to switch to Xojo, I am fine with an increase in cost if it means a brighter and more stable future for Xojo.

In 2020, I was hesitant to switch from my familiar C# .NET and Python - but now I think I am ready to give it a good spin (though I don’t think I could ever truly leave Python haha). With these recent advances, and API compatibility between platforms, I am ready to try to make Xojo my primary development environment. I had been working with .NET Blazor since it was released, which is supposed to be a multi-platform environment sometime in the future with .NET Maui, but despite the hype, I question if will actually be anywhere near the level of capability that Xojo offers right now.

I may still use C# for gRPC services and Python for other web related tasks. Right now, I am trying to scour the Xojo forums in order to figure out what I should expect in regards to actual limitations with the Xojo platform. I don’t expect one tool to be the best at everything, and I am looking at Xojo mostly for front end work, while perhaps keeping backend services in C# or Python if that would work the best.

The idea of writing everything in one language does have appeal, and the effort put into tools like @Tim_Parnell Lifeboat look really nice, and gives me hope that perhaps Xojo on the server can be robust and scalable enough to replace some other battle tested web frameworks.

As a developer new to the platform, I would just like to know where the landmines are, so that I can simply avoid them, and concentrate on what Xojo does best - to avoid wasting a lot of time, when other tools that I already know how to use, would be a better fit. Of course I would prefer to be able to decrease complexity, working only in Xojo, but I am willing to augment Xojo with other languages if beneficial. Any guidance from seasoned Xojo devs would be helpful in providing some realistic expectations I can work from.

Anyway, hello again, and it is nice to be back!

4 Likes
2

It is impossible to stop using Python. It is an excellent tool in many aspects, useful for data analysis.

But XOJO is strong. I recommend that you start developing on WEB. Then continue with iOS and Android.

5 Likes
3

Hi Michael. I have used XOJO of and on since it’s name was RealBasic. I have also tried other platforms that ‘promised’ to be cross platform - and after numerous dollars spent a few thousand, nothing seems to be further along than XOJO.

I’ve always done internal development work but now I’m looking at publishing my own apps.

Although some other platforms had a couple of really nice ideas and I was able to develop in those platforms - the downsides seemed larger than what I was comfortable dealing with.

That being said, there are quite a few gotcha’s to watch out for.

At the top of the list would be to make sure you’re viewing the latest documentation and the control you are using has not been deprecated.

As a rule, use as few components as needed to make your app cross platform compatible.

Simultaneously compile for multiple platforms and view each change on each platform you want to support. For me it is easier to get over the hurdles of objects not looking correct on platform B when it looks perfect in platform A. It might be easier at that point to switch to another control.

The IDE doesn’t always explain if a property switch applies to your platform - I’ll pick on ‘transparent’ as an example. In Mac ‘transparent’ does nothing. In Windows it’s very significant. When developing on Mac it appears to do nothing (like a placeholder). I’m sure there are other gotcha’s in reverse - i.e. develop on Windows and compile for Mac or Linux etc…

The IDE doesn’t always expose properties you might need in an updated version, but is typically addressed in later versions.

I many times create a ‘button’ using a multilayered approach - Clear Button + canvas + text so that it will look exactly the same on different platforms. However, you do loose the ‘native’ look when doing that.

Borders on objects do not always render exactly on different platforms. Compile and review while implementing that object to make adjustments along the way.

#IF TARGETplatform
#ENDIF
is a command you can use to get around platform specific issues like this but I tend to avoid it if possible. Write-once compile for platform.

In the version numbers for you app - Windows imposes limitations - that won’t show up in the IDE - keep the version numbers short. i.e. I couldn’t use 20220420 - the windows version will debug but nothing show up. A fully compiled version will through an error - that takes quite a while to track down - b/c it appears to be a windows problem - when it’s a source code problem.

Parent and unParent (objects within other objects) can be very frustrating - if you don’t know how to fix it. When an object is embedded within another object in the IDE you will see a RED border around the parent object (for example a button inside a group box or a listbox inside a rectangle) - developed that way for aesthetics. If you get runtime crashes, it’s many times as simple as right-clicking on the object and selecting un-parent. The red border disappears indicating there is no longer a parent of the object. It just lives in it’s own space.

The listbox - oh boy - that listbox. It was written and hasn’t changed much in years. It has some really good features and some not so good. It’s terribly slow - for anything over a few hundred rows. You can use a database CURSOR to page through data pages - but I typically do not like to do that - as it increases the traffic back to the server.
I haven’t checked this in years but there used to be a row limitation in windows - the 65K magic number. If you find you’re struggling with that, I have used PiDog listbox with fairly good success. (However, today, I need to figure out why his latest version causes a Nil object exception - I reverted back to a previous version and sticking with that for a while.) That’s the joy’s of third party plugins. It’s another layer to keep up with.

WEB vs Desktop vs ??
This is an entirely new issue set to work through. The code is NOT the same. Similar but not similar enough. The objects are different so you can’t just ‘compile’ for WEB from DESKTOP or vice - versa. This is probably also true for IOS and Android but I haven’t used those.
For more fluid WEB development, GraffitiSuite is a plugin set that I have tried and it worked well.

Of course I couldn’t have gotten to where I am today, if it hadn’t been for MBS. I have since written some of my own routines but back in the day, and to get up and running fast, sometimes it’s just easier and quicker to get a plugin

I too have used other languages, python included, to get some simple thing done quickly and just call the compiled python program I had written. I don’t remember what it was, but it was quicker and easier at the time.

Despite all its shortcomings, I have found XOJO, the forum, and its members to be quite helpful. I read the forum as much as I get time for and once in a blue moon I get lucky and can answer a basic question.

Good luck with your development. I think XOJO is a good choice for the long haul.

11 Likes
4

Funny, I have a listbox with more than 22000 rows which loads in under a second from an SQLite database and can be sorted equally quickly.

5 Likes
5

I’ve been using Xojo since around 2005, so I guess I fall into the “seasoned” Xojo developer category. My company uses Xojo for in-house applications. Maybe that is why we are more forgiving when it comes to issues. We don’t really need a polished app to sell. We develop Windows console apps, Windows desktop apps and web apps. Our web apps are compiled for Linux and deployed with LifeBoat. We have no experience with mobile and at least for now, I don’t anticipate any mobile development. What is cool though, is that if we decided to develop for mobile, we have a ton of reusable Xojo code (not UI related).

Having a single language is the biggest benefit for us. We have lots of shared code. Many people have been vocal about their displeasure with Xojo renaming things for API 2. We have embraced it and at this point it is a better development experience for us since naming is more consistent.

Xojo Web 2.0 is still a work in progress. For example, we could not get the grid to work good enough for our application so we switched to the GraffitiGrid. Also, tabbing between fields on a container is broken but I have hopes that the next release will fix this.

In terms of landmines, they exist. You may go a long time without running into anything. It really depends on what you are trying to develop. I have found that new classes or functionality take a few releases to get right. There have been times that something really weird occurs and it never gets fixed. For example, in January of 2021, we reported this bug: “Renaming a folderitem to an existing file name does not cause an exception”. Even though it was fixed and verified, it still is not really fixed. What happens now is that a silent error occurs. The FolderItem.LastErrorCode will show the error but, in my opinion, an IOException should be raised. We worked around it, so it is not causing any problems in our apps. I am pretty sure that I could lobby for this or even contact support and Xojo could fix it. To be honest, I really just forgot about it and I doubt it has affected any other Xojo user since it would be a very odd thing to do.

As I said, our apps are for internal use so we are more tolerant. I will say that our Windows Desktop app really looks good running in dark mode on Windows 11. I have to give credit to Xojo for supporting dark mode, but a lot of credit goes to Microsoft for making the desktop controls look much better in Windows 11.

Anyway, good luck to you. I would suggest that you dive in a see for yourself. There are always good people on this forum willing to help when you get stuck.

8 Likes
6

Back in the day, loading 100,000 rows and then attempting to scroll that was terrible. It took, about ten seconds to load first off, then scrolling was a nightmare. Wouldn’t work.
If i’m just loading and scrolling a few rows (a few thousand now?), I don’t bother with third party as it’s another layer to maintain.

7

Thank you @Benjamin_Brannen for taking the time to write such a detailed set of guidelines to follow and things to watch out for. That was extremely helpful, and I really appreciate it. I will be copying your message, in its entirety, right into my notes.

Thank you so much!

8

Thank you @Brandon_Warlick , I appreciate the comments and advice.

I think I will probably be taking a conservative approach and slowly expand the functionality that I rely on from Xojo.

The web is where I am not sure what approach to take. I might just continue to use what I am currently working with, and maybe try introducing small Xojo web apps to test the waters.

I need to do more research on exactly how Xojo web apps work. I have seen older messages on the forum where people talk about getting timeouts, which makes me wonder if they are a javascript front end that talks to the backend via websockets. For some reason, I was under the impression that they actually were more like a desktop app that ran on the server as a session, with the screens being sent down to the clients - but I might be thinking of a different platform.

In any event, I am sure it works in a much different manner than what I am used to when developing for the web, so will probably just approach that aspect very cautiously to begin with.

Thanks again everyone for leaving your thoughts. It is very encouraging and I am looking forward to embarking on this new adventure…

3 Likes
9

My two cent:

If you are familiar with other technologies, there’s no real “need” to switch to another platform, unless the tools you use cannot give you what you need.

Therefore look at the strenghts of Xojo, which might be weak points at you current tool set:

  1. One code for most platforms. At least for Desktop.
  2. Easy to use. No need to use bundlers, package managers and maintain dependencies.
  3. Easy to learn. The language is simple yet powerful and if you are familiar with python or .NET, you’ll learn Xojo pretty fast.

But with all these advantages, also drawbacks are introduced:

  • Dont’ expect to write one app, for desktop, web and mobile.
    You can re-use code, but thats not very handy, hard to do with version control, and all UI-related stuff will have to be developed separately.
    Even iOS and Android will be different animals. Only Desktop (Mac, Win, Lin) support compiling from one source.
  • Since Xojo is written in its own IDE, you will have to get familiar with this IDE. There’s no way to use another editor.
    And compared to other state-of-the-art IDEs like VSCode, Webstorm, PyCharm, Atom etc., the Xojo-IDE stinks completely.
    It lacks on functionality, speed and flexibility.
  • The structure of webapps are very different to what you might know from classic webapps. Frontend and Backend are not really separated. This has advantages (easy to create) but also takes a lot of possibilities from you.
    The used technology is, let’s say, “dated”.
  • And the last thing which a lot of use faced several times: you are tied to the goodwill of Xojo Inc. If they drop the support of a thing you rely on, you’re ■■■■■■. Happened to us, when they abandoned the former web framework. The new framework took over two years to become really usable and there’s still no way to convert your old apps to the new framework.
    This happened with API changes and other smaller decisions in the past.

tl;dr:
Xojo is cool, if you look for an easy and extensive tool. But it closed source, maintained by a small company. It doesn’t really give you something, which you couldn’t achieve with other tools (like flutter or ionic or B4J or whatever), but you will achieve it here faster and with less effort.

5 Likes
10

That was more prevalent in web 1 as a good chunk of the HTML was rendered on the server and sent down to the browser to be inserted on the page. In Web 2, everything that’s sent to the browser is sent as JSON and the pages are built from scratch by the browser itself. It means that there’s a larger initial payload (which the browser should cache for future use) but that the overall data transfer is much lower than it was before. Data is still sent back and forth under http(s) or Server Sent Events depending on whether it’s in response to a user action or an async event, but the server was upgraded to be http/1.1 compliant for web 2 so supports some features that make transport a little more efficient. I just wish the timing had been right to support HTTP/2.0 when we’d made that decision.

3 Likes
11

Xojo introduced “new” controls that are mostrly the same but with new names and renamed events, so API 2 changes and renames maybe are not done. And the dust… just check the release notes, most fixes are for bugs introduced with API2 instead of long standing bugs.

Xojo is not hiring new staff so, there is nothing that indicates this increase in cost and lack of discounts like other years means a better product.

All the renaming of the controls and changes to the framework, make the “compatibility” closer to what VS had in 2015, totally different proyects that can share some code, but Xojo cant even open all the proyects at the same time and shaaring code is a PITA.

If you want ios, Xojo decided to have it ONLY be available only if you work on a Mac, so… Not an option if you use windows.

Most web solutions use multithreading servers, The nature of xxojo being SINGLE threaded limits its scalability making your only option running multiple instances with some load balancing.

Xojo has focused for many many years on the renaming of things and creating New platforms instead of adding functionality, so dont expect many features out of the box and be ready to spend money on many third party plugins.

3 Likes
12

I was under the impression that Xojo web server is single core but multi-threaded (and hands each request off to a new thread) and that to max out cores on VMs that have more than 1 available, you would just start multiple worker processes in SystemD? Is that not the case?

I have worked with both single and multi-threaded servers, and the major issues with single threaded servers are blocking i/o (like requesting data from other web services) and needing to be behind a buffering proxy to prevent clients purposely sending slow requests in order to create a DOS attack.

I run my services behind a proxy, which buffers the requests, but it would still be good to know for sure if Xojo web services are single process multi-threaded (which I thought they were), or actually single process and single threaded.

Thanks again, Ivan, for sharing your perspective. Making a change to a new language / platform is a pretty big decision (since there will be a considerable amount of time invested), so it is great to hear everyone’s thoughts.

13

Thanks Lars.

Yes, I have to say that I am somewhat of an IDE snob and really do like the extra features provided by the more advanced ones. I have a Visual Studio Enterprise license, but still thought it was a good idea to use JetBrains Rider lol. I am actually a big fan of JetBrains because of the consistency between the IDEs. Switching between them is not an issue.

I also use VS Code, but mostly to make changes to single documents as opposed to projects. I tried switching to it a few years back, but setting it up on new machines and the lack of some features drove me away from full time use.

When I looked at Xojo a while ago, the IDE seemed to be less featured and didn’t play nicely with source control. It seems to me that there has been a good effort put into improving it (though I am not familiar with it over the years).

After everyone’s comments here, I am still thinking of making the switch to Xojo for front end work and maybe phasing it in for backend on smaller projects to get a feel for it. In the meantime, I would still be able to use all of the IDE features (like DataGrip) that I have come to enjoy while developing for server side.

Thanks again Lars!

1 Like
14

That’s unfair to Xojo. You need a Mac to compile for iOS. Blame Apple for that.

10 Likes
15

Talking about web, you won’t be able to create just the frontend with Xojo.

If you build a mobile app, than you might be more happy with tools like Ionic or Flutter, but Xojo is still a valid choice.

If you really want to build everything (backend, frontend, mobile, desktop) in one place with one tech stack, then the Javascript world (Ionic for instance) is the only non-esoteric one, which provides you with the complete and stable toolset you need.

If you build desktop apps, Xojo is a good choice, especially if X-Plattform is important.

I would never write a backend server in Xojo. There are far better tools out there (Python, .Net, PHP or Node.JS).

16

I’m not disagreeing but consider open source Xojo projects like Express for a backend web server.

3 Likes
17

compiling is a tiny part of the process. I developped ios apps for 3 years in windows without owning a MAC, (remote compiling service on the cloud) debug on a phisical device. Then 4 years using a local MAC for the remote compilation (Same service over LAN).

Cant name tools here, but MOST of them offer Windows as platfor to develop ios, it is clear that Xojo chossed blamimg apple, and just do nothing to support ios on Windows and Linux.

Well, sort of. Single core, multiple “threads” sharing the SAME core, this means that the processing power is shared, you have to pause one request to serve the others, it is not bad to few users and if you dont have blocking code like i/o.

Yup, that is Xojo. try to download or upload a big file

18

Python has similar characteristics, so I am used to dealing with / working around these limitations. The big hype in the Python world right now is FastAPI running on Starlette because it uses AsynIO. Everyone assumes there is a massive performance boost over non AsyncIO frameworks when in reality that is just false. If using Flask, in order to get good multithreaded functionality, we have to use Gevent workers (and when doing this, performance is very similar to Starlette/FastAPI). In order to use more than 1 CPU, we have to run multiple instances of the app. To me, this sounds exactly how Xojo works, which is not bad. Most people setting up Flask wouldn’t know to use Gevent, where Xojo seems to do this out of the box, which is a plus to me.

I don’t mean to bring Python into the mix here, its just what I am familiar with, that sounds similar to how Xojo operates when used to run backend web services. And if I am completely off base in how Xojo works, then maybe someone who also knows Python would be able to relate.

1 Like
19

Well not to start a trolling thread, but i think PHP and Nodejs are outdated. I’ve learn golang, it’s pretty cool and easy to start with. Juste check benchmarks nodejs vs golang. If you don’t know JS like me, php/nodejs and to start from startch, golang language has a lot of traction, true python is major language according to stats

Plus depends on what you do, xojo as backend can be a solution afaik

20

« I’m not disagreeing but consider open source Xojo projects like Express for a backend web server »

Yes i downloaded it last week and checked it, i’ve sent you and email to ask you if you were still maintaining it,? email must got lost in spam.

We do microservices like backend architecture, and i’m sure xojo Apps can fill some needs