Just tested. 2019 R3.2 works on my Sonoma VM.
1 Like
That’s different. Web 1 vs Web 2 thing is more like the difference between macOS 9 and macOS 10.
Look, the problem is that we couldn’t have the old and the new frameworks commingle. Their architectures differed so greatly and there was so much code that needed to be updated but the functionality replicated. Early tests showed that having both frameworks present on the browser just wasn’t going to work.
Web 1 was designed around the concepts that were current for web development in 2009-2011. Ajax callbacks were all the rage back then and there was no such thing as a WebSocket or ServerEvents or HTTP/2.0… or even Bootstrap. JQuery was just getting started at that point. As the years went on, we hacked together patches for things to try to add better browser and server technologies, but the underlying framework still had issues that were ultimately going to require a rewrite. To be quite honest, web 1 wasn’t designed to be maintained and upgraded forever. There were things about that framework that couldn’t be fixed without breaking everyone’s projects, some of which constituted security risks IMO.
When it came time to do the rewrite, I wanted to make sure that it followed one of the core strengths of Xojo… that we used native controls on each platform so that Xojo wouldn’t have to create all of the controls from scratch. Having to do that and then asking 3rd party vendors to follow those design decisions got out of hand each time a new version of macOS, Windows or flavor of Linux was used because we were trying to make it look like a desktop app. Switching to Bootstrap as the visual framework and having the layouts match the IDE on all browsers and platforms was as much about solving that issue as it was about opening the Xojo community to the hundreds of 3rd party, theme-matched controls that were already out there.
Just a quick note about this though… Web 2 was designed with the future in mind. It was always my plan that it would migrate from Bootstrap 4 to Bootstrap 5 and beyond as time went on (Bootstrap 3 was current while it was being designed) and the fact that it was done recently with minimal pain shows that the plan was worth it. But just like an OS or SDK upgrade you may still run into layout or color changes. Web 2 was also designed from the beginning to support 3rd party controls, whereas it was an afterthought on web 1. I know this because before I worked for Xojo, back in the fall of 2010, I was creating custom controls using the parent class of the YouTube control that was included because it had some rudimentary functionality. One of my first acts as a developer on that project was to create a way for users to create their own controls.
Personally, I think the main mistake that was made was to make Web 2 only work with API 2, first because API 2 wasn’t completely hashed out at that point, but also because it made the transition that much harder. Had we been able to tell users that they’d be able to make a few layout tweaks, and then introduced API 2 later, things would have gone a lot smoother.
9 Likes
Thank you for the insight.
FYI, if people are having trouble running 2019 R1.1 in modern macOS, see this solution: Big Sur prise? Bug Surprise? - #38 by Lars_Brennicke
1 Like
I use 2019r1.1 for work every day using Ventura 13.5.x, no need for that for Web1, it is only needed for Desktop (from what I can tell).
I think this is important to mention as this topic is about Web.
3 Likes
I remember many users, (including myself) to write in the forum that no one expected “frameworks commingle”, but SEPARATED web1 and web2 proyect types to being able to mantain the web1 proyects, benefit from IDE improvements and have a real support of at least being able to edit, compile and run web1 proyects in current OSes even if the framework didnt had more bug fixes.
Offering Web1 while Web2 reach a less buggy state and users find the time/money to do the rewrite could have given xojo more sales than just killing it and leaving users with no other choice than to use their old releases. And no, as many users have told in this thread and others, the rewrite is sometimes way to expensive to do it, and the lack of vision from xojo to accept that is what drove users to other tools and made many of others (me included) to stay with an old release.
6 Likes
Aside from the fact that Greg clearly said the two couldn’t exist at the same time.
I think what Ivan meant was that a good compromise would have been to be able to choose framework 1 (to preserve the compatibility of older projects) or framework 2 when starting the IDE. The IDE wouldn’t open projects 1 or 2 at the same time. You’d have to restart the IDE to choose a different framework.
Geoff thanks for your input. One area that has not been broached here is support for Web1 apps on Xojocloud. You currently support them. Do you see a future when you will no longer be able to support them?
Well, he explained a lot why both cant “commingle” in a single proyect…
Yes, Web1 and Web2 are completely different platforms, having web1 and web2 in the same IDE is like having web and desktop… No need to explain why a web proyect cant have a desktop control, but it is useful to have the 2 proyect types available.
We will continue support for Web 1 apps on Xojo Cloud for as long as we can and as long as it is needed. We have no plans to stop support anytime soon, but when the time comes we would give people impacted a long-term heads up about any forthcoming changes.
2 Likes
What you may not realize is the framework is a Xojo project. Of course, it’s been a long time since I’ve worked on Xojo, but I don’t believe what you suggest would be practical. If I recall correctly, nearly the entire framework (not just web) would need to be duplicated, which poses a serious problem for maintenance and development. Plus, as Oliver suggested, the IDE has no concept of switching frameworks so that would need to be added at launch. Which is a synchronous process, so waiting for user input would also be a problem. Yeah, it could be technically possible. But far from practical, since any time you’re duplicating code, you’re doing something wrong.
2 Likes
Ahem… This is exactly what I would have to do to make OAK work for API 1.0 / RectControls and API 2.0 / DesktopControls.
It is one of the most significant factors as to why I decided to stop making it public. I’d have to duplicate and update thousands of functions, to which I couldn’t efficiently support because all my apps are API 1.0 / RectControls.
I begged for functionality that would help, I did get one, but it was partially implemented and not enough for the whole project.
1 Like
Hi Geoff. Web 1 has a terrible memory leak that’s hard to work around. Any chance of a hot fix?
Hi Eric. What exactly is the nature of the memory leak? What causes it?
1 Like
I hear you loud and clear.
1 Like
We think its either a socket or JSON class. If so, it was fixed in subsequent versions and should be back portable, since Web1 did get to API 2. We are at 2019r3.2
I confess I don’t quite understand the problem, apart from the fact of course that there is a cost for Xojo inc, immediately to do this, and over time to keep the framework compatible with today’s technologies/IDE (but it could be a paid maintenance target too). On the other hand, this negativity surrounding the product also has a cost for Xojo inc.
There could have been an option in the Xojo settings to restart the IDE with the Web 1 framework. This would only work to open an old project, not to create a new one (or an option to restart the IDE only with a Web 1 project file whose path/name is indicated in the option. No other project can be opened, unless you restart the IDE by unchecking the option).
I don’t know whether this is technically possible or not. But commercially speaking, it would be such a good thing for Xojo inc, so much!, who could say that since the beginning of the company, customers have never been abandoned, which is very rare, and one of the main reasons to use the product of a small commercial company.
And customers like us would be so grateful!
1 Like
May as well have two versions of the IDE, then.
Then all you are doing is belling the cat (see Belling the Cat - Wikipedia).
Good luck with that. A back-port would require Xojo to set up the entire tool chain exactly as it had been in summer 2020 just to be able to recompile the IDE.
IIRC, SSL Sockets did have a memory leak in Web 1 which we specifically fixed in Web 2 because it was deemed not safe for a point release. JSONItem was also updated to internally use the framework dictionary methods for the sake of speed and it’s entirely possible that it had a leak in Web 1 as well.