Ask HN: Is “No Code” the future of web/app dev?

It's been "the future" for 40-ish years now, with dozens (if not hundreds) of failed attempts. At some point, one has to wonder: are we there yet? If not, why aren't we?

To me it seems logical that designers should one day be building frontends through visual interfaces that are almost as malleable as tools like Sketch. It seems to me that many features from design programs (like Framer) seek to make design closer to development, and we've even seen a Git for design workflows. So why hasn't it happened yet, and will it ever?

No-code means programming without text, it doesn't remove complexity, only abstracts it away, covering it with some visual programming GUI.

Here's some problems that I can think of with visual programming:

- Version control: Not only the logic of the system, but the shape of the visual representation needs to be tracked... along with a lot of other metadata.

- Debugging: Visual programs need yet another step of compilation and translation, to go from visual to text to machine code. This makes debugging much harder to implement, if it's even an option.

- Architecture: Visual programming environments are usually optimised for a certain way of doing things. This effectively cements the architecture of your system.

- Refactoring: Without text, you're going to have a hard time renaming variables and moving things around, basically it's back to the mouse... you could go through the text-source files and find/replace variable names, but that defeats the purpose of the visual abstraction.

- Verbosity: Displaying the programs visually - usually a graph of nodes - is extremely verbose and cumbersome. Trying to navigate a large graph/tree and work out what's going on is difficult. Text on the other hand scales much better for large programs.

- Integrations: Integrating the system with obscure libraries is often difficult or not possible at all. Using a library in node or python is simple, in a visual environment you're generally relying on the pre-built components/nodes...

- Vendor-lockin: Visual programming languages are generally all propitiatory making them extremely hard to migrate off.

- High Complexity: A text-based language simply needs a compiler to run, as text-editors are interchangeable. A visual language needs a compiler and a visual editor, which makes development of the system much more difficult and complex.

Basically, I think text-based programming is here to stay. Text is simple, flexible, efficient, elegant and most importantly it's one of the most concise ways to convey logic of a system.

As a follow-up question, I vaguely remember that Dreamweaver was pretty popular to design websites once. What happened that caused its decline?

If the technology for interactive web front ends were to somehow slow or stop changing rapidly... maybe that could happen.

But it hasn't and I'm not sure we're there yet.

And no code I don't think has taken over the desktop world yet has it? That's a hell of a lot more mature area front end wise.

Yes and no. Right now we're in a period of decline of code and want everything to be configurable and enumerable by control panels and slick GUIs, after a long period of needless complexity and broken ecosystems only navigable by domain experts. Eventually, we'll realize that our declarative configs behind our control panels and slick UIs fail at enumerating the complexity of particular problem domains and we'll write scripts to glue together those systems in better ways, and then someone will make the suggestion that hey: we can do this with code!

And then we write the code and our ecosystem gets broken and we build needless complexity, and we realize that 90% of the time a simple config file will work. And then we replace the config with a control panel. And then we need more options, so that becomes a slick GUI.

And so on, and so forth.

IMO we have been optimizing the design of digital experiences for professional/commercial applications for 30 years and we have about 30 more years before we get it "right" and that solution will be (more or less) HTML templates. A declarative low level language that expresses everything possible, surrounded by multiparadigm languages that can compose it, and user interfaces that compile visual representations into those contextually. There's no one best approach.