The Case for Lower Code
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.
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.
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 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
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.
I agree that most platforms have struggled to find a balance between designers and developers. But I think platforms that focus on that gap are missing where most business value is actually created.
I think no-code is successful because marketers, salespeople, and customer success teams can use it just as well as anyone else. Putting this power in the hands of the people actually generating revenue for a business means they can start and run businesses without even talking to or hiring a coder — and start learning about their customers from day 1.
I hope to see more platforms blending everything together like you suggested and I agree they'll win in the longrun (can't wait to see what Webflow do in this space!). With a powerful platform like that, the marketing team can design a prototype, salespeople can sell it to customers, customer success teams can fill in the gaps in functionality with manual actions, while designers and developers are hired to rewrite one piece of the prototype at a time and make it more scalable and powerful.
A company I consult for actually started that way — doing everything with spreadsheets combined an amazing customer success team. Now we have a full tech team and a lot of happy customers!
That's my ultimate goal for an open-source framework I'm building called Remake (remaketheweb.com). Right now, it uses HTML as the underlying technology, but that's just to give it a strong foundation. We also have an online IDE and drag and drop builder in the works. I'm hoping non-technical people will be able to copy a template of an app, modify it, start a business — and developers can come in later and add extra functionality once they've already seen some traction with real users!
I also wrote up a blog post about the no-code/low-code ecosystem where I reviewed all of the latest and greatest tools. I'd love for you to check it out if you have time: blog.remaketheweb.com/no-code-and-low-code-..
Lovely to see you in Hashnode! I'm also an advocate for low to no-code tools. I've written up my experience already last year in case if you want to check out my blog: thecodingcow.com/why-its-perfectly-ok-to-us..
Great article! One of the philosophies we live by at appsmith is that visual elements and configs should be configured visually while logic and workflows should be expressed via code. Anything that cannot be a simple config should just never be forced into a complicated visual interface! This has always been one of my peeves with workflow builders. They're great to connect to the data sources but the minute you have to write logic on the data in between, it becomes a nightmare!
As with all things in this world, choosing which adventure to take is a series of trade-offs. Low-code is a compromise on the disadvantages at the extremes, but it's not without its downsides.
Fundamentally, this is a discussion as to where on the scale you fall on Vendor / Dependency management. After all, unless you're fabricating your own silicon you will always have dependencies - it's just a question of scale.
It's all a question of trading speed and ease of development for control and maintainability.
(I very much disagree with your suggestion that low-code is automatically more maintainable for the following reasons):
You have significantly expanded your attack and maintenance surface. You may only use 5% of the framework / functionality that you've brought in - but you own the resource needs and maintenance of 100% of it. You now have to map dependency trees that may be incompatible between different libraries. You've traded complexity of code for complexity of dependencies (which is something you have less control over).
If you need to do something which your framework considers to be 'unorthodox', you may have to write your solution in a more complex way to fix into the existing framework's model (as opposed to the most efficient / maintainable way - introducing additional complexity).
If, God Forbid you tickle a bug that's located inside one of these frameworks and you've relied on the framework to hire less experienced people - you are stuck. You may end up with an application that's down that you don't have the skills in-house to fix.
Vendor lock-in. If you rely on a framework or a service and that relationship breaks down for any number of reasons - you potentially have to write your application from scratch.
Low-Code doesn't remove complexity, it hides it. The piper will always need to be paid - it's a question of when and by who.
These tradeoffs make sense in some cases and not others.
As the architect of a solution, only you can make the decision as to which approach is the right one for your use-case.