In the NetSuite webinar today Tim Dietrich described Xojo as being “Low Code”…
is it generally considered to be that?
BTW Why I am listing to the webinar, is because while the webinar was live, I was in a meeting at work going over a NetSuite Demo because we are considering it for an ERP.
-Karen
I wouldn’t say it is
Not like FM, or Bubble or some other “low code” tools
That is what i thought.
-Karen
This is a marketing term excessively used in Filemaker world. They call it low code even when Java scripting is involved 
Describing Xojo as low Code makes it simple to see: it is not a High-Level programming language but a Low Code tool with major limitations in it’s abilities. In this case I would say: yes, Xojo has good functionality. For a Low Code System. But it is not a real professional programming language. It is a low Code TOOL. Under this circumstances I would say: yep. But it isn’t a professional System for Software Development. It is a Low Code Tool for simple projects which are not in the need of the full-fledged functionality of a professional language. There is no need for nothing anymore. Totally described how Xojo looks on itself.
No, Xojo was more a RAD (rapid application development tool). You have to code a lot esp. when you really want to go crossplatform. Modern low-code enviroments are mostly web.based where you’re clicking around with processes and dialogs. We’ve had a thread recently here:
We know that but we did not had the idea that it is low code.
“poor code” is perhaps the strategic evolution after the “low code” buzz. Let’s stay calm and relaxed, the next XDC keynote is around the corner 
.
Low / No Code is just the latest in a long line of (often recycled) fads. It produces clickbait articles with titles like “developers had better get ready to be replaced”. Similar to the ChatGPT craze.
All that a true low code / no code tool produces is something that IT professionals have to maintain or integrate or make safe or fix bugs in or use as a template for a real solution. It can be a boon for small companies / departments that need to bang out CRUD apps or something, where they need something to get started. But even that will have to be re-done when they reach a certain level of maturity, most likely.
So it doesn’t perturb me that Xojo isn’t low-code per se, rather it is that they are making another false claim via cynical use of a buzzword to entice new customers who will surely be disappointed.
Salesforce is a good example for low code. Even if you can program in sf, it offers end users the opportunity to automate workflows first, e.g. a human resources department could create forms, checklists for onboarding, and then create their own reports, etc. all via drag&drop. These can be automated, sent to employees one after the other, or the MA get them displayed in the browser.
As soon as they want more (always) the programmer will come again anyway ;-). But this developer will already have a starting point at least.
IMHO The good low code solutions are currently available on top of excellent business solutions (SAP, SF, ORACLE, etc.), or as standalone solutions on top of interface hubs (which a developer has preconfigured). And some solutions concentrate on AI-supported reports on big data etc.
Except for false promises to new customers, I don’t know why and how Xojo should go low code. That would only work with API0 and with embedded interfaces to the well known cloud service providers or on-prem business solutions.
According to Gartner Low-Code is defined as:
Low code is the evolution of RAD to cloud and SaaS models. Notes: Gartner defines a no-code application platform as an LCAP that only requires text entry for formulae or simple expressions. The LCAP market, therefore, includes no-code platforms.
And they predict (no surprise here either) a growth in this market:
Gartner predicts that by 2026, developers outside formal IT departments will account for at least 80% of the user base for low-code development tools, up from 60% in 2021.
But this is a market segment (business, cloud) which I am not aware of to be Xojo’s targeted audience.
An Enterprise Low-Code Application Platform is an application platform that is used to rapidly develop and deploy custom applications by abstracting and minimizing or replacing the coding needed in development. At a minimum, an LCAP must include: Low-code capabilities (such as a model-driven or graphical programming approach with scripting) to develop a complete application; Support for developing applications consisting of user interfaces, business logic, workflow and data services; Simplified application test, deployment and management.
But there is hope, there is still enough white space left for Xojo to make a difference
Sure. I have gradually migrated a lot of my code base to a table-driven rule engine that trained employees (maybe $25/hr kinda folks rather than $125/hr) can maintain the system by entering match and transform criteria. That is, depending on your definition, low code or no code. But it still required a dev to design and build and maintain the engine.
I think every major application system should look for ways to make things user-configurable to the fullest possible extent, even if the definition of “user” isn’t “any old yokel in the accounting department”. Even if some training or domain expertise is required, at least everything isn’t dependent on scarce and expensive developer resources.
Low code platforms need a carefully designed minimum viable product (mvp) definition and a complete implementation of the latter. The number of bugs and functional omissions must be very low. Lengthy workarounds shatter any attempt of running a project as ‘low code’. Functional and stable database connectors are part of the mvp. Field experts who do low coding do not have the time nor the expertise to code around bugs and missing essentials.
I must say that in many aspects even FileMaker outperforms Xojo easily.
Fully agree, and well spotted. Low code rarely (aka never) means low training cost 
I agree. Solutions like Filemaker (w/o knowing much of it than their homepage) seems to be much closer to Low-Code in this aspect.
Talking about the large ERP systems, extern low code solutions would not even be able to connect directly to the underlying database. Those systems need to use the well documented APIs and that connection is done by specialists and ultimately a non-technology-savwy subject matter specialist has a graphical drag&drop playground to either create reports, workflows, forms, etc.
When Xojo talks about low code as a coding tool, it’s either dubious marketing or they want to go there first, but then a tool would have to be created that has nothing whatsoever to do with today’s Xojo.
But I’m sure I didn’t understand anything and that a stable genius would explain it all to us on the XDC or on the phone. That’s the problem, if you just want to say stupid stuff, then there are good reasons to only do it verbally, even I understand that part
FileMaker rocks at making development possible for almost ANYONE up to Pros. It’s “pretty darn good” except for the pricing.
Xojo missed out on this. The key is to make high level AND low level function(laity). Just look at how goofy Xojo Date Intervals are. In FM you just add integers to a date and the date will change. Easy peasy.
Just one example…
And don’t get me started about how with FileMaker most devs NEVER write SQL.
That’s definitely the case. Here’s a real world example:
Last year I started development of a CRM for a language school. It was scheduled for implementation in Xojo. In November I binned the Xojo code because it would have taken several months to iron out all the things that do not work as documented and that are missing. I also completely lost confidence in Xojo Inc’s ability to get the bug fiasco under control before this decade ends.
So Xojo was binned and I started again in FileMaker. After 8 weeks the CRM rolled out. Time was of the essence and this and budget called for a true low code solution.
As you stated, the low code solution will have to be replaced in the future by a different solution, because of the known limitations of the selected platform. The new one will be done in Swift.
Conclusion:
Compared to FileMaker, Xojo is to buggy and takes to much time for coding.
Compared to Swift and SwiftUI, Xojo is incomplete and has many constraints.
and that’s the general problem as a developer in Xojo.
What I can not understand is that, if you consider to write a CRM in Xojo, why not writing it in C# or in Java? And instead of it you used filemaker what makes it on both sides more expensive: the programmer which needs a license and the user. So I can’t understand this decisions, don’t get me wrong but wouldn’t it be faster to write a Solution in Java instead of Xojo and having to pay no license fees to anybody and having a rock solid and bug free situation?
My last exposure to FileBreaker was back in about 2001 or so. I assume it has progressed a lot since then? ISTR a very limited / quirky proprietary scripting language, only writable from within a rather crude editor within the product.
