The promise of low-code development has long been the ability to develop business-critical applications by humans with little programming experience. In fact, over the past year or two, the lines between low-code and no-code have become increasingly blurred. Low-code platforms have incorporated more and more functional no-code features to increase the efficiency of the developer even further. Some of these platforms have become so intuitive to use, the idea that anyone can create an app has evolved into the idea of citizen developers. But is low-code really the be-all and end-all when it comes to app development? Seems the answer to that is, “It depends.”
It has become glaringly obvious that exclusively no-code platforms can’t create complex applications. But then again, these platforms were never really designed with that kind of functionality in mind. No-code can be a highly valuable, rapid prototyping tool as well as a decent tool for very small, very specific apps. These apps would be best suited for intradepartmental use or to extend the functionality of very specific SaaS tools. No-code is not going to power your business-critical applications, and a not-quite-a-developer is not going to lighten your IT load.
But what about low-code? Can low-code be the bridge between citizen developers and the ever-growing list of backlogged apps? Maybe. Using citizen developers comes with a whole heap of issues that need to be addressed. While this topic can be the subject of an entire blog in its own right, I can quickly highlight the major issues to consider. How much of a citizen developer’s time should be dedicated to app development? Is using citizen developers going to create backlog issues in their primary departments? Who is going to train and support citizen developers? How is IT ensuring that citizen developer-created apps are secure, scalable and extendable? As great as citizen developers sound, they still are not a definitive solution.
A realization has dawned in the low-code industry. Low-code can’t be and do everything, but it can be a useful development tool to speed up application development. However, most low-code platforms are in their own development silos, separated from other development tools with their own IDEs. Instead, one idea is to create a quick and easy-to-use user interface, drag and drop some app functionality, and then finish complex apps in a language the low-code platform can integrate with, such as Java, or via a Visual Studio plug-in. Even the biggest and best low-code vendors admit that just using low-code isn’t going to power your business.
Low-code can’t be everything, but it can be a major part of everything. It just needs to look different from how most low-code platforms are designed. Using a hybrid low-code approach will allow organizations to truly use low-code from start to finish in the app development process. Rather than looking at low-code as a separate tool in the development process, a hybrid low-code approach brings low-code inside an IDE where traditional coding methods are still used.
Is hybrid low-code the future of app development? I would say hybrid low-code is a next step in the evolution of app development. Low-code development tools shouldn’t be isolated in their own IDEs. It can be frustrating to leave a low-code IDE to finish the app in another IDE, and then have to connect the different elements into one cohesive app. As you can see, efficiency is reduced every time a developer leaves one IDE for another. Hybrid low-code views low-code as a tool inside a bigger development toolbox. It is there when convenient, but a developer isn’t forced to use just low-code. They can import already created assets from other languages, hand-code complex solutions, drag-and-drop when it makes sense, and create all the necessary components of a progressive web app with a click of a button.
While there might be a profound realization that “traditional” low-code can’t do everything it originally promised, hybrid low-code could, instead, fulfill that promise.