Having worked with several low-code/no-code systems in the past, I've had similar experiences. They work really well if you stay within their area of strength, but once you go outside of what it was designed for, it becomes an ugly, unmaintainable mess.

In every project I worked on, the users of the system always wanted it to do things that go beyond what the low-code system was designed for. That always required what was essentially coding, but using some clunky UI for advanced code-like functionality.

In the end, you have a system that would have been much more maintainable if you had just gone with a standard "with-code" solution.

They always sell these things with the idea that non-coders can do most of the work on the system, but that's only true for a very basic system. In my experience, it's coders that end up doing 90% (or more) of the work and it ends up being inferior to a coding-based solution.

Not at all a sales person, but...

I think that a lot of the problems that general wisdom thinks are implicit to no/low code are so prevalent precisely because the barrier to entry is so low.

You get a lot of people who have never programmed anything who can basically put together something that almost works by tweaking tutorials and googling around.

But where they get stuck is lacking the programmer's mentality - of being able to puzzle around restraints (which all programming languages have) and then imagine all the worst case scenarios and test against them.

Down thread, somebody even makes the claim that low code doesn't permit for maintenance but of course this isn't true - again, it's just inexperienced users thinking that once something works once it will work forever.

And the amount of professional developers who would be willing to come in and untangle a low code mess as opposed to suggesting a "real" solution (coincidentally using their favoured stack) probably reinforces the idea that the last 20% is impossible with low code.

It's not about agendas or people being stubborn, it's just about people playing to their strengths and having their perspective coloured by experience

Any no/low code problem trivial enough to be hacked together by a non-programmer can be completely replaced with code in extremely short order by someone who knows what they're doing. The nightmare scenario, where that principle breaks down, happens when you hire people specifically to work on your low/no-code codebase.

As a rule of thumb, the only kind of job posting that should mention a low/no code solution is one for a software developer hired to migrate your current solution to real code.

Yeah code is not a bad thing. It constrains us and make the hard things about designing and building non trivial systems up front.

It may seem like a good idea to postpone such considerations. And it might even be in some situations. But complexity will still bite you in the ass even if you sweep it under the carpet and tell people not to worry about it (for now).

But if people say you can't replace a railroad consist that necessitates engineers and designs with wheel barrels that anyone can push and you say "you totally can, you just need enough wheel barrels" you're being disingenuous about the realities of the two approaches.

> Yeah code is not a bad thing

I think code is a great thing, just that the "everything looks like a nail" argument goes both ways

This whole hammer metaphor gets too stretched in the context of software. Code is not a single thing, it's a whole approach to programming computers. It's hard won territory, seeing people had to use machine code and op code tables to program for a good chunk of history. And the allergy some people feel about it is unjustified in my opinion. The strengths of coding tooling are well worth the investment and trying to avoid code as if it ware a deterrent to "getting things done" is failing to understand what is hard about programming. Not learning how to code (and properly, with version control, code reviews etc which are surprisingly shunned by some professional programmers). The hard things about programming non trivial computer systems are made easier by the scaffolding of programming languages. Not harder.

Low code is great if you don't know programming. For more complex systems you want developers who understand the system deeper than "box connects to other box makes things go brr", and if you have developers who know what they're doing they'll make a better system faster with actual code.

Low code is just a GUI on top of some library. I'd rather just write the code and call the library functions directly than mess around with boxes that do nothing other than limit my options.

As a "no-code sales person," I actually agree. It's why we started on https://plasmic.app, to bridge the gap between low-code and code—we think there can exist low-code tools that integrate deeply with existing code and codebases, to allow scaling in complexity.

A very nice effect of this is cross-functional collaboration—once it's possible for the team's developers to provide the right components as building blocks, then the non-developers in operations, design, marketing and product functions can compose these into full pages.

> Developers are hostile to these types of solutions specifically because once you go past basic CRUD your no code solutions make everything so much harder and complicated compared to if you had of just used JavaScript in the first place.

And being fully honest, I've not seen basic CRUDs since college homework days. Every CRUD I've seen since has some business rules applied to it, whether these are triggers or some special field constraints.

If a business needs a basic CRUD, it gets away using a spreadsheet.

I am sincerely wondering if this must be the case or is it a shortcoming of the existent solutions, but something that can be overcome. (Disclaimer: I am a programmer who never seriously used any low code product apart from a spreadsheet. Unless you count Emacs as a low code platform, which would not be wrong, I guess.)

I think it's intrinsic to the problem. That 20% long tail of the customer's problem is not just different for every company, it takes a decent programmer to recognize where that border line is.

As a result these solutions work just fine until the point where they trip the user up and start repeatedly punching them in the face. The user will usually try to work around the limitations and that's when it goes really badly wrong. Often the users will blame themselves for not knowing how to progress or for creating a mess.

If your needs are simple enough you might never reach that border. It's suitable for those tasks.

It's made worse by the economic incentives of no code platforms too. They try and trap the user on their platform. So, once you reach the border line the user usually has to dump the entire app and bring in a programmer to code it all up from scratch. That makes bad workarounds that much more tempting from the user's perspective and thus that's how the no code solution dumpster fires are born.

Emacs were pretty productive but sometimes overcomplicated imo. Remember TRAMP mode?

in my experience this makes sense. really true, hands down.

however the answer still boils down to "it depends" since it intersects with different industries, and companies of different maturity stages.

making a landing page for some simple site? no code works.

need a fast crud for operations team? no code works.

creating a web app prototype to validate a simple idea? no code works.

refining a product with existing users in terms of platform compatibility, scalability, performance? time for specialists on front-end and back-end languages.

i think there comes a time when sales are coming in at the door and at that point throwing money at the problem makes sense, to move from no code to handwritten web apps and mobile apps.

i personally prefer appsmith over budibase. zapier and n8n, cool stuff too.

but in complex stuff i still come back to reactjs and nodejs.

For anything complex, for example a SaaS platform, your best bet is to build from scratch with code. The flexibility, ownership and technical viability are essential in these scenarios.

For simple CRUD apps, internal tools, reports, spreadsheet replacement - low-code platforms - particularly OSS options (Budibase, Appsmith, and others)