No-Code and Low-Code software platforms may be the next wave of software innovation that you haven’t heard about yet. The article below from IEEE Spectrum Magazine shows just how rapidly the popularity of these platforms is growing. Per the research quoted from Gartner, “low-code application development (which also encompasses no-code) will make up more than 65 percent of application development activity by 2024, with three-quarters of large enterprises using at least four low-code development tools.”
Our team has anticipated this and has been working hard to support this trend with the development of Virtuoso for many years. Virtuoso is a framework that allows No/Low-Code platforms to be easily developed using a state of the art “Node-Based Visual Programming” environment. Think of node-based visual programming as a high-level representation of anything using configurable nodes and connections between the nodes. When used to build fully formed applications, this functions as a 4th– or 5th-Generation Language (4GL/5GL), compared to standard 3GL’s such as C# and Java.
The Virtuoso “Core Framework” provides the high-quality node-based visual programming environment out of the box, so it doesn’t need to be reinvented. It’s designed to be extended to provide the high level of abstraction to any existing 3GL IDE and toolsets. Virtuoso doesn’t seek to replace existing tools, but to extend low-code to those tools using a common framework. This is important, because some low-code platforms exclude the 3GL part of the development process, which significantly reduces flexibility and contributes to “vendor lock-in” of the low-code platform. Most low-code platforms are hosted in a runtime on the cloud, which incurs latencies and bandwidth limitations that are unacceptable for a large number of applications. The output stage of any Virtuoso low-code platform is a fully formed 3GL project which can be built and run as-is or modified in code. So even if a developer can’t find a low-code component to do what they want, they can always do it directly in the underlying 3GL.