Part 2 of this series looked at low-code solutions in the context of their architectures—antiquated, monolithic, and unfriendly to application deployment. In Part 3, we examine proprietary toolsets vs. standards-based tools and their contrasting effect on the application development process.
A plus of having proprietary tools bundled into a low-code solution is alignment of the tools and hopefully the platform, since they come from the same vending source. In theory, this should benefit developers and ultimately the business. However, the realities of proprietary tools include steep learning curves, vendor lock-in and an ecosystem of code samples, tutorials and community applicable only to that vendor—all of which could be spotty or non-existent.
Another caution would be that just because a platform vendor promotes their use of standard languages, that doesn’t mean they don’t have a proprietary development process.
Besides the expense and time involved in learning and integrating niche skills, seasoned developers will likely resist transition to a vendor’s proprietary tools. Proprietary code can be tough to debug with fewer resources available to find examples and address issues. It also separates developers from mainstream development communities and isn’t impressive on a resumé.
With a view now focused by the inflexibility and risk, it’s clear there’s really nothing to recommend proprietary tools.
Developers need transparency. Any low-code solution should be one where developers have full access to all source code, and they need to be able to fully see the implementation.
Keeping the entire development environment in mind—lifecycle and tool chain—compare your existing tools and skillsets with what you’re considering for a solution, so you don’t end up with an inflexible silo.
They should also have access to a wide array of open source components in common repositories, so they aren’t restricted to proprietary components designed for a single platform. They also need the option of using different frontend SDKs so they can support different project efforts with a common platform.
Brian Rinaldi and Mark Troester contributed to this series.
Mark Schafron was a Senior Copywriter for Progress.
Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.Learn More
Subscribe to get all the news, info and tutorials you need to build better business apps and sites
You can also ask us not to share your Personal Information to third parties here: Do Not Sell or Share My Info
We see that you have already chosen to receive marketing materials from us. If you wish to change this at any time you may do so by clicking here.
Thank you for your continued interest in Progress. Based on either your previous activity on our websites or our ongoing relationship, we will keep you updated on our products, solutions, services, company news and events. If you decide that you want to be removed from our mailing lists at any time, you can change your contact preferences by clicking here.