First of all I want to thank @Geoff_Perlman for the possibility to talk about any concern related with Web 1.
My only one concern is related with future security issues the apps created using web 1.0 could be affected.
It will be impposible for me to assist so I would appreciate if someone could record the zoom session and upload to youtube to assist later.
2 Likes
When your app remains under active development, then working under a VM is just a huge pain. As an employer you need to stay attractive. And forcing your devs to work with an esoteric language an abandoned framework, a 3 years old IDE - AND in a VM on an outdated OS - that is not attractive.
Additionally you will into other compatibility problems when you’re forced to develop on old OSs.
So yes, we had luck once again, that Venture doesn’t break the old IDE. I wouldn’t bet, that this lasts for the next releases. The bomb is ticking and we complained because we we thought Xojo Inc. will help us postponing it’s explosion.
4 Likes
There is a big confusion here. This is not about javascript or Ventura alone. In order for the IDE to work on the latest operating systems, Lars has explained things very well. We also use other work tools at the same time, and these may require new OS versions, resulting in incompatibility and breakage in the workflow… But the problem is mainly from a possible sudden need to recompile the server side web framework.
Two years ago, after the web framework was discontinued and many distressing messages from his customers, Geoff reassured us that they would do everything possible in the future to solve the problem if a browser or OS update broke our web applications.
So the situation was pretty clear. For new projects, use the new framework. For old simple projects, we should try to migrate to the new framework. For old complex projects (mine took more than 10 years of daily development with this framework), the situation is much more complicated and depends on many factors, especially financial, especially since the new framework is conceptually different from the first one on the client side.
So Geoff’s statement reassured us. We were not happy of course about the abandonment of the historical web framework, but at least, for complex projects, we could ensure continuity of service to our customers.
But we discovered this week that it would actually be very difficult to recompile an old version of Xojo (“The crux of that statement is ‘everything possible’. Xojo is simply not set up to be able to go back in time and compile and release older versions of Xojo after a new major release has occurred” according to Greg. Geoff liked the message and confirmed: “We do not release updates to any version of Xojo except the current shipping version”. Although he added later “I didn’t say it was impossible”). In short, we are lost, since the historical web framework does not work with Xojo versions after 2019.
Since the IDE, the server-side web framework, the small internal Xojo web server, and all of Xojo’s code seem to be compiled into a single project at the same time, how will they deal with a serious non-hackable problem? It’s not clear.
So we are very worried. Because, what’s going to happen, for example, when our customers’ web browsers require security protocol updates? And these days, it can be very, very fast. Because as soon as a security flaw is discovered, or the encryption used is no longer sufficient, the whole chain must be secured quickly. The web framework also uses the HTTP 1.0 protocol, which is very old. Here too, there may be a nasty surprise and a sudden requirement to add a header of some kind or other to satisfy new security requirements.
Of course, all this is just guesswork. But like everything else with disasters, before, we laugh that it will never happen and that this has never happened before, and afterwards, everyone wonders why this problem, “obvious” after the disaster of course, has not been anticipated.
Our apps communicate a lot with the outside world these days. Of course, via web browsers, but also via a whole bunch of APIs. My web app for example communicates with my customers’ bank servers, government services, accounting apps, carriers’ APIs, services like Stripe, Amazon, Wordpress, Paypal, Google, Sumup, Yavin, Twillio, Sinch/Mailjet, Zalando, etc., via for example handleSpecialUrl. Again, at any time, these services may require new security protocols, more advanced encryption keys, etc.
These are just examples, there can be many other problems that break our web apps. It can also come from Apache, reverse proxy mode which has new requirements, etc.
Of course, I’m sure someone will say “for this problem, we can do that”. Okay, maybe we’ll find it, but some of the problems will touch the core of the compiled server-side web framework. It will be hard to fix the problem without updating/re-compiling Xojo. And I would add that it’s hard to bet the company’s life on unclear probabilities of re-compiling. Geoff, without realizing it, you are playing with us, that’s not nice.
In short, at some point, there may be a need for an update of Xojo 2019. We thought for the last two years that Xojo could probably do it. And now we feel that it will be the other way around: that maybe it will, but probably not.
6 Likes
I think that Olivier’s application cannot be rewritten quickly, neither with Xojo Web2 nor with other tools.
I understand that application is very important to Olivier’s business.
The dangers reported by Olivier, Lars, Jeannot (and others in the past) will also affect others who have developed complex applications with Xojo Web1.
Even those who do not see them or do not want to see them.
Dealing with these problems should be a moral duty for Xojo Inc.
3 Likes
Correct, the basic and underlying problem is IMHO the release model. However, as far as I understand Xojo Inc. so far, there is no effort to change that in the foreseeable future, or to question it.
So you only get fixes as “new” releases. This means in extreme cases a completely new product (Web 2 versus Web 1).
The argument is always that you can still use the old version “forever”. The problem that is ignored is that this outdated version may also carry security risks, which is particularly critical for web applications.
I have tried to put this together. The example is of course bumpy, but the core message is right: with Web2 we got a new car, and the old one continues to rust away because the underbody protection is faulty.
https://xojo.jeannot-muller.com/xojo-no-patches-no-cry-8a1e7c270246
That is exactly my understanding. That’s why I see it that Xojo obviously needs a meeting to get the actual problem explained again and not vice versa.
But then it would probably be more targeted if our customers contacted Xojo directly. Unfortunately, there is a complete lack of understanding that we are not playing drama queens here, but really have a serious problem and are keeping Xojo from a lot of trouble.
The model that the MVPs become the mouthpiece here does not help, either, except that some have offered that they could possibly create workarounds with plugins. That’s not their job and it’s not ours.
Anyway, I’ll start switching over the last Web 2 (!) app next week at our own expense and then the chapter will be closed. At least I warned others as well as I could, because I’ve held up the flag for the product for a very long time. Of course, everyone has to decide and evaluate this for themselves. Due diligence should never be delegated!
I would highlight this sentence.
1 Like
Believe me, it is no fun spending 8 hours a day every day doing Xojo development in a VM. This is something I have been doing for the past 12 months because all attempts to get our app working in newer versions of Xojo (since the transition to Direct2D) have failed. This means we have to use the Xojo 2014 IDE which is 32 bit so we have to run a version of macOS which runs 32 bit apps.
1 Like
Then why do that? If you are really spending 8 hours a day for 12 months in a VM, then it seems to me the problem is that you should be running it on hardware that still supports the IDE version you choose to use. Even if you don’t still have older hardware that can run it, used macs which can are cheap.
I simply went the route of a 4-port KVM which lets me instantly switch between multiple devices. I spend most of my time via dock to my 2021 MBP with M1 Max chip. But can instantly switch to other devices going back to a 2012 mac mini mounted on the wall behind my 4k monitor, or to a boot camp machine for when I want to test under Windows on Intel hardware instead of in an ARM VM on my MBP.
2 Likes
The Xojo 2014 IDE doesn’t run well on the last few versions of macOS that supported 32 bit so it means going back to something like macOS 10.11. It is much easier to do this in a VM rather than using an old Mac running 10.11 since that would mean running older versions of all other apps.
The plan is to get this project onto a newer version of Xojo as soon as possible. Unfortunately, Xojo hasn’t made this easy with the changes they made to the Windows framework.
For Windows, I stayed with 2016R3 which is the last one doing transparency correctly. It runs perfectly under Windows 11. The alternative to running in a Mac VM would me much more comfortable in a real PC. Such machines are extremely affordable.
For Mac apps, I currently use 2021R3.2 on my Mac Mini M1.
1 Like
That’s a great example of something we would absolutely try to resolve if it ever came up. I can’t say what form such a solution would take but we would certainly doing what we reasonably could do.
1 Like
If you run into a situation, please contact us and we will see what we can do to help. It’s obviously impossible for us to guarantee that there will always be a solution. Like you said, the only framework is HTTP 1.0. The difference between 1.0 and 1.1 is much bigger than it appears.
But again if ANYONE has an issue with their Web 1 app, contact us and we will help in any way we reasonably can. I just don’t want to set the expectation that we will continue updating 2019r3.1. It could conceivably turn out that a simple patch would solve a particular problem but since no of us can predict the future, I don’t want to try and predict the solution now.
We truly believed in the beginning that we could make web 1 and web 2 interoperable but it didn’t work out that way.
We do care about our users and will always try to help.
At least for me and my actual needs this promisse from @Geoff_Perlman is all what I need to continue supporting Xojo.
2 Likes
? dude what’s your point except trying to be a useless *troublemaker.
http 1.0 is less secure, ok we knew that, and cry wolf ?
you just said exactly the same as geoff says
http 1.1 is more different than it appears, duh
This is known for years indeed. It was one of Web1’s major weaknesses but was rarely openly addressed by Xojo, except that it was one of many explanations from the Xojo devs why Web2 had to be completely re-designed. What should change about that now? The “best effort” offer is very kind, though Web1 remains to be end-of-life for many good reasons.
It doesn’t help much if the new version is better if there is no reasonably feasible migration path for Web1 developers (Xojo ultimately recommended restarting from scratch for Web2). Apart from that, functions from Web1 are completely missing, which makes it a mission impossible in some aspects.
IMHO some Web1 users might now face issues that they probably don’t grasp. Please don’t take that again in a bad way. Isn’t Xojo’s goal so that the end user doesn’t have to deal with such “details”? At least that was my understanding for many years.
I’m afraid this use of language may give users a false sense of security:
The most sensible thing Xojo could have done would be to make such adjustments in Web2 that migration might be possible, or at least simpler.
But in fact, this has been discussed endlessly. It is also certainly not the task of a software manufacturer to ensure that its products are always used sensibly.
However, I see it as an obligation that the manufacturer clearly addresses the challenges upfront and urges the users to finally migrate and equips them with tools of whatever kind (tutorials, tools, best practices, changes in Web2) to deal with an urgently needed migration. I’m just afraid that this is excluded from “we will help in any way we reasonably can”, anything else would certainly surprise me.
@Hector_Marroquin 's original question has now slightly drifted into the following “discussion”.
I am adamant that Xojo would have done itself a great favor by addressing this problem much sooner (at least now) and offering help. However, once bitten, twice shy. Many will conclude that such a hard stop might be repeated anytime in the future.
It may surprise you now, but I would still support Xojo in saying:
Please really stay away from Xojo Web1 in 2022, but we (finally) understand that you need more help with the migration. We will help you with your migrations!
In my opinion, the vague statements and usual promises are IMHO not helpful and lull users into a false sense of security. Some might now plan to continue with Xojo Web 1 for the next decade. It is obvious that this will very likely go wrong.
Last but not least, and that’s what annoys me. The fact that Xojo noticed during the development of Web 2 that the new release must be a paradigm shift is less of a problem than that it was not communicated early on, or at least hinted at.
The opposite happened. “The bugs in Web 1 will soon be solved with Web 2.” - As politicians often argue: “It’s forbidden to lie, but we don’t have to tell the people the whole truth either”. I see things differently.
Maybe this textwall explains my short “seriously” now better to you.
What would that look like to you? What could we do that would help you migrate your projects?
I do not know what this might mean for anyone else, but for me it would be a utility that will convert all controls and code from a Web 1 project into a Web 2 project. For any code that could not be converted it would be isolated and turned into commented code with an explanation why conversion is not possible and point to potential workarounds. For Styles it would provide relevant CSS if the style cannot be set in the control. I’m sure I have missed details on conversion handling that others can add to this.
I realize this utility would be a momentous project and likely it would need to be contracted out by some external team that would need to consult with Xojo’s primary development team. There are probably a few folks on this forum that might be qualified or interested but that isn’t me.
Thanks Geoff, that’s always good, but we saw that technically it would be difficult.
The ideal solution would of course be for both web frameworks to run on the latest version of Xojo. It would be much easier to maintain the framework to close security holes and be ready for any problem.
Greg told us that technically, it will be difficult to make the two cohabit. But maybe that’s a choice that could be made when starting the IDE?
Of course, this has a development cost, but it would help us so much… Maybe the development cost could be shared?
The possibility to run web 1 at startup could be hidden too, if Xojo doesn’t want to encourage it.
But I think that even commercially it would be interesting for Xojo to offer :
-
A “desktop oriented” web framework (with an additional cost if needed) (the web 1)
-
A “responsive and mobile welcome” web framework.
Of course, the second framework would make desktop web apps as well, but we’re talking about a general direction here, with each framework being designed in a certain dynamic.
This is not technical, but marketing. Most of us need a clear and simple concept, that’s what made the first framework successful.
Michel said that 80% of Amazon customers order on mobile. But let’s not forget that many people still work all day in front of a big screen. In the BtoB world (so a lot of people, all day long, in a lot of different companies), but also in administrations, governments, hospitals, schools, etc., this is often the norm.
By the way, desktop web libraries like Webix have a growing success (only in desktop companies of course), while they don’t work well on mobiles and tablets, that’s not a coincidence.
And the cost would be low for Xojo, because the desktop web framework is mature on the client side. And this framework has been so successful.
1 Like