We've reviewed several no/low-code tools in the Console Newsletter: Appsmith, Retool, Budibase, Pipedream, Wayscript. Each has their strengths and weaknesses, but they are all good products (otherwise we wouldn't have included them!)

But if it's called no (or low) code, why is it a developer tool?

This was my first reaction when I started exploring the category. Surely developers want to be coding interfaces, parsing JSON API responses, and constructing SQL queries for their datastores?

Yes, but only where that is a good use of developer time. Often there are critical internal apps that ensure the smooth running of the business, but they are usually little more than CRUD interfaces for a database. As the company grows, things get more complex with multiple APIs, user authentication, third-party integrations, data tables with sorting, filtering, pagination...but these are all relatively simple for developers to code.

Simple, yes, but also time consuming. Bootstrapping a brand new code project with proper linting, tests, docs, setup scripts, dependency management, deployment tooling, production observability and logging...all for an internal system that only a few people will see and doesn't require solving any challenging problem solving...why would a company assign its (often) most expensive and skilled people to work on this?

More likely, none of that will be implemented and instead you'll get an MVP that does the job today, but quickly starts degrading as maintenance overhead, security updates, feature additions, and tech debt racks up.

This is why no/low-code is for developers. Which tool you choose will depend on your requirements and preferences, but they all target the developer as the primary user. They allow quick drag and drop creation of a UI that will be well maintained with all of the operational overhead already handled. Once built, it will "just work", with any use-case evolution handled through the an easy interface editor. It's the next evolution of using spreadsheets as a database, like we do for content management at Console.

That's the pitch, anyway.

The question for every developer evaluating such tools is: how constrained is the environment? Connecting to a datastore with drag and drop components is great, but what happens when you have some custom requirements? Sometimes you just have to write code.

The best no/low-code tools make this easy. The ability to write some (serverless) code that can take event triggers or other pipeline data as input, then pipe output into pre-built components (or even more code), is essential. Otherwise it's just a glorified form builder.

Coding is always going to be the way to solve the tricky problems. No/low-code is about dealing with everything else, then connecting the two together. Developer time should be focused on business-differentiating work, not struggling with tedious maintenance tasks from that one script someone wrote years ago, but now handles business critical systems.