Every VC in the world right now is betting on this becoming a thing... problem is that No Code/ Low Code as a product doesn't actually solve the problem that they are trying to solve.

The overarching concept of No Code/ Low Code is that "code" is the hard part of building software, ergo if we can make it so "normal" people don't have to code the problem is solved. Of course we all know that code isn't the hard part of the job- if code was the issue software developers would all be using No Code/ Low Code solutions already (as it's been pointed out, they've been around forever).

No Code/ Low Code is about selling accessibility to the wantrepreneur crowd... the same people that have an "app idea" that they want you to build. It's a huge market, but it isn't going to have an impact on software development any more than model rockets would have on the aerospace industry.

If the No Code/ Low Code tools were any good software developers would already be using them.

(When I am talking about No Code/ Low code, I am not talking about things like Webflow / Dreamweaver NOT solutions like Serverless.)

I came here to write basically this. I agree, and by the way, "wantrepreneur" is perfect.

As a counterpoint, my ML team regularly dumps data into Google Sheets for review / note taking, and we build dashboards using some SQL dashboarding tools.

I've cobbled together email sign up forms for some non-technical side projects with Google Forms, App Script and MailChimp.

I'm not a frontend developer so maybe frontend folks will tell me it's super easy, but my feeling is that there is a lot of space for low code tools that produce software that is not polished, but good enough.

That's not code, it is software usage. The same way a gamer is not a coder when he type some small things in the console or add some script.

Some of these tools are successful in larger companies, basically to handle demand for crud apps for somewhat technical business groups. Quickbase is doing quite well, for example.

Essentially the Microsoft Access market of old.

Yes good observation. Though nicer for the IT department because you can actually see what everyone is doing, what data is there, integrations, etc.

It's also been something a lot of investors have put their hopes in before and had them dashed (probably starting from the early 80s).

It might be that This Time Is Different, but there were a lot of times in the past when "This Time Was Different" too.

isn't there wordpress devs that don't code and make (for now) slow loading websites?

I think low-code is basically just graphical programming. If you want it more powerful/universal you need to code just the same. There might just be more or less big library helpers/blocks. Maybe it's just the next step of being "high-level" and now is indeed the time for it.

Also if you manage to write something as a nice XML/yaml/json you might as well put a nice UI on it.

Technology is no longer a tool for economic growth, it is now almost entirely a tool for economic control. So investors should adjust their strategy to the new reality.

"Does this technology provide a means for seizing control of the existing economy?" That's the question which investors should be asking.

I think cryptocurrency is the only technology which can achieve this due to the way it transcends existing legal frameworks in terms of ownership rights; a bit like the notion of corporate personhood allowed corporations to gain an upper hand and transcend the legal frameworks of its time.

Corporate stocks were vehicles for inter-generational wealth transfer and the next vehicles will be cryptocurrencies.

I agree with this. I do wonder if low/no-code products will ever become good enough that you'd feel comfortable actually using one. I believe a part of this is having infrastructure/system that can describe itself in sufficient detail. Then the ability to modify itself with sufficient variety. Fundamentally I've seen ORMs/APIs/integrations that are more or less a crap shoot as to whether or not they're going to work, god forbid if a version of something is upgraded. The fallibility of it all will prevent this from happening.

they totally will... but it's probably going to show up the way you would expect it to... some open source project will get really good at helping you configure 95% of your app with a CLI or something... then you'll mod some methods etc. Eventually that will transform into something that can predict what you'll need.

IMO stuff like serverless, OpenAPI, some of the boilerplates out there, etc are already heading in that direction. It used to take me a week to build a standard CRUD API with a handful of models, now I can do it circa 15-30min.

I have been reading the same prediction my whole life so I'm sure this will be a boom at some point by pure chance. But I tend to think that those solutions already exists, and the typical tool coming to mind is WordPress. You literally don't need to know code, just install some plugins that give what you want and go ahead. Pay someone to maintain it (there are tons of companies already). It doesn't need to be WordPress, there are many other platforms. For low code Django comes to mind.

For the very typical use cases there are well suited SaaS tools e.g. Shopify for shops.

I do think that the very typical cases are well covered. Sure, there's room for improvement but not sure if a real boom is around the corner but as I said I heard this so many times (and also seen so many tries) that well, at some point something may actually happen I guess.

For the past month I've been working on remaking one of our company's internal apps in ReTool. Retool is definitely "lo-code" and not "no-code": you will need to write a few lines of JS, and more than a few lines of SQL, so you do need an actual developer to do the work. However, I was able to replicate about 90% of the functionality of the existing app in a little over a month working by myself, while the full-fledged React app required a team of 3 and had been ongoing for several years.

The downside to the user is that certain kinds of UI polish and more complex behaviors aren't possible. From the developer's side, there is limited ability to share code between apps, so you wind up cutting and pasting a lot, and the work is much more boring that regular dev work. Still, it's a lot less work than building up a regular CRUD app.

What a lot of people replying to this are missing is that nobody wants visual drag & drop systems. Not coders, not "no-coders". Not anybody.

This is the root cause of an endless series of failed ventures and products.

The successful no-code products are something else entirely, merely masquerading as no-code. Excel is probably the prototypical example of this: it is a reactive dataflow system, but you'll never find any dragable widgets with little input ports and output ports you can connect.

It's trivial to get started with Excel. It's trivial to connect cells and get some computations going. It's then a nice smooth transition all the way up to multidimensional analysis, and not once do you have to break out into a full programming language.

That's what people want.

What you imagine they want is something childish and useless. To be honest, it's simply arrogance. By assuming the user can't code, it's natural to assume that they think at a level of a young child and need only toys.

For fuck's sake, Excel is 64-bit and fully parallel! Did you know that? I've seen 60 year old ladies from accounting produce spreadsheets that can bring a 16-core terminal server to its knees, and that spreadsheet was doing entirely legitimate, useful, productive computation. Show me the last system you built that can efficiently utilise a modern high-core CPU for a single user!

Your market is adults. They need power tools, not toys.

Start thinking like that, and you'll have a successful product.

No code/low code is snake oil that gets sold to us every few years, and always fails to take hold. The reason why is because by the time you get the GUI widgets, hand gestures, whistled tones, or whatever in your low-code solution specific enough to be interpretable by computer, what you've come up with is isomorphic to constructs in some programming language. (And don't say "But AI will solve this problem!": anything intelligent enough to turn vague requirements into working programs outside very well specified constraints is intelligent enough to demand compensation negotiations for continued output.)

So you really haven't made the code go away; you've disguised it as something that isn't code. This actually works well for tricking people into programming when they otherwise wouldn't. And this itself is a viable strategy: consider the secretaries in the 1970s who used Lisp to "customize" Multics Emacs and were never told they were programming it. But it doesn't eliminate the complexity of coding. And most "no-code/low-code" platforms have disadvantages (vendor lock, extremely limited applicability, zero portability) that are almost guaranteed to bite you in the ass later.

I think the real shift will be in "no code experts" who get paid more than actual programmers because they learn how to deal with the limitations and extend them for businesses who already have sunk costs in them. A perfect example is Excel experts who can do very well because Excel has symbiotically intertwined with how many businesses operate. Or COBOL experts who get paid because nobody learns COBOL but places refused to upgrade.

Servicing software debt is an industry in itself.

I am predicting this at the large firm where i work. They use terms like "robotics" and "ai robots". The primary line of thought being touted across the firm is "easier to transfer and maintain than traditional code", but there is substantial gatekeeping occurring. I assume license prices are high, because there are not many per department. I am guessing that some of the "automators" holding these scarce licenses will develop a nice moat for themselves if they can prove their value. I sat in on a meeting where the "automator" and his manager said they were seeking to automate high-time-savings/high-risk tasks first (risk being large potential dollar loss, legal exposure, etc. upon failure), which is odd but great for visibility and moat-building (given that fear of traditional code brought them to this point, fear of being unable to properly maintain the ""robots"" could easily come next)

I feel like this will be like WordPress at best, and Cordova at worst.

WP lets someone with no formal CS training do wonders, and I think it's a good thing.

Cordova tries to save time and cost, but you need people with above average skill to hack things, know all the gotchas and bugs of the no-code system, all the undocumented bits, but still deal with the risks. Nobody wants to do the plumbing, nobody wants to dedicate their career to it, and so it ends up overpriced to the buyer and underpriced to the seller.

You could also end up with something like Parse, which had some of the best handovers from closed into open source, but the stigma of being dropped by a major tech company made people avoid it.

No code = someone else's code, it's been around forever, used to be called cots

And "cloud" means someone else's computer, been around forever, used to be called mainframes. Didn't stop it from being a marketing explosion.

In the "cloud" space I think the difference was being able to sell it as a commodity and in as large or small chunks as the client wanted, not the concept itself.

Not sure what the equivalent in no/low-code would be.

In my mind, "the cloud" came into existence when it became practical to rent servers (virtual or physical) by the hour, rather than by the month.

It's one of those things where a difference in degree in implementation terms (leasing in smaller time increments) allowed a difference in kind in usage terms (on-demand server allocation over advance provisioning).

Isn't that what I wrote? Or do you disagree with something I wrote?

I think you are both right but it’s funny because most customers have this stuff up and running 365 days a year anyway

In the 80s it used to be called CASE. It flopped then too.

And 4GLs. About the same time period.

As an example, the best and most successful no-code low-code product was and is Excel.

Excel is spreadsheet application. It is not related to the parent post, which discusses networked CRUD application, with various integration points, DB, caching, redundant deployments, etc..

I've experienced Excel being used with all of those in bigger non-tech companies.

Integration points: Everyone sends their version to Person A, and they integrate it, filter it, postprocess it, extracts parts into another sheet, etc.

Caching: Everyone has their own version of the excel sheet in their local inbox.

Redundant: There's typically plenty of shared directories on which you can find the same excel sheet in different versions.

lol, HN melodrama-purists downvoting

No, Excel is not relevant to the conversation. Excel is a standalone desktop application. No, Excel is not an example of a "no-code" webapp. Do you seriously need another adult to tell you these things?

No-code/low-code is definitely reaching a crescendo of buzz in the legal tech market right now. Which is funny because it’s an idea as old as computers themselves, but there’s a lot of low-hanging fruit still left.

They tried this in the 90s and 00s.

It was such a spectacular failure it's funny to see it recycled.

And for you to claim you wouldn't have to worry about maintenance is especially comical. It was extremely high maintenance and expensive, and it often broke.

Programmers don't just code a problem, they solve the problem. Teasing out the actual business logic is as much a part of the job as anything else, and one that most employees and managers are so clueless and utterly useless at that any no code solution will require a programmer to actually use it any way.

But without any of the flexibility code gives, you end up with tons of dumb, manual, expensive, hacks and a sub-standard product. Eventually the 'no-code' platform adds the ability to use some code and you end up with a really shitty software platform that delivers 80%, but the effort required to get that last 20% is far in excess of just starting again and writing it from scratch in code.

Ask any programmer who remembers workflow software their experience and you will learn from the mistakes of two decades ago.

Tried it in the '80s too, here's an ad from around 1981

https://thedailywtf.com/images/ads/All-programs-you-need-sma...

https://en.wikipedia.org/wiki/The_Last_One_%28software%29

"Teasing out the actual business logic is as much a part of the job as anything else..."

That's the definition of a programmer analyst or business analyst. If the business is too cheap or clueless to create business process maps or hire someone as a process efficiency expert, then they are certainly too cheap fund properly developed software and too clueless to intelligently answer the questions that an IT resource has to use to tease out an answer.

I do agree that no-code is not going to replace the need for software professionals.

I think low code/no code could really change thing if they can figure out how to make declarative code fast.

Think Prolog etc

You're on to something.

Low code platforms, at their core, allow you to define the software with data (from predefined components usually through UI) and that's how they enable super productivity, until you hit a wall.

Data Declarative programming paradigm could potentially achieve the same levels of productivity without its limitations but it's very difficult to get the right implementation.

The most interesting development in this area I had found, is Fulcro Rapid Application Development Tools [1] - a fullstack clojure framework that's performant, declarative and extensible. RAD is still alpha but it bases on battle-proved Fulcro. Once you hit the limits of declarative RAD you can easily extend it with regular Fulcro components which are, in their essence, a cheap abstraction over React/React Native components - offering industry standard performance.

[1] https://github.com/fulcrologic/fulcro-rad

Kinda like MS Access ? I am only half joking :)

I’ve been part of a couple no code/low code platforms. They pop up every decade and do ok for a while and then wither and die, only to be replaced by the next gen of them.

4GL (fourth gen languages), BPM systems, things like clipper or dbase, access, even VB is a low code kind of platform.

The new generation focuses on web tech and mobile, and they’ll do well for a while, until the landscape changes enough and they accumulate enough cruft to become unwieldy to use.

In 10 years or so we’ll be talking about something like that again.

I like, and use these tools. Getting it right is hard though. Google just shuttered their AppMaker, which I thought was one of the better attempts.

I think one of the issues of nolocode is it doesn't actually help people think like programmers, but the tools are often created with the implicit need to do that, a need which the creators don't see because they are coders.

People get spreadsheets and word documents. I don't really know why. But they get them. But while it might seem like the step from doc/xls to nolocode is small or even non-existent, I think it actually is really big for most people who are supposed to be the audience for that (complete non developers).

I think one reason is because people don't want the responsibility to make a system that can break. I'm not too sure if this is the only or the biggest reason, but I think non-coders don't have the sense that they can build things, and even if you show them they can using some hot tool, it seems they're still scared it's going to break and it will be on them.

Maybe one reason is because if you break an Excel doc, there's usually someone around in your org who knows how to fix it. But the same can't be said for some random new hot nocode tool.

I think for specific use cases, yes. But for general, web and mobile apps, I just think it is too much complexity you can't simplify away, or at least none of the box-dragging UIs seem to have achieved that.

I agree this can be a big market, but a shift is needed to make it actually easy, not "look how easy it is" easy. Taking a different tac, maybe there's just not a market for it. The browser/HTML/JS is everywhere. It's not that hard to build a simple tool or app, but people in orgs use Excel, they don't build a simple page, even. It's not because they couldn't learn how, but somehow that just now what people in orgs do. I don't know why.

The tool I use has three user types: Maker, Editor, and Viewer. Only Makers can make the kinds of changes that would be code. Editors can manipulate the underlying data. Viewers, of course, get read only.

The nice thing about this model is that it implies there's a bar to be a Maker and other users can't break your work. You need to be able to reason about concepts like DRY, star schema, cardinality, etc. As a Maker in my org (15-30K people depending on where we are with the pandemic) I can support many no-code apps painlessly in addition to my primary responsibilities, whereas one CRUD app on Heroku had me feeling spread pretty thin.

Part of it is probably that editing a spreadsheet feels much like a direct manipulation of the medium, where programming is much more abstract, made of descriptions.

> The problem these tools solve are more related to infrastructure rather than one's ability to code.

So... SaaS?