It's a basic error of attribution.
We need complex systems, and we build them typically by text source, which is the most efficient way of coding a system (as we've found over the decades).
Because the source looks arcane to an untrained eye, people attribute the complexity to the form of the code: text source, and not to the nature of the systems being built, which have some natural level of complexity.
Hence we try to alter the source form in some visual "friendly" way and believe we've achieved further simplicity. Demos looks attractive by connecting 3-4 high-level blocks together that make milkshake, or whatever.
In real world projects, using these visual systems end up even more complex and much less flexible than text source. Rinse and repeat.
Text is so amazingly intuitive that don't even think of it as graphical, but it is. As you also point out, the reason it looks complex is because software is complex.
A full-blown general purpose text-based programming language is of course always more powerful, but a task-specific GUI can be much more efficient for the particular tasks they are designed for.
People who claimed GUI lost something were right, and that's why what was lost keeps coming back and it's still with us.
Google Search, Siri / Google Assistant, and the prompts in almost any video/graphics/3D-modeling software or other professional packages, not to mention the recent craze in "chat bots", all of those are essentially CLI reborn.
First of all, no-code tools are not intended for developers. Although, developers can and do benefit from them by using them occasionally for prototyping and mundane automations. The main beneficiaries of no-code tools are "citizen developers" - people who get paid for something else than software development (e.g. marketing analysts, accountants, lawyers, etc) but who need/want to automate things to be more productive in their main work. For them, no-code is a godsend. It's like not having hands and asking someone else to do something for your with their hands all your life, and then suddenly getting your own pair of hands. No-code is a super-power to them because now they can do things they need but couldn't do earlier. For instance, querying databases without knowing SQL, pulling data from web APIs without having a clue about HTTP, or renaming a thousand of files in a loop. No-code is not about doing everything. No-code is about being able to do something, because previously its target audience could do nothing. Remember that excitement when you wrote your first Hello World program and it worked? This is exactly how "citizen developers" feel about no-code.
Second, no-code is not a replacement for general-purpose computing and never meant to be. There is only a limited set of tasks, that can be efficiently automated using no-code and high-level abstractions - ETL, file/folder manipulations, RPA, certain things from gamedev and ML, and maybe robotics. However, these tasks are very common and no-code saves a lot of time and money for them.
Third, no-code creates a new class of people that can do programming, because no-code is programming. It just uses higher-level abstractions and can be imperative, declarative, or functional. This class of programming is here to stay because it works.
I'll stop here because I can talk about no-code for hours :)
I feel the view of ‘no code / low code’ is a bit primitive here. It used to be like that but last 3/4 years, the entire thing paradigm has changed fundamentally.
A previous company forced devs to switch/add a no/low-code tool. We were given 3 to evaluate: dell boomi/mulesoft/some other crap.
Most devs were gone within 6 months of that mandate coming in to effect.
Horrible, immature, limiting tools.
Do you think the A team devs are building these no-code tools after their initial prototype? No, they're being farmed out to design and development by middling product managers and devs - which never ends well.
What killed RAD tools was the web, not them being a failure.
Maybe what killed that push was proliferation of cheap journeymen: everyone’s niece wanted to be a web dev, everyone’s nephew a web designer, so it was easier to have your nephew or niece build your site than research which low code boxed software of the age would let you do it yourself.
The niece went down the path of PHP, Rails, and node.js+Angular/React, the nephew down the path of Dreamweaver, Creative Suite, Sketch, Figma. Plentiful cheap hands you can pick up the phone and boss around, nobody needs low code.
Now the tide has shifted. Nieces, nephews, cousins, anyone with a knack are all doing it, but the demand outstrips this supply.
So the demand needs more workers or more automation. Code camps aren’t keeping up, but boxed software is now web delivery. Advertising puts it under general public noses.
Anyone can find a way to build a thing (there are a thousand drag and drop app/site builders now), and the average small biz owner reading the marketing then dragging and dropping doesn’t have a clue whether that’s limiting or good idea.
So yeah what killed RAD tools was the web, but also kids. Now the kids on the web are building the next gen of RAD. And the circle of life continues. :-)
Minor nitpick :)
VB6 never had tooling to integrate with .NET.
Rather, .NET could provide an "interop" layer to allow you to consume components written in VB6, or just COM in general. You can also create COM visible components written in .NET that could be consumed by VB6 or even scripting languages such as VB script. But the tooling for that was delivered through the .NET SDK/VS.
But on your other point, you're right, there are probably a bazillion unknown VB apps out there still chugging along doing their one thing for a specific department or company.
(i) higher coding literacy, either from folks already knowing something or companies taking a more active role in providing trading for some minimum set of coding skills.
(ii) more compliance burden and control, i.e. while in the old days people might have been allowed to use Excel macros, some development environment etc., today tools are more likely to be locked down. So a controlled environments allowing people to do limited development and adaptation are of interest.
(iii) Low hanging fruits partially picked. There are tasks that could be automated but where gathering the requirements is too expensive. For example, small tasks done by a few people only - but there are a lot of those. So allowing people to partially automate themselves is a good idea.(and yes, these tasked could well be pretty trivial).
The same way things like Twilio/Stripe/AWS speed up standard development also make no-code development more valuable.
People (on the customer side) want automation that people who nominally aren't coders can build.
People (on the seller side) want sweet enterprise sales with maximum vendor lock-in.
Nothing, really, has changed... that's been the story forever.
> I know Microsoft tried to allow non-developers to create apps without developers
Hence, Excel, Access, PowerApps...
Also, really, the low-/no-code capabilities and empower analysts vs. devs to build tools or perform tasks that would otherwise take one-time dev or DBA time is also a selling point around a lot of the SQL Server ecosystem, e.g., SS[R/I/A]S.
> I know Microsoft tried to allow non-developers to create apps without developers
Yes, and have lots of success and lock-in from doing that.
> But failed!
No, no they didn't.
Oh, I mean sure, their no-/low-code tools require a lot of the same skills to build decent apps that arr required for other software development because coding was never the hard part. But, from MS’s point of view, that's irrelevant to the problem they are solving.
Where before concepts like a logic branch and a loop were very foreign I think a lot more people know what they mean.
Also the industry has learned that 80% of the uses cases are around CRUD and different ways to enter data and view data.
Total failure,
From reading the comments here, sounds like the no-code, the rebranded RAD, has the exact same problems again.
Creating fixed UI is extremely easy to understand. You just put a control, snap it to grid for consistent spacings and that's about it. Everyone can do it, very fast with very little time spent on UI.
Modern computers are highly variable in size. Small smartphones, large smartphones, tablets of all sizes, laptops, 5K mac displays.
Smartphones and tablets expect full-width applications. It's not appropriate to design your UI for 320 px fixed width. It'll be too terrible on larger phones. It's expected to have fully stretchable UI at least.
But that leads to very complex to understand creator UI. Xcode, Android Studio, Java Swing. They have powerful layouts, but their GUI to build those layouts are incredibly complex. You might spend lots of time for very simple thing. It's nowhere near good old Delphi, when I could put few buttons around and call it a day.
Of course I'm not arguing that layout managers are not needed. Another feature is internationalization and it was terrible with Delphi, when you had to translate a button but translated text could not fit into its fixed width. What I want to point out is that there's still unfulfilled need for layout manager, which is powerful, yet very easy to use.
May be we need some AI for that.
I suspect the answer is that they don’t require you to buy seats for all the users, but wonder if anyone is familiar with both.
Not being Salesforce ;)
I worked on a bunch of Salesforce stuff for about a year, including building an app. Can't say I relished that time. I think the thing that seems attractive about Bubble is it doesn't carry the other baggage that you get included with Salesforce.
I know Microsoft tried to allow non-developers to create apps without developers, and they have been trying for decades. But failed! They built an app that allowed you to drag and drop blocks, and they tried a visual query builder(not sure what the exact name was) for SQL. They added a workflow builder to SharePoint.
They all worked great during the marketing demos. But as soon as you had to execute a slightly complex process/workflow/idea, it broke. And that happens almost on day 2 after deployment. The only success they found in automation was by getting non-devs to learn development using VBA macros for MS Office.
How is the current suite of no-code apps different. How will they solve the problem with non-trivial tasks?