Are Developers Right to Distrust Low-Code Solutions? Part 3—Proprietary Tools

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.

Proprietary Toolsets in a Low-Code Solution—Why?

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.

What Now?

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.

The ideal low-code solution for pro developers capitalizes on common or easily-acquired skills, such as JavaScript, Typescript, CSS, Angular and Vue. While not every developer is proficient in those platforms, languages and frameworks, many are and learning resources are readily available.

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.

What’s the Key?

The key is having a low-code platform based upon a widely-used and standardized language that has a strong ecosystem of tools, libraries and learning material. We believe that language is JavaScript. JavaScript offers the ability to use a common language on both the front and backend of an application, and it has the added benefit of enabling frontend developers who are already familiar with its capabilities. For example, the developer need only think about a collection vs. having to understand the nuances of different backend data interfaces. And for organizations moving to full stack development, they can use a full stack approach leveraging JavaScript for both front and backend development.

At Progress, our long heritage of working with professional developers has led us to choose a path that lets you build consumer-scale, multichannel apps on a modern serverless cloud platform. That’s Progress Kinvey. Its JavaScript base means no re-training and no platform lock-in. The result is high productivity with no loss of developer control. We call it the best of both worlds and we think you’ll agree.

Try Progress Kinvey

Brian Rinaldi and Mark Troester contributed to this series.