there are a lot of these completely useless languages around
Xamarin has being used to make iOS and Android apps for years now. Microsoft said, you can make mobile apps with VS and they delivered. Even if it was a âbig giant kludgeâ, they make it happend.
So, if they say that this year all the .Net technology will be consolidated with .Net 5 and a real cross platform next year with MAUI in .Net 6, most likely they are going to deliver.
With the development happening on Github, looks like Microsoft is listenig to users more than any other, lets wait and see MAUI, it is just 17 months ahead
I need to catch up with the Core, Net 5 and Ne t6 thing.
Obviously I have not worked with Xamarin but the reviews Iâve read have not been too positive
You are much more optimistic than I. I have been waiting for this for years, so I will be very happy if youâre right. However, theyâve got an insanely long way to go, and theyâll never be a proper VS for MacOS or a drag/drop UI editor, so even if they get the rest of it working, itâs a moot point.
The events of recent weeks exposed the MVP program as a travesty.
1 Like
Garry, this is the conclusion I have come to ⌠if you are doing a desktop app and especially if you have just one target, itâs pretty darn good and it has in fact restored the joy of programming to me in that particular realm. I suspect itâs at least okay for IOS. I just find it alarming how much ground they are trying to cover with a small dev team, and how they advertise the web target like itâs usable when itâs not, now long Android has been in âactive developmentâ, and how they are (not) handling bugs ⌠or as you say âhow it is managed by the companyâ.
2 Likes
I am using JetBrains Ryder myself. Gave up on the MacOS version of Visual Studio, although the current version is probably much better, I have no pressing reason to switch back.
1 Like
And that is why it frustrates many⌠We long time users (who started when there was ONLY desktop) from the start saw it had LOT of potential if it could smooth out enough of the rough edges (I am speaking of desktop) ⌠but it never has and so never really took off as it could have.
-Karen
4 Likes
Xojo is far away from good quality but we should speak also truths: it was also a pure Desktop Platform not a real Programming System. Xojo had always the same problems: it is not C++ or Java. So they builded a beautiful RAD. Drag and Drop the UI and the most stuffs are abstracted for the Programmer. So less to learn compared to Java or C++, programming made much more simple and much more funny for the people. Especially Citizen Developers can grow there to Pro developers which are building good Software with commercial success. But we have to realize what it is. It is not Java, C++, C, Swift, Xcode. It is: Xojo. An RAD System which is able to build for multiple platforms with a limited set of capabilities. If it would be that great and that super and that big: it would have Millions of users. But for sure: look on the forum and look on the Java Forums. Java Forums are a few k times bigger. And much more frequented. What is normal if you have more than 10 Million pro programmers using a language every day. We should not forget all of it. To be a Java Pro or a C++ Pro with all the Platforms it is and will ever be a real hard learning Curve to learn it. With Xojo you can write simple Software. Not the next 3D CAD-System for the Industry. Not the next ERRP-System for there industry. But Software like the E-Mail-Archiver and other small nice projects I saw. That is Xojo. And for that it is not that bad. No question. But: as a RAD for Citizens it would be the right to sell. As a programming system for professional developers you will see: the borders are reached really fast.
To me the main advantage of .NET 6 / 7 (.NET Core was something of a first pass at .NET 6) is performance improvements, which are substantial and, for the console / service apps I generally write, provide significant speed improvements almost for free. And thatâs saying something because .NET framework 4.x was no performance slouch itself. Microsoft, unlike Xojo, has invested heavily in compiler and memory management improvements as well as adding functionality.
But ASP.NET has gone through something not unlike Xojo API 2, it seems like they have renamed namespaces and changed best practices for the purpose of breaking things. You cannot in a straightforward manner take a nontrivial ASP.NET MVC 5 app and move it to ASP.NET Core / 6 / 7. You will have to reorganize and rewrite quite a bit of stuff to do it ârightâ. There is a conversion app that will kinda-sorta ease the pain but it canât go very far on its own.
Sadly, at my paying job, Iâm blocked from moving to .NET Core+ because the client-facing stuff is in ASP.NET MVC 5 and the company doesnât want to invest in moving it forward, and that stuff canât easily interop with mine if I move my side of the house to Core+. In fact weâve been acquired by a company that has standardized on Google technology platforms, so weâre sort of out there flapping in the breeze on Azure and .NET and their approach to it is really to just sunset it all eventually and hope for the best. They arenât even trying to port any of our particular innovations to improve their own platforms.
Xojo API 2 does not particularly perturb me because I came into Xojo post-API2 so itâs not really an issue for me and because as per the above, other vendors can also be cavalier in chasing the latest fads without sufficient regard for backward compatibility. In the early days of the .NET world for example, .NET Interop was the advertised Second Coming and very different from ActiveX before it. I wrote a bunch of software for a client around the 2005 time frame using .NET Remoting, only to find, not that eventually, that it was deprecated for something completely incompatible called WCF. .NET Remoting still works to this day but it hasnât been maintained for many years now. And WCF has had its own evolutions / deprecations I believe, although I havenât had to do RPCs for a long time. I guess the fad du jour now is JSON/Restful APIs. I am building a web API on that, and probably about the time I have it perfected something new will displace it and what Iâm doing will be âso yesterdayâ. Already, we have other standards being advanced, like GRPC.
It is this constant churn that is what I was hoping to be largely insulated from with Xojo and it was apparently naive of me. I really donât want to have to cram on tutorials for at least one new abstraction or framework each and every week of my existence. Itâs changing at an unmanageably, impractically fast pace. If you focus on some particular tech stack, you are likely to be lost with the other technologies that might arise. In practice, a lot of corporate devs change jobs every year or two and are jacks of all and masters of none.
At this juncture I will use Xojo for existing internal projects that can be deployed to Mac desktop and will have to look elsewhere for other targets, I think. I am glad that Iâm on the glide path to retirement though. Iâm getting too old for this crap.
5 Likes
Amen.
2 Likes
I think many will agree, that sometimes you need a complete change, and that indeeds happens at a higher pace year by year. I would not have an issue, that a Xojo 2023 will habe new features, and might break older projects and that you need to convert old projects (if you want those new shiny features).
But it is quite unusual, that a new release breaks regularly (approx. every quarter) your projects, but thatâs the Xojo way for some years now and what drove me finally nuts.
Now Xojo is right that of course you donât need to update. Sure, but if the fixes of show stoppers are only available in new release and not backported as patches to some of the old releases (ideally an LTS version) youâre screwed. Xojo is not updating, it is almost always an upgrade to âsomethingâ new.
GO has a different approach, pretty much like JAVA has. Iâm sure @thorstenstueker can point us to the corresponding JAVA manifest.
GO does say that there might be breaking changes with GO 2, GO 3 but not for GO 1. So far they are doing a great job to fulfil that promise.
I think most of the discontent comes from the web and iOS side - desktop users like myself are by and large happy, with no big show-stopping bugs; just annoyances with the recent renaming of everything, and going back a few years, the replacement of the old RealStudio IDE with the current one, which imo is inferior.
Oh, wait, I just replied to a two year old post 
2 Likes
macOS Xojo desktop apps are fine but the graphics / UI related parts of the framework on MS-Windows since the the switch to Direct2D is a bit of a shit show.
be welcome Julia, we all have done it. I realized to late. And yes, Desktop makes less problems, no question. But only to compare: I have Desktop Apps outside with about 100k Codelines. Thinking about to rewrite for the massive API changes would kill my wallet paying my employee for that. It makes no sense in my view. It could run further without this changes definitely. Saying the I know that for RTOS the C++ API was also massively changed and also that was disturbing enough for everybody working with RTOS bare metal. But that was for a sense cause they had to modernize the API itself und the underlying functionality which was needed since years. Xojo was only renaming, the C++ team wrote a new API. What makes me nervous when a vendor behaves like that is always the question: what comes next?
1 Like
Donât worry Julia, your comments are timelessâŚ
Kind regards, Andrew
4 Likes
no worries, as nothing changed at Xojo Inc. (at least not to the better), there is nothing wrong in replying to older posts 
4 Likes
True that.
2 Likes