Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What do you think about the no-code movement?
348 points by arrayjumper 67 days ago | hide | past | favorite | 395 comments
Hi HN, maybe it's just the bubble I'm in but these days I see a lot of discussion around "no-code" and the "no-code" movement. There's also a bunch of new no-code apps being launched every day - https://www.producthunt.com/topics/no-code#order=trending.

Some seem to supplement developers (eg: retool) and some empower non-engineers to be able to build websites/apps/integrations without necessarily having a developer in the loop (eg: shopify/zapier/airtable).

What do you think about this movement? Clearly these apps/platforms enable non-developers to solve a bunch of problems which would otherwise need a software engineer. Is this a paradigm shift?

It's interesting, but always calibrate their claims against the fact this is about the tenth time this movement has come around. This movement literally goes back to COBOL. That is not a typo. It's not only likely older than you are, but probably much older than you are.

I recognize COBOL may not seem like "no-code", but that's just because "no-code" is a stupid label. "No-code" doesn't mean "no code" just like "serverless" still runs on a server.

I would say the main problem with the no-code hype is the idea that it is a leader. It is not. It is a follower. "Normal" code goes out, hammers things out over the course of literally decades, and then, when it has finally settled what the best couple of ways to do something is, it's finally time for the "no code" solutions to come in and systematize that for a larger audience. Nothing wrong with that. Power to the people and all that.

It just goes wrong when no-code advocates put the cart in front of the horse and make grandiose claims about replacing all developers or something. That's not the direction the stream flows in. No-code can't operate without the "normal" developers doing immense amounts of work charting the territory and building the infrastructure to get there. There is no chance of them displacing "normal" software developers; they are structurally incapable of it. Woe unto the no-code startup that doesn't understanding this dynamic, and foolishly tries.

Things we agree on: ignore everything no-code proponents say about their tools or capabilities

Things we disagree on: code before no code

My experience has been that actual code is always superior* to no-code, because no-code is always more complex. E.g. the no-code developer environment + code (in whatever designer form) + interpreter / runtime / libraries + any integrations + actual generated code.

Consequently, business critical functions should be in actual code, if it's an option.

So where and why to use no-code?

As a prototyping tool, no-code before code, because it inverts the pyramid (few developers, many users) by making users into prototyping developers, and it makes the best use of scarce resources (code developer time).

No-code written by users allows you to waste user time figuring out all the things that are typically missing in a business spec, without wasting developer time. Then, when they've figured out exactly what they want (because it works!), developers can come back and do exactly that.

This usually involves throwing away the no-code model when coding, because it's probably not going to be architected well, but does provide a concrete, tested, proven spec.

So essentially, the company gets version 2 of the code, at the cost of 1x user time + 1x developer time. Instead of version 2 of the code, in 2x developer time, which is too expensive and never happens.

* From a TCO, maintenance and reliability standpoint

I suspect you are talking at cross purposes. You are suggesting no-code first on a micro timescale. For prototyping. That seems like a solid suggestion and use of resources.

But from the GP, I read a statement on the macro scale. No-code can't codify turn-key pluggable building blocks until the problem spaces of those blocks have been thoroughly explored by code solutions, and a small number of "winning" configurations identified.

Sure, those blocks can be plugged together to prototype "novel" line of business "problems", but I think there's a disconnect in the kind of problem spaces you are talking about.

The "solved" problems that the no-code widgets represent still need to be solved by code first. And expectations continue to move.

We have a different definition of no-code, I think. I wasn't including any tools that don't offer generic enough primitives to build an arbitrary business process.

If we're reducing no-code to "things that have been written in code first, that can then be plugged together by the no-code user", then we're talking about libraries with a visual designer on top.

I think you’re thinking higher level than the other side of this conversation thread? Maybe a better way to describe it is that you couldn’t build something like Retool (which is super cool, I like it) without a lot of prior formative design around CRUD and repeatable consistent model handling even across very different data stores and dealing with double-sent commits and the like.

No-code approaches need to be prescriptive about how they deal with systems and it takes a long time to get to the point where we know how to do that in a way that won’t infuriate people.

I guess here is where "no-code" as a big-tent term breaks down.

Most of the targeted products in the space seem like they can be expressed as "I know how to ___, but I don't want to ___" (f.ex. Retool looks like: write a query, write a UI). Which, yes, trade opinionated design for design time efficiency, which is most of their value.

On the other hand, you also have no-code frameworks which are icons and a designer wrapped around primitives that afford you enough access to control flow and variables to build anything you could code. E.g. Node-RED, UiPath, or Power Automate. Which don't need to be very opinionated, because their entire purpose is to be a build-anything toolbox.

So it's probably more useful to differentiate focused no-code products from general-purpose ones.

> Node-RED, UiPath, or Power Automate.

All of which have teams of developers behind them, maintaining the code that underly those control flow constructs and form the higher level abstractions that the low code user interacts with.

Yeah - where I've seen those things used for more than trivial things, there's usually a developer in the org who's handling the places where they fall over.

UiPath (and similar) as a "no code" solution is a bit of a joke (on those that don't know any better). Don't get me wrong, I think it's a good application for automating processes or certain types of jobs, but a lot of coding has to go into it. Often you are typing lots of VB.NET or C# code into boxes.

What's often really going on, is often "packaged libraries" that you add to do a task, then lots of typing of sort of "glue code" in boxes to get them to work together. Which can lead to getting bit in the butt with the problems of "no code visual programming", where there is boxes on top of boxes hiding stuff and potential troubleshooting headaches.

Often, the team needs a "real programmer" or close to it, that can handle the heavy lifting, troubleshooting, or custom solutions.

Sure, your no code system can be Turing complete. Lots of things are accidentally Turing complete. But at that point, aren't you just coding with a different interface but all the same problems and complexity? And (as argued already elsewhere in the thread) none of the tools and support...

I agree that "arbitrary business process" is a smaller target. But it's one that grows over time (see GP comment) to include more and more "solved problems" that were solved by lots and lots of code.

>So essentially, the company gets version 2 of the code, at the cost of 1x user time + 1x developer time. Instead of version 2 of the code, in 2x developer time, which is too expensive and never happens.

Not sure why, but in my experience the difference has been closer to 1x user time + 1x developer time <> 4x developer time.

I believe empowering a customer to think along — be pushed to their limits, even — within the boundaries of a system's technical/business domain _from the very start_ is likely to dramatically improve a system's design.

From a technical perspective it may not be architected well, but in terms of user <> business fit it probably will be.

SQL is no/low-code compared to using a low-level database like BDB for a given level of power. And yet it's much simpler for most use cases.

By the same token, C is low-code compared to assembler, Python is low-code compared to C, and Steel Bank Common Lisp is low-code compared to Python.

Using the same kind of reasoning, JavaScript is a framework and JQuery is no code. Or maybe React and Angular are no code and JQuery is low code? We basically need a firm, objective basis for determining what a thing is. The question is: what is it?

> My experience has been that actual code is always superior* to no-code, because no-code is always more complex

Yes, usually an order of magnitude more complex, even.

Maintenance is a big issue when you are using a no-code system to create another system which someone else will use (e.g. to create a business application).

But if you are using a no-code system to create an artefact (e.g. to wrangle data into a new format) then that issue isn't so relevant.

I used to think this as well, that No Code was not a real development to production level option. I have very much been proven wrong. I transition recently from 15+ years as a developer to contracting for a no code platform. Virtually everything a regular web dev can do in code can be done in no code. Sometimes its easier to do in code and sometimes it is much easier to do in no code so mileage may vary but no code is very much a mature technology now that can produce applications to the same scale as regular web 2.0 coded software.

I've been consulting in no-code platforms, in addition to writing actual code, for about 8 years. Producing something that works isn't the problem.

Maintaining it is.

The legacy codebases from this stuff are dumpster fires, because most of the tools are closed enough ecosystems that the companies supporting them have to reinvent every programming best practice from the last 30 years.

'Version control? Sure, that's a feature on our roadmap that we'll get to at some point...'

In addition to going back to the bad old days of limited-use, proprietary compiler problems. 'Oh, that bug? Yeah, just don't do that.'

Furthermore, unless you choose very carefully, you're playing right into vendor lock-in, and a lot of the people buying this stuff aren't technically proficient enough to realize that.

Once these companies hit the end of the easy growth ramp, and the industry turns into monetizing & squeezing existing customers, there's going to be migration pain on an Oracle scale.

Maintainability is always the issue, even for the things made from code.

What do you think will happen if the no-code platforms become open source?

Every general no code platform I've worked with has had an order of magnitude (sometimes, multiple) worse maintainability story than code alternatives.

And admittedly, maybe I've worked with a series of terrible ones, but I've also worked with a lot of popular ones that big enterprises are adopting.

As for open source, I'd say zero percent chance that happens, because no code solves problems developers don't have: (1) I want to write code, but I don't know how to code & (2) I need to integrate a lot of really boring, legacy, usually-Windows apps.

It's the "Why are there no polished open source desktop environments?" problem from the 90s, multiplied by ten.

Which I think is why you see what open source no-code tools do exist focus on web, because that's closer to what their developers are curious about.

Based on your experience would you be comfortable to list a few of the no-code tools to avoid when taking maintainability into account? Would be useful.

Names seems a bit specific, but it's easy enough to think in terms of basic software hygiene practices: things we expect our languages and their ecosystems to provide in traditional code these days.

Is the "code" serialized to a text readable format, for storage and parsing by other tools? Can I get a copy of that serialization? Can I regenerate the effective program from that serialization?

Are there methods for appropriate modularization and encapsulation?

Is there a coherent versioning strategy that allows for controlled updates, down through dependencies?

Can I check it into standard source control? And does it play nice with the expectations therein?

Basically: everything you were taught in undergrad for software engineering & at your first job

The biggest problem with the industry is that it's being sold to people who know none of that, or they're being told that doesn't really matter here, because this isn't code and thus doesn't need all that.

People who have maintained these systems know the level of pain is much worse than nearly any codebase. No code solutions that end up mission-critical can stay active for decades.

We have solutions from the 90s that, thank the heavens, I don’t have to work on them. If I did I would probably quit. But the business has to keep the thing chugging along, and it’s _very hard_ to get out of.

> no code is very much a mature technology now

How is "no code" a technology? Aren't there a variety of "no code" technologies?

I'd be interested to hear which ones you are seeing that can produce applications similar to ordinary software development! Like... it's probably not WordPress or SharePoint.

Unqork platform is pretty robust.

OK, but web development is an area that jerf would probably classify as "solved".

I like this idea, but does it work in praxtice?

My first job out of university was working with a very large firm that bought into Computer Associates' product suite - including 4GL code generators such as Telon ("green-screen" generators) and Easytrieve (4GL report generators). From what I recall, we spent 90% of our time trying to work around the code generators to accomplish tasks, as opposed to simply using native CICS, which was difficult to master (hence the 4GL). I've since used a number of 4GL-type tools, and they've all had the same limitation in that the tail wags the dog, to use an old idiom. Quite fast and seemingly magical if you stay within the guardrails, but as soon as you veer off course (and unless you don't want any differentiators, you will) they quickly become far more onerous than hand-coding, plus lock you into their 'forced march': cost, upgrades, incompatibilities, and so on.

As an aside, it was a very interesting time to be a developer as we had a mix of youngsters (me), who were raised on personal computers, many people seasoned on mainframes/mid-range computers, plus a few "old-timers" who started coding in the 1950s without any formal training. Everyone had great stories, and I feel lucky to have been exposed to people firsthand who were some of the first programmers (and they universally thought everything above assembly language was 'cheating'). Their stories and perspectives have stayed with me throughout my career.

I knew a team that did 4GL on AS/400s (generating RP4 I think) and they were all about how superior their tool was and how terrible the Java team was in comparison and how they would never be out of a job. Within a couple years none were programmers any more as their tool was abandoned and they had no other programming skill.

Where did they come from, and where did they go? Business analysts that were given no-code tools, thought themselves the new-wave programmers, and then faded back into analyst/architecture roles?

The first time I encountered something that called itself "no-code" was when the internet portal I worked for (Remember those?) decided to offer a "webpage builder" for its users. I didn't work on it, but just looking at the limited webpages you could build with it, how all of those were basically just our best practices, and how the amount of code needed to support the builder was just massive compared to the code it generated, it was pretty clear to me that my job security wasn't threatened.

Every single solution like this has an edge, a limitation, and when you reach that edge, the answer is always "well, you can edit the code directly if you know what you're doing..."

It's exactly as you say, every solution like this can do the already mapped parts of programming, but they are fundamentally incapable of being used for the unmapped parts, the woods, the edges, the limits.

I remember my father coming home in the 80s from work with a book detailing an environment they built at the company he worked at for creating complete business systems by just configuring building blocks; no code at all. You modeled the data, modeled the screens, modeled the processes by picking options of screens covered in dropdowns and input fields: the end result was a working system. Sounds familiar? It was extremely close to Bubble with a different GUI. It worked until clients asked feature that were very hard or impossible to make and they add to add features or code extensions; after a while they noted that many projects were just extensions upon extensions. They ended up taking out the modeling part and use it like UML type of thing, but the no code was removed in favor of people writing it manually following the modeled parts.

Yup, this is a very old hype cycle. Seems that every bunch of years, the industry has to relearn it. Yes, they can be useful for some situations, but the limits close in fast, and soon you will have to deal with real logic, concurrency, etc, as well as product limitations, and vendor lock-in.

And there are multiple reasons that corps separate development tools from ordinary users. First is that it is a very short path until the project will encounter questions that require actual development training and expertise to get right - and there are 100 wrong ways to get it wrong, many of which will create real damage & business costs.

And the other perhaps best described by the exec who said (a few decades ago) that "I don't want to turn a great senior $200k analyst into a mediocre junior $35k BASIC programmer at the same cost".

So yeah, giving users such tools to hammer out prototypes to give better specs to developers ican work great, but thinking that the latest "no code" tool is the end of it is foolish.

COBOL. SQL. HyperCard. Visual Basic. Spreadsheets. Yeah, same song, next verse.

In some ways it's like AI, though. Once it succeeds (at what it can do), then it no longer is "no code", it's just it's own niche. (We don't think of SQL or spreadsheets as "no code" any more; we think of them as their own categories.)

I mean, spreadsheets are not nothing. They're useful for a segment of things. They didn't replace web programming or embedded real-time or machine learning, though.

I remember articles early on during the release of SQL that promoted it as a way to reduce the need for programmers because it would allow managers to access all the data they wanted through natural language. Things didn't really turn out that way.

I took a course in COBOL when I was in Unversity. The professor was in industry but taught one night class a semester.

He started the class by talking about how when he learned COBOL, they told him this would make developers obsolete because it would let managers build their own solution. In his experience, it made developers even more valuable because “give a manager five minutes with a codebase, give a developer a job for five years cleaning the mess up.”

As a software engineer, the business data my manager wants is basically in Jira and even if they provides a (supposedly) user-friendly UI, they also offers their powerful JQL. And at the end of the day, each times my manager wants something specific from Jira, he comes to me so that I can provide him with the right query. And he's supposed to have a technical background, so I guess it's even worse with non tech people.

I totally agree, and this jives with my feeling that no-code is an evolution or a codification of the best practices and principles "hammered out" as you say over the years by regular software development.

The Tao gave birth to machine language. Machine language gave birth to the assembler.

The assembler gave birth to the compiler. Now there are ten thousand languages.

Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.

But do not program in COBOL if you can avoid it.

- The Tao of Programming (1987)

I remember an ad in the programming rags of the 80's that ran for about a year. It advertised (from my memory) "no coding required! Just use our script interface!"

[No|Low] code platforms just breed a new class of consultants instead of empowering end users due to the simple fact that [no|low] code is still too technical.

> It just goes wrong when no-code advocates put the cart in front of the horse and make grandiose claims about replacing all developers or something

"no code" like most IT industry buzzwords over the last 70 years, is mostly bullshit but with a kernel of useful truth.


The funny thing about no code is that after delving into it for 6 months as a non-technical person and realising its limitations it pushed me to start my code learning journey again.

It has its purpose for prototyping and some early validation but...

It gets expensive... it gets fragmented and you are closed down to one ecosystem (hello Bubble).

I hacked things together with airtable, Webflow and Zapier. It aggregated to hundreds of dollars per month in costs. I also found myself constantly trying to find some workarounds and in fact there are additional app extensions to Webflow that allow to create even basic functionality like search or multi-filters.

Long story short it has its place for specific purposes but even then I would still rather learn how to spin-off netlify or vercel and put a boiler plate with mailchimp online to test my hypothesis rather than mapping data strings in Zapier for as simple as form collection fields.

I though must thank no code for getting me back into code! I am still a newbie but I am enjoying every moment of my javascript journey (is it a masochistic thing to say considering all the frustration with bugs?)


You just have to look at WordPress / Squarespace / Wix / Weebly / I forget the rest ... for examples of consumer-oriented platforms, however you define the term "consumer," that promise no coding needed for the average user - but you'll get a better result if it's built by a fluent developer who isn't constrained by the platform's conventions.

The brain is great at imagining stuff “we could build that, and you’d have this and that…”. And a lot of the time you can build it but it requires code.

Using a tool that avoids code always means either compromise or you are really coding but in an inefficient ui (eg building a budget app in excel)

COBOL never claimed to be "no code", but what it did claim was that it would significantly lower the level of training required to program. Which it absolutely did. Before compilers, you had to program in machine code which was extremely tedious and error prone and required a detailed understanding the microprocessor and computer architecture.

COBOL may seem clunky compared to modern languages, but the productivity improvement going from machine code to COBOL was likely larger than going from C++ to Python. COBOL have a bad reputation these days, but this is only because of how successful it was, leading it to still being used for mission-critical systems.

Well and having to maintain legacy code written by people who had received only little training.

COBOL isn't older than all of us!

Completely agree, and it makes me wonder if we are at the edge of standardization for many types of applications. The desktop, tablet, and mobile form factors and use cases are well understood. Best practices amongst these major platforms are in place. The cloud is maturing (litmus test for this is the reinvent seems to be less exciting each year). New form factors, like AR/VR, don’t have the market share for broad changes to development practices yet.

This seems true until one can generate code based on descriptions like GH Copilot can do. That’s a step towards structurally capable.

COBOL is code - it's not nocode.

It was sold as "basically English, so programmers are obsolete since everyone can write their own software". Which is pretty much the same pipe dream as "no code".

Yeah, if you look at it, it's designed after recipes, even more so than typical programming. It starts with a title of the module, then a data definition section (ingredients), and the the program section which is a numbered list of english phrases to be performed more or less in order.

The idea was to convert women who had been working _as_ computers, into programmers.

"Programmers" referring to engineers working with machine code and hardware architecture. People writing in high level languages where not considered "real programmers" back in the day, just like people writing in Python or JavaScript were not considered "real programmers" more recently.

But who you decide to call "real programmers" is of course beside the point. What is interesting is the raising of the abstraction level which happens with higher-level tools.

By the standards of the time when even macro assemblers weren't always available and programmers often had to do the translation to machine code manually, it was unlike code. It was even portable!

Have you met assembly?

well said!

I can say from our experience: we made more that 2000+ no code projects so far and it really required some customization, some coding and technical understanding from "no code developers".

No code operates together WITH normal developers. At WeLoveNoCode (https://welovenocode.com/) we have mix of no coders who knows design, no code tools but also can dive into code. So it's not like isolated function, no code is an instrument to build something faster with visual editors. Agree?

Also, why see no code as a "competitor" or something completely different? Wix or WordPress was around for a while and only until recently "every" tools decided to call themselves as "no code" :) I mean, it was there for a long time already...

"Also, why see no code as a "competitor" or something completely different?"

Only, solely, and singularly because overexcited no-code proponents are holding it up as such. Otherwise it's no problem.

I actually came up with the insight I posted above while I was typing it. There'll probably some future variant of this post that has it expressed more cleanly, instead of burying what should have been the lede.

I'd say that no-code advocates should be more careful about their messaging; I understand the desire to sell to management, but pissing off "normal" developers is eating your seed corn. There's also architectural ways that manifests in the product itself, where if you think "normal" code is an exception, you'll build it as an exception, and cut yourself off from later growth.

If everyone understood no-code as a follower (and honestly, generally a rather late one... the developer community as a whole needs to process things down to maximum degree before it's ready for the non-developer community), and everyone involved saw it that way, I think we'd end up with a productive harmony. If no-code developers insist on attacking developers (or attacking their job security, or attacking their credibility with their managers, or attacking their work ethic... no-code advertising has done a lot of these sorts of things), it's going to raise hostility and ultimately be self-defeating for the no-code startups.

Did you have any cases when devs collaborate with no-code devs?

This is an imperfect analogy, but consider for a moment the role Microsoft Excel plays.

Excel allows non-coders to do many useful things, and provides a relatively gentle on-ramp to actual code via formulas. If you take that on-ramp and keep going, towards VBA and add-ins and other pieces of Microsoft technology, you might wind up becoming a full-time software developer, leaving Excel behind and using “real” tools.

Now, there’s a happy path and an unhappy path here.

The happy path is that you use Excel for what it’s good at, but recognize when you are operating at its limits, and at that point pivot into “real” software engineering tools.

The unhappy path is that you stick with Excel too long and become mired in the world of VBA and advanced formulas and attempts at shared workbooks, and build pseudo-database application-contraptions.

No-code can be like that early Excel usage: it can grant some limited but useful powers to non-developers. But no-code can also evolve to become like those contorted, unmaintainable spreadsheet monstrosities that stretch the technology far beyond the point where some “real” software engineering would have been the right answer.

Short version: use the right tool for the job.

> Excel allows non-coders to do many useful things

I heard a great quip at some point: "Why is Excel the most useful IDE?" Answer: "Because it's the one IDE every business allows every user to access."

Most of us here have forgotten that many businesses flat out ban access to programming tools for the majority of users.

And what is an enterprising user to do, when they realize they're performing the same process 100 times a day?

Reach for the only wrench they've been given access to.

PS: I guess an analogy would be people griping about shell scripting, without considering that someone might not have the ability to install their framework of choice when connecting into a client server. It gets the job done, with the tools available.

I definitely think that's a large part of it, but I saw impressive uses of Excel and Access by non-coders long before it was typical to lock-down workstations the way corporations do nowadays (like, 20 years ago).

Excel is used because it's understood by business types, not because it's the only thing available. They're comfortable with spreadsheets, it's no surprise that they'll try to solve any given problem they have with spreadsheets.

You see the same thing in reverse, with programmers reaching for Python when Excel probably would've been a better choice. Everyone reaches for what's familiar.

I regularly have issues with new hire data scientists straight out of Uni.

Connect to database, pull multiple tables into pandas / numpy. Then start joining to find the records they want in python.

Why, why, why ???

100 x this. Most companys ban all kind of software. So Excel is the only solution for really all kind of problems.

Some years ago someone posted here on HN an excel extension that turned excel into an actual IDE.

While it’s true for a lot of people is the only choice, there’s also an amazing amount of enterprising users that sadly don’t know any better!

That's the Venn diagram problem: how many people are there who (a) understand the needs of line of business non-developers, (b) understand their corporate IT policies that non-developers suffer under, (c) know the better way that other developers do it, & (d) are willing to wade through the political and policy @&$& to actually get something done about it?

In my experience, not too many. Non-developers don't know what they don't know, and developers don't know what non-developers need.

> Most of us here have forgotten that many businesses flat out ban access to programming tools for the majority of users.

That sounds... counter productive to say the least.

Good luck even getting access to cmd.exe at a lot of places.

We have a phrase where I work: “Security: we put the ‘no’ in ‘innovation’!”

One of my clients blacklisted cmd.exe, but not PowerShell.

I can't imagine why we continue to have security breaches in major companies...

You get no argument from me, but I've seen it too frequently to believe it's not by design.

Typically the rationale given is "Non-developers can't be trusted to write code and follow development policies," while leaving the unspoken that they're limiting development to people who by their organizational seat definition aren't experts in the problem they're being asked to code.

Very true and a good post. Many managers and companies will go bananas if an employee wants to "program" any custom solutions for repetitive processes or for perceived efficiency. Then on the flip side, if the same employee gets "creative" with Excel, they are all for it, and smiling.

Problem is, Excel can be like trying to fit a square peg in a round hole, might be the wrong tool, or the less efficient option.

Nothing like watching various companies do absolute insanity and cause severe eye pain with convoluted and mangled up Excel spreadsheets. "Damn, at least go use MS Access or MS Project, if you going down this path."

It’s also useful to know some VBScript. I’m not allowed to install Python or any other “actual” programming tool on my Citrix VDI but VBScript runs fine and is pretty capable.

Excel is a great example of how “low code” or “no code” are recent buzzwords for a long continuing evolution. There have long been attempts to make software development more accessible. Some attempts stuck (Crystal Reports 1984, Excel 1987, WordPress 2003, IFTTT 2010) while others did not (HyperCard 1987, FrontPage 1995). The same will be true for the current crop of platforms.

Seems like you either die a hero or you live long enough to see yourself become a villain.

I don't agree: Frontpage was definitely a villain.

Not as villain as Dreamweaver. Not directly but considering how MS saw that has no future and abandoned it, while Dreamweaver became the "web dev tool" for many, many out there for long years until Adobe understood those tools had no future at all.

Pfft. Dreamweaver (and even FrontPage) were perfectly fine back in the pre-IE6 days when they dominated.

People today crap on using <TABLE>'s for grid formatting, just as we crap on 1990's Java code for its `AbstractStrategyFactoryFactory` excesses. Because it's "what people did back in the bad old days", and is a glaring red flag that one's skills are out of date.

But whereas OO design patterns are a matter of subjective debate, early HTML4 and prior just flat out didn't have modern mechanism for separating presentation and content. CSS 1.x was very limited, and no major web browser even seriously supported that until the year 2000. CSS 2.x didn't get real until the 2010's.

Would any professional use Dreamweaver today? Of course not. But it was an appropriate tool for its time.

Pre-IE6 days, sure. I'm talking about much later, Adobe abandoned DW just a few years ago, much, much later than it should have been.

FrontPage from day one generated garbage that only IE could read, on purpose. The other day I found a notebook from my high school days in which I attached a "Best viewed in your own browser" sticker to mock the best viewed on IE (and also Netscape) buttons that were the rage back in the day (pre-2000).

I would go further and say Excel is the ultimate no-code solution. It has been used by more people to solve coding like problems by non-coders than any other no-coding tool.

I kind of disagree, because what I often see is people causing more difficulties for themselves than if they made the jump to Access, SQL, or even building an application.

There is arguably a kind of limit to how far one should take using Excel. Microsoft clearly knows this, so has Access waiting there for those that figure out they should go the next level up. Even then, Access might not be the best answer, as compared to creating an application that addresses specific needs.

I disagree that these are coding problems. Just math isn't coding. These might be real problems that are difficult to solve, and that problem solving happens on a computer, but that doesn't make it coding.

I mostly agree. But I think there’s an important semantic distinction: people who use excel are coders. They are programming the moment they write an expression into a cell.

I think this is important because we fool ourselves by calling these people non-coders.

Excel is really just a coding environment that has a ridiculously smooth learning curve.

Yeah, this is why the term "low code" seems more appriorpiate. We should definitely be describing `=A1+B1` as "code" and we should be calling it the "Excel Programming Langauge". (Especially now with LET and LAMBDA and compound data types making it Turing complete).

(However it's still low code because all the imperative stuff about the GUI and loading/saving files and updating other cells reactively and so-on is written for you by Microsoft.)

It's a perfect analogy. Don't sell yourself short. Look, the following things are true.

1) This industry absolutely has the capability create more tools like Excel that are both extremely empowering and orders of magnitude easier than what we think of as coding.

2) Unfortunately, there's a strong, likely frequently subconscious, incentive to definitely not do this, since it carries a strong danger of IT making itself "obsolete."

(Not judging here, just observing)

> 2) Unfortunately, there's a strong, likely frequently subconscious, incentive to definitely not do this, since it carries a strong danger of IT making itself "obsolete."

I can't think of a single case that this has ever been the decision making process when creating a product.

If you look at the myriad of available tools that trends in this direction, in all fields, you'll realize that the industry is littered with both successful and failed examples, ERP systems alone are a huge market.

It's just that people wanted to replace actual convoluted general purpose logic known as coding, that they ran into problem that could not be addressed by some GUI. And that no-code solutions that exist today propagandize about.

What? I can think of a ton egregious examples of deliberate "disempowering" right off the top, to say nothing of the likely TONS more subtle ones.

Shutting down Hypercard.

Google Reader.

Bill Gates emphasizing to NOT make MS docs compatible with others. The list goes on and on.

How are any of these related to making IT obsolete?

I would think the incentive to make a bazillion dollars if you did this sucessfully would outweigh your purported frequently subconscious disincentive.

Plus there are other people in this comments thread saying they are working for companies that are (they claim) doing so. Not to mention all the past attempts to do so over the past 40 years. Is the idea that those companies are intentionally not doing it as well as they could, because of their allegience to not making the field of IT obsolete?

The idea that we collectively could easily be making software construction toolkits for non-programmers that would make "IT obsolete", it's an easy problem, but we just choose not to... is a conspiracy theory.

I'd argue there's a massive incentive to do this if you can because then every other company in the world can downsize their engineering staff and take advantage of the no code solution that you're selling. Even if you sell at an absurd price like $1M/year but it allows a company to replace 10 programmer, it'd probably be worth it.

The problem is as it's always been. Solving problems in the general sense is hard. It is true in design, it is true in AI, it is true in the automotive world, and on the battlefield. Specialized for one task is easier to learn, and easier to design for. General is harder to learn, and harder to design for.

With that in mind, it's interesting that we still even have "general-purpose programming languages." There is some specialization for sure, but that's partly because of things like e.g. the browser only supports Javascript. And then you see things going back the other way, e.g. with NodeJS.

So I'd wait till we see some actual, real specialization in the languages / tools that engineers use, beyond "ecosystem" reasons. In the meantime, we've seen tools that help non-programmers "automate" things. Everything from CAD to Wix, Salesforce, Figma, etc. would fall under that umbrella. But then you still have code. If what you want is automation / labor-force-multipliers, the common denominator will still be highly generalized, and therefore, hard.

I suppose the difficult part is figuring when you've crossed the fine line from "good enough for now" to "this is becoming a monstrosity, we need to hire developers and create our own software now"

The second difficult part is when the team that built the "good enough for now" realizes that the line was crossed, that they do not have the skills to be part of the "hire developers and create our own software now" solution and then start subtly, or even openly, sabotaging every effort to move away from the Excel/VBA solution.

Case-in-point, there are more than a few non-software engineering firms where the entire business is a series of mind-boggling amalgamations of Excel and VBA with a healthy dose of Matlab on the side. I'm talking full applications written in VBA with Excel as the interface. I wouldn't be surprised to see the same in non-quant finance.

>>>> The unhappy path is that you stick with Excel too long and become mired in the world of VBA and advanced formulas and attempts at shared workbooks, and build pseudo-database application-contraptions.

How happy was the "let's just spin up a software project" path?

There's a second version of the unhappy path, as well: you're trying to use the tool for what it's good for, but there's a bug that makes your particular use case unnecessarily difficult. At worst, what happens is you silently either get bad results or lose data. At best, you either don't use the tool for that purpose until the bug is fixed, or, you implement some silly workaround. All in all, this can be a rather disempowering situation for a non-technical user, which is the exact opposite of what "no code" promises.

TL;DR: "no code" is just somebody else's code. You're introducing a massive external dependency you have little control over by using a "no code" solution.

I am an engineer with 20+ years of hands on keyboard, I've got projects that are now part of Apache, 1000's of stars on github. I've been CTO at a number of startups that have got significant funding. My point is to establish some credibility. I probably still suck.

Having said that, I have been working with Microsoft PowerAutomate for the past 1.5 years and while it has saved a lot of time and been overall a good experience, there are times when the no code/low code gets in the way and I wish I could just "drop into code" to get something done. Examples are things like data validation. This technology is not going to replace coding, the paradigm shift is really happening for people in the marketing and sales operations parts of the business. For these folks, this tech is life changing. In a lot of ways, this tech felt like when you try a new framework in your language of choice; at first it's super easy and you get hyped, and then you hit a requirement where the nocode/lowcode environment really gets in the way.

I think this is spot-on. No-code solutions allow non-technical folks in marketing and sales to build some amazing things that would have required teams of software engineers: marketing, shopping cart, and email integrations; email onboarding workflows; complex ad campaigns; better inventory and wholesale sales management; and a lot of other things I'm not creative enough to think of. I've seen an entire application prototype built by a product manager by duct taping Google Sheets, Mailchimp, and a database together with Zapier.

However, their wants always grow just beyond the no-code capabilities, and there's still a need for software engineers for things that haven't been fully solved yet.

IMHO, the best fusion of the two is offering a no-code tool to non-technical folks... while ensuring you have a tiger team of random and varied developers to produce one-off duct tape bits to cover gaps for them.

It seems far more efficient to have a non-technical person fiddle with a GUI, get most of the way on data integration, etc., and then come to the team with only the parts they couldn't figure out.

"I have this list of strings and I need to X" or "I need to push data to this API"

We did something similar at a previous job, and it generally worked out well. The code assistance kept people from constructing Rube Goldberg machines in the designer tool, to solve simple coding problems that the tool couldn't cover.

> I wish I could just "drop into code" to get something done.

Since you're using PowerPlatform you can prob easily do that with Microsoft's Power FX, built - I believe - especially for this.


I'm confused about the intended audience.

Power FX has a level of abstraction squeezed between MS's other options (excel formulae,power query M/DAX, Powershell, C#).

It gives the impression of a pet project rather than something users actually asked for.

thank you for pointing this out! Microsoft is so vast in its offerings, sometimes you can't even find the thing you believe must exist.

I’ve had a different experience with PowerAutomate.

Both as a no-coder and a user.

As a user the UX is horrible and I’m now swamped with terrible “apps” or “workflows” that people try to get me to use and fail for arcane reasons. Or are just ugly or brittle.

As a no-coder the tools are hit or miss, the docs are bad, and widgets frequently don’t work due to my licensing and there’s no way to know other than to try and see.

It has such promise as the shell scripting equivalent for the cloud what shell was to PCs. But instead it is a costly and difficult thing to use.

It has such promise as the shell scripting equivalent for the cloud what shell was to PCs.

What ever happened to Yahoo Pipes?

I really miss yahoo pipes.

I played with Huginn a bit, but it’s a steeper learning curve.

I feel like the promise of the Internet has really been blocked off my adding in some nice business models. So now companies don’t want interoperability and orchestration as that stuff just reduces revenue. Why would goog/face/etc want us spending less time doing mundane tasks. They want us spending the max amount of manual stuff as long as we don’t quit.

I find the UX horrible for different reasons, ones that I believe are pretty easy for microsoft to address if they just watched someone like me use the product. I have not experienced the brittleness, maybe what I am doing is more trivial.

> I am an engineer with 20+ years of hands on keyboard, I've got projects that are now part of Apache, 1000's of stars on github. I've been CTO at a number of startups that have got significant funding. My point is to establish some credibility. I probably still suck.

More about being in a right place at a right time, but granted.

> Having said that, I have been working with Microsoft PowerAutomate for the past 1.5 years and while it has saved a lot of time and been overall a good experience, there are times when the no code/low code gets in the way and I wish I could just "drop into code" to get something done. Examples are things like data validation. This technology is not going to replace coding, the paradigm shift is really happening for people in the marketing and sales operations parts of the business. For these folks, this tech is life changing. In a lot of ways, this tech felt like when you try a new framework in your language of choice; at first it's super easy and you get hyped, and then you hit a requirement where the nocode/lowcode environment really gets in the way.

I think higher-level languages with a dual code-graphic representation and a possibility to drop into lower level are an interesting option, but even that is not new - Unreal/Unity3D etc.

Why are you trying to diminish his accomplishments? Does that make you feel better, to try to bring someone down? You come off as bitter and unaccomplished and this site could use less of people like you.

Humble-bragging either works real well or backfires real hard.

It was not meant to be a humble brag, sorry if it came off that way.

Maybe ask some of these people:

1 hour before you Ask HN: Do you like the term 'nocode'? https://news.ycombinator.com/item?id=29187754

2 days ago Ask HN: No Code GUI Tools? https://news.ycombinator.com/item?id=29160858

3 months ago Ask HN: Is there any future for low-code/no-code development? https://news.ycombinator.com/item?id=28150056

4 months ago Ask HN: Anyone built a business with no-code tools? https://news.ycombinator.com/item?id=27593073

3 months ago Ask HN: What do you think of Producthunt's obsession with no-code solutions? https://news.ycombinator.com/item?id=28194430

We have to start doing like those Soccer Mom Facebook groups and put something like: "please use the magnifier glass[0] to search if your question hasn't been asked before"

[0] https://hn.algolia.com/

Edit: I'm getting heavily downvoted. Sorry guys, it was just a joke.

Not everyone checks HN and Reddit every day.

Just because it's been asked before doesn't mean that the people answering it are the same etc etc

Thanks for posting these. I did see these threads before posting this Ask HN. However in most of those threads there wasn't much discussion at all.

I'm finding the comments in the current thread quite enriching to be honest.

Most of these posts have less than ten comments where this one is at 317 currently. It's no secret you gotta "win the HN lottery" before traction on a post occurs, repeated submissions are going to be a natural consequence of that.

Ouch! Ok, somebody came ready to rock-n-roll on questions. Originally I read, for example, "4 months ago" instead as "4 months before asking HN [see link here]" as in don't ask answered questions!

The ultimate "low code" experience I had was back in the 1990s with Delphi. You drag and drop your form elements, get everything just right. Next you hook up your event handlers and type in a few lines of code to do the actual work.

It was the best I've ever seen balance of managing complexity, yet letting you write code when you needed to.

The C++ version was nowhere near as god, it generated a ton of templates and things that just weren't necessary in Pascal.

Since then everything is expected to work across the internet, through a web browser, web server, etc. It'll never be as simple and effective as it was.

>The ultimate "low code" experience I had was back in the 1990s with Delphi. You drag and drop your form elements, get everything just right. Next you hook up your event handlers and type in a few lines of code to do the actual work.

Today I was thinking about Visual Basic 6, which worked more or less the same way.

I wonder what similar alternatives we have today? Gambas? https://en.wikipedia.org/wiki/Gambas

The problem is that you can’t usually afford to target just a Windows 95 PC or equivalent today so such a tool cannot exist. The UI must morph and adapt and feel native across phones, tablets, retina displays, etc.

Even video games these days need to adapt to a different UX on each platform even thou they are the closest to having one unified UI across the gamut

It's unrealistic to expect a full, productive, desktop experience on any smaller devices.

Giving up on the desktop is a huge step backwards.

On the other hand, the market has expanded beyond economies where users have the space, power and physical safety to actually own a desktop. For some people their first, last and only "PC" is their smartphone. Your choice then becomes embracing those users or not having those users at all.

"One size fits all" fits no one.

You build where your money is; our clients are asking for phone versions of dashboards, reports etc as they simply don't have or don't want to use desktops. Maintaining software for it is just not worth it.

I like typing stuff in and instantly seeing the results, rather than rat wrestling widgets onto a form. Rat wrestling also makes adaptive UIs difficult; again, the solution is being able to declare your UI with layout managers that apply constraints.

The most rapid UI tool I've ever encountered is Tcl/Tk. Everything else involves incurring more tedium and misery -- even Visual Basic or Delphi.

> The UI must morph and adapt and feel native across phones, tablets, retina displays, etc.

Isn't that a solved problem by the likes of React Native?




- Open Source

- Written in Pascal for Pascal

- Cross-platform

- Over 200 Components

- Extendable through packages

- Package Manager with Online Repositry

- Many Frameworks

- Converts from Delphi code

- Regular Releases

You can do "drag and drop form elements and type up the event handlers" with Visual Studio and C#. The problem is that Microsoft have rather lost their way on GUI frameworks - too many of them and the latest ones are either "to be obsolete" or "not finished yet" (winui3), and winui3 has broken the interactive designer.

Theoretically it can be multi-platform https://platform.uno/

WinForms is the spiritual successor to VB6.

I'm not sure where the "confusion" about your options is coming from because Delphi (Object Pascal) still exists. You can get the Free Community Edition from here- https://www.embarcadero.com/products/delphi/starter/free-dow...

If a person knows Delphi/Pascal, there is no need for them to use Visual Basic 6, unless that was their feeling about such. There are several Object Pascal options to choose from, where if a person was previously exposed to Pascal/Turbo Pascal/Delphi, they would be able to get back up to speed very quickly.

As you mentioned Gambas, maybe you are thinking completely free and open-source, which Object Pascal has such too. The most obvious choice would be Free Pascal with the Lazarus IDE. For those that don't know or are confused, Delphi is a dialect of the Object Pascal programming language (check Wikipedia or Embarcadero website to verify). So the closest dialect of Object Pascal to what is used in Delphi (the IDE), would be Free Pascal/Lazarus. You can even import and convert Delphi projects (including Turbo Pascal) to Free Pascal/Lazarus. You can get Free Pascal/Lazarus from below:


https://github.com/LongDirtyAnimAlf/fpcupdeluxe (this is a special cross-platform installer)

There are also other dialects of Object Pascal that are free and open-source, such as PascalABC, which is a variation for .NET. You can check it out here- https://github.com/pascalabcnet/pascalabcnet

Vb6 still works. I just put out a new version of my project today :)

I love this, you are a great example of dark matter developer, using old and boring tech to deliver everyday some real value to businesses

> Today I was thinking about Visual Basic 6, which worked more or less the same way.

VB .NET, which is just Visual Basic now, is like that and is "modern".

The first one I encountered from that same era was Interface Builder, on the NeXT. And it turns out it's still around, as part of XCode on the Mac.

I remember Borland C++ builder being similar. Was actually pretty good to use.

It's been 10 years now, but the Visual Studio GUI/Winforms designer was (probably still is) similar - and being .NET, you could get some pretty decent software up and running without too much code - depending on which language you used.

I used Delphi a lot in the 90's and early 00's, but I never really considered it "low code", with the exception of the drag and drop forms designer of course.

It depends very much on what functionality you needed.

If you needed a GUI for database CRUD operations (which is a lot of business processes and a lot of webapps now), then you could do that with nearly zero code, as the built-in behavior was all that you needed, but if you needed some interesting custom script and just a button "run it" and a textbox for results, then of course that would be nearly all your own code.

A lot of companies, especially from Russia and Ukraine, sold visible and invisible VCL components that you could drop on the form and configure. Depending on your functionality you needed very little or no code at all. We a lot of applications that way in the 90s and begin 00s.

The “no code” and “low code” movements come up over and over again because programming is now like writing: Yes, it is its own profession, but also yes, it permeates all other professions as software eats the world.

Languages and tools are user interfaces, and any time you have many different jobs to be done by many different people with many different contexts, it is natural to develop several different interfaces for what may appear to be the same work.

Thus, low-code and no-code. But!

Programming is more than just coding. It’s also all the activities AROUND the coding, including things like reviewing code before it is deployed, version control, reverting code, testing code, automated tests that also serve as DSLs for describing the behaviour of code, &c.

Robust no-code or low-code systems also need to address the needs that the systems and tooling that live around high-code serve.

They don’t need to do these things the exact same way, but it’s a Chesterton’s Fence situation: We shouldn’t just ignore those other systems, we should figure out why they exist and make sure that either we know those needs no longer exist, or address them another way.


Discussion around the original post:


It's weird from the perspective of game development because it's so obvious. A lot of time is spent on development tools because making a modern game is a very complex undertaking that is highly data-driven. A large amount of game tools are #nocode not because it's a movement but because it's useful. A classic example is level design tools that are much more about spatial design with some coupling between entities in a game. Non-programmers can get really far and build some surprising diverse things with simple primitives.

As an example our Art Director built this without any programmer assistance or writing a line of code. Just taking a basic multiplayer FPS game then grabbing components we had already made and jamming them together to get parts working: https://twitter.com/voxeleus/status/1437754413813207047/vide...

You can further see this in many creative games or games with modding tools where players put together complex behavior without using a line of code. Right up to things like Minecraft Redstone which is really an esoteric, spatial programming language. But crucially doesn't feel much like programming at all.

I think there's a lot to be taken from the game space for people trying to build no-code tools. Particularly in that you're not trying to remove a programmer but empower non-programmers in ways that suit them.

I feel like there is a distinction between tools and no code and these are just tools. You can maybe prototype a game mechanic if it’s not very unique with drag and drop but it’ll never scale to production. By the end the game code will have thousands of special cases which would make the nice no code experience a complete Frankenstein monster

> I feel like there is a distinction between tools and no code and these are just tools.

Programming is just a tool as well... there's a odd distinction here that somehow more specific tools are lesser. I also think this is where the whole #nocode thing can go wrong. You should empower non-programmers in ways that suit them.

> You can maybe prototype a game mechanic if it’s not very unique with drag and drop but it’ll never scale to production.

The expressiveness of composition is only limited by the number of elements you have to compose. In the specific zombie case no it wouldn't scale to production. But then the prototype wasn’t meant to and also would never have existed if it weren't for these tools. We unlocked the ability for our Art Director to prototype a new game all by themselves. That's massive from a creativity point of view. We'll almost certainly turn it into a full game at some point.

From a production standpoint a game is thousands of special data cases. Which is why tools are so important and code is both data and a tool but if you can simplify things so much the better.

> I feel like there is a distinction between tools and no code and these are just tools.

How would you describe the difference?

I work at Stacker (YC S20) [0] -- we're actively building a part of this future and so I've done a lot of thinking about it.

My view is that, indeed, the general no-code category represents a paradigm shift in the truest sense. That is, it is not going to replace anything we currently use software engineering for, except at the very edges. This is pretty obvious to anyone who understands software and the complexity inherent in building custom things. Rather, it will enable a massive new category of software to be built, where presently it is uneconomical to do so.

Think simple tools, sometimes throwaway tools only needed for a few weeks, tools specific to each new project - things currently implemented with whiteboards and sticky notes that would clearly be better as digital tools in all sorts of ways - and indeed increasingly essential as the assumption that everyone is in the same office gets less true.

This stuff is typically quite straightforward but requires deep domain context that'd be really difficult to translate into a spec, and way too expensive anyway to justify hiring engineers to build, but it can now just be done directly by the domain experts themselves who need not necessarily be technical.

This category is simply massive - think of the number of such tools that could be useful in even a single given business if they were simple and cheap to create. Now multiply that by every business.

If you're convinced / intrigued by any of what I've said, by the way, we are hiring. So let's chat about it more! Email is in my profile :-)

[0] https://stackerhq.com

Looks like a cool company. I'd apply, but it looks like you're only accepting applications from EU timezones.

Nice. Looks similar to the Restya Core. By any chance, did you get any inspiration from the Restya Core?

I have been a professional programmer for forty years. In the eighties, there was a no-code desktop relational database application called Helix. I continue to think that it belongs on the same shelf as Excel in the UI hall of fame.

Like Excel, people made applications with it. Unlike Excel, it created a server product in the mid-eighties that allowed it to become an IT platform. Small business owners who had hacked up a Helix database to help with invoicing were able to extend the function to the entire organization without ever using a keyboard for anything except typing label names on reports. All drag-and-drop icon stuff.

Fast forward twenty-five years. Today the applications have grown and grown and grown. The owners who created them are old, prosperous and tired of screwing around with it. Also, Helix is no longer well supported. These people are screwed.

I consult for a few companies that use it. These apps are exact replicas of the brain process of the owner that made them without a single structured thought in sight. Even if Helix were a healthy platform, the apps are largely unmaintainable.

They are also so complicated and so deeply integrated into the companies that they represent a horrible threat. They can't easily adapt to the modern world and will cost millions to replace.

Which is to say, these no-code systems encourage amateurs to reach too far. I advise people against them.

I wonder if you could find any 'enterprise' system at a business of any size that's lasted 25 years, if it would have much the same problems. And if you can't find many enterprise systems that lasted 25 years, that says something to, in Helix's favor. (some of the ones you can are... COBOL I guess?)

> These apps are exact replicas of the brain process of the owner that made them without a single structured thought in sight.

To be fair, we've probably all seen applications written by professional software engineers that fit that description..

Remember Omnis? That was fun to code in, hard to maintain.

I think it a good answer to the wrong question.

The wrong question is: (most/many) people cannot program because it is difficult to type the right things in, so let us remove typing.

The right question should be: how can we more efficiently develop software?

No-one would ever think to start a no-write movement because people cannot write properly. We instead teach everyone to write starting from the first grade, and we build tools to help them write better (dictionaries, word processors, spell checkers).

For programming, we should also concentrate on building tools (like the awesome IDEs of today) that makes developing software more efficient. Some of the efficiency can be had by no-code (i.e., Delphi-style forms), some can be had by improvements to technology (code completion), some can be had by improved language design. We should also invest more in programming education.

Low/no code DSLs are also good (think of Excel).

But I am skeptical of general purpose no-code: if it's Turing-complete, it's just a programming language in disguise.

In my experience, these tools have another - counter intuitive and often overlooked - strength. Their limitations.

You want to handle this very specific edge case? With code, there is certainly a way to do this. It may take days, it may add unreasonable complexity. Nevertheless, someone (yourself?) will ask that this kinda insignificant edge case is properly handled. And won’t take no for an answer.

With a (too) limited « no code » tool, maybe there really is no way to handle the edge case (or it would require code in a context that forbids it). Management (or yourself!) has no way to make someone fix this, and can just give up. Soon enough, there is no problem. Finally, you can live with the unhandled edge case! Ok, you’ll just brief users. Ok they’ll learn by themselves that they shouldn’t do this.

So sometimes, « no code » tools can’t solve a problem. Then the problem simply disappear. It helps with finding a 80-20, something good enough. Everyone can be focused on more important stuff.

You may underestimate the ingenuity of non-developers hacking on no-code platforms. They end up thinking a lot more like developers than one might think.

Our operations organization has independently arrived at some things pretty darn adjacent to more advanced software patterns, like circuit breakers. (This being for workflow automation no-code tooling, vs website builders).

And a ton of real world work is getting done out there with Zapier, that's for sure.

I've seen a JSON parser written in a drag'n'drop visual no-code flowchart-like application that was very impressive and, if printed, would have caused the death of many trees. Utterly unmaintainable and horrifically stupid given any full-code solution would have involved using a pre-written library.

But then it's no longer no code. It's just a code environment for people who somehow got convinced "I could never learn to code".

There is no such thing. There are simply different representations of 'code'.

Those who promote 'no code' solutions always seem to think that just because one does not edit with a text editor that there is no need to design the solution or to debug it.

One is still developing, just using different tools.

For some subset of problems it might indeed enable someone who is not a programmer to create a solution just as Excel enabled millions of people to do just that. Unfortunately one usually finds a little later that the solution has the shape of the tools used to create it, that because the tool could do something in a certain way that is the way that is chosen rather than choosing the tool to fit the intended solution.

You end up with people creating databases in Excel because Excel is what they had.

What is old is new again. This has happened before. Graphical programming, low-code, no-code. They all inevitably hit a wall where it does not cut it. Either the performance is not good enough, they need to dip into real code to add features, etc. Then there are the issues like CICD and version control that they don't do well that hold them back, and then integrating with the rest of the company. Its just not worth it, its a dream sold to VPs and will die off in a few years and come back a decade after that.

I previously was supporting a company integration with Appian (building the AWS/Webservices integrating the two halves), which bills itself as a Low Code platform for Business Process Management. And their hello world example kind of worked fine for getting "a business person" to "write code". So the idea was they get these business people to write code instead of developers. But the problem with this platform was that we had to eventually get full time software developers (so no cost savings there, but also had the issue of these devs were now niche developers and not learning broader skill sets). Because their graphical development didn't cut it, so they had to drop down into their code proprietary DSL. Then the actual platform was a mess of no cicd, bad disaster recovery, bad monitoring, bad everything. It would have been cheaper and easier to literally just write a business process management from scratch in whatever language we wanted.

tl;dr No code, low code, graphical programming is a fad.

I agree completely. IPaaS tools are bad programming languages with awful tooling. The logic you need to transform some data, say, can become very complex quickly and you're stuck manipulating it with terrible graphical tools. When you inevitably find a bug, it's a huge pain to deal with.

For making a website with a store though, it can be great.

>What do you think about this movement?

The "no-code" desire has been around for decades -- just using different terms. E.g. in 1980s and 1990s, a common phrase for new tools that didn't require programmers was "self-service" ... like Crystal Reports software for "self-service reports without programming".

To put it in perspective, consider that Microsoft Excel is a "no-code" tool. In the old days before desktop computers, if a business person wanted to look at a report of sales amounts grouped a different way, he would ask the COBOL programmers in the IT department for a "change request" and they'd do the following:

- "code" new punch cards for the mainframe: https://www.google.com/search?q=mainframe+punch+cards&source...

- load of magnetic tapes (each held about 40 megabytes) of the sales data: https://www.google.com/search?q=mainframe+9-track+tape&sourc...

- get a new report on greenbar paper: https://www.google.com/search?q=greenbar+paper&source=lnms&t...

Now, any office worker can do the above with a "no-code" tool like MS Excel with pivot tables, filters, etc. Even though Excel eliminates a lot of coding work, the demand for programmers keeps going up. No matter what "no-code" tool is invented, the world keeps inventing new tasks for human programmers to do that today's no-code tool can't do. There's always a delta in capabilities.

> No matter what "no-code" tool is invented, the world keeps inventing new tasks for human programmers to do that today's no-code tool can't do. There's always a delta in capabilities.

And by that logic always an opportunity to make something that was once hard to do, easy.

I hate it.

Some time (not long) ago I was working remotely on some software that was driven by an API on a remote server maintained by some folks in a different country. A long way from me.

Cutting a long story short I realised that the lack of control over the server was because they really did not know how it worked, or how to fix it or diagnose issues their server was having.

It was a laraval/MS-SQL system built from building blocks supplied by Microsoft. They wired all the blocks together in a GUI and look! It works!

* Putting images into a UU-encoded text field worked for images <7MB... The actual images the customers want are >10MB

* Low levels of activity it was reliable. Under load it randomly dropped sessions.

* They did not seem to know what logging was, or how to use it. I was supplying them with problem reports, carefully noting the time - and getting ghosted. I realised they had no way of knowing what their software was doing, or did. They could only set it up to do what they hoped.

* The stored times as wall clock time strings "2019-02-12T03:02:12.123" No time zone included. Time series data worth a lot of money. "What happens when daylight savings repeats an hour or skips one?" I asked. No answer. This infected the whole system. I spent a lot of time fighting dates, and was that in the past? Future? Is that supposed to be now?

Back in 1997 we had more reliable, and higher quality software, on a telehoused 486 Apache/Perl/Postgres system. But we compiled it from source and edited the configuration files by hand.

"No code" might be OK for Aunties cookie recipes, but for building infrastructure it is rot

What do you think about "serverless" architecture where everything server related is handled for you and all you have to worry about is code? I'm talking about services such as Azure Functions, AWS lambda, etc..

What little I have heard of it sounds intriguing. But I know very little.

I don't like the idea, not because it doesn't work. It might, but in the mean time I lose ownership to my own code and tools. My code and tools might be shit, but at least they are well documented and I know how shit works. I prefer to play with my own shit than someone else's, if possible.

You may ask why then I don't write my own OS/IDE/Database/etc., well I'd love to but sadly I don't have the skills. I only do things within the boundary of my skills.

Sorry, ownership is No.1 issue for me.

> What do you think about this movement?

It's not a movement, more like a mini-trend based on rediscovery of an old idea. At least not a pure investor duping like "metaverse".

> Clearly these apps/platforms enable non-developers to solve a bunch of problems which would otherwise need a software engineer. Is this a paradigm shift?

If it is, it happened in the last century and many times since then already. You could still hype it up for a new domain to grab some investor money, I guess.

I look at no-code as evolving to produce a high-level, (often visual) Domain Specific Language, with abstractions suited only to the problem domain.

Excel is the archetypal success-story, perhaps. It is ill-suited as a general purpose programming language, but as a language for arithmetic operations on data it... excels.

The same is true of Airtable and Zapier. They introduce new, simple abstractions for data, and for automation.

Disclosure: I'm the founder of a no-code startup in the browser automation space. I rationalise what we do as 'introducing high-level abstractions in a visual DSL'. You won't see that description in investor pitches. No-code products are just high-level programming languages.

If you pick the correct abstractions, working this way is actually faster than coding for the bulk of use-cases, whilst making edge-cases hard to deal with. For those, coding is inevitable.

I was wondering if there was any similar conversation going on way way back when compilers were a new thing - found this gem by Grace Hopper (1958) (yeah THAT Grace Hopper).


She's talking about the difference between "programmer" (one who designs logic and processes) from "coder" (one who converts those processes to "codes" - i.e. assembly) and how compilers have the potential to eliminate the need for "coders"

I'm tickled by the (IMO) obvious parallels that have just moved up a few levels in complexity us who use text editors to write programs are often supporting configurable logic for someone downstream who can get work done with less complexity using simpler, more accessible tools.

I first learned of Grace Hopper from a children's book I read to my kids.

Recently, I've been wondering what kinds of Hopperesque ease-of-coding advancements are still left to be invented. For example, are there advancements to made in syntax highlighting to make code read more like a natural language, and bugs easier to spot. (I'm explaining my thoughts poorly, text is the wrong medium).

Also: I Ctrl+F-ed "Grace" on the main page of this post knowing I'd find a hit.

My observation from running a consulting business is that there's a gap in the market that I have not seen meaningfully solved. On the one hand are these no-code tools where you can do something reasonable in a very limited domain. Wix, Squarespace, etc. Every decade the limited domain expands a bit, and you can get something serviceable for your hobby or small business fairly cheaply, in the order of $10s or $100s, maybe a couple thousand.

On the other hand, is full scale development, either in-house or outsourced. This is only doable for projects that are ~$50k and up, even if you go with cheap offshore developers.

So there's this gap from ~$5000 to $50,000 where if that's all you can afford, you just can't justify the project. In theory that's where the "low code" tools should fit, but so far, I have never seen it work out like that.

I have been a software engineer for a long time, C++ for the first half, and web development for the second. Recently I took a job as a contract developer for a large no code company. I had no idea what to expect and thought I was going to be limited to creating toy UI apps. I have been blown away at what I can accomplish in this platform. Virtually anything that can be done by a software engineer via languages like PHP (with some very definite exceptions / limits of course), Javascript, etc. can be done via the no code platform. Integrating with virtually any API takes seconds and they dont have to be pre built, I can essentially take any open api endpoint and get and send data to in in a minute (after I understand the API parameters, etc.) SSO integration, Parsing JSONS, complex data filtering, database queries, creating forms, saving data, creating work flow processes, relatively complex server side calculations, you name it, it can be done. It allows for the use of excel and lodash functions as well against data although that is pushing the "No Code" concept, Essentially anything I have done in my prior web development work, I can do on this platform. Some things take a little figuring out and there are some lengthy chaining of components but it works. No code is not a toy anymore, it is a legit technology and while it definitely takes some engineer level thinking sometimes, it very much works.

Can you suggest some tools that you really like in this space? You got me intrigued about automatically integrating an API. I want to do this + small amounts of scraping for side projects but even as a 'developer' I cannot drag myself to start the IDE after hours so many project ideas just languish in the back of my head.

EDIT: oh sorry you posted the response just as soon as I posed this question. What a coincidence!

Sounds a lot like the platform i've been working in for the last year or so (coming from a pretty hard code software engineering background for the last 15 years) and continually finding it surprisingly capable. Do you mind to share the name of the platform?


Darn, it seems like they are not something a regular consumer can just buy and use. Guessing something that good wouldn't be appropriate for consumer environments. :/

dang, I missed it, would you mind to PM me?

Unqork :)

I'm a backend focused engineer that's worked on PHP and Javascript API / apps. In the past I had to write a lot of boilerplate code, now things like Strapi make it super easy to prototype data models and give you authenticated APIs for very little effort.

I'm a huge fan of Plasmic so far, I've tried to make frontend react sites and they don't look as nice as what I'm able to achieve with what I can only call a "website builder" tool.

My goal is to customize the CMS and use it as an API for a separate frontend site. JAMStack is the future... I don't think there is anything specifically 'no-code' about it but I'm suggesting two tools here that let you do no-code and also have nice doorhandles to let you get under the hood. I think that last part is key.

It's in the same class of ideas as perpetual motion machines.

In that case, it violates laws of thermodynamics, in the "no code" case, it violates Information Theory.

The entire process of coding is about translating requirements into machine executable programs. The requirements cannot be condensed below a certain threshold and that's where the 'no code' promise fails. You can move around blocks of shapes but in the end they must represent the same amount of information and it just resembles code.

Yes. People can make wonderful things on computers. Online satellite maps, GPT3 text generators, simulated 3-D universes.

But never a successful no-code system.

The fundamental problem with any no-code type solution is balancing how complicated the system is. If a no-code system is too simple, then you'll need a programmer whenever you need to do something not offered by the no-code system. If it's too complicated, then you might as well just use an actual programming language.

Obviously, there are use cases for these type of systems. Many businesses only need a simple website, and there are a lot of problems out there where an off the shelf solution will suffice. However, I doubt no-code is going to make any meaningful impact on software development. The world is full of problems too complicated to solve with off the shelf solutions, and those problems will need a programmer to write some code.

I don't see the 'no-code' movement as something new, just a new name on the same idea. Developers are expensive, so let's migrate this work to people who cost less, using tools that provide the same or similar value.

Do you know how many people's jobs today are "this person is really good with excel, so we can hold on hiring a dev team and data scientist"? Probably millions. They're everywhere. I met dozens of them hidden away in Amazon warehouses during my career there. And Excel is the ultimate 'no-code' tool, pinnacle of the industry.

And yet the developers, we're all still here. Frankly, there's more of us. Because what really happens when you don't need developers to do the simple stuff is that developers can instead focus on the hard, higher-value problems, that a no-code solution can't do for you. More gets done, more value gets created.

There's always talk that eventually, we'll reach the end of the runway and the no-code will replace are large portion of us. I don't think we're anywhere near that. So bring on your no-code products, I say.

When these things pop up again for the umpteenth time I just refer people to the classic text on the subject.

Fred Brooks essay "No Silver Bullet"


I'm in the process of doing a technical audit of several of these for a government. My favourite so far is the ServiceNow platform.

These platforms are great at making use of bottom tier devs quite effectively. They're a resource amplifier, when you don't have the cash to hire better devs. Hire a few devs to create the custom controls, actions, etc.. and have a boat load of juniors implement the requirements. Most of these folk haven't picked up a new language since college, and don't incorporate coding into their lives. These individuals have value, but often create more problems due to their lack of skill and/or experience. In a low/no code environment, you can better ensure that they're on rails.

The issues we're encountering is the pricing model, and it's most likely we'll end up going with Microsoft's because of the existing contracts. ServiceNow for all it's strengths really shoots itself in the foot with pricing. A product like this benefits from any "power" user being able to implement their own internal workflows, but ServiceNow charges per dev. So they're handicapping themselves. But someone will figure out all the pieces, it's inevitable.

As a means to solve boring, repetitive, uninspired development, it's great, and it'll be the future in the way that SquareSpace and Wix ate into front end presence sites...

And honestly, if you aren't a great developer, I suspect the rails would make you feel a lot better.

This won't take any jobs from anyone likely reading this. HN frequently has a blind spot for that vast majority of enterprise development. It's not sexy, but it makes up more developers than the Silicon Valley crowd by magnitudes. And most of them would fail a Fizz Buzz. With no code, I can make use of those resources.

I asked this a few hours ago here: https://news.ycombinator.com/item?id=29187754

Here's my take, quoted from my thread:

I've slowly started appreciating the nocode / low-code movement. At first: I thought it was a lazy person's dream, but more and more I realize a lot of the low hanging fruit that you can do with code has been done and there's little left to make. I mean, why bother re-invent the wheel right? So now I just leverage software made by other people typically GUIs / point-and-click tools and a bunch of online services to automate burdensome tasks.

I still write simple one-liner helper scripts in my free time though, typically userscripts that I place into Tampermonkey/Violentmonkey to automate a bunch of stuff and make the web more accessible. I call this 'low code' so I'm not entirely reliant on GUIs.

What's your thought on the movement? Do you like the term 'nocode'?

I have a relative who's been programming since forever (although he would never call himself a programmer), and he talks about the first time he saw FORTRAN IV. Finally there was a language where you didn't have to be a programmer or know about computers to use. You just typed in what you wanted the computer to do and it did it. You could solve your own problems without having to wait for the programmers to do it for you. So clearly the desire to get "programming" out of the exclusive domain of programmers is hardly a new thing.

Visual no-code/low-code tools have been around for decades. They can work really well when they are aimed at a manageable sized domain (e.g. data wrangling). They tend to fail badly when the try to be a replacement for a general purpose programming language.

I think a lot of the problem is the endless hype and over-promising by marketing and sales people.

Platforms like Alteryx (https://www.alteryx.com/) used for large data cleaning strike me as a strange stop gap between a clunky system like Excel (which has its natural 1 million row limit) and Python/R/SQL that are full OOP and are likely considered too hard to learn for many business professionals. And yet watching people using the platform looks tortuous! Why not invest in an often free application that you can fully control instead of buying an expensive, no-code based application? Likely has to do with what allows you to maintain talent / not pay for 'programmer' up front in salary costs.

I'm a decent programmer and I use an expensive, no-code application called FME for data cleaning/analysis/exploration/transformation etc. almost all the time. While I'm certainly capable doing basically everything I do in FME using Python, I am far more productive using FME. With FME I can knock together something in 10-15 minutes that would take me hours to do in Python.

That being said, one feature of FME that I do use a lot is that at any point you can drop in a PythonCaller which lets you execute arbitrary python code on your data. Invaluable for the last 5-10% which cannot easily be done using the "no code" approach

The combination of visual programming with the ability to add code when required can be very fast and powerful (it is the approach we are using with our data cleaning tool, Easy Data Transform).

They need to stop locking people into their ecosystem and generate code you can get out and hand out to a developer if necessary.

No-Code / Low-Code / Full-Code is a false trichotomy anyway. There's no reason why visual coding needs to be any more restricted than the real deal.

It's all just one big usability problem. We'll continue to develop software pretending we're running 80 character wide terminals for awhile, but I believe this will change someday.

Tools like Enso, or the Elm debugger already show how much better things are with instant, actionable feedback, even on "real" languages. Then you remember Smalltalk and HyperCard existed in the 80s and you wonder how it all went so wrong.

I think if someone made a decent auto-fullstack-web-CRUD app they would be very rich and would have solved a lot of no-code problems and saved us an amazing number of man-hours on internal tools.

Just: SQL tables, prettified CRUD on those SQL tables on the frontend (with R/W permissions per user on tables), and reports (either on-the-fly or SQL queries run on a cron schedule).

We're (https://www.wax.run/) doing this. We expose a CRUD app for your existing database in Google Sheets. You can also call custom Python for anything not covered by SQL.

Isn't that just basically Rails? It has a (pretty good) built-in ORM, prettified CRUD on any of the tables managed through that ORM and making SQL queries on a cron schedule is possible through Rake tasks, which come preinstalled with the framework.

JHipster (https://www.jhipster.tech/) goes a bit beyond that. From my reading, its basic functionality is taking in either interactive command line inputs or theor custom DSL, and spitting out DDL for a MySQL DB, Spring Boot backend, and Angular frontend.

> Just: SQL tables, prettified CRUD on those SQL tables on the frontend (with R/W permissions per user on tables), and reports (either on-the-fly or SQL queries run on a cron schedule).

Supabase is pretty much the backend piece of this (built around PostgREST), all it needs is a frontend generator that fits with its DB conventions.

Lots of startups attempting this, two big ones being Retool and Airtable doing almost exactly what you describe.

Ms-Access says Hello :)

> Ms-Access says Hello :)

You mean Sharepoint. oh wait, it sucks! ...

You mean Dreamweaver. Oh wait, it produces crappy code ...

Visual FoxPro...

VBA apps...

Java's Vignette...

Who the hell are people kidding here? I encourage all the "no-code" people here to try all these solutions and understand why they eventually failed, because yours will suffer from the exact same problems...

Background I have worked at a low code/ no code shop. We could deliver prototypes fast. But that’s just it they were prototypes that went into production but at that point clients were hooked just where you want them. At that point feature requests require one of two things. A coder to build a new no code widget or more likely just code the feature. So to summarize they make the easy things easy but the hard things impossible. As time goes on maybe you have enough widgets to be successful but most problems are one offs where the widget is only needed once so why build the widget when coding is faster and cheaper?

I mean, what is programming? It’s describing the rules of a system and all edge cases. For some stuff it makes sense to combine rule descriptions into Lego blocks. At some point, the Lego blocks become too big to be useful and you need fine-grained control over the rules you want to implement.

If you can combine big Lego blocks into something useful, that sounds great.

If you need more fine-grained control, you need smaller blocks.

And that is the spectrum from assembly to higher level languages to platforms to libraries to frameworks to low-code tools to no-code tools. Pick what works for your use-case.

While I certainly saw them coming a mile away, the rise of sites like Squarespace and Wix still unnerves me a little bit.

While I do primarily backend data work these days, I spent a lot of the early 2000's working for an agency that built websites for people and companies. Many of which would have been simple enough to throw together in Squarespace.

I'd always thought I could fall back into building websites if this didn't work out, but I feel like that's falling out as my backup plan. I still try to keep up on CSS and JS though, just incase.

I feel you.

I freelanced designing and building websites in the '00s before gradually migrating into in-house creative direction and product design. After getting burned out doing that, I've tried to start a little solo web and brand shop again, which sounds fun on paper, but I can't find a market for it. People just want inexpensive Squarespace editors. They look to Fiverr, Upwork, etc.

It reminds me of the Wordpress-only shops that drove me to in-house/product design in the first place, but with even less custom work being done.

It's a loss for web as a creative platform, and has left me unsure of how to proceed professionally.

I see it as kind of comforting. These tools take care of the cookie-cutter projects so developers can work on more interesting things.

The first successful no-code platform(VisiCalc) came out in 1979 so calling it a new movement or innovation is just people being ignorant about the past.

In essence this is an old Idea that have been on the cusp of making the professional application developer obsolete since COBOL was invented back in 1959.

There is a cyclic nature to this and at i don't see any real difference in this generation of tools then something like SAP ABAP in that it will not also develop into a new sub-specialization that Leeds to an increase in the need for full time programmers.

No Code can solve problems that have been solved so many times before that a bunch of developers decided there was money in solving the entire class of problems once and for all.

So I think they are great, because who wants to reinvent the wheel? It's so much nicer to pay someone else to deal with the problem while I focus on building solutions to novel problems.

Is it a paradigm shift? Yes, in the same way that Excel was a paradigm shift. When you make it easier to solve a class of problems, then people solve more problems in that domain.

Excel radically transformed so many industries because it suddenly became dirt cheap to do complex costs analysis, so instead of paying an accounting firm to run two or three various costs analysis for a product, they could instead be paid to find the optimal solution for a product to hit a specific price point. Suddenly, we have candy bars with 54.51g of chocolate in them.

Something to keep in mind, is when the cost to compete in a segment goes down, competition increases to the point where the cost to compete is driven back up. If anyone can build a competing product in a weekend with 0 background, then competing products are going to pop up where ever money is being made. And one of those competitors is going to innovate their way to the top, through technology, marketing, corruption, or some other means.

As an SE, I think that no-code is great. It lets us focus on the more interesting and challenging problems. Here's how we approached that in my current start-up.

We built the website on Squarespace ( a tiny bit of custom JS because I wanted a specific UX, but minor). When we are fully launched and selling product, we'll probably continue to use squarespace, but we'll see. It suits us for marketing purposes and capturing interest now.

At the same time, we're working in the hardware space (healthtech building an EEG), so we write all of our firmware, and we've got AI running on google cloud, so all the data pipelines that go along with that.

We're building the front-end for our mobile app, but using Google Firebase for the user account, and other simple user-data stuff that we need. I consider Firebase to be mostly no-code, I code up the front-end, but don't need to do anything on the backend.

The more interesting thing I've heard of recently is Fl{0} (https://fl0.com). They're a Sydney based start-up that is building a low-code style backend system. I'm not completely sure I get it, maybe it's just another version of nodeRed, and other similar tools.

Yeah, I tried to get on this wave of (no|low)-code to enable non-devs to prototype their ideas. Turns out they run into "counter-intuitive" things when modeling your data and ones mental models have to be redeveloped.. and the query languages (like bubble) get pretty abstract fast. Future AI driven prototyping may be interesting. For now lets get back to "medium-code": rails, django, airtable/baserow, canonic, firebase, etc.

From what I've seen close-up in the indiehacker community, it's shifted the goal-posts of what an MVP is.

You used to be able to get away with a landing page with just a form to collect email addresses - now you need a hell of a lot more polish to get started.

The hype around no-code is manufactured and financed by the VC-backed companies in that space. Webflow is probably the biggest culprit, no other company attempts to pretend that a modern Dreamweaver (with all kinds of CMS lock-in under the hood) is going to revolutionize web design.

Other types of no-code tools span the entire gamut of IT, sales and marketing workflows. You already mentioned Zapier which for me has been very useful for a niche use case. I was setting up a virtual conference that used one app for selling tickets and accepting payment, and a second Zoom-like app that would host the livestream. I needed a way to automatically send event registrants an email from the livestream app with their conference link. Zapier did this very easily.

Another type of no-code tool that's pretty common is something like Google Tag Manager. Instead of needing developers to set up custom tag snippets in page templates, you can just add one GTM tag, then use a web GUI to add in additional tags. No access required to the production site.

No-code is always doomed to fail because the forefront of development always requires complex reasoning and understanding of leaky abstractions. I worked at one point with a business rules engine, and non-programmers are fine with a decision tree, but start introducing loops, queues, function calls with multiple parameters, database queries, or even complex logic in if statements and it gets hairy. It takes training to reason like that.

It doesn't matter how nice the UI is, there's a fundamental level of complexity there that requires study and training that also induces anxiety in an untrained person.

No-code can handle a significant percentage of work. In the system I experienced ten years ago I would guess 20-30%? In that case, we had close collaboration between developers and business people within the same building, and some of the business people were even willing to be trained in SQL (!). It's certainly useful in that regard, but it doesn't eliminate the custom stuff. The eventual interactions between the custom and no-code logics are something that requires balancing too.

Bret Victor has ideas. https://youtu.be/8pTEmbeENF4

There is a fundamental tension between “what computers understand how to do” and “the problems that humans are trying to solve with computers.”

Every programming language lies somewhere between one of these two fixed points. The goal of many if not most programmers is to end up with a system that lets you express all of your domain-specific problems as clearly as possible, abstracting away the fiddly bits that you don’t care about.

There’s a lot of stuff that has to exist in order to get to that level, and we neither agree about it nor know all of what it entails for any specific thing. So Domain Specific Languages (DSLs) are often the best that we can do, and they vary wildly in quality.

Some DSLs lend themselves to being visually programmed. They tend to be rare and niche, and incredibly helpful to the people who can use them. Perhaps more is possible, but it requires a foundation to build upon that does not yet universally or even commonly exist, and may never exist.

Its a shift in some ways. Lowers a lot of friction for prototyping and production purposes for plenty of adhoc tools. People think this will help. It does and it will. I've used quite a bit of it and had generally good results. We're only in the early stages even though plenty of tools are a decade old.

But it has limits like everything else. Vendor lock-in is returning similar to the old days of mainframes. But at least this time around the tools are more varied and from different vendors as well as the ability to use one of many languages in most cases.

You can run a bunch of businesses with writing very little code. What they don't seem to include in that no-code advertising blurb is the amount of configuration required for some no-code solutions. Especially integrating each *aaS to the next. That seems trivial but can become quite a project.

The bigger cloud offerings such as AWS create dependencies that might be an issue for a lot of businesses if they try to switch. This includes wanting on-premises solutions for whatever reason instead of the cloud. AWS is more than "hey you can run redis, mysql etc in the cloud". Its constellation of convenience is quite a thing to behold. Gets hard to leave. That's the new variant of the old vendor lock-in strategy: You don't want to leave and it can hurt a lot to do so.

There is also an issue with non-cloud alternatives as inherent to most of the no-code solutions in practical use. Unless of course you have a disaster recovery plan for when your favorite sites go down. We still need to have DR plans even for no-code.

You are ready for the no-code platforms you use to go offline, right?

Haven't mentioned security. Better not forget that either.

No-code means more contract management.

> Clearly these apps/platforms enable non-developers to solve a bunch of problems which would otherwise need a software engineer.

I'm not sure that's as clear as it seems at first. Everywhere I've been involved with them, the flow is like this:

1) Org sold on idea of no/low code tool, "business analyst can build things!" 2) Business analyst tries, fails to build things, calls dev 3) Dev figures it out, could have done similar in a few lines of code. Either a) becomes "expert" in tool or b) goes back to code

I'm not ready to rule them all out, and maybe I just worked with some inept business analysts. These tools are by their nature usually closed source/proprietary, but maybe there's some great ones. But I also wonder if it's not partially fundamental: maybe text is just more concise and expressive than visual paradigms for some problems - there's a reason we still have textbooks for some things.

Good examples of no-code (relative to the things they replace because a good no-code solution degrades gracefully into code/abstraction it replaces for complex cases):

- spreadsheets :: textbook example

- OS/file systems :: it is hard to imagine times without it, when these operations had to be programmed manually

- relational DBs/SQL :: compared to myriads of ways data manipulation was programmed previously

- shell pipeline :: compared to manipulating processes directly in C. People can be tricked into writing useful shell commands without thinking about themselves as programmers.

There are many [less general] domain-specific examples such as GraphEdit, GUI/web-site builders, yahoo pipes, labview, etc.

Declarative configs for various things (even if they literally called "code" can be also considered no-code solutions e.g., IAAC) or various DSLs that discourage the general code with loops/ifs (even if it is Turing complete formally).

I've been waiting for a (popular) low-code movement to hit the backend. Right now we still seem to start every project with - auth,connections,server, etc..

Something like https://github.com/oshalygin/gqlgen-pg-todo-example but easier and more tied into everything already.

Effectively instead of hand coding up the stack, there would be this server that you install and you get auth (implying a user model), GQL, and all you have to do is make the database and define a special file that tells the DB what is viewable or restricted and how that connects to the user.

The package would be 100% open source but would have like modules you could enable to connect it to auth0 (or others) or use a pre-created schema.

That's the stuff that should have been turned to low code by now and I still don't see much progress.

We see a novel use case around low/no code.

We hire engineers (usually ML, computer visions, etc.) and embed them with clients.

They meet 1-1 with their team members to walk through what they actually do in their daily work.

The eng. can then build light-weight solutions in real-time to optimize & automate those workflows.

It’s like prototyping as a service.

There’s certainly a huge movement around “citizen developers,” but what we’ve seen is these makers get stuck quickly when their solutions need to scale, be used by someone else, or integrate with other workflows.

Computational thinking is the key.

Initially we thought, like everyone else, we’d hire no coders and teach them to think like engineers.

It became obvious quickly that is was more about finding product-minded engineers who enjoy building things that help people and then show them how fast they could do that with these tools.

It’s made us incredibly opinionated about no code tools. Most are too limited for this approach.

Someday it might happen, but the problem is being specific enough:


I think what we're seeing is what we've always seen. That is, we start at the lowest levels and continuously work towards a higher and higher level. Constantly making the development process more efficient. No-code solves a problem, but it's not a panacea.

The movement i'm most interested in as a backend developer is the no-software movement.

The idea that the entire process of developing and deploying services can take place in the browser. Why install an IDE when i can just code in a browser. Why install git when i can press a button in the browser and have it handled in the cloud. Why run the code locally when i can run it in the cloud and stream the output to the browser. Why install a bunch of software and configure everything to work on my machine, when it can all be handled in the cloud and interfaced via the browser.

It's always been a pipe dream. I wish that people would invest more into making decent real SDKs for full developers to use instead of chasing this fantasy that you're going to be able to solve all your problems by gluing pre-made lego blocks together.

What invariably happens is that somebody gets a bee in their ear about some silver-bullet low-code tool, and tries to use it. They maybe get a few simple work-flows to work. Then they try to start doing more complex things, and it falls apart rapidly. Then more requirements are foisted onto the low-code platform, and developers get dragged in to try to build integrations into it and new custom components for it. Usually this is unbelievably awful to do.

Eventually you have developers having to maintain this awful Rube Goldberg machine of crap that they didn't want to be involved in,

You don't need to learn to code, and neither do your kids.

I'm a Software Developer, but I don't see why everyone should have to, or feel like they have to, learn to code.

In general, kids and adults alike, but especially kids, should spend more time being active, around others (within reason, these are extraordinary times), and outside - not in front of computer screens.

Not everyone is cut out for or interested in coding, just like not everyone is cut out for or interested in medicine, law, a trade or literally anything else.

That's not a value judgement or a judgement of people's intelligence or lack thereof (unlike a lot of techies, I don't believe we're smarter than anyone else) or a belief that you can't acquire or develop skills - it's just fact.

I think there's a reason this is such a recurrent theme that keeps coming up in different forms across the decades. Often people who are not developers have sensible ideas for apps/websites but do not have access to engineers who can implement them. This is especially true in enterprises.

For example the content team in a company like Doordash won't have access to engineers to help automate content creation.

But people in that team WILL have ideas around how they can automate their processes using a low-code/no-code tool.

Shameless plug - I am myself making one of these tools to help more folks DIY tools, flows & apps without making it themselves. We're here at https://getmason.io

Very old idea. First one I remember was COBOL--enables accountants to learn to use computers "without having to program", meaning without having to learn 1401 code.

Later, there was the 5th generation movement with Prolog or Prolog-type langauges.

Before that there was Fourth Generation Programming.

Building systems is hard and requires programming. So people look for a way around it, leading to the next generation of "no-code". Then, the systems reach some sort of inflection point where programming is again required to add functionality.

[Edit] See also "No Silver Bullet" for a thoughtful discussion about complexity of problems. This cycle will continue to repeat.

As a programmer, I've got a love for code but I have to accept that this is going to be the future for 90% of consumer-facing apps. The most common abstractions for the most common use-cases are already built and they're going to stay that way in my opinion. Once the "hard thinking" work is done building these abstractions, it's just a matter of connecting the dots to bring a product to market in <insert industry of choice>. While there's been no-code tools for a long time (Yahoo pipes being my earliest memory) there's no doubt they're improving every day.

I think in a few years (decades?), "developer" and "programmer" will mean something very different that they do today.

I'm a programmer who does a lot of "no code" development and find those tools very productive for many of the problems I deal with. And I observe every day the people who know "programming" can use those tools far more effectively and come up with far better solutions and solve far harder problems than the people who cannot program, but just learned the tool.

The hard part of programming is computational thinking, and coming up with novel ways to string the right algorithms together to get the result the client needs, not typing vs dragging and dropping.

""" I think in a few years (decades?), "developer" and "programmer" will mean something very different that they do today.""" Hello. Your opinion is very interesting. And can you tell your version of this in more detail.

Laugh all you want, but I genuinely believed that XML standards, yes those 'design by committee' standards like XForms, XProc, XPath/XQuery 3.0+ and just general web standards like XHTML 2.0 could've been the future and a backbone of something that a lot of people could use and not just as customers.

Not by writing XML by hand without proper tools, but using something built upon this, on an extensible, inter-operated web. Think using modern XMPP for messaging, instead of a zoo of messaging apps that can't talk to each other or Yahoo Pipes on steroids. But that's not the universe we live in and that's not the no-code we're talking about.

the shift already happened -- the shift is that software ate all the CRUD business processes that could possibly exist

if you want to build something cool now it had better do more than update a database

I mostly agree, but I suspect not all CRUD businesses have been eaten. The ones that have been eaten have the following property:

-- You have to enter the information in yourself, or your equipment currently captures it for you

There are still CRUD opportunities where you find, capture and enter the information on behalf of the user. The phone captures a lot of data, so all that is already CRUDed up, but if you had novel data -- say from a wearable device -- you could still produce a new CRUD for that.

I think this is why hardware is hot again. It allows us to automatically capture new data that isn't already captured by the phone.

What is the best way to represent and manipulate an abstract syntax tree, or maybe a directed graph of flow control and data movement?

Text is just there as a crutch to language-brain. Image brain is fast with concepts, but bad at details.

I think it stems from the inability to realize that it's not the fact that programming is currently done by typing words and symbols into text files that makes it hard for some people. But that it requires some ability to break up a problem into simpler tasks and then solving those tasks using discrete actions.

The people who can program in no-code environments can also program in all other environments.

Sure, there are _LOTS_ of ways to improve the status quo, and any idea should be tried, but I'd much rather explore more interactive programming environments than focus on the input method.

I've tried this with my current company, where the majority is not tech savy. The business analysts had immense difficulty in creating and maintaining automations on their own. And it gets worse: the few devs that we have at the company had to "rescue" the no-code automations on a daily basis and ended up rewriting most of them. It takes longer for a dev to create an automation in a no-code platform than by simply writing code for this solution.

Your mileage may vary, but my feeling is that no-code will keep growing in relevance, but it's not there yet on what it claims to do.

Explaining the power of programming to someone who can’t code is like explaining living in 3 dimensions to a someone in a 2D universe.

If you can’t code, nocode seems awesome. If you can, it seems like 2D in a 3D world.

Software engineering is too hard. A relatively easy project still needs a coder that has had lots of training and then the never ending maintenance comes after. Even the no code version takes lots of work.

We need the ikea version of software development where a lay person can put together a common type of app and maintenance is mostly automatic. I think the nocode "movement" is here to stay and it's only going to get bigger, in terms of number of apps, and ease of use.

It relates to a lot of things. One thing like telephone adoption "at this rate, everyone will need to be an operator" and then we had self-dial phones instead of switchboard operators. So for simple often done things people can do it themselves. For other rare/special things we can still call for an operator (we still have those right?)

Another way to look at it is like computer architecture. We have technologies for holding data and impedance mismatches between them, so we make intermediary caches, integrated/hybrid devices and devices start blending to look like each other 3D XPoint/NVMe. On another scale a Facebook datacentre can look like a macroscale computer architecture. My point is that 'programming' and programmers started out being one thing, but there will be many different forms of this at many levels, in various vertical areas. We already have specialized platform (Shopify) programmers, and self-serve (Zapier/Airtable) and even among those there could be third-party helpers as has happened around Google sheets data collectors/analyzers. Lo-code/no-code is so many things. It comes back to 'any sufficiently capable configuration schema becomes a lisp'. People want to tweak, so they learn to program.

> (we still have those right?)

I think there might still be operators to help setting up a call with a deaf person. Other than that, I had kind of assumed that the concept was obsolete. What would you need an operator for?

I do think it's a major shift but not in a mutually exclusive way, and maybe not a "paradigm" shift. I think initially, no-code tools were touted as being for non-developers. But now there is a realization that no-code tools are more like "automation" for completing a task. In that mindset, anyone (developer or not) can benefit from using them since it can be/should be/is more efficient. To the extent that no-code tools let a non-developer build and test an end-to-end app as their business, I think that's rare today but I would say we're on our way towards it.

I liken the no-code movement to the introduction of a higher-level programming language. For certain tasks, the higher-level language is more than adequate and a developer (or user) who knows nothing about OSes, file systems or networking, can build an application and probably create value and make money. But the higher-level language doesn't replace the lower-level language overnight, and for certain tasks it'll never replace it.

To use the example you mentioned, if you just want to display a webpage for your co-workers that lets them filter a SQL table, it might take you a few minutes to build that in Retool. If there is a class of such webpages or webapps that could make you money, then it's easy to see Retool as a new higher-level language for building those types of apps.

So, my view is that it's not a paradigm shift for building software, but rather the next step on an evolution towards a more automated process of building software.

Disclosure: I founded a no-code web testing app https://reflect.run

I see a lot of great tools these days that describe themselves as no-code. To me it kind of means: this tool is a tad more powerful than average and can accomplish things you might expect to need code for. In that sense, handing every user tools that are a little bit more powerful, seems great.

The "no-code" where you are building end user apps inside a proprietary, cloud based WYSIWIG editor, that seems like a fad.

I wrote this on another thread a few months ago:

I think the basic reason why low-code / no-code works is down to software bugs and long-tail maintenance.

Bugs are a function of number of engineers, features, moving parts, and significant lines of code.

No-code takes out engineers, moving parts, and SLoC from the equation (as far as the enterprises buying these solutions are concerned), but leaves a lot to be desired in terms of feature set; low-code brings down number of engineers, and SLoC, whilst providing flexibility in terms of bespoke feature sets.

Also, in essence, No-code and Low-code are a natural extension of the cloud computing model in which capex is traded away for opex. And economies of scale, over time ensures Low-code / No-code will be cheaper yet more reliable than anything one (tech-enabled) enterprise can roll on their own. While at some level it is also an indication of 'software is eating the world' phenomena (both in terms of available capital given software economics, and rise in popularity of CS, in general).


It's another case of "your profession will be automated and replaced", which has always historically proven to be both true and false.

The "professions" that get replaced typically aren't professions by the time they can be reliably automated, in that they are usually monotonous tasks that don't contribute to the advancement of any field.

Everything evolves, but the bulk of people creating new software are still coding it after decades, just the same as the bulk of musicians creating new music are still playing instruments after centuries and millennia.

Perhaps our coding tools will eventually become so advanced we can just think it and a piece of software will be created, but that's also boring and unchallenging and will likely have the equivalent creative value of singing into a voice-changing social media filter. We have this in the present day but people still write and perform songs that others perceive as valuable.

The goalposts of what constitutes "creating" reliably move just as much as people continue to need to get their hands dirty in order to craft actual innovation.

The "no-code movement" is perhaps more an example of a "no-movement" trying to masquerade as a movement.

I don't mean to deride it, some things can and should be automated, and this is valuable in itself as it shifts the goals of innovation along. But it's misleading to elevate such things higher than their pay-grade.

And sure, maybe sometime AI and deep-learning could anticipate and create everything we need - "the singularity", etc - but at such a point, that innovation itself has been automated, we'll all probably just happily hang out at the beach, as there'd be no more work left to be done anyway.

There’s nothing new, here. It’s been going on for decades, in one form or another.

Visual Basic was sort of a “no code” solution, at one time (of course, it is, actually, “code,” but the barest minimum possible).

The dream of the C-Suite has always been to toss out those filthy engineers, and generate product directly from the (obviously) superior minds of the executives.

Not sure how well that’s worked out, so far…

The thing is, I hear people give as examples "excel", "visualbasic", and all I can think of is "wow, these are wildly successful technologies that improved the lives of millions of people"

Also, these types of technologies do not reduce demand for real programmers. And a desire to deploy them - effectively to make a product more "programmable" by end users - may not be rooted in a desire to replace developers, but rather to make the product more useful, and thus be able to charge a higher premium for it.

I know a guy that had the best thing ever happen to his career, because of this.

Back in the last century, he was a well-paid employee of a bank (C++). He managed a group of experienced engineers.

The bank wanted to roll out a new product, and they asked him to submit a bid from his group. He specced out a reasonable 18-month plan for a C++ project.

A Vice-President then stepped in, and yanked the project, stating that he, and a small team of sycophants, could do the project in six months, using VB.

My friend quit, and spent the next two years, traveling the world.

When he came back, the project was a shambles, the VP had been fired, and the bank was begging my friend to come back.

He vowed never to be an employee again, and signed on as a contractor, for an eye-watering rate; which the bank immediately paid.

Last I talked to him, he’d brought a house in a Tony neighborhood, for cash, and he wasn’t even 40, yet.

That's a great story! And it makes a lot of sense - you are getting people used to thinking about automation, demanding automation, and trying to deploy automation to more places than before. You are also creating all sorts of APIs exposed by documents and making things more scriptable.

That's going to increase demand for developers of all languages, even if some of that demand consists of hiring professionals when people recognize they are in over their head with one of these scripting languages, or that they've stretched their existing tools and it's time for a more powerful tool.

The downside is horror stories of developers being called in to fix a tangled mess of VB macros. But there's also gold to be mined in those hills.

I wrote ~300 lines of Python in a day and then I passed it to an Okta dev who has spent the last three months trying to replicate it in Okta‘s no code platform with limited success.

At first I was interested in the tool, but seeing how long it’s taken him and his struggles to get things working has convinced me that he probably would have been better served to just learn Python.

It seems like the period when this idea hit its peak was in the late 1980s and early 1990s. That's when there were a lot of apps built to maximize what non-programmers could do, and which also offered the easiest possible on-ramp for people who did want to write simple scripts. Among the big successes of that time:


Macromedia Director, which later evolved into Flash

VisualBasic, which had fantastic WYSIWYG tools for interfaces

A little later:



All the early Web tools (there were hundreds)

It is difficult to now remember the cult that existed around Hypercard for awhile, and which lead to spin off products, like SuperCard.

There was a real mania at that time to make it easy for everyone to learn the basics of programming.

At some point after 2000, and especially after 2010, the idea seemed to fade, and the tech industry for awhile got caught up in going in a very different direction: big frameworks, increasingly complex, increasingly abstract, a development system that required more and more tools.

I would like to see some of the old "education for the masses" energy come back.

Not a bad thing, but you should understand the economic ramifications of it.

"No code" is basically commodification. For some subset of IT tasks, there are now tools you can use to achieve your goals without employing a software engineer. Great - it makes everybody more productive when humans can be replaced by software.

But note that commodity markets, by definition, are low-profit. If you can use some cheap off-the-shelf tool to achieve a goal, so can all your competitors. So people thinking they're going to build the next great billion-dollar web startup off of Wix or Shopify are probably going to be disappointed. They can build a great web startup, but so can everybody else. You can no longer make life-changing sums of money just by being able to throw together a website.

It's more useful to businesses whose competitive advantage is elsewhere. If you make complicated hardware, for example, and just want to be able to sell it without paying the Amazon tax, these tools are great.

What's fascinating to me as that it's happening at the same time as the "X as code" movement.

Devops: Infrastructure as code. or dbt's viewpoint on analytics as code (see https://blog.getdbt.com/building-a-mature-analytics-workflow...)

So I'm seeing it as an exercise in finding sweet spots. There are things that have been mostly manual or point-and-click and people are seeing wins from defining and managing them as code. Usually in terms of reproducibility and testability. Then there are things that people have traditionally done in code (e.g. admin UIs) where maybe most of it can be abstracted away into a point and click tool.

No-code works great until it breaks, and then your ability to debug is going to be very constrained. We're fighting that problem with some no-code ETLs using Stitch at work today, for example.

I mean, once upon a time, UI design and digital composing were "coded". Slowly things get hoisted out of deeply technical domains, or at least, such that someone talented at other things can apply their type of technical knowledge. An artist generally makes a better UI designer than a programmer.

What I don't like is the trend of teaching people to almost reach their goals, without also teaching them how to fill in the details that the "Do What I Say" tool cannot.

What would be a more laudable and practical goal would be something that eases people into more advanced programming, or points them down different paths that are associated. It is useful to know "No, I don't want to do this, but

So in the end, I think the "No code" movement is just the latest iteration of sky high dreams. It looks like training wheels, but it is anything but.

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