Many developers don't like the idea of low or no code, yet they use tooling to dramatically lower the amount of code they need to write. They're hesitant about graphical user interfaces, yet live in Visual Studio Code which has had widespread success due to its visual interface.
Let's first discuss what low code, no code, and full code are and their strengths and weaknesses and then I'll go all thought leader and give my thoughts on their future: what will make them successful and why developers should embrace these tools.
No Code
First off, no code. No code is when you build an application with, as the name implies, no traditional code. You instead use a graphical user interface where you click, drag, or fill out a form to build websites, apps, or automation flows. Some examples of no code tools include Squarespace, Notion, and Zapier.
These tools are great for building something that fits within what features they support, but if you want to create something custom or go outside their boundaries, it isn't really possible. They are great for their purpose: allowing non-coders to build quickly, but they are limited in customization and scaling.
Full Code
I'm a software engineer, so my career has focused on building full code solutions to problems. Code is when you give a computer a sequence of written instructions and the computer executes those commands. You use a programming language, like Python, Java, or JavaScript to do this.
This means the product built is completely custom, or at least that was true historically. You can build whatever features you want or need. Scalability and extensibility are possible with full code solutions.
That being said, code is difficult and expensive. Programming is a career and takes a long time to learn. One person most likely won't be able to be the sole developer on a large-scale application, and developers are a relatively high paid role. Plus code needs to be maintained and updated, which means even more time and money over time.
Low Code
Low code is a hybrid of these two types of solutions -- it falls somewhere in between no code and full code. So, maybe you scaffold an application using a graphical user interface instead of traditional code, but then you can extend that application using code to make all the extra features you need.
That being said, developers are often hesitant about low code solutions, and for good reason. Historically, many of these tools have thought of developers second and so the code was poor quality and the interfaces were clunky.
Second, I think developers fear that low code will make their jobs irrelevant. I think this is misguided: first these solutions are backed by code and extended by code. Code isn't going away anytime soon, and in the best case scenario low code will just make the annoying parts of our job less annoying.
The line between low and no code is often blurred and pedantic. In fact, tools I would personally categorize as low code brand themselves as no code. I mostly agree with this post by Shawn Wang: the categorization doesn't really matter.
The Lower Code Evolution
Code has already evolved to be a lot lower code than it originally was. You used to have to write all the code for an application from scratch, which is no longer the case.
When you start a Ruby on Rails app, thousands of lines of code are pre-written for you, and you can famously build something useable in 15 minutes. Ruby on Rails depends on "convention over configuration" which essentially means that trades developer decision making for increased productivity. If you follow the framework, you to write less code in return.
In addition, you can use a Gatsby or Next.js template to have a full app you only need to tweak or add features to. There are also managed services that can be used to add something like authentication or comments to your application in a few clicks and a few lines of code.
Most developers embrace these solutions in part because the amount of self-written code is much less than you historically needed. These tools prioritize developers as part of the solution instead of attempting to go around them. They meet developers where they're at.
Serverless has also done something similar for the cloud computing industry -- you no longer need to jump through hoops or be a DevOps engineer to get an application deployed in a scalable way. Tools like AWS Amplify and the Serverless Framework enable frontend developers to build full-stack cloud apps without having to know a ton about infrastructure or a secondary backend language. Serverless doesn't actually mean no servers, it just means that the server is mostly abstracted away from the developer, making their jobs easier and safer.
But, low code attempts to expand who can build software: non-coders are comfortable in different environments than coders. Teaching a new developer how to use a CLI instead of a GUI is a large task. At first it feels much more difficult to use a CLI. But most developers feel more productive inside a CLI -- it is faster for them since they have commands memorized and are comfortable in that environment.
The truth is that under the hood, low code and no code solutions are code. They're built by programmers and though they may allow for most or all of the stuff we think of as code to be abstracted away, they contribute to the same goal most programmers have: building applications and sites for end users. Just because the code looks different or is more understandable to a wider group of people doesn't make it less valid or less useful.
In many cases, what a programmer used to be able to do in hundreds of lines of code is now doable in one. This is a good thing: it leads to increased productivity, less maintenance of repeated codebases, and the barrier to building on the web is lowered.
What will make a low code solution viable
My thesis is that low code solutions need to prioritize the developer, the non-coder, and designers. Right now, building a full scale software product with no code isn't feasible. It should be possible for a non-technical founder to prototype a product with no code, put it out as a proof of concept, and then pass that off to a designer and developer. They shouldn't need to start from scratch, they should be able to extend the prototype using the environments they are most comfortable in. For designers this will most likely be design tools like Figma and Sketch, and for developers it will be in their text editor with a common programming language like JavaScript.
I think tools like this are on the horizon, but in the short term, tools that enable more people to become developers or enable existing developers to be more productive are growing quickly. The idea that what used to require 100 lines of code or more is now able to be one line of code has been accepted by developers. For example, managed authentication services like Amazon Cognito, UI component libraries like Chakra UI, or payment management systems like Stripe.
In addition, the code should be readily available to those who need it. It should be fully generated instead of just having partial generation for a few features or having slots to insert custom code like some tools have. At least in the short term while these types of tools are gaining trust.
I've been working on the AWS Amplify Admin UI for the last few months, and I am impressed by its ability to simplify developer workflows via a visual interface despite being a tool completely aimed towards developers. It's low code in practice but not in positioning.
The same is true for the visual Git integrations in VS Code and the increasing integration of component libraries with design software. These are visual (i.e. low code) solutions that developers use in our workflows. They aren't branded in this way, so we're more accepting of them. Maybe this is also needed to win over developers in the short term, but I hope instead that we can embrace this progression instead of shunning it. Increased productivity on the boring stuff means more time to work on challenges and innovation.
Webflow has proven that low and no code tools can be a multi-billion dollar industry. I'm eager to see what comes next in this space, and I'm really excited about the possibility to allow more people to be developers and product builders.