undefined | Better HN

0 pointsethbr04y ago0 comments

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.

0 comments

eropple4y ago

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.

ethbr0OP4y ago

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.

haswell4y ago

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

1 more reply

Tozen4y ago

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.

mdpye4y ago

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.

j / k navigate · click thread line to collapse