New Framework vs Class Framework: need suggestions

I’m starting this “New Framework vs Class Framework”" discussion here, even though there’s another one on this forum, because the other one was supposed to be a poll, and I voted there. I’m coming at this as a FileMaker developer who switched to Xojo within the last couple years. So I’m not the seasoned Xojo developer that populates that other thread.

After successfully producing a Xojo Web app that has been running for over a year now in production for a real estate firm, I recently started rebuilding a very mature complex FileMaker Desktop app into a Xojo Web app, using the Classic Framework. It’s going very well, and I’m happy doing this. But now I hear (in that other thread) that the Classic Framework will most likely be replaced by the New Framework in some 5+ years. I have never used the New Framework.

Should I start converting this far-from-production project to one that uses the New Framework exclusively? That is, find every block of code in that project that could use the New Framework, and rewrite it using the New Framework? Here are my considerations:

  1. If I wait until I have no choice, like some have suggested in that other thread, it would mean I would end up rewriting over 5 years of code at that point, instead of about 2 months of code currently.

  2. But if I start the New Framework conversion now, I face the possibility that the New Framework ends up being a moving target in its implementation because of its frequently reported immature state, or it’s later abandoned by Xojo Inc.

  3. I guess I could just wait a little longer and see how serious Xojo Inc is about this New Framework replacing the Classic Framework, so I end up rewriting, say, 6 months of code instead of 5 years of it.

I’m not looking for opinions as to what Xojo Inc should do with the New Framework. I’m just looking for suggestions as to what I should do with my current project, given the current state and status of the New Framework.

  1. you could foregoe the “new framework” completely for now, and should such time ever occur when the “old” framework is removed, you could very easily (as I have previously suggested) write a library of wrappers the enclose “new” framework functions in an “old” framework syntax… allowing you as much time as you wanted to change or not.

Don’t worry, i’m almost sure they both will co-exist for a long time. Xojo does about everything to make sure that they don’t break your code with their changes, the New framework is only complete for anything that would require it. While you can interchange most stuff, it would require you to write a lot more code.

Basicly keep this in mind;

  • Xojo.Core.MemoryBlock is faster then MemoryBlock you may use it for (tcp)sockets, giving a little speed improvement
  • Use the new framework as much as you can if using New Framework classes ( for example Xojo.Net.HTTPSocket).
  • I might be smart to use Text for (dynamic) constants (instead of string) to be translated
  • Use the new framework for iOS and interchangable code between iOS and your other platforms.
  • Overall use the old Framework

We have stated several times that the existing framework and new framework can co-exist so YOU can decide over time how to move things. We have also stated that the classic framework is not being removed / deprecated for some time (probably on the order of at least 5 years - I think at one point Joe said 10 even). So once again you can transition when YOU decide not when we decide. The existing framework is in “maintenance mode” - new features wont be added to it. Bugs will be fixed etc we’re putting any efforts to create new functionality into the new framework so that over time it becomes the preferred way to do things.

There’s no “right” answer to “when should I move to the new framework”
Because they can interoperate you can use it when you need it (ie/ for things like HTTP 1.1 support etc)

I can say that even in Feedback and the IDE we take this exact approach and move to it as we do work that can take advantage of the new framework. We’d never consider trying to move the entire IDE at once to the new framework. THAT is much too large a job and precisely why we made the new framework so it could interoperate.

As you pointed out, the new framework is still immature, and at the pace it is progressing, for at least most of the next 5 years I doubt it would be possible to do a new framework only app… That means some recoding over time, no matter what you do for a project you start now, or 6 months from now.

Given that, I would use the new framework only for things the old framework can’t do, or the new framework does much better (in terms of functionality)… and slowly change things as the new framework matures…

That is an unfortunate situation… but it is what it is.

In any case, given past history, I suspect the old framework will be around for significantly longer than 5 years and the code produced by the “last release” of it will work for even longer.

  • karen

[quote=358729:@Norman Palardy]We have stated several times that the existing framework and new framework can co-exist so YOU can decide over time how to move things. We have also stated that the classic framework is not being removed / deprecated for some time (probably on the order of at least 5 years - I think at one point Joe said 10 even). So once again you can transition when YOU decide not when we decide. The existing framework is in “maintenance mode” - new features wont be added to it. Bugs will be fixed etc we’re putting any efforts to create new functionality into the new framework so that over time it becomes the preferred way to do things.

There’s no “right” answer to “when should I move to the new framework”
Because they can interoperate you can use it when you need it (ie/ for things like HTTP 1.1 support etc)

I can say that even in Feedback and the IDE we take this exact approach and move to it as we do work that can take advantage of the new framework. We’d never consider trying to move the entire IDE at once to the new framework. THAT is much too large a job and precisely why we made the new framework so it could interoperate.[/quote]

Norman, they can’t really interoperate in iOS now can they. It’s probably the base of all confusion, iOS locks in into the New Framework but gives 0-access to the Old Framework, the side platforms can still use the old framework. This holds back code interchanging making Xojo less x-platform.

Giving the community something to scream about, cause it would take a whole of a lot time to change to the New Framework without giving all (current) functionallity, similar to the old framework.

Makes sense?

So iOS code to> desktop/web works fine with some modification
Desktop/Web (old framework code) to> iOS doesn’t work UNLESS you change alot of code if you have a major source.

The whole thing is more like Xojo gives Web & Desktop the possibilty to interchange code, but iOS suddenly requires lot’s of modifications, making it less xojo…? Not to talk about the documentation, redirecting docs from documentation.xojo.com to developer.xojo.com but not all ? It gets me thinking it’s half finished, and not even looked at.

The old framework could not be “ported” to iOS - regardless of what anyone supposes could be done.
There was NO opportunity to make iOS use the classic framework (regardless of others opinions on this)
That would have meant reimplementing the “classic framework” for iOS and mimicking the API.
But something like HTTPSocket from the classic framework could not exist in its previous form on iOS.
So calling it that would have badly mislead people into believing they were the same thing - when they were not.
You’d have been just as upset if we said “Oh sure its an HTTPSocket BUT you MUST use it asynchronously as thats all that exists”
You STILL couldn’t just copy & move code from one target to the other.
There are other issues the new framework solves.
Like the fact that when you use almost ANY piece of the classic framework it HAS to drag EVERYTHING in - there’s no possibility for ANY of it to be stripped out even if you do not use it or need it
We can do that with the new framework simply because things can be stripped at the module/class level - something the old framework quite literally makes no use of. Everything is global.

We’ve said all this before

Thank you Norman, sometimes the information is hard to find, and for us newbies is great that you and other people that know how things work post the information again, so we can find it and learn ‘what is going on’.

[quote=358737:@Norman Palardy]The old framework could not be “ported” to iOS - regardless of what anyone supposes could be done.
There was NO opportunity to make iOS use the classic framework (regardless of others opinions on this)
That would have meant reimplementing the “classic framework” for iOS and mimicking the API.[/quote]

And doing that would not have left us with the mess we have now for the foreseeable future…

Yes there would have been some non UI things that would have to be different… but those could have been dealt with on a case by case basis and that functionality added to the classic … and few things in classic deprecated…

That would have made the non UI code mostly the same as for desktop/web from day one, with only a few cases of #If Target… needed in the code

You then you speak about issues problems with HOW the old framework was implemented under the hood and how the frameworks are interoperable…

Most of the under the hood issues COULD gradually have been taken care UNDER THE HOOD… For us what matters is the API we use. (as well as speed and bugs)

You could have had old and new frameworks (of a different from than now) UNDER the hood and have handled the interoperability UNDER the hood with minimal effect on our code and still add new features and classes…

That would have allowed US to have a lot less work, keep the features of the API that made us fall in love with RB … and STILL allow Xojo inc migrate to more modern underpinngs.

Yes it would have made some things more difficult for Xojo inc and required more ingenuity, but that would have been accepted a whole lot better by customers IMO.

Instead Xojo inc decided to dump a lot of the issues of interoperability on us for at least half a decade (and that is if the new framework is complete in 2 years - it will likely be much longer).

Since the old framework won’t be upgraded to keep pace with modern requirements, using only the old framework is going to be less and less possible and keep requiring us to write more and for code just for “interoperation”.

All that is besides the fact that the philosophy of new framework makes it less palatable to a certain type of customer that likely makes up a significant portion of Xojo customers.

I don’t think posts like this will change your opinion, or Xojo Inc’s direction, but it’s how I see things. Over the last several years I find myself feeling more and more Xojo inc is making decisions that show they going for a different market than they were originally … one that is less oriented to people like me.

  • Karen

While it all may be true, we now have a probably only 1/50 th part of a the new framework usefull to Desktop and Web. While we would like to see a more complete “new framework”, it’s been a long time to see a change in there and people want to start porting over to keep future maintainability for their sources.

Most likely people like to see improvements (fixes & features), instead of having almost a year of stand-still. Currently it looks a lot like the community is doing all the major testing work and feedbacking. I feel a need to ask if Xojo has it’s own testing purposes for their releases as it looks a lot like the end users are all doing it in their time. It’s a major pain if there is a bug that can’t be worked around and isn’t solved over 1+ year. It’s even a bigger pain if xojo adds something that never seems to be updated, even if, it will be really minor.

Apple is also moving forward with Swift, as is MS. It is HARD to maintain an old framework and moving it forward without breaking some compatibility at some point.
I would also very prefer that Xojo would bring us a more mature and ready new framework, but I think they hit some roadblocks at some point with IOS wich triggered the whole thing.

My major income-producing app has over 6,700 variables defined as strings. A few are used to store and process data read from disk files, the vast majority are actual words. How long would it take me to adjust the code that uses those variables? Years? Just to make everything work the same way it does now. I’m already struggling with upgrading 500+ graphics for HiDPI.

Edit fields, labels, and other controls currently use strings, not text. If the IDE changes those to text-only, then I will either have to hire multiple people to help convert my code base (which I can’t afford) or fall years behind Xojo’s release schedule. Neither option is anything I want to deal with, I’d rather be offering my users new and better features.

I’ve been told over and over that we’ll never have to give up the classic framework, but now I’m hearing 5+ years before its deprecated, which is the first step towards end-of-life. My software typically has a major release every 4-5 years. That means I should have converted to the new framework a year ago.

Are there any automated tools available to help with this kind of large-scale refactoring of code to move to the new framework? If not, then somebody should start writing them…

The classic framework will never die. We will always have access to the current & previous versions of the IDE so even if Xojo do deprecate and remove the classic framework it will still be available.

I choose to use the new framework where I can, not so much to future proof my projects but to future proof myself.

Slowly convert them to Text, as Text does automatic conversion to String…

But string does not autoconvert to text… (I know about string.ToText) but why not auto convert string to text as long as the string has an encoding, and throw an exception on the assignment if it does not?

THAT would be one thing that would make “interoperability” more convenient when one is primarily using the old framework but needs to use some new framework methods because the old is not being modernized (HTTPSocket comes to mind).

As far as I can see, the reason why not is purely philosophical…

  • karen

or maybe just because it hasn’t been done yet ?

Personally I don’t see a reason to auto-convert string to text, when there is .ToText The auto-conversion of Text to String is a placeholder until everything is Text…

We have moved some things away from autoconversions precisely because they can be the source of some really hard to track down bugs BECAUSE they are automagic and easy to overlook when reviewing code.
IMO variants are a never ending source of bugs.
I have personally fixed many in the IDE that were excruciatingly hard to track down because they were autoconverting variants.
They’ve been among the most difficult to track down bugs of any I have encountered in my 10 years here.

And yes not having automatic conversions does mean you write more code
But you are writing more EXPLICIT code and that helps to reduce bugs and increase readability.
Even in the places where I cant remove the variants I always replace a line like

   dim s as string
   //   assume v is a variant

  s = v

with

  s = v.StringValue

simply because it IS explicit that I expect this thing to give me a string value so when I reread that code in 6 months (or 10 years) I know exactly what I was expecting. And I’m unlikely to mistake the intent - since I explicitly stated “StringValue”

Sigh… we are arguing in circles. Norman: you give the same old arguments again and again. Hasn’t the discussion shown you that we don’t really believe you? We still have an IDE where you can’t even do a selection properly (select a method in the IDE, hide the search panel and lose the selection, <https://xojo.com/issue/29897>). As Thom has said: deprecate date, deprecate variant. Improve the string. Just don’t force us to rewrite all our code because you were burned by some minor variant problem. And the argument with iOS: sorry that doesn’t fly for me. You were doing the same for web after all.

What does the have to do with string to text auto conversion? No ambiguity there! (if you throw an exception when the string has no encoding)… Are you sure that not being there from day one on teh desktop was not philosophical?

BTW I have never had an issue with variants…

I use them sparingly and when I do always always use the explicit getters, BUT when it makes sense I also take advantage of the conversions done by variants WHILE using the explicit getters. Quick to code that way!

Convenience matters in a RAD environment … after all the R stands for Rapid!

  • karen