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?<p>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 <i>text</i>, it doesn't remove complexity, only abstracts it away, covering it with some visual programming GUI.<p>Here's some problems that I can think of with visual programming:<p>- Version control: Not only the logic of the system, but the <i>shape</i> of the visual representation needs to be tracked... along with a lot of other metadata.<p>- 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.<p>- Architecture: Visual programming environments are usually optimised for a certain way of doing things. This effectively cements the architecture of your system.<p>- 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.<p>- 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.<p>- 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...<p>- Vendor-lockin: Visual programming languages are generally all propitiatory making them extremely hard to migrate off.<p>- 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.<p>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.
Excel is likely the most used IDE of all time. We’ve been living in the no code business application future for 40 years.<p>I can stand up a cluster of web servers that automatically scale to effectively infinite demand with a few clicks on the internet.<p>I can design a front end without paying attention to code and have been able to for 20 years.<p>No code is like AI. The goal posts keep moving. So you need to be more specific when you ask if it’s what’s next.
In my mind, "no code" doesn't really exist. All that exists are different programming languages, some of which are visual and require less learning. You could, principally, design a no-code web app IDE that could build whatever website you like; but that doesn't remove the complexity of building it, it's simply expressed in a different way. Seeing programming as some nuisance is, IMHO, the wrong mindset; it's the very process that transforms requirements and expectations into a product. True "no-code" would require human-level (or at least very advanced) AI systems.
Of course, for very low-complexity systems, you can define a graphical programming language that abstracts away most of the technical details (e.g. Dreamweaver, stuff like Wix),
but even that is a very primitive form of programming. Excel is also a form of programming.<p>Also, I don't really get the hostility for code as a textual format. Text has a number of advantages that just haven't been replicated; it's a very compact format, reasonably standardized, can easily be refactored and can be universally edited. Also, I don't think it hinders learning about programming; learning the programming language <i>syntax</i> is the easiest part, IME. It took me about 4 weeks when I was 14 to learn Java. Learning how to solve problems with the language is a whole different ballgame and that wouldn't be solved by having a graphical programming language. There are cases where it is advantageous (e.g. Excel), but for the majority of use-cases, I think you'll find it hard to get more productivity with a graphical format.
I think one of my favorite HN comment from this past year [1] addresses this a bit:<p>> Software has really interesting economics where as the cost/feature decreases by a factor, say 1x, then the set of features that can be profitably worked on expands by like 10x, so paradoxically, as cost/feature decreases, it makes sense to hire more engineers and expand R&D budgets.<p>"No code" is part of this, IMO. If a "no code" tool made certain things easier (e.g. building a landing site with some functionality), then the business starts to see the next set of features that can/should now be built because that previous problem was solved, that can't be done with a "no code" solution and needs some R&D effort to build out. The cycle continues as "no code" tools get more advanced to cover those use cases, and then more new business use cases will come out as a result of having those new tools in place.<p>1: <a href="https://news.ycombinator.com/item?id=23298080" rel="nofollow">https://news.ycombinator.com/item?id=23298080</a>
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!<p>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.<p>And so on, and so forth.<p>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.
'no code' usually does not just refer to a different type of editor, like a visual widget composer. It usually implies the creation and specification an now be done by a person that does not need coding skills.<p>The latter is not impossible, but there is a tradeoff. As computers have endless capabilities, a hue number of design choices need to be specified in order to select/create the specific outcome desired.<p>This required information need can for the end programmer/designer be reduced by shrinking the potential design space through premade implicit descisions. Creating a 'stopwatch' app from scratch starting with a blinking cursor in an empty text file will require a lot more specification than creating it in a dedicated graphical stopwatch designer where all that is still needed is specifying the color of the start/stop button, but the former leaves you endless more possibilities than the latter.<p>Getting the above tradeoff right usually runs into the 80/20 situation. You can live with 80% of the choices made, they cover 80% of your needs, but for the rest...<p>And now your non-coder runs into a problem. Not only is the skillet promise now void, the higher level abstraction made in the 'no code' model is not crisply delineated, so the coder brought in to finish the job now has to understand the complexities of the code underlying the abstraction where the design tradeoffs were chosen not in favor of this under the hood meddling.<p>A similar problem occurs when a bug or unforeseen configuration breaks the no code veil. This is referred to as the 'leaky abstraction' problem.<p>In the end usually you still need a coder that understands the lower level. And specifitions for highly open systems are more efficient conveyed and maintained through textual 'code' than through other types of graphical editors.
The web is, at it's heart, a distributed document system with a layer of hacks on top for building applications.<p>You can create pure documents for the web without any code. Documents are, by nature, easily expressed declaratively; and it's not impossible to build an intuitive interface to express declarative data visually (or hide the data aspect completely in the case of a WYSIWYG interface).<p>Modern web pages are, in my mind, a sort of document/application hybrid (with few exceptions as of 2020). We have yet to find a better way to express an application than through textual code.<p>Procedural code is branching and time sequenced; how do you express that in a meaningful way visually? For some reason our imaginations find it easy to understand that the side effects of every line before this one are still around, and we're pretty good at picking up the concept of branching and jumping around the instructions; but I believe that's because the code is essentially a sequenced list of commands (and our brains are good with sequenced lists).<p>The attempts I've seen at visual programming remove common programming capabilities to fit more neatly within their visual medium; as long as that is the case, I don't see visual programming breaking out of being used strictly in DSLs (domain specific languages), which are often inherently limited.<p>I don't think a no code future is likely, as long as custom software is in demand; however I can see a future where fewer technician type roles require code. Of course that would require someone to spend a lot of money building a standard visual vocabulary of related tasks, excellent ergonomic interfaces, and extensible GUI systems; the type of things the FOSS world hasn't built much of a community for as far as I am aware.
I think the general problem with "No code" as you describe it is that if you want to only offer the lego building blocks then you can't support corner cases. If you want to eliminate all of the corner cases you often times end up creating something as complicated as code but without the nice tooling or information density.
My experience with " no code" reinforces the issues raised in ex other comments, with a little emphasis to add:<p>If you never learned your times tables, then used a calculator, imbedded calculation loops are tricky to troubleshoot .<p>" no code" layers this more deeply, creating a very large number of programming code lines, function calls and subroutines on interpreted code that runs slow anyway. It can be difficult to untangle when things just don't work right.<p>Interpreted code always runs slower that code compiled into machine code. Maybe adding in AI and machine learning will eventually be able to take this first-rev , " no code " prototyping and optimize it into an efficient, effective, fast system that is bullet proof, and intellectually protected.
I think no/low code stuff has its place. For example, our product guy can build our landing page using Webflow and doesn't need to bug the devs, who can focus on actually coding our product.<p>Would we consider a no code product to build the fundamental pieces or our actual product? Likely not based on the tools I've tried over the years.<p>Wish it wasn't so though. The disconnect/handover from design to implementation is still a bottleneck. Tools like Figma offer ways to export CSS, etc. but that's not really the main pain. The real time sync is in coordination, iteration, time spent on designs that change out from underneath you, etc.
Pure no code in the current form may never catch on. I wrote something on No code this Sunday <a href="https://technotes.substack.com/p/no-code-the-revolution-that-wasnt" rel="nofollow">https://technotes.substack.com/p/no-code-the-revolution-that...</a>
If the technology for interactive web front ends were to somehow slow or stop changing rapidly... maybe that could happen.<p>But it hasn't and I'm not sure we're there yet.<p>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.
What are the common users and use cases of no code? I feel like it's well worth the investment to spend a year or 2 learning serious programming or just hiring a team if someone wants to get into the software space so kind of confused by the movement
I'm working on a "low" code platform for developers (use your IDE, write in the generated code, iterate / redesign / regen )<p>Docs are a bit MIA, so I haven't pushed it much yet, but you can check out the lib/gen dir and the Cue files for examples. I'm very curious to hear what more developers with strong opinions about low code think.<p><a href="https://github.com/hofstadter-io/hof" rel="nofollow">https://github.com/hofstadter-io/hof</a>