Comment by brw12 | Hacker News Reader

Comment by brw12 | Hacker News Reader

I'm a huge skeptic of no-code among my friends and colleagues.

But seeing how pretty much everyone else here is also expressing skepticism, let me play devil's advocate.

I recognize that the utopian promise of no-code is nonsense. There will always be feature demands that violate the "on-rails" nature of the environment, and either require supplementary code, or require waiting for the platform's coders to code up support, or require rebuilding the application from the ground-up.

That said, there are all sorts of applications that really are so narrow that an existing GUI can accommodate them. Other posters here have called out Excel/Sheets as an example; Wordpress, Squarespace and WYSIWYG web page editors are another. As a coder, I always feel frustrated by WYSIWYG interfaces' side effects, limitations, and inevitable bugs, but people do use them all the time, productively.

Of course, both web editors and spreadsheets do involve the ability to write code! It's just that the code's role is very narrow and limited to a small expressive range (CSS, say, or various SUMs and HLOOKUPs).

When the domain is relatively narrow and its boundaries are pretty clear, no-code can be wonderful. The real question, right now, is whether applications that are innovative can be built using "no-code" tools that necessarily assume all sorts of limitations.

I have seen some clever and impressive uses of, say, Airtable + Zapier + Typeform. That sort of "API-weaving" seems to me the most promising direction for no-code. I'm more skeptical of the projects, like bubble.io, which try to be a sort of Photoshop-for-building-applications.

Let me add to this. My viewpoint is similar to yours, and I have some anecdotal info to support this devil's advocate.

My wife was able to setup a WordPress site that sold fundraiser raffle tickets for her Rotary Club. The event was on local TV and handled a spike in traffic – thousands of ticket sales in a few hours – with no problem. This whole thing cost her less than $300, which would only get a few hours if she had to hire a dev.

I kept on telling her I was on standby and could help out, but she didn't need it once. She built the entire thing with WYSIWYG and WordPress plugins.

No-one is saying you build your tech startup with no-code WYSIWYG. But imagine if my wife's no-code skills (in her place, WordPress) became as common place as knowing Microsoft Office.

I’m skeptical of no-code solutions because every once in a while, a user does something really problematic without knowing that they do — this isn’t a criticism of the user; how can they be expected to understand, let’s say, security, if they don’t have a rudimentary understand of cryptography or client/server models?

A more physical analogy is that I do DIY — including internal wiring of the house. I’m comfortable doing that because I’ve read through the whole of the regulations and have a degree-level education in Physics and understand the risks. If a stranger asked me whether they could wire their house through Youtube videos I still wouldn’t happily say yes — even though theoretically there’s enough good information out there to wire a house.

The security example is a really interesting one because what you describe as a weakness of no-code viewed another way is a huge strength.

That is, an approach of the user not understanding these things and so deliberately going for a black box, just-works-in-exactly-this-way solution that's centrally tested, audited and maintained across the no-code platform is actually pretty great for security.

Having an understanding of how these things work, even a really good one, does not preclude mistakes if you want to do things customly - on the contrary this only ever increases the surface area for mistakes.

You might argue, and it often is argued in engineering (use the auth provided by your framework, well-trusted ecosystem libraries, etc), that it's better to just rely on known good solutions even when you do have a great understanding of the principles for this reason.

I think your counterpoint is a good one — but I would argue that it has the implicit assumption that such users will and can delegate to authority.

In my own experience this hasn’t been the case — the alternative of the user not understanding a problem is not going with an authoritative approach, but simply not to think or care about the problem.

Even when relying on ‘good’ solutions you need the requisite knowledge to judge what is good — otherwise people, engineer’s included tend to view such solutions as unnecessary. In your example, an authorization framework will have a selection of different protocols from OAuth, Basic, LDAP and so on — all of which are ‘good’. Without understand authorization and authentication could you really select between them?

The other problem with "no code" is that code is more than just text on the screen. It's a way of thinking. A very formal and precise way of thinking, which is what you need to have to be able to make a computer do what you want, and not do the things you don't want it to do.

To build complex things with "no code" tools, you need to adopt the coding mindset anyway. You end up discovering concepts like modularization, abstraction, you end up internalizing what the "no code" building blocks actually do, vs. what they advertise to be doing. But by then, what you're doing is just writing code in an extremely inefficient, unergonomic and probably visual way, and you'd be better off having learned a programming language.

I totally agree, and look at the success that Salesforce.com has had. I have seen numerous examples where a reasonably tech savvy person on a sales or support team has been able to put together a totally acceptable workflow to manage their team without having to deal with any product managers, qa, developers, or IT personnel. It can save a tremendous amount in both development and opportunity costs.

It's not always perfect. As adoption and complexity increases, teams often find themselves bumping up against the limits of the tool eventually, and need to bring in specialists to help. But even then, it seems much better than the alternative of trying to code your own CRM system from scratch.

Excel is what it is because of the VBA escape hatch. Competing spreadsheet applications with 80% of the formula support are only 20% as useful.

I have used excel a lot in my career, but I don't think I have ever created or even seen VBA in any spreadsheets. I think it probably varies a lot by domain, but if I were to guess I would probably say that far less than 1% of Excel spreadsheets use VBA. And a lot of spreadsheets that do are probably good candidates to be rewritten in some other tool.

In my opinion, the reason that Excel has such a commanding lead in that space is more due to familiarity, compatibility, and that Excel is still just one of the nicest spreadsheet apps to use.

Indeed xlsx files don’t have VBA macros, you need the less common xlsm file format for that.

Reply on news.ycombinator.com