Automate your infrastructure to build, deploy, manage, and secure applications in modern cloud, hybrid, and on-premises environments.
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.
Try Progress Kinvey
Brian Rinaldi and Mark Troester contributed to this series.
Mark Schafron is a Senior Copywriter for Progress and a business journalist, with 20+ years experience crafting messaging across topics including software development, cloud, security, big data and CAD/CAM/CAE, among others. He’s also a voice actor known for his ability to write and narrate complex technical scripts.
Subscribe to get all the news, info and tutorials you need to build better business apps and sites
You have the right to request deletion of your Personal Information at any time.
You can also ask us not to pass your Personal Information to third parties here: Do Not Sell My Info
Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.
Copyright © 2020 Progress Software Corporation and/or its subsidiaries or affiliates.All Rights Reserved.
Progress, Telerik, Ipswitch, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.