I am a big fan of hand-coding websites, but it is hard to ignore the growing trend of no-code and low-code tools for the web, and the businesses basing their workflow on them.
What are no-code and low-code tools?
No-code tools are systems that enable you to develop websites and applications without the need to write code yourself, or in low-code terms, write very little code. Usually, this means creating a website or web app with a more visual, design-led interface. These tools often make use of drag-and-drop interaction to pull sections together or create actions that are combined or run in sequence to get to the desired outcome.
What no-code and low-code tools exist?
There are so many that I would find it difficult to name them all. But, some popular no-code and low-code tools are:
- Webflow
- Wix/Editor X
- Framer
- Squarespace
- Weebly
- Shopify
- Page builders for WordPress, such as Elementor
- Many many more…
There are so many more, with new tools seemingly popping up every few months. A lot of these tools can be deemed as no-code, as you don’t need to write any code to use them and produce a functional website and then host it on the internet. Some of these can also be used as low-code tools as well. Meaning most layouts and functionality are built without writing code, but you can add your custom code for something specific on top, such as an animated element.
Are no-code and low-code tools sustainable?
There are a couple of ways of looking at this question.
Energy usage and underlying infrastructure
One is how these tools are powered, and what energy their servers generally use. I’ve tested many websites since setting up lowwwcarbon.com, and quite a few using these no-code tools. On the whole, what I’ve found is that the majority of them appear to not use renewable energy or offsets to make them ‘carbon neutral’. That’s according to the Green Web Foundation that I use within the tests.
However, I do believe this is partly due to where the server delivering the files is located, where I am located, and of course which server infrastructure each tool is using. Many of the tools appear to use Amazon S3 or Google cloud to serve files globally across a network.
Code output
The quality of the code ranges quite dramatically between the different no-code tools. Some of them produce really quite lightweight, readable and semantic code. Others, not so much. On the whole, through my testing, I would have to say that tools that integrate on top of another platform – such as a page builder for WordPress – generally produce a lower level of code quality compared to the dedicated website builder products. Good semantic code is really important. So it is key that if you do choose to use a no-code tool to build a website, you first look at some example sites built with them, dig into the code produced, and make an informed decision based on your findings.
Default code, scripts and tracking
Many of the no-code tools seem to add default CSS and JavaScript to every website created with them. While some default CSS – such as reset styles – can be a good thing, having no control over what is being loaded from these no-code tools can mean you end up with a bloated website. A website that has many unused styles, or JavaScript that don’t directly apply to your site’s design or functionality needs. This is wasteful. However, some tools, such as Elementor–a page builder for WordPress, have been striving to change that within their own codebase. Refactoring and altering the way the plugin generates and outputs code to make it lighter. I can’t say the same for other tools like Webflow or Framer, as they don’t talk about it publicly. Squarespace has recently released its first impact report, but it missed a really important factor.. a measurement of its carbon footprint!
Time implications
One of the unique selling points of these no-code tools is often that they save you time. In my own experience, I have found the contrary. Each tool is different, with a different system to learn. Over time, maybe you could save some minutes/hours overall as you are both designing and building in one process. However, I also feel like this could waste a lot of time. Time spent tweaking and changing designs on the fly. Time spent on your devices uses energy. The more time spent, the more energy used. If you can build faster without a no-code tool, then I’d say do so.
Working in the cloud
All the tools mentioned offer you the option of working fully in the browser. From design to development and deployment, you can do it all without leaving the same browser tab. Again, depending on where the server your site is stored on, and where you are in the world, there could be a huge distance between the two.
As you’re working in the cloud the whole time, you are constantly working on that server, rather than say locally on your machine. This has the potential for using an incredible amount of energy and causes a huge amount of data transfer every time you interact with the tool. Working locally on a desktop app, or hand-coding in your favourite text editor of choice, could save a lot of that data transfer and energy usage. Some of the no-code tools offer desktop apps, though I’m not sure if they too are constantly connected to their servers or if you are in fact working and saving locally. I suspect the former.
A quick comparison
I decided that the best way to see the difference between custom coding and using no-code tools was to give a few a try. In my tests, I thought I would recreate the desktop version of the homepage of the-sustainable.dev site. The reality was, that as every system is quite different, it took a lot longer to get to grips with multiple tools. So I instead decided to focus on one.
Framer
It took me approximately 3 hours to get to grips with the system and put together the homepage. It isn’t a perfect match, but a pretty close approximation. I didn’t time myself when building the real homepage of the-sustainable.dev site, but I’d guess it probably wasn’t too far off this timeframe.
Page weight
As tested with Beacon, the initial load of the homepage built with framer weighed 360.52 KBs. Not too bad. But compared to my custom-coded version on this website at 21.85 KBs, it’s quite a difference. For what is a simple page and grid layout, system fonts and no images, that is quite a significant weight change. The code output from Framer (from what I can tell) is React, and the site loads JavaScript by default (I assume it handles layout and React components – I’m not a react developer).
Hosting
The server the test site is based on is run on AWS and has its origin at their EU location in Ireland. This location, as tested with the Green Web Foundation appears to use renewable energy. I certainly would imagine that a live version would be published to multiple regions and data centres.
HTML output and semantics
Semantically, results are dependent on how you choose to use the tool in front of you. Much like hand-coding. There are many ways of building a certain area of a website.
Within Framer, you could choose to have a navigation element. You could as easily create the same area with a series of anchor links styled to look like buttons. Worryingly, you could also very easily include many H1s on a page and style the text to look like a button. Not great. But of course, someone could also do that when hand coding.
Overall HTML structure was pretty good. Although there were a lot of divs
used where maybe there didn’t need to be.
Google Lighthouse performance
I’m proud to say that my hand-coded homepage on this site receives a score of 100 across the board in Google Lighthouse tests. The Framer version also did very well, but not quite 100 for every area. I believe I could have got the accessibility to 99/100 by tweaking the colours – but I was using the same colour palette and where I could font sizes. So I am a little confused as to why they didn’t match.
- Performance: 100
- Accessibility: 98
- Best practices: 92
- SEO: 100
Missing features
As this was a test of a no-code tool, I didn’t want to write any within Framer. So, the light and dark toggle is missing, which also means the light styles are missing from Framer as well. This is important when you take into account the overall weight of the Framer page, knowing it is missing those styles as well.
Of course, this is just one example. And I didn’t mean to pick on Framer, it was the first tool that I chose to create with. I also began testing with Webflow and Editor X, but due to the amount of time and not wanting to create additional digital things for no reason, I chose to stick with just Framer.
The verdict
It is rather difficult to say exactly how heavy no-code tools are. They all take a slightly different approach. And a lot of page weight rightly comes down to how they are used. However, from my experience of testing with Framer in full, and a little less in other tools, I can safely say that they do generally weigh more by default than my hand-coded version.
Most tools output code and load scripts to the front end without user consent or action. These tools are by no means alone in doing this. Many developer tools and frameworks do the same. WordPress as a platform does it. So this is a bigger problem than just no-code tools.
Working locally on your machine is definitely better than working solely in the cloud when building your test site. Being locked into a particular host or service like AWS is perhaps not the best thing for sustainability. Once live, content being spread across a network/CDN is good. You can read why using a CDN is better for the planet here.
Overall, I think there could be some improvements to these no-code tools so that they output less by default. But, at the end of the day, it is how they are used that will result in something vastly heavier, or not.
My suggestion. Work with a friendly developer who can build you something right for your needs, rather than do it yourself with potentially negative results. There are many listed in the Directory!