MacOS Ventura an R2019 R3.2?

The fact that you interpreted Geoff’s message differently than he intended isn’t his fault.

Stop please, stop. It’s a public message that everyone can understand. There is no ambiguity. It’s plain English. And the person who wrote it has a lot of experience, both technical and commercial. He knows very well how it will be perceived.

3 Likes

At some cost, I imagine.

That would depend on how well he communicated his intentions, wouldn’t it?

1 Like

Edited today…

True, but it seems that I am nit the only one. Its a sender/receiver problem, who made the mistake, the sender or the receiver?

Also that some from the community have the expectations agains Xojo Inc. to actually continue to support Web 1 (as the blog post implies imho) is nothing new.
We had several similar discussions in the past.

Back then it was written to calm down the community I suppose. We had serious arguments at the forum about this and the blog post seemed to gave the crowd what they wanted.

You could either say we really misunderstood the statement, then it wasn’t clear enough written, or it was written with the intention to be misinterpreted. I don’t know which case it is.

Addition:
Now it’s made clear. Web 1 is not supported anymore. Actually it never was since the release of Web 2. Sure built apps continue to work, also the IDE for a time. Nice at least something, but does this count as „we still support“?

1 Like

The blog post is about technical support and we do still offer technical support for Web 1.0 apps.

1 Like

Conclusion.

Web 1 won’t stick around for to long anymore.
There is a chance that it still works at least with Ventura.

Any active application should be brought to a more modern platform.

You have to decide if you continue with Web 2 of Xojo. I for my self lost faith in it for two reasons:

  1. Web 1 was abandoned before Web 2 was mature. So there were 2 years with no stable framework for complex apps (small apps in web 2 worked from day 1 on).
  2. This can happen again. And because it wasn’t announce to happen, I don’t know when it happens. Maybe never, who knows, it is to risky for me/us.
6 Likes

The javascript code can be easily patched to some extent to fix some browser problems, but patching the executable file… each time you need to made a change and recompile… Well, is not realistic.

Also, there is no such ting as “upgrade” to web2, you have to rewrite/migrate

Serious question by the way…

Web v1 is dead. It might be possible to patch JavaScript code but if there are any issues with the IDE or other parts of the framework then you are screwed.

I suggest you rewrite your app using something like PHP & JavaScript. It will be faster, more scaleable, more stable and there will be little chance of being screwed over by some poorly thought out decisions.

4 Likes

It is amazing how many people in this thread seem to believe Web 1.00 is to be run exclusively on Mac. As a matter of fact, even if occasionally some will run servers on Mac, the immense majority of Web 1.00 apps run on Linux hosts. And contrary to Apple, Linux hosts don’t make it a habit to desecrate software every year.

Besides, it should be easy to run in a VM for occasional maintenance.

There are also many Windows users and Windows servers who don’t give a damn about Ventura.

All and all, the idea that Web 1.00 would be obsolete because of a Mac system version is short sighted.

3 Likes

true, running the app won’t be a pain unless something deep changes in Linux or IIS. But running it securely can be problematic in the near future.

Also, developing will cause increasing pain over the years to come. And beeing forced to run a VM, instead of just using IDE on your device, will be a pain. Bit it’ll remain possible at least.

Do you have a blog or other reasources about that ?

No. We do this silently. Also we’re easing customers to the new software step by step and sometimes function by function. The whole transition will take another 1.5 or two years.

But here are the key aspects:

  • We started building a new backend first. This learned the data structure (over 250 tables) and got the core features
  • Then we started to remove the logic from the Xojo app. We replaced it with the new backend over a rest api as soon a new function was transferred to the new backend.
  • Currently we’re building the new frontend, which only uses the new backend. As soon as a bigger part is ready, we remove also the UI from the Xojo App.
  • We take this as an opportunity to improve our UI and the software itself, so we do not clone the Xojo app, but we take it as a deep inspiration and template.
  • Eventually there’s nothing left in the old app and it can retire completely.
4 Likes

I can’t tell you how many times PHP updates have screwed me over.

1 Like

The transition from PHP 5 to PHP 7 could be tricky if you were using out dated practices or some of the more ‘unique’ features of the language but at least they were changing / removing stuff for good reason.

From experience there is also a very low chance that you will run into a regression when updating to a new version of PHP or find serious bugs in new functionality. Sadly, the same cannot be said about Xojo.

2 Likes

One of the reasons we use the services of a small company like Xojo is to avoid this type of problem.

Using Xojo instead of the vendor language, or the big universal languages, has its drawbacks of course. But generally, at least, we think we are in the “same boat” (Xojo and its customers).

Before Xojo, I was using 4D, which has maintained code compatibility since the first Mac came out in …1984! At the same time, I played a bit with Realbasic/Xojo. And when the web framework was released, I switched to Xojo. As with 4D, I could see a compatibility in time of our code. This reassured me. Even with the switch to cocoa, the adaptation was feasible. That’s why we were very surprised to abandon the historical web framework, with a very difficult (and above all very expensive) migration possibility (of complex projects) because of the conceptual change on the client side.

Then remember the move to API2 already did that once.