Excellent post Karen. I think you hit the nuts and bolts of the issue.
The problem in my world view is if you leave the “rapid application development” model for something more computer science/engineer friendly you have to compete with more mainstream languages to which most of them are open source and free.
Yes, it’s crazy. 5 years? it’s tomorrow… We can not redo projects that each contain tens of thousands of lines of code, be serious.
I can’t believe this.
it’s not that simple, web projects are based on the classic Xojo’s web server and the classic framework requests. What will happen when the classic framework is deprecated, and web browsers will no longer accept 1.0 or 1.1 HTTP requests? Or that new security standards, hash, or new types of SSL will be mandatory or else be relegated to the bottom of the web with an “unreliable” label?
I hope that before it is abandoned, the classic framework will receive the necessary improvements (http 2.0, security, etc.) so that it can be used effectively for many more years. It’s not like the xojo web framework was ahead, we still use HTTP 1.0 requests in the web framework, a protocol that dates from the late 90s.
Of course Xojo must evolve and we must use the new technologies proposed by Xojo, but please do whatever it takes to keep the current projects sustainable!
Your comment is plain wrong: Norman has stated several times at least 10 years. And then it would be deprecated, not removed, which means another 5 to nn years. So it is not tomorrow at all.
I guess the old framework will survive as long as Xojo survives. As it’s in maintenance mode, no new features will be added. However that may be said, it looks like the new framework is also in maintenance mode, i’ve not seen it change much while it should be.
Even if it’s 10 years, but as of this year, there will never be any improvement of the classic web server that powers the whole web framework, it’s serious. For the web framework, we are entirely dependent on Xojo’s internal classic web server.
For the rest of the development, we’ll make arrangements, we can also use an old version of Xojo, as Wayne says. But for the web framework, it’s different, we’ve been waiting for years for an improvement of its internal web server (currently HTTP 1.0), and I have the impression, but I can be mistaken, that there will be no more improvements for the classic framework and the classic web server. So, as of today, for all our big projects that have been developed for several years, we’re stuck with a web 1.0 engine dating back to 1996. I hope I’m wrong.
Hopefully indeed Xojo has planned some upgrade to Xojo Web so it supports http 1.1.
As for now, I had to use Xojo.Net.httpSocket to post back in the required http 1.1 to Paypal server. It would have been mighty simpler is the web framework did support 1.1 natively.
And based on an impression, you panic about what will happen in 10 years or so…
The problem is not in 10 years. From what I understand, as of today, the classical framework is in maintenance mode, while we’ve been waiting a long time for an improvement of the web server. There is no panic, but a need for legibility in the medium term. You have a big commercial project developed with the web framework? Do you have employees who depend on it? This is my last answer to that thread.
Eli, that was probably the misquote of the year. Did you read ANYTHING of what he wrote?
Yes.
IMHO Olivier is mixing up the situation of the web framework we developers are using with the internals of the framework of the Web App.
And in addition if he developed big applications under wrong assumptions he made, then it is his fault, not Xojos. When you start a project, you need to work with what you got. We all now how Xojo Inc “works”…
Whoa, where did that come from? The internal workings of the web framework have nothing to do with this discussion.
As far as this discussion goes… for all of you that are nervous about the classic framework going away when it has been deprecated, dont be. The IDE itself was written in Xojo using the Classic framework and removing it would cause the IDE to not work either.
[quote=358867:@Greg O’Lone]Whoa, where did that come from? The internal workings of the web framework have nothing to do with this discussion.
As far as this discussion goes… for all of you that are nervous about the classic framework going away when it has been deprecated, dont be. [/quote]
People aren’t nervous about it going away, they are already nervous about it NOT BEING UPDATED and being stuck with old technologies while the new framework is still not usable.
I don’t use Web edition, but if it is using the old framework that would mean HTTP 1.0 which should not be used anymore. Maybe some clarification is in order here.
I suspect theres an assumption being made about how the http server in the web framework is implemented. While it does use ServerSocket, It does not use the built-in HTTPSocket, so we are not tied to its limitations.
I have classic desktop apps that use the HTTPSocket for desktop apps to pull info from web services… and desktop OSes change too in ways that require more than maintenance to stay relevant…
Why? It is still a valid protocol.
[quote=358729:@Norman Palardy]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]
[quote=358731:@Karen Atkocius]…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.[/quote]
Thanks for the replies to all, not just the two I quoted above. For now, I think I’ll follow the advice of the two above and just use the New Framework when needed, or when easier to use than the Classic Framework, for now.
However, I do like the syntax of the New Framework, as it more successfully pushes me into thinking in terms of OOP, something I was not doing until I dove into Xojo the last couple years.
How so specifically? Do you mean using the “dot” notation extensively?
When I first started with REALBasic about 17 years ago, I was aware that OOP existed but I had never used it despite having used a number of languages… but I was able to pick it up OK…
The key ideas it seems to me are encapsulation/information hiding by the use of classes, the whole subclassing/inheritance thing and using an event driven model where it is appropriate…
To use the classic framework most effectively, one needs to understand those things, and RB always provided an easy way to lean them (unlike C++!!!) and the old framework did that pretty well for me!
There is no difference between the two frameworks in regard of OOP or forcing the developer in thinking more in terms of OOP.
Which almost nobody does (public properties, public setters, etc.).
Overrated. The only situation where it is necessary in Xojo is for subclassing UI elements and Sockets and the like.
Not related to OOP per se.
About event driven…
[quote=358910:@Eli Ott]
Not related to OOP per se.[/quote]
Well the way i look at it is that responding to events is essentially message passing, which is how OOP was described to me before I learned to use it.
But in any case I agree the both frameworks are equally OOP…
OOP is not best for all situations and neither framework forces one to use OOP for everything… Which is a good thing IMO
Event driven programming means, that the “outside” world can interrupt the program flow (user interactions, threads, timers, sockets, etc.).