
Ask HN: Is “No Code” the future of web/app dev? - zaksingh
It&#x27;s been &quot;the future&quot; 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&#x27;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&#x27;ve even seen a Git for design workflows. So why hasn&#x27;t it happened yet, and will it ever?
======
gitgud
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.

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

~~~
tmaly
What version of Scratch are you using?

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

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

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

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

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

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

------
godot
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](https://news.ycombinator.com/item?id=23298080)

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

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

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

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

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

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

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

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

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

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

------
thepoet
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...](https://technotes.substack.com/p/no-code-the-revolution-that-wasnt)

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

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

~~~
duxup
AR has been oh so close for decades ;)

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

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

~~~
woah
How is the field of view?

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

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

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

------
verdverm
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](https://github.com/hofstadter-io/hof)

