I started building "no code" tools since 2004. I am also the author of codeflow - a not yet open sourced visual programming platform. I wish no code distinguish

I started building "no code" tools since 2004. I am also the author of codeflow - a not yet open sourced visual programming platform. I wish no code distinguishes between frontend no code(webflow, wix etc), backend no code(codeflow, mulesoft etc) and full stack no code(outflow, mendix etc). First of all this "no code" is being used for decades in fortune 500 companies and many of their major backend services are run on yesteryear no code. In fact it wouldn't be wrong if to state that all big financial companies use no code as part of their major backend stack (its called in different names such as middleware/soa/integration/etl etc), but they are all visual, drag-and-drop backend/business logic builders that would have required complex coding without them. In my decades of experience there are of course many ups in no code, but as with any paradigm, the downs are highlighted the most and especially when you want to disrupt the text-based programming world that existed for almost a century now. The major complaints about visual programming environment (backend) are: 1. Code is more expressive for experienced devs Its true that code is much more expressive than generic graphical programming platforms for writing algorithms.. But how many of us write algorithms on daily basis?. What all of us do is glue various reusable pieces together to build the business logic. And for gluing graphical programming is actually superior - you can discover easily, dependent fields can be expressed easily etc. You need to use code in a properly designed no code system, but it's only 5% of the project. Now coming back to code being more expressive, if you look at algorithmic visual programming platforms designed for expressive coding like DRAKON (https://en.wikipedia.org/wiki/DRAKON https://en.wikipedia.org/wiki/DRAKON), you can see that they are equally good or even better than coding. 2. No or degraded version control experience. This is true as visual programs are still written to file as xml or json and there is disconnect between committing that vs seeing actual programs as graphs. This is a difficult problem to solve. 3. Incompatible or poor tooling This is related to above point. Because visual programming tools need to distribute with a custom made IDE, the common tooling and CLI other available for generic text based programs can be lacking. 4. Hitting a wall This is one of the biggest drawback I have heard from the devs so far. To be honest which programming platform have not made you hit a wall? In node.js you hit the multi-thread wall, in Java you hit the thread safety/performance(high memory usage) wall. In python you hit the performance wall. How do you solve it? Well in python you solve it using C or ASM libraries - and expose it to python. but you seldom hear a cry from python devs saying they reverted to C because python is slow or lacking.. Cos you learn to use the right tool for the right purpose. Similarly a well designed visual tool will let you do few things extremely well, but like no single programming platform can do everything extremely well, same is with no code or visual tools - for e.g. see DRAKON for writing expressive or algorithmic code. 5. Performance not on par. Most of visual programs tend to not focus on performance as the priority is different. However this can be solved with compiling the graphs to native code. When we built Codeflow, we tried to solve 4 and 5 and in our opinion we succeeded to good extend. 2 and 3 requires more effort from the vendor and the community (which is hard because every visual tool is unique). and 1 is possible but require more research. One way to think about visual programming is this way - imagine a world where graphical vector image editing tools evolved without mouse - i mean you literally have to code everything - right from the pixel you need to edit, the selection - everything. Smart designers (or more of coders) became experts in it and they can produce some great quality images. The tooling is also great as the tool existed for decades with hundreds of libraries and ecosystem surrounding it. Now you come up with a new paradigm where you can use mouse and make it easy for novice designers to use it - there are two benefits you tout - More artists as opposed to coders can now create images - its much more easy to build the images. The coders on the other hand are not in favour of the new tool both subconsciously and consciously. Consciously because the new tool, while better in many aspects are no where near the previous precise tool in expressing the image - and tooling as well (version control, transformations, plugins etc). Subconsciously because somewhere they feel their decades of experience is not relevant anymore.. this is controversial but i have felt it when interacting with senior devs. (Similar to how many don't want to move away from vi/m to vs code for e.g).