Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

From what I can tell yes. It’s intended to imply something more.

See bubble for example - https://bubble.io . It’s basically “visual” Rails. The intention is to allow users to build complex, interactive software visually, without having to write code.

Webflow has a ton of plugins that can get you something similar. You can have a user model (memberstack.io) with authentication and even the ability to create user specific content. I was able to create a fairly complex user dashboard that had real time charts pulled from an Airtable database that was synced automatically with user interaction using Zapier.

...but, here’s the issue. You just can’t do enough. I made it about a week before I abandon the idea and went back to Rails.

I’m still bullish on the idea of no code though. The tools are there. They just need more functionality.



That's always the case though. The reason why we use programming languages is because we need the expressiveness they offer. Attempting to simplify it any further severely limits the type of applications you can build. And so you end up with cookie cutter apps. It might be fun, it might even be useful for some back office tasks, but if the marginal cost to produce a thing goes to near zero, it would imply the supply of apps competing for that category would explode.


A lot nocode or lowcode tools are visual programming languages; they are in fact just programming tools but look (and often are) simpler to start off with. But when you need more, you are in fact programming with code, just via a visual interface. Which indeed can (will) become painful for many tasks. Then you are using the wrong tool for the job.

Thing is, and this differs per market; most companies do not need anything more than endless streams of crud apps, and that is where these tools shine. You (and many of HN) might work in the b2c market, but where I work, people do not care much about how things look or ux; they care if they work just a little better than the sap or oracle interfaces they had before. Actually, this goes for many (most?) b2c products as well; most (traditional; challenger banks are a lot better) banking or airline apps I know look like bad template barf-ups (many are indeed that, bought from the same cooking cutting companies) and yet people use them. Would it be better if they were custom designed with money spent on actual ux and design? Sure, but apparently not enough to matter to the company commissioning it.

When companies I work with look for no/low code, the only reason they will not use it is vendor lock in; if they cannot run on premise and/or ‘eject’ the code, they will not use it. Several products allow this and they are fairly popular (so much in fact that they cannot find enough ‘devs’ for their clients).

These systems have their place; it is just (much) faster (some boring things in regular environments are just a few clicks with these tools) for some x% of applications while another y% you cannot do with them or is very difficult; I would still do the x% in such a tool as thinking ‘we might need x+y later on’ is premature usually and in my experience does not pan out. We have programmed applications ‘created for expansion’ 15-20 years ago that run to this day which would have fit in the x%; aka we wasted time and money while the expansion was never realised by the client.

Edit;

> it would imply the supply of apps competing for that category would explode.

And that is a very consumer centric approach; we are not all making fitness apps or something; these apps would all look (more or less) the same but work on different APIs and data; that is fine for almost everything; not only some internal stuff. It helps companies a great deal to just have something their clients can use vs nothing, even if the cost is close to zero; and they cannot be the same as they talk with different systems and different data. Even creating partner dashboards more efficiently than slinging code is something people do all the time and you cannot ‘just copy paste that’ to another company.

These products are not generally meant to build ‘the next whatsapp’. But you can prototype it with them and show investors; I agree with you there though; wrong tool for the job.


> When companies I work with look for no/low code, the only reason they will not use it is vendor lock in; if they cannot run on premise and/or ‘eject’ the code, they will not use it. Several products allow this

What nocode tools don't have lock-in? The ones I know which are open source still have these proprietary add-ons for important stuff like authentication or connecting to other systems.


Conceptually some no-code tools work essentially as glorified editors or code generators for a particular subset of a mainstream programming language. In this case, at any point you can abandon the no-code tool for a project or part of it and continue maintaining and developing it as an ordinary bundle of code.


Which ones? As a dev, if I had one that ejected into readable React (Typescript) code I'd probably use it.


WordPress


>Thing is, and this differs per market; most companies do not need anything more than endless streams of crud apps, and that is where these tools shine.

IME at least 20% of the needs of these companies are not met by "basic CRUD app programming" which is why these no-code things never really take off despite often appearing quite impressive. 80% is not enough.

Basic CRUD also implies an understanding of domain modeling and normalized relational db design. In practice these are uncommon enough skills among developers never mind users of tools like these. That's half the reason why spreadsheets business users want turned into apps are so horrendous - it's not even intrinsically a problem with excel, it's just that the relationships between the domain objects are usually confused and the data is in a mess.


I've worked for a company that market themselves with "No code". How it worked there was that we spent a lot of time understanding the users need and business domain and modelled a properly normalised db from it. Then came the "no code" part, which was a platform that made it easy and very fast to create the first iteration of the interface from the database. For those things where the mapping to some tables in the database were simple it was just a few clicks. Something like search customer and create/update customer pages takes less than a minute to create.

And you are of course right in that this will only create 80% of what the customer needs. But the marginal cost for us to create those first 80% of the application were almost zero. And since we weren't worse than anyone else with the last 20% we could deliver fast, inexpensive and still have large margins.

The mistake I think many do when they think "no code" is that they think that they can eliminate the developer and let business people just "configure" the new application. But those people have the insulting idea that the only thing that makes programming hard is syntax.


> The mistake I think many do when they think "no code" is that they think that they can eliminate the developer

Exactly. No-where did I mention you do not need (good) devs for this. They are just not writing code (in the traditional way). No/lowcode is not saying the same as end-user development, although it gets mixes up quite a bit (also by the companies selling the tools), it is not what I mean when when working with such tools.

And in my experience at least, you can push back closer to the 80% than the 100%, so sure, you don't get that last 20% (or part of it) but maybe I can convince the client they don't need it. And if they do, I would choose (maybe) another tool for the job like I said.


On one hand this is correct, many apps compete only on form function like (Instagram vs snap).

I think there will always be a random form function that captivates (today’s ticktok), but my prediction is that the web will be won less by competing on form factor, and rather won focused on other parts of the user experience.

In a simple example, logistics is an obvious differentiator, 2 day vs 5 day shipping etc.

There are so many dimensions to compete on and app design will contribute to many of those dimensions, but some ways to compete will not involve coding.


For me, no-code tools were the gateway to learn to code.

Build a site with a WordPress theme and ultimately end up editing the HTML and CSS to get the desired result that's not possible out of the box.

Add a plugin that doesn't quite meet my needs and end up learning PHP to edit the source.

For people that learn by taking apart what's there, no-code tools are excellent learning tools.



> See bubble for example - https://bubble.io . It’s basically “visual” Rails. The intention is to allow users to build complex, interactive software visually, without having to write code.

Why the "hate" for code? I immediately understand the problems that typical programming languages have for people who are not trained in programming. But there exist good reasons why other approaches like "visual programming" have failed (except for some niches). So in my opinion the solution is not to "spread hate" against code for a "stupid" market pitch, but take the time to develop programming languages that are better suited to the needs of the customer.


I can think of a few. Most of these things could also be done with text-based code, but typically aren't when you're just starting out:

- No set up issues (visual programming is cloud-based)

- Less of a discoverability issue (visual programming shows a lot of things all at once)

- A sense of familiarity (people have seen flow chart like things before)

- It's easier to see the difference between arguments and parameters

Full disclosure: I have almost never seen visual programming languages, but I got the idea that there was no devil's advocate present within you. So here I am ;-) I find it quite easy to think from a beginner's perspective, because in some sense I can't fathom that I know what I know now since I never thought I'd ever know this much in my entire life (and I'm only 31, lol).


> - No set up issues (visual programming is cloud-based)

Cloud-based has nothing to do with visual programming or no-code (you can also do cloud-based editing of conventional code if you desire). Counterexamples: LabVIEW, Simulink.

> - Less of a discoverability issue (visual programming shows a lot of things all at once)

Wasn't "shows a lot of things all at once" actually an argument (marketing pitch) why conventional programming language overwhelm many people who are not programmers, and visual programming languages are "thus" better because charts have a lot less "intellectual density" than computer code?!

> - It's easier to see the difference between arguments and parameters

What is actually the difference?


I said

> Most of these things could also be done with text-based code, but typically aren't when you're just starting out

This means that it all can be done, but isn't. Which means that it's a cultural issue, not a technical issue.

Also, I was under the impression that discussion was about mainstream programming languages and mainstream visual programming languages (of which you said there were none). Here's a workable definition of mainstream: the Stackoverflow top 10. It doesn't have LabVIEW and Simulink.

When you discount niches for visual programming, then you have to do it with text-based programming as well, otherwise the argument isn't fair. I presume that you know this. So I find it peculiar that you don't qualify why you're using languages that aren't (seemingly) remotely mainstream, or why you're not using mainstream examples.

> Wasn't "shows a lot of things all at once" actually an argument (marketing pitch) why conventional programming language overwhelm many people who are not programmers, and visual programming languages are "thus" better because charts have a lot less "intellectual density" than computer code?!

I wouldn't know.

I'm quitting this discussion, the exclamation mark + question mark, "what is actually the difference?" There seems to be no wonder or curiosity from your side. Instead it seems purely adverserial.


There's lots of people who want to do stuff, but code is expensive. They are excited for solutions that let them do "pretty much" what they wanted to, without having to make that investment into code.


> There's lots of people who want to do stuff, but code is expensive.

Nearly every work is expensive if done by other people.


That's true until the work done can be shared among many.

Shopping websites used to often be custom built or unsuitable platforms (eg. web forums) repurposed. Now they're on Shopify.

Warehouses used to be something that you rented, fitted out, and hired personnel to run. Now they're Fulfillment by Amazon.

Servers started on premise, then moved to data centers, then moved to cloud.

With each of these shifts, a little bit of control is given up on order to have these things on-demand at lower cost.


Isn't this tool, exactly one of those languages? And their marketing, a filter for the folks that will find it useful?


> I’m still bullish on the idea of no code though. The tools are there. They just need more functionality.

Maybe, but I think the idea of setting up a SaaS business without writing any code just won't work.

If the tooling is simple enough that a non-coder can get it to work, then the no-code SaaS business is providing very little of value. The user could just do the job themselves using the same no-code tools.


I think you’re right that having some sort of moat is very important to a business, but I don’t think that moat has to necessarily be the software. It could be operational expertise or fame or capital or connections or anything else that’s hard to replicate.




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

Search: