In this article, the writer described good points for me.
Paul described XOJO as a small tool. Maybe I do not understand well because I do not have English as my native language or advanced knowledge.
If I worked in a big company, I would use XOJO. But I would not limit myself and my goals to the mentioned list. The prototypes, tests, and demos are small developments.
What do you think?
If you worked in a large company, the IT department would tell you that you cannot use Xojo for production. You have to use C# or XCode or Visual Studio or whatever big name language/environment is popular. You would be allowed to use Xojo for prototyping and demos. Thatâs the corporate culture in the US. That was Paulâs point. It would be awesome if big companies embraced Xojo based on its capabilities, but they tend to be blinded by the big names.
Well, The real MS product is the .Net and VS for Mac is not the only IDE for .Net and arguably not the better either. MS is porting efforts to VS Code (FREE) so users will have OPTIONS to keep their current work, just in another IDE so at best, acusing a big name (MS) for âabandoningâ VS MAC is missleading.
The las version was VS 2022⊠It had more than a YEAR of fixes and improvements and now that MS annouced the retirement, they offered ANOTHER extra 12 months of extended support with updates for security issues and updated platforms from Apple.
Another tool the blog mentions is VB clasic, but when MS âkilledâ VB, they offered 10 YEARS of extended support, with bug fixes and security updates. (Lets exclude the 25+ years of the runtime support)
Compare that with the ZERO support offered by xojo when Web1 was killed, without noticeâŠ
So, based on the facts around the tools mentioned in that post, it is a LOT safer to buy from a big name.
Big companies requiere some degree of trust in the tool, When they buy from a big name, they have a written Support Statement that acts like a WARANTY of their invest in the tool. (10 years for VB6, or those 2+ years for VS MAC for example).
Unfortunatelly, the ârapid releaseâ model that xojo adopted, offers ZERO extended Support for any release. That is an instant NO for most companies. The lack of a Final/stable version that has a warranty of bug fixes is a risk that not many big companies want to embrace.
Web 1 to Web 2 was a struggle, but not that unusual. .net 1.1 to 2 had the same issues & server support ended for .net 1.1 with 2012 although we did manage to keep it working on 2012R2 which has now ended life.
Web 1 was an awesome product, but would I do away with Web Charts to keep using it? Not likely. Would I continue to require native Web controls? Again, not likely.
Every project Iâm working on Iâm looking to innovate. It is either Innovate or Stagnate. I prefer innovate.
I feel kind of sad for those who donât have the ability to keep up with innovative technology.
I donât think anyone can disprove that âWeb1 to Web2â doesnât exist, since you need to ENTIRELY redo the UI and change lots and lots of other things.
besides, to have a decent version of Web2 (since the first release in 2020) has been a long time coming.
And we all know that bug fixing is not keeping up with releases.
so, those who have been (or are still) forced to stay with Web1 risk so much, in case something suddenly breaks irreparably, due to browser upgrades, etc.
Iâm sorry to say this, but I think the whole thing is very very very dangerous.
This was why I first came to Xojo in about 2017. My app was originally done in javascript communicating to PHP scripts via AJAX. The PHP scripts did the backend stuff and the JS presented to the user, in a browser window. Due to these browser changes I converted entirely to a Desktop app in Xojo.
I am one of those who donât have the time to keep up with innovative technology. My typical work-week is between 60-85 hours performing regular work, and then to spend an additional 20-40 hours a week doesnât allow for much time to keep up with other innovative technology.
Since time is a valuable commodity, reworking existing technology seems to be a low priority. I agree with your comment, and it appears there are exceptions.
All the best.
80h?? dividing by 6 days equals 13h per day.
???
Yes, that number is a little low. I work in the Oil and Gas sector. My last tour was 6 weeks straight (42 days) and 16-23 hours per day. When spending millions of dollars in a short time-frame, sleep is a luxury. When business is âslowâ its about 13 hours per day.
I hope for you that you are happy. Let that be a goal in your life.
This puts food on the table for my family, and keeps the electricity flowing for people in my country. It is rewarding.
So if you find gratification, good for you. There are various ways to put food on the family table. Then everyone finds their passions gratifying, which are different from person to person. I would NEVER work that many hours, it would be surviving, not living. (itâs just my personal opinion, far from me to make judgments about your life and your choices)
For me, it is dangerous to work so many hours from a professional point of view.
That is the way to stop keeping up or get out of date.
But the greater the risk, the greater the payment.
I want to keep this post on topic, although I enjoy your comments. Purchasing from a big-name company is usually the professional path. If I can trust that software/hardware can work when going to mission-critical places - such as the moon, then its good for my critical work.
When I am near the end of a long shift, I donât want to question the software that I am using, or programming. The software/hardware MUST work.
Removing bugs, having a consistent base programming language, a great help-system, and for a good price-point, are all positive factors in choosing a programming language.
âobsoleteâ in what sense?
I mean training and updating in new technology.
Large companies insist on using a single tool, which may be out of the market.
For example, those who have always programmed in COBOL now find that most companies no longer use it. Fortunately, it is a very well-paid niche.
Youâre right.
I recently decided to use a tool to create robots as software because the others were not running consistently. The others have a much better environment to design robots or to generate processes in a few steps.
The competition is better in that aspect. But those tools make mistakes when running the process, and I discarded them.
Itâs sad.
Just my personal experience: I started writing an app over 20 years ago using RealBasic 5.5.5. At that time I was using a 32-bit PowerPC G4 Mac. A lot of the code I wrote back then is still running unchanged in that app which I continue to sell to this day. But now that app is 64 bit, runs on not only Mac but Windows and Linux⊠under Apple Silicon, Intel or ARM processors.
When I look back there is no question I made the right decision to go with RB⊠many of my other options would have meant starting all over at least once if not several times.