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.
Top comments (12)
Well written and explained. I think people have been trying to do this forever, they just change the name of it. :P Where I work they are trying to pitch Microsoft Power Platform for low code, but us devs would rather not go down that road really...
I'm currently sucked into finishing off a power app and let me tell you, power apps in their current state have no place being used for apps larger the a couple of pages and a handful of simple functions. The main problem with them is there's no transparency on how the logic works and the code you do have to write is done on specific element properties (on select, text, opacity) making it even harder to see where something happened. Not to mention the code is written in an excel style box.
And sure they can pitch them as a way for non devs to build apps but they're too complicated/convoluted to build anything particularly useful. For devs it would be faster to build a quick web app with a framework like nuxt/next.
I am a dev who happily builds many Power Apps and Power Automate Flows. It's a great tool for working within the Microsoft ecosystem and sometimes even outside it. Pairing them together let's you do even more. Add a little SharePoint for data storage and you have a great little tool that doesn't have any extra costs besides the Microsoft license you already have. Flow wraps up a lot of the Microsoft Graph API in easy-to-use blocks, which makes my job faster and lets people who don't know how to use APIs take advantage of them. I will wholeheartedly recommend either one of them.
They do have a learning curve, but really so does every tool ever. The only thing that it's not very good at is processing very large amounts of data. That'll break it. That's when I break out Powershell or C#. Other than that, I've had much success implementing Power Apps and Power Automate processes in my projects.
Thanks for the great article.
I like to think of this as a spectrum between Configuration and Code. Full configuration has a large learning surface area with all the app-specific configuration options and their supported interactions. The learning curve is more appropriate for non-devs since you only learn app-specific stuff without bringing in the universe of dev things. Configuration is essentially an app-specific programming language.
I think another reason that developers tend not to like no/low code solutions is because they are used to having the full power of a programming language. Low code necessarily has some restrictions. And no code tends to have limited supported interactions. There is a frustration in knowing how easy something would be in a different context but how hard that same thing is with no/low code.
I like your idea of taking a no/low code prototype and translating it into full code for further development. I think we can see the beginnings of that kind of thing even in the developer space with projects such as Create React App.
I'd like to phrase this in a more agnostic way, because I think of "code" and "hand-waving" as being the two ends of the configuration spectrum.
Another angle to this discussion is Infrastructure as Code where you seek to codify all software configuration. We would like to run software with as few hand gestures as possible. Drag 'n drop achieves the ease and high short-term value-to-customer ratio, and IAC achieves revision control, reproducibility and high long-term value, but at a steep learning curve.
There is a point in the distance where these two meet for smaller scale projects, so that the configuration and customization of e.g. a WordPress installation is separated from content and versioned appropriately.
It's a huge spectrum. I've seen comparable arguments regarding languages like Python compared to C. Python gives you both dictionaries and memory management/garbage collection for no code/free. Sure, you can import a 3rd party dictionary implementation in C, but by the same token you can write your own in Python too, and then rewrite it in C if your Python implementation is too slow.
I see the ideal no/low code solution similarly - GUI, but customisable all the way down, much like I can write
<html><p>hello code</p></html>...but then I can add styling, pick font, pick alignment etc going more and more custom mostly via gui, eventually using the GUI to specify a custom font file I made, all the way down to a custom vector drawn font that responds to the screen size and cursor/touch inputs.Ideally this would be some sort of code generator/editor that can recognise where the generated code has been customised/extended. Maybe a star next to representation in the editor where you can right click and see/edit the customised code.
Nobody builds an iOS app without Interface Builder these days, platforms like PowerBI are built in such a way that they can start out as a simple but well-formed spreadsheet, and people have been building applications with Excel and macros forever. People using any of these examples are as much programmers as the people who include a handful of node modules/libraries to form the structure of a node server or webapp.
This is a great guide to the frontier of applications and developers to come, as well as an acknowledgement of the reality of what's needed to make those applications and to be those developers. Awesome write-up, Ali!
Thanks for the great article! I am really excited to see where the low-code / no-code space is going. I love using it in my work and I've made some pretty fun things using Microsoft's Power Automate. Custom coded apps can sometimes come with a lot of overhead and time so I don't like to use them unless it's absolutely the best option for the task.
Like you I came with the assumption low/no-code is bad but it's really just another way to deliver value to the user.
Great article! I can't agree more, we developers are always looking for ways to write less code but it seems that those ways are only legit if they're written by us.
Nice. My feedback: User land can be exciting. Possibly in the future people are going to like building tiny pieces. Not the whole app all by themselves.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.