Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: Is “No Code” the future of web/app dev?
47 points by zaksingh on June 30, 2020 | hide | past | favorite | 36 comments
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.


> Version control

The other day I tried to reverse engineer a lego mindstorm program from a pan across it in a youtube video(stitching together screenshot frames with Hugin panorama editor), only to find that that visual language was dependent of a silverlight app, and OSX had deprecated it, so I could only use scratch to re-create the logic. Then the scratch editor crashed and corrupted my project file, which when opened in a text editor was just a big encoded data blob. So I started from scratch and took to copying the file (file (1), file (2)..) every so often.. I did not feel like the future to me..


That sounds like a workflow issue. Instead of arbitrarily renaming files, which is what we used to do back in the 90's, 80's and probably before, you could have used something like git to take care of backups and version control.

Of course it doesn't feel like the future when you are maintaining your code with something other than modern practices.


What version of Scratch are you using?


I was using the lego mindstorm classroom program that has scratch built in, so I'm not sure of the exact details. It autosaved the project on every change, and didn't even tell me where it was keeping the files. The first time I was using it, it suddenly told me it couldn't open my project. So I found the save folder and just duplicated my recreated project as I went along. Not an ideal workflow, but fine for a few hours project.


The new Scratch 3 works right in the browser. There is a Lego Mindstorm extension for it, you just have to install this program called Scratch link to bridge the web to the hardware.


This is a comment about graphical programming interfaces, not no-code. No-code also encompasses tools such as Airtable, which can be used to make a great number of different serviceable crud applications without anything resembling programming.


Would love to hear your thoughts on our "low code for devs" as I have tried to eliminate many of (my shared) complaints about low code as a dev. Text based so you can use your IDE and terminal

https://github.com/hofstadter-io/hof

(sorry to post link twice in same topic, but seems helpful.to have it in the two spots more than not)


Excel is likely the most used IDE of all time. We’ve been living in the no code business application future for 40 years.

I can stand up a cluster of web servers that automatically scale to effectively infinite demand with a few clicks on the internet.

I can design a front end without paying attention to code and have been able to for 20 years.

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.


I feel like people here underestimate how much work can actually be done without having to write any code whatsoever.

There's the common cases with businesses being built on top of a pile of Excel spreadsheets. It is also easy to take for granted, but things like hosting your own website, or setting up an e-commerce service could be done without much code for a very long time now.

But the cool thing is that nowadays, it is possible to do more sophisticated things, like spinning up interactive web apps that are backed by self-hosted databases with authenticated APIs, all without writing a lot of code. Is this a good way to build things? Maybe. It wouldn't be the most maintainable stack, but the barrier to entry is pretty minimal, and that makes it worthwhile.


> businesses being built on top of a pile of Excel spreadsheets.

But, "=SUM(A1:A10)" is code. Spreadsheets have a visual layout and mental model different from other programming languages, but they are code none the less.


> It wouldn't be the most maintainable stack, but the barrier to entry is pretty minimal, and that makes it worthwhile.

I still don't know whether that's really true.

On one side, there's the observation I've made with low-code (having been at an org and bailing right around the time they started going down that road;) When I was at the 'free training' (just a sales pitch) most of the people there were from other medium to large size companies, a couple of those companies multinational.

B/c the sales pitch I've seen isn't to startups; it's to bigger orgs. It was actually pretty disturbing to listen to the sales rep explain as developers would leave through attrition/disgust at the product they could be replaced by 'non coders.' No, it wasn't exactly said like that but the sentiment was understood by all the developers (not managers) in the room.

Okay, so lets say that they clean up their sales act (lol) and actually start to go towards smaller business.

Those business are still going to wind up with a product that may or may not be maintainable long term, but are now guaranteed to be paying yearly licensing costs.

No thx.


I used to use a spreadsheet in all my forensic reports. The ability to instantly sort between timeline and specific subjects or groups of subjects was extremely useful. Even during an investigations, you could coax out some connections and relevant details you might not notice in any other way.

Since I don't really do any math or accounting, I suppose spreadsheets are a type of flat-file database.


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.

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 syntax 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:

> 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.

"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.

1: https://news.ycombinator.com/item?id=23298080


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.


'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.

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.

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.

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...

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.

A similar problem occurs when a bug or unforeseen configuration breaks the no code veil. This is referred to as the 'leaky abstraction' problem.

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.

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).

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.

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).

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.

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.


Or, as happens a lot in no/low code but also in code-heavy (normal) development is that this 'corner case' feature is just taken out of scope. That eliminates it too as well as a technical solution does.

Basically; you can run a rather medium sized company on google docs or ms office or a bunch of trivial crud apps hacked in php/AD; I know rather a scary amount of companies that do work like that. They are not the biggest companies (I know of at least one that has well over 150m revenue/year for the past 20 years; most others are smaller) but they also spend almost nothing on (that kind of) IT and it works. The corner cases are removed from the business process instead of hacked into the IT flow.


My experience with " no code" reinforces the issues raised in ex other comments, with a little emphasis to add:

If you never learned your times tables, then used a calculator, imbedded calculation loops are tricky to troubleshoot .

" 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.

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.


Not all low code platforms use interpretation or dynamic code creation. I work on one which is language agnostic / polyglot (see other comment here) and have seen more examples from other devs / competitor demos. You can think of this probably more like code gen for stubs, but one place to write in Cue and multiple tech / language outputs (for our Hof tool).

You are right about the complexity hiding and difficulty therein. It's part of the reason ours is open source.


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.

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.

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.


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


As I recall (using it as a hobbyist and student, not a professional) it was primarily geared towards static sites. As people moved more towards dynamic sites (or automated upload of new content via things like content management systems) it fell out of vogue.

People who still wanted static sites often kept them simpler and made them by hand, or used some scripts to tack on the complex parts (consistent nav bars, headers, footers, etc.) in a "compilation" step.


I feel like once Adobe bought it it started to just not be worth caring about anymore. But... that was a long time ago.


Pure no code in the current form may never catch on. I wrote something on No code this Sunday https://technotes.substack.com/p/no-code-the-revolution-that...


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.


Just wait until AR like the Hololens 2 comes out, all of UX and design changes.

Some examples are 3d fonts and signage, interfaces without windows (widgets just float wherever), whole new deaths of UI elements and building blocks. Oh, and the mouse is gone in favor of hand tracking and the most amazing digital interaction I have ever experienced. One week in and my mind is still blown by the possibilities.


AR has been oh so close for decades ;)

Granted ... SSDs finally came to PCs too, eventually ;)


HL2 feels like it's here, it's so light and comfortable, and the experience is not something words can do justice for


How is the field of view?


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


A lot of non devs use it for Business Process Automation. Dashboards and forms for smaller data sets / processes mainly


The upcoming generation can't even type, they grow up using cellphones instead of PCs. Of course it is.


I'm working on a "low" code platform for developers (use your IDE, write in the generated code, iterate / redesign / regen )

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.

https://github.com/hofstadter-io/hof




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: