Why NoCode Development is So Fast: The Complexity Behind the GUIBy: Korey MacDougall Published: 2022-05-31 Last Updated: 2022-05-31
Summary - In this article we explore how NoCode tools save you time by providing high-level abstractions and interfaces to many complicated pieces of the web application stack.
- How NoCode Tools Speed Up Development
- What NoCode Eliminates
- Dev Tools
- Databases and File Storage
- Cloud Infrastructure
- Version Control
- Continuous Integration / Continuous Deployment
- Authentication - session management, cookies, privacy, access, row-level security
- Scheduling and Job Queues
How NoCode Tools Speed Up Development
A lot of the recent enthusiasm for NoCode and Low-Code (NC/LC) tools (e.g., Bubble and WebFlow) has centered around the fact that these platforms enable people without a programming background to build web and mobile apps. This is wonderful, because it makes tech entrepreneurship accessible to non-coders, which in turn leads to products and services that are built by domain experts, who may not have experience or interest in writing code, but who have deep knowledge of a problem that is shared by the community of their customers. We might call this the “positive” benefit of NoCode, “positive” in the sense that it is adding or enabling something new.
In the scope of a single project, this elimination of work can mean massive gains in productivity, allowing a developer or a team to get to market faster, to iterate on their builds more quickly, and to be more responsive to user feedback. That alone is amazing.
In the rest of this article, I will detail some of the complexity that No-Code/Low-Code platforms abstract away. I think this is useful for 2 reasons. First, it provides a perspective on just how much value is being offered by these platforms, which may be useful information if you are trying to decide whether to use these platforms for your own projects, or if you are trying to gain internal support in your organization to adopt these tools in some part of your work. The second way in which this overview may be useful is as a guide map for NoCode/Low-Code developers who are interested in learning about the technology under the surface, whether simply out of curiosity, or as part of an interest in learning more “traditional” web development skills. If you have learned a platform like Bubble or WebFlow, you will have picked up a great deal of the vocabulary and mental models of coding (perhaps without realizing it), and will be in an excellent position to start learning to code, and I hope this post can serve as a helpful overview.
What NoCode Eliminates
Let’s look at some of the pieces of work that No-Code/Low-Code tools eliminate. Note that each platorm will be a bit different, according to what comes packaged with their offering. For the purposes of this article, we will use the features offered in Bubble’s paid plans, as they currently have perhaps the most feature rich offering, though most of these features are also part of the offerings of WebFlow, Adalo, AppGyver, etc.
- HTML defines a site/app’s structure, in a a sort of abstract box model
- CSS defines its visual appearance, things like colors, element sizes, and fonts
Each of these languages is non-trivial to learn has lots of “gotchas” that take time to master. Working with these languages, as with any programming language, can be very finicky and error prone. NoCode/Low-Code tools provide an interface to these languages by providing pre-built components, like buttons, inputs, and image elements, with sane defaults and checkboxes or dropdowns to customize them. This saves developers from needing to learn the syntax, workfow, and tooling of each of these languages, and from many/most of the challenges of writing good code in them.
Furthermore, concerning the 2 visual languages, HTML and CSS, I think there is a case to be made that it is simpler to create user interfaces when using building blocks that map directly onto visual space, than it is to write text that becomes visual. Or put another way, it may be more cognitively taxing to read HTML and CSS and translate that to a mental picture while developing (or conversely, to find the proper textual representation of the display you want to build), then it is to create the same interface with a visual builder/GUI. This has been my experience, but I do not know how universal this is. If you have thoughts on this, please let me know on Twitter!
When writing web applications, or any other software, you typically need to learn and use a suite of tools to actually build the software. These include, among others:
- A code editor, text editor, or integrated development environment (IDE) - for writing your source code (e.g., VS Code, Atom, or Vim)
- Browser developer tools - for testing, inspecting, and debugging your app
- Linting tools - to automatically check your source code for errors
- Documentation tools - to generate documentation for your team and your users (and your future self)
All of this stuff (with the exception of documentation tools) comes baked into the NC/LC platforms:
- Your “editor” is the platform interface
- Your “browser developer tools” come in the form of a built-in error-checker and display (e.g., the debug bar in Bubble, with it’s “inspect” and “step-by-step” buttons)
- And your linter is running always in the background to notify you if you have made a mistake somewhere (in Bubble, this appears as red text when selecting dynamic data sources, or as the error count that apperas in the right of nav bar when you’ve made a mistake somewhere in your app).
Needing to learn and use only a single tool can provide an enormous productivity boost.
Databases and File Storage
Most web applications need to store data, things like uploaded files, user data (e.g., user name, chosen subscription, sign-up date, etc.), posts, comments, etc. Traditionally, adding a “persistence layer” (aka as storage layer, data layer) to a web application requires 2 different things:
- a) a “database engine”, like MySQL or MongoDB, running somewhere (i.e., on a cloud server/Virtual Machine)
- b) a way of interacting with that database engine through your app, either:
- b.1) directly interacting with a database
- b.2) using an “Object Relational Mapping”, which is an abstraction layer on top of a), that allows you to interact with the database using the programming language of your application, rather than with raw database functions (e.g., SQL queries). Web application frameworks, like e.g., Django (a python framework) and Rails (a ruby framework), typically come bundled with such an abstraction layer.
Database administration is difficult, and traditionally requires years of learning specialized query languages, deployment and “migration” workflows, and data modelling principles. With No-Code/Low-Code platforms like Bubble, you get a database integrated into your app right out of the gate. This is incredibly valuable (perhaps even the most valuable of all the pieces covered in this article… what do you think?).
In addition to the application code you would traditionally need to write in HTML/CSS/JS (i.e., the code that defines your app), web applications also require infrastructure to run on. There needs to be a computer, somewhere, that users can access to use the app (the scenario is different with downloadable software and mobile apps, but we’ll focus on web applications here). While it is possible to run a web app from an old desktop computer in your closet or basement, it is almost never a good idea to do this (see, e.g., this howotogeek article for some reasons why), so you will most likely need to create and maintain some cloud infrastructure to serve your app. This infrastructure primarily involves servers and related or supporting components. The list of pieces/skills required is something like this:
- Servers - you’ll need to know how to “provision” (i.e., setup) a server that stores and serves your app
- Networking - you’ll need at least a basic understanding of ports, firewalls, routing, IP addresses, domain name services (DNS), and SSL/HTTPS certificates
- Load balancers - if traffic to your app grows beyond the capacity of a single server, you will need to employ a load balancer to distribute requests between servers
- Command line - system administration is normally done through a terminal or command line via ssh (a program/protocol to connect to remote computers)
Setting up and maintaining servers is a non-trivial component of running web applications, and is normally the purview of a dedicated team/expert on a software team (usually under the moniker of ops, devops, or sysadmin). With NoCode platforms, you don’t have to learn any of this. This alone provides a huge productivity leapfrog.
While developing new features for your app, or planning a new release, things can get messy. It is usually a good idea to keep track of what you are changing, to have a way to roll-back to previous versions of your app, and to allow different team members to work on different parts of the app. Most software developers and teams manage this by using a type of tool called “source control management”. And these days, almost everyone is using a tool called git for this purpose. Git, created by the inimitable Linus Torvalds, of linux-creation fame, is an amazing tool, but like all tools, it has a learning curve. To use it, you need to learn a mini-language, consisting of things like “commits”, “branches”, “head”, “tags”, etc., and you need to learn a tool to interact with it, whether that be the command line interface or a GUI.
With NoCode tools, creating a new “branch” or rolling back to a previous “commit” (called a “save point” in Bubble parlance), is as simple as clicking a button or two.
Continuous Integration / Continuous Deployment
One of the key pieces of infrastructure that modern web applications rely on is something called Continuous Integration / Continuous Deployment (or CI/CD for short). This refers to a pipeline that incorporates recent changes to your application’s code into the “live” version of your app. It works something like this:
- You “commit” (i.e., save) your most recent code changes with git
- You “push” (i.e., upload) your code to some hosting service (e.g., GitHub) or some private storage location
- Your hosting service / storage location triggers a set of steps to compile, test, and deploy your updated app.
- Success/Failure data is sent to some dashboard or email address, so that the team knows whether the most recent “deploy” was successful or not
This piece of the puzzle tends to come under the umbrella of the ops/devops/sysadmin folks, mentioned above. Setting this up typically requires knowledge of the command line, facility with some scripting language like bash or a “markup language” like YAML, as well as a deep knowledge of cloud infrastructure, application compilation, and monitoring tools.
With NoCode platforms, this part of the pipeline is almost completely invisible. With Bubble, for example, you simply click “Deploy to Live”, and your most recent changes are “put into production”. As with the other components discussed here, there are tradeoffs for this simplicity: you cannot, for example, easily conigure your NC/LC apps to run automated tests on deploy, or to send compilation reports to your email address. But on balance, the benefits of abstracting away this component of system administration are substantial.
Authentication - session management, cookies, privacy, access, row-level security
Handling your users’ data responsibly is imperative. Leaking usernames, emails, and (especially) payment information, can cause terrible trouble for your users. So any information your users provide to you must be safeguarded to the best of your ability.
But doing this well requires knowledge of many different pieces of web tech:
- Session Management - tracking whether a user is logged in or not
- Cookies - how to store data on your users’ computer. What data can/should you store?
- Privacy - what data do your users consent to sharing? Are you operating GDPR compliant?
- Database security - is your database properly secured, with, e.g., row-level security, determined according to a user’s account permissions? (e.g., do you prevent users from seeing other users’ private information?)
Authentication is, in some sense, a subset of the database section above, but presents some challenges unique to the management of user data, both technical and legal.
With No-Code/Low-Code platforms, authentication nearly always comes built in (because it’s such a fundamental component of web applications), and you can be confident that you’re not making the most common user data security mistakes.
Scheduling and Job Queues
The last piece of the stack we will cover here is asynchronous job processing. In some applications, you need to run code (or tasks), that require a long time to complete. Examples might include video encoding conversion, analytics on a large dataset, or complex machine learning inference (e.g. image generation from text inputs).
For these types of tasks, we typically use something called a “task queue” and a “message broker” (see, e.g., RabbitMQ and [Celery](https://en.wikipedia.org/wiki/Celery_(software) for examples. These tools allow you to schedule tasks to run “in the background”, and then do something once completed. While this may seem simple on the surface, it can be quite involved to implement a system to handle this sort of processing.
With NC/LC platforms, you often have a built-in way to do this easily. In Bubble, these tasks are called “backend workflows”, and you can use them without worrying anything about a queue or messaging service.
In this article we have looked at how modern No-Code/Low-Code platforms speed up development by abstracting away the complexity of so many different, disparate parts of the modern web application stack. I hope this has been useful both to point out the value of NC/LC platforms and to help those interested in going further down the rabbit hole of web development.
If you have comments or questions, please feel free to reach out on twitter!