You Don’t Have to Write Code to Think and Build on the Web. Stop The Gatekeeping!

You are being misled. You are told things that are not true, and you are believing them without asking questions. Why?

Well, I would ask the questions. And I will leave you with much to think about, because unlike those who are attempting to prevent you from dipping your feet in the waters of web development, I would not spill opinions as though they were facts. I would instead let you use your reasoning faculties. You have them. So, use them.

I would not spill opinions as though they were facts.

The Never-ending War: Code VS No-Code

Let me make something very clear: When people in the WordPress or Webflow world say they develop “no-code”, they are not saying that they do not want to see code. At least, that’s what the majority understand to be the case. They are saying that they prefer to build web solutions (web apps and websites) without writing code by hand, but visually!

But people who code say: Well, that does not make sense. If you do not or cannot write code, then you should not be a web developer!

And hey, let’s be straight here: Is it true that no-code developers don’t write any code? My answer to that would be “it’s impossible!”. Why? Because even if a person decides to make use of a page builder such as Elementor, Bricks, or whatever else exposes such building into a visual interface, they will always interact with one aspect of code or another.

Here’s an example:

Do you see how the color of the element is defined? How about the font-size? Do you see that those two values are defined within the visual interface, while the underlying properties and rules write themselves?

Here is how it is printed in code:

The result is as correct as that written by a person who understands how to code and would decide to write this same code by hand.

But wait!

What’s the point of showing you this? Did you take note that there are aspects of that code that did not write itself and that I had to define? Such as var(–text-s)? That’s just a variable meant to determine the size of the font. I had to write that. If I did not, then there will be no font-size definition in the code. My point? Even if a person uses a so-called “no-code” interface, they still write some aspects of the code without which they will be unable to build a website. They need to make decisions that affect the code output. And those decisions don’t rest on the interface or builder. They rest on those who use them.

Given this fact, how would I then define a no-code web developer?

That’s a person who uses a builder or visual development environment that does not require writing of every aspect of the syntax that make up the resulting code, to develop websites or web apps.

Do they touch code? From the example above, you have your answer. But do they touch every aspect of the code and need to understand how CSS rules or HTML tags or JS scripts are formulated? From the example above, you also have your answer.

This is not a fight about syntax! It’s a fight about what professionalism really means.

The Real Question: What Makes a Person a Professional?

You have heard it before: A web developer is not a professional unless such a person understands the principles behind the written code they deploy!

I agree with that, 100%! But hold on. Am I not contradicting myself? Nope. I am not. Hear me out. The underlined word here is principles. And not syntax. Well, what’s the difference?

Put it in the simplest way possibel: Principles are why something works a certain way. They teach you to think like a web developer. BUT Syntax is how you write them. They teach you to speak to the browser or server.

Let me make it make sense with a simple example in CSS (the language that determines styles of items on the page like colors, size, and others). The principle of specificity in CSS determines which style will win when there is a fight between two rules pointing to the same element on the page.

The principle tells you this: When you style an element by it’s #ID, then that will almost always win the fight against the conflicting style you give to it’s .CLASS. Put in a different way, if I have an element present on the page and I give it a class name and attach a style such as ‘color’ to it, then it would work fine. Unless I have also given it an ID, and attached a different color to it. Then the style I gave to the element via its ID is what will show in the browser. Using Bricks Builder again, here is an example:

Now, as you see in the screenshot, I have an ID defined called “#brxe-stndou”. And I attached the color “red” to it. Although I have previously set a different color via the class called “.updates__notification”, this new color set in the ID rendered the one defined in the class useless.

If you never knew this before now, have you learned something new? Great! So, here is a question for you: At what point did I need to show you THE UNDERLYING CODE to explain to you how this works? You did not need to know that. Why? It’s simple – you just need to understand the principles of web development to be able to use a no-code builder and thus become a no-code developer.

If I showed you the code printout in the frontend… Something like this:

#brxe-stndou {
  color: red;
}

.updates__notification {
  color: brown;
}

#brxe-stndou {
  color: red;
}

.updates__notification {
  color: brown;
}

And you saw visually that the element that is being targeted has the color RED and not BROWN, take a guess, what would a layman think? He would first assume: Oh, it’s because the rule that says it’s red comes first. And he would be wrong. He would try to take the rule that says it’s brown above, and realize that it made no difference. The element stayed RED. So, what next will he assume? I don’t know. But maybe he will arrive at the same principle after multiple trials and errors – that the defining factor is the #ID on which the rule is set.

Know this: This principle does not care about builders. It works the same way because what sets the rules is the programming language responsible for those principles and actions: CSS.

A messy developer who codes everything by hand is not more professional than a web developer who uses a page builder AND understands the PRINCIPLES of web design and development.

I would argue that there would be countless coders who would not pass as professional web developers even if they know how to write the programming and markup languages of the web. What would determine their professionalism are two clear things:

1. The understanding of the principles that guide the decisions made during development. Principles which I have just established can be learned without ever seeing the code output.
2. Using such principles to build websites that scale and can easily be maintained in whatever tool that helps them achieve just that!

So quit the lies! As long as a person can do what a coder does but in a visual interface, and do so correctly, they can be called professional web developers. And make no mistake, coders rely on visual interfaces too! Should I explain to you why they make use of the browser inspector tool of Chrome or Firefox? It’s because they usually need something visual to tell them what they are missing. So, if a no-code developer has an interface that abstracts the underlying code, but tells them what they are missing too, who should be faulted for using an interface?

The brain doesn’t care whether you learned through typing or dragging. It just learns. What matters are the principles! If they are correctly taught, you do not need to code to learn them.

Innovation May Start with Code. But that’s not where it ends.

There is an abstraction above everything in the software and tech world. Everything. Pay attention to that. I said Every Thing! And let me me make myself even clearer:

1. Your car is an abstraction. You don’t think about pistons, fuel injection, or spark plugs when you drive. You just turn the key (or press the button), and it starts. The car hides all that complexity and gives you a steering wheel, pedals, and gear… that’s your “interface.” The resulting output is almost always correct.
2. Your phone is an abstraction. You don’t write assembly code to make a phone call. Do you? You just tap a contact. Beneath that, a thousand lines of machine-level instructions run, but you don’t need to know any of that. It works because the output is almost always correct. You just use the interface.
3. WordPress is an abstraction. It hides PHP templates, SQL queries, and JavaScript logic behind simple buttons like “Add Post” or “Publish.” Yet everything it does still depends on the same core web technologies. Technologies that you don’t need to touch to hit “Publish”. Why? Because the output is almost always correct.
4. CSS frameworks like Tailwind or Bootstrap are abstractions. They give you pre-written utility classes like .flex or .text-center so you don’t have to type out display: flex; or text-align: center; yourself. The resulting display output is almost always correct.
5. Page builders like Elementor or Bricks are also abstractions. They take the properties you define visually like .. colors, spacing, typography, and convert them into actual HTML and CSS and JS rules.
6. Code Editors like VS Code are abstractions. You are not talking directly with the computer’s processor when you use them. These editors usually color the syntax, autocomplete the tags written in HTML intelligently and sometimes with AI, and make coding easier to think about without touching the underlying system that does the heavy lifting.

Make no mistake. Everything is an abstraction. So what does this tell you?

No one works without abstractions. Coders simply operate at a lower level of abstraction, while no-code developers operate at a higher level. Both are building on the exact same foundations. The only difference is how much complexity they are willing to engage with. But the output can be the same or in some cases even better with no-code.

No-code isn’t laziness. It’s could be the most efficient and accessible option for those who learn visually and love to work visually.

The Innovation Argument.

This argument will never, ever end. And I will tell you why. Many pro-coders say that when there is something new in the world of web design and web development, people who code can very easily catch on without having to wait until the visual development environment or page builder implements such innovation.

Is that true? I would be lying to say that it isn’t. Here is an example:

At the time of writing this, there is something new in CSS which was just very recently accepted as a very good alternative to design responsively (that is in a way that adapts to larger and smaller screens). It’s called Container Queries. And it is an alternative (but not in all cases) to Media Queries. At the time of writing this, I don’t know of any page builder that has implemented Container Queries in its interface. And why? Because it’s relatively newer than media queries and they probably would have to think a bit about how to abstract it into a visual interface.

So what’s the general argument?

Well, if a person relies entirely on no-code interfaces, how then would they use innovations that have not yet been abstracted into those interfaces? This… this right here is why I say that this argument will never end. Why? Because there will ALWAYS be something new that has not yet been abstracted into a person’s chosen level of abstraction.

The argument isn’t really code vs. no-code. It’s how far removed you are from the raw materials. Everyone, from the person writing C++ to the person dragging elements in Bricks, is standing on top of someone else’s abstraction. And the one above will always have to wait for the one below.

By that logic, coders also have to wait until advancements below them get to their level of abstraction. And all the while, you can objectively say that even coders were limited at some point until the abstraction gets to them. And you would be completely right.

So STOP with the innovation argument. Of course it would take a little bit for it to get to my page builder, but that’s because of the abstraction level I chose. And by the way, what’s the rush? Afterall, statistically speaking, it takes years for even coders to implement these innovations, sometimes because they don’t understand them, or because they are unstable at first.

How should abstraction be seen?

As what it is. Abstraction. More than people realize, abstraction is the reason why PHP (the programming language on which WordPress runs) is so popular. WordPress is used by almost half of the entire web. Many of those who use it have never interacted directly with PHP. So, if you are pro-code, is your argument that people need to go learn that first before interacting with WordPress? You would notice that most who make this argument have little knowledge about the underlying architecture.

Those who do? They LOOK for abstractions. Because they realize that a lot has been done for them correctly. So why reinvent the wheel?

The argument isn’t really code vs. no-code. It’s how far removed you are from the raw materials.

The WordPress Proof

No-code will always be here. Take WordPress as an example. It’s touted exactly as a no-code tool. As I stated at the beginning of this writ, it does not mean that a person who uses WordPress would never have to touch code. No. But that abstraction helps people reach their destination a lot faster than if they would start from scratch.

The fact that WordPress is used by about half the web is proof that the no-code philosophy works. Has it been propagated by people who promote bad development practices? Maybe. But that’s not the point. The point is that many people would prefer not to interact with any level below the abstraction of WordPress. They like the convenience. And page builders give us exactly that.

There is a reason why WordPress and Elementor are so popular. No-code works.

The Middle Ground Nobody Talks About

I have heard people say over and over again that web designers should not be web developers and that those are two separate fields of endeavors. That they are two separate fields, is right. But that one person cannot be both things, is wrong! Again, understanding the principles both of design and development is the key here.

You would also hear people say that using a no-code builder will get a person stuck because when they need deeper customization, they get handicapped by the provisions made by the interface. Need I remind you of these two flexible functions contained in most page builders?:

The point? If you have to code, you certainly are not limited! You can code. And what does that allow for? Collaboration! That’s the middle ground. Just in case a person does not understand how to get certain things done, they can ask another human or even AI and get code that helps them move past the limit of the no-code interface that they work with.

And I must also mention here, that such limits do not only exist in the no-code context. Even people who only code by hand also face limits, whether technical limits that make them realize that WordPress is not even the place they should have been coding in, or limits of their knowledge, in which case they had better ask someone else or even AI.

If your argument is that no-coders can get stuck from time to time, think again. Everyone can get stuck and will need help. They are not also limited by the no-code interfaces because these interfaces allow you to code if you absolutely have to.

Stop Gatekeeping. Start Teaching.

The argument between No-coders and Pro-coders has been in existence since the first user interface that allows a person to code, but was something other than this:

The command line.

This argument even exists within the no-code world, between Canva users and Photoshop users who believe that Canva users are actually not graphics designers even though the design output cannot be the only thing a person sees that makes them guess what tool produced it.

So, what’s the solution they come up with? Gatekeeping. It’s fear in disguise. And I can understand it. People have spent years learning the syntax of the underlying code/processes. To watch all of that be diluted by an interface that simplifies it and takes a person without such knowledge to the same destination faster? It hurts. It makes their skill seem less valuable. And in this fast-paced world of AI? Sorry to pour salt on your wound, but it’s speedily becoming irrelevant to learn many things.

Here is a question I would leave you with though: When has a professional’s worth ever been about how they build? It has always been about what they build, and whether it works as intended. If a no-code developer uses a visual interface to achieve a clean scalable and functional website, it does not make them less of a developer. In the end, the results are what matters. Not the process.

Nobody, literally no regular visitor to a website clicks on a button and says “oh, this was not coded by hand! I can feel it!” … Not a single soul.

That’s why middle ground matters. Collaboration over competition. So, what should coders be doing now that there is a faster way to achieve the same result?

1. Adopt it.
2. Teach those who are doing the wrong things. Stop competing with them. It’s only hurting the industry and discouraging people who would love to build beautiful things on the web.

The web does not care about the method of building. It only cares that it works. Beautifully.

The Future is Layered, Not Divided.

There is another abstraction currently about to the take the web development world by storm. AI, sitting above page builders, and letting people prompt their way to clean interfaces that they can tweak in the page builders if they so desire. This abstraction is almost here. And one day, I suspect we will debate it out – AI prompting vs No-code Builders. That day is not here yet.

But it’s coming.

I made my case from the start regarding this. And here is the Tl;Dr of it all:

A person should be able to learn to build websites correctly in a no-code interface that allows them understand the principles of web design and development. The abstractions will keep getting higher. Those who understand the principles, not syntax, will never be outdated. They will adapt no matter what the abstraction looks like. Because principles will transcend tools, frameworks, page builders, visual development environments, and whatever else.

The real skill is not in coding. It’s in developing. And many times, developing does not require hands-on coding. It’s a lie that gate-keepers are telling. The real skill is in understanding and implementing the principles that make the development functional, the design awesome, and the website performant. The future of web development is layered. People should work together across whatever levels of abstraction there is, to build things that work.

Innovation may start from an abstraction lower than we would wish for, but professionalism is knowing this very fact and doing things correctly with the tools within a person’s grasp.

The next time a person tells you that you are not a web developer because you use a no-code interface, look them in the face with a smile wider than their imagination would allow for, and say everything I just demystified here.

Every thing!