@Thom_McGrath you are Right. This I could not know. Cause in this case it is impossible to simply switch.
Sounds also like a big pile of word. But in this case I do not even understand why Web 1.0 could not be modificated like for example our Eros kernel and the rtos GCc build. But okay, that’s not my business to decide.
For me it is a loss of functionality with a 3.2 which is not stable and not maintained anymore. Maybe you have another View on it I will not say anything against. But for me it is a loose of the ability to rewrite. Whenever and where ever I got informations about getting things to run we had to test and mostly find out that we do not have what we need with it.
I can understand that Xojo provides most simple functionality for the citizen users. But I can not understand why Xojo is punishing existing pro users with this loss of power. And yes, there are ways to Programm it with hours of work. But this exactly hits the sense of using Xojo: be able to write fast and reliable. So if I have the same amount of work I can write mouth more comfortable in other languages. Why buy Xojo for stuffs I can do as fast and comfortable in other languages.
The Pointing on Web 2.0 would not be this big if it would not be shown as the future with less comfort. If somebody can reach the same target he will not be interested in buying Xojo.
When I bought it I had the target to get my customers also to buy pro licenses and being able to write small changes and maintenance code byself. Now it is running out of control cause they can not build their Solutions with Web 2.0. not now and not in the future. This makes a big difference.
Users don’t like namespaces because the bugs with them were never fixed.
Its hard to like something when things like code autocomplete stops working when you use namespace. And even the hoovering over method to see the syntax can stop working as well.
While I don’t doubt that’s true, what we heard more often was that namespaces made the language feel more complicated, less friendly and inviting. That was the primary reason we decided to move away from them.
The web changes pretty rapidly. I remember desperately wanting to use WebSockets to handle out communication in each direction, but it just wasn’t ready yet. That’s just an example. Web edition is already 10 years old, and techniques have changed a TON since its original design. If I were doing WE now, or working on Web 3.0, I’d probably carry nothing over. These days we have LLVM and progressive web apps are a thing. I’d have your web app running entirely in the browser, except for a few server-side features. LLVM, with the right setup, could convert your Xojo code into JavaScript so your button action event would actually run on the browser. Of course, I’m glossing over a TON of details, but this is the general idea I’d approach. The point is, that shift in where the code runs means I can’t just assume old projects would function the same. That’s why I’d leave old projects behind, because I’d need the developer (you) to work with your code to ensure it works how you expect. I imagine it’s similar with this transition. They’ve migrated what they can be certain about, but other things require your intervention.
I understand functionality is missing with 2.0. It’s unfortunate, but it sounds like most of that will be addressed. But they had to get something released. They were approaching a year without an update. That’s a really big deal, and tells me the project turned out to be more trouble than expected.
Give them time. I know these guys. I’ve worked with them. They’re trying to get those gaps filled in, but they had hard decisions to make and they made them. This release didn’t go as planned, but they’ll work hard to catch it up.
In my opinion the “new framework” (with the namespacing) was more like it was incomplete and slower (used text) for desktop. On ios it was usable but slim, in our ios apps over 40% or even more is declares or extention functions on desktop targets way more could be done in native xojo code (without the “new framework”.
It’s true that namespacing makes things different, but “using …” is available so that overcomes this problem pretty simply. (Or the option in ios “simple references”)
I bet we and xojo prefere a framework that can last, and if that’s api2.0 then that’s ok. We all require some more functionality for web 2.0 i’m progressing in some projects using this already notice some problems, not really major but these should not have a problem at all. Problems are to be soved so…
I said most of that will be addressed. Not all of it. If Geoff has said something won’t be coming back, that’s what you should believe. Find a different solution, don’t wait for a train that isn’t coming.
I’ve patient for years. I’m not patient anymore. Something needs to change at Xojo if Xojo wants to keep developers around. Xojo just isn’t reliable. That is what needs to be addressed.
This is the key point that Thorsten made when he started this thread.
Fine, but they need to support users on Web 1 who are stuck there without a viable replacement. Fixes for the IDE should be back ported. There’s really no excuse not to do at least that much IMHO.
Exactly but nobody at Xojo seams to be interested cause they have to be patient to answer in the wise they are doing. Maybe reliability isn’t important, okay. Than it will be like it will be. If they find the connection between its okay. I know exactly what it means to write a compiler and also the needed IDE. And I beleave that there is a way out and the needed time to figure out Web 2.0. but the company byself has to move for it. As developer or in my position as a software company witch uses Xojo as companion it is complex cause we can not do anything then wait and complain
Sorry, but I’m not getting that because both Web1 and Web2 would exist in the framework at the same time makes it impossible for them to coexist and just use a switch.
“Xojo code” is simply text that is being translated into computer code. And the “translator” can choose to translate the same code into different things.
So subclass the classes that need it, add _API1 or _API2 to the name, and modify the code for each framework accordingly.
If you have a switch set then translate that text calling for a class of type cFoo into API1 compliant code (return cFoo_API1), otherwise into API2 compliant code (return cFoo_API2). Basically what computed properties do.
The user wouldn’t have to see any of that, he just sets a switch (like for Mac or Windows target)
Under the hood it becomes slightly more involved (and might need a pre-compiler?), but impossible?
Isn’t it more the case that Web1 and Web2 aren’t treated as separate targets like Mac and Windows?
But feel free to tell me that I have no clue what I’m talking about
They can (and as far as I know DO) use namespaces under the hood. Which is why I’m not buying it.
The problem with namespaces for most users is that you really need to know the language to use them. If you don’t know which namespace a function belongs to then how do you write the code? THAT’S why users rebelled against it.
Other languages have a MUCH larger vocabulary than Xojo - Xojo’s vocabulary is quite small and compact in comparison. That’s why Xojo users don’t NEED to use namespaces.
The argument that third party developers NEED them was always a strawman’s argument as evidenced by Monkeybread who just add MBS to their function names.
