As JourneyApps is nearing the launch of OXIDE, our next-generation IDE, we are exploring the “dreams versus reality” of low-code, and showing how the industry can chart a more enlightened course for software development. This is part 3 of the series. You can read part 1 here and part 2 here.
- In the first two parts of our series, we made the case that visual point-and-click / drag-and-drop app development (no-code/low-code) is great for building simple apps, but its value quickly diminishes as apps become more complex.
- We talked about how visual tools can be very valuable when applied to specific aspects of application development (such as UI design) rather than being used for every aspect of app development.
- We also made the case for why writing code is often by far the best way to solve specific problems.
In part 2 of our series, I wrote that, “Some forward-thinking app platform vendors are finding ways to combine code-centric development with visual tools. Yet there are many different approaches to this problem, and some of these approaches have serious drawbacks too. We will explore these different approaches and their pros and cons in the next part of our series.”
This is where the rubber hits the road. Where theory turns into practical reality. Let’s drive straight in.
High-Productivity App Development Using Code: The Good, The Bad and The Ugly.
Several app platform vendors have attempted to solve the problem of combining visual app development with writing code. Here are a few examples:
- LANSA with its Visual LANSA “language-based low-code solution”
- OutSystems and Mendix with their pro-code extensibility
- Ionic with their upcoming “Ionic X” product
To be able to compare the merits of the various approaches of these vendors, we need to look critically at key aspects of how their products work. Here are the 10 most important questions that you should ask:
1. Is code a first-class citizen or an afterthought behind visual tooling?
One thing that quickly separates the wheat from the chaff with these platforms is whether code can be used as the primary mechanism for building apps in the platform, or whether the primary mechanism is always visual development (and code is a second-class add-on relative to the visual tooling).
Earlier this year, I was talking to an accomplished Silicon Valley CTO about his experience of helping to build a niche digital process automation (DPA) product. He made a very interesting observation:
“Many platforms claim that they cater to both professional developers and citizen developers. In other words, you can build stuff either by drawing bubbles or by writing code. They claim they do both well. But the reality is that one is always favored over the other. One is prioritized and the other is the stepchild. We found the same thing when we built our product. We spent way too much time on the citizen developer experience.”
We heard the same thing from a Director of Technology at one of our oil & gas customers, who participated in the early access program of OXIDE after doing an in-depth evaluation of the most well-known low-code platforms on the market:
“I’ve used other low-code platforms, and it seems they put much more emphasis on the no-code part of their products than the low-code part — so when you’re using their visual editing tools, your hands feel tied in terms of what you can do. And then when you get to the code part, it is just so overly complex that it stands in stark contrast to the visual editing.”
When a high-productivity app development platform allows you to use code as the primary mechanism for building apps, and development productivity has been streamlined around writing code, this is a good sign if you’re planning on building ambitious and sophisticated apps. When code is an afterthought that was added on top of a primary visual drag-and-drop low-code tool, it generally tends to perform much more poorly. It’s often very complex and convoluted, and switching to code means that your development velocity often slows down dramatically. Caveat emptor.
- Image: hillarylane.ca
2. What is the skill level required to build apps on the platform using code?
The complexity of the coding required by an app development platform is directly correlated with the level of skill and experience that your developers will require in order to use the platform effectively.
Some platforms allow you to build custom business logic using relatively straight-forward JavaScript. Others require much more onerous and complex Java or C# code.
If we look at the major low-code platforms that offer “pro-code extensibility”, the code that developers have to write tends to be very complex and requires expertise in compiled languages such as Java and C# that are typically used in enterprise software environments.
This typically translates to hiring senior developers who are familiar with these languages — which means that you often spend more money on staff, and have to beat out your competitors in hiring scarce developer talent.
3. What is the learning curve for the platform?
- Image: Darius Foroux/dariusforoux.com
Platforms that are based primarily on visual development tools tend to be highly proprietary. Even if they offer pro-code extensibility, the bindings, APIs, and patterns that need to be used in the code also tend to be highly proprietary.
Complex proprietary environments such as these typically translate to a long learning curve. What we often hear from developers is that they had to spend a lot of time learning their way around all the ins and outs of the major low-code platforms before they can become productive with them. There’s a substantial and expensive learning curve.
4. Is coding on the platform based on a popular, open language?
According to GitHub’s annual “State of the Octoverse” report, JavaScript is the most popular programming language in the world. Therefore it’s no surprise that the best code-centric app development platforms allow developers to use JavaScript as the primary programming language.
TypeScript is a statically typed version of JavaScript, and is one of the fastest-growing languages in the world, with strong advantages over plain JavaScript. That is why you should also pay attention to app platform vendors that are starting to support TypeScript.
The use of a popular open language translates directly to readily available talent that you can recruit.
We recently spoke to a Principal Analyst at a top analyst firm who specializes in low-code platforms, who told us:
“The most prevalent developers are JavaScript developers. If you can allow a company to get these readily available developers and get them up to speed rapidly on your platform, that is a very attractive value proposition.”
By contrast, some code-centric app development platforms require developers to use proprietary languages such as 4GLs to develop apps. Visual LANSA, for example, requires developers to use its RDML language.
5. Can you make use of open source libraries, or are you stuck in a walled garden?
- Image: “The walled garden of Edzell Castle” by Jonathan Oldenbuck is licensed under CC BY-SA 3.0
Not only should you look for platforms that allow the use of open and popular mainstream programming languages — you should also determine whether these platforms allow you to use open source libraries to build your apps.
If the platform allows you to use any JavaScript library of your choice — that’s a big win for extensibility and innovation. It allows you to draw upon a huge wealth of already-built software components.
For example, NPM is the package repository for the Node.js JavaScript framework — and it’s the largest software package registry in the world, with more than a million open-source software packages.
By contrast, some low-code app platforms don’t allow you to use any of your own software libraries, because of their proprietary nature. Some of the big low-code platform vendors offer their own “app stores” where you can get widgets and components from a closed community. This can often mean that your innovation is at the mercy of the vendor and its closed community.
6. Developer productivity: What kind of headcount do you need?
If you’re going to be writing code in a high-productivity app development platform, one of the key questions is: How much leverage is the platform giving you?
How many lines of code will you have to write to accomplish a certain task?
Many low-code platforms that are extensible with code leave a massive amount of heavy lifting to the developer. The developer often has to write thousands of lines of code to implement certain kinds of functionality.
By contrast, the leading code-centric high-productivity platforms provide a huge amount of leverage (through abstraction and built-in functionality) and enable developers to build sophisticated apps with advanced functionality, with an order of magnitude fewer lines of code.
The bottom line is this: If developer productivity and output is lower, you will need a larger team (and therefore a more expensive team) to develop the same number of apps.
A common example that we’ve seen is data synchronization. OutSystems provides some tooling for offline data sync, but the developer has to do much of the heavy lifting themselves — writing their own sync logic. With Ionic, developers also have to write their own SQLite queries to implement offline functionality. Requiring developers to do this pro-code level coding to implement this kind of functionality means that you need a larger headcount of more expensive senior developers. It also means that projects take more time, and there is more technical risk involved.
7. Is the platform a true full stack, or do you need to build your own full stack?
Many of the major app development platforms on the market do not provide a true full stack. With most of them, you have to bring your own database. Many do not even provide a cloud backend at all.
This means a much higher total cost of ownership (TCO) since you have to wire together and maintain the full stack yourself. There is also more technical risk in putting together your own stack: There is a bigger probability of getting certain things wrong (and small mistakes can have big consequences), especially since building a full stack is such a complex endeavor.
8. How badly are you locked in to the vendor?
- Image: MikeDotta/Shutterstock.com
Vendor lock-in is a major drawback of many low-code platforms.
In many cases, the platforms have no portability — you either can’t export your code out of the platform, or the code which you’re able to export is virtually unusable.
Consider Microsoft PowerApps — exporting your code results in a massive JSON file that is hardly human-readable. It can easily be 40MB in size.
9. Are developers excited about using the platform?
This is an overarching consideration that is incredibly important, and it’s exactly where a low-code platform can become more of a liability than an asset: Professional software engineers tend to loathe low-code platforms. As the folks behind the open-source framework Ionic put it: “Low-code presents a fundamental threat to your relationship with your developers”.
There are several reasons behind this tendency.
- As we have seen above, many low-code platforms tend to force developers to work within a constrained proprietary framework – which can be very frustrating to them.
- Many low-code platforms do not allow developers to leverage the major innovations in software tooling. For example, they can’t use their distributed version control system like Git to manage their code.
- Professional software engineers tend to think that low-code platforms put their expertise and experience to waste, and do not help them improve their marketable skills to advance their careers.
In a recent eWeekChat held by the tech publication eWeek on the topic of no-code and low-code development, Jason Bloomberg, President of the analyst firm Intellyx, remarked that “many hand-coders still scoff at the whole idea [of low-code]”. In the same discussion, Mike Hughes, Senior Director of Product Marketing at the low-code vendor OutSystems, remarked: “We just don’t get many devs who are excited to call themselves low-coders”.
In the previous year’s edition of the same eWeekChat, Sumit Sarkar, Director of Product Marketing and Developer Relations at Progress Software, mentioned that he “surveyed over 5,000 developers to get their sentiment about [low-code] platforms, and over 60% were negative”
There is certainly a risk that talented software engineers could leave your company in favor of more rewarding opportunities if they are forced to work with proprietary low-code tools.
By contrast, high-productivity app platforms that are based on popular open languages and allow developers to use open source packages, are much more attractive to developers.
10. How much does the platform reduce your risk?
This is our final overarching consideration. Many of the above points that we’ve made come down to risk.
- Higher costs introduce more risk.
- Reliance on hiring scarce developer talent introduces more risk.
- Reliance on proprietary closed-system technologies introduces more risk, because of vendor lock-in.
- Requiring hand-coding of functionality like offline data sync introduces more technical implementation risk.
When you’re evaluating app development platforms and are thinking through all the above questions, we encourage you to analyze what it means for your overall risk profile. You may be surprised at how much risk you’re willing to take on if you accept many of the unpleasant trade-offs of low-code platforms.
Where do we go from here?
In the next installment of our series, we will look at how JourneyApps has created a unique paradigm amongst app development platforms — one that has taken all of the above considerations to heart as key tenets of the platform’s design, architecture, and overall philosophy.
