Yah unfortunately where I work has 4 different deployments.
1. Sandbox for the devs to do whatever they please
2. Environment for the acceptance testing of features
3. Stable environment that mirrors production for sales and training
4. Production environment
ETL tools are what came to mind for me. To some degree, we can already observe no-code examples like you mention in engineering fields.
So far, the driving force behind no-code is the limitations of the overall workforce. Data engineering is a field that is desperately needed in many companies, but without a sufficient workforce to meet the demand.
> no-code has the potential to massively improve the day-to-day lives of programmers
In this, I don't agree at all. It is not an improvement to someone who can write code to do anything they want, and force them to learn the quirks and limitations of a no-code environment. How many engineers want to spend their days managing broken configurations rather than solving problems? Simple things are often simple, but hard things become impossible. What then?
Going back to data engineering -- what I see is a large percentage of jobs that don't even require programming as a skill. How many people with more than 5 years of experience will apply to these specialized tools-based positions? What happens to the problem solving capabilities of your teams?
You may achieve a fully replaceable workforce when you take this path, but you also accomplish a brain drain. Worse for engineers -- as these tools fail to meet the needs of business, they come and go like fads. Unless you want to learn a new set of tools and their limitations every 2-3 years, it is impossible to remain employable in certain fields.
To me, no-code is exactly the wrong direction. Knowing how to solve problems in code is one of the most valuable skills for modern work. The problem lies in our education system, which has not embraced that it is as important as the "three R's". Efficiency of work would be greatly improved if more people knew how to write code (at least scripting) than if fewer people did.
These are all absolutely solvable. We're building a low-code internal tool builder with features meant to address these drawbacks that keep nocode from scaling.
Not true for all such tools. Though like a sibling comment suggests, part of the issue is that no-code is defined too broadly to include everything under the sun.
I work on a no-code tool that checks those specific boxes (shameless plug: https://www.plasmic.app), but the use case is very different from Bubble. The key is that it explicitly doesn't try to replace all code, and was designed from the ground up to integrate deeply with existing codebases. I don't think we need be the only one, other tools can also do the same. But this aspect is by far the most complex part of building this product. That, and the pressure to create vendor lock-in is real.
No-code has been the "future" for 20 years, but no no-code framework has never reached close parity with code ecosystems, and always require someone doing code for each no-code component
I read the other day (but failed to really verify) that COBOL is so verbose in part because it was designed as a "no code" language that at least could be understood, and possibly written by "business people".
I have yet to meet anybody in this magical category that knows how to program except for the syntax, and if only they were given a way to draw their vision as a picture or write it in English, instead of have to stoop to "code" they'd be able to cut out software developers and go straight to their vision. But I assume as long as software is sold to "leadership" there will be a niche for these products - just not one in which they are actually used for anything.
> I read the other day (but failed to really verify) that COBOL is so verbose in part because it was designed as a "no code" language that at least could be understood, and possibly written by "business people".
So was ADA, allegedly. I don't find it more readable than C or C++, just more verbose.
The issue is that, syntax doesn't matter when one still has to understand concepts BEHIND that syntax.
Visual programming may help learning though. I learned OOP via Flash, learned SQL via some SQL editor, and learned basic ASP classic via Dreamweaver. But it's just a step, like ridding a bike with training wheels.
Ada's verbose syntax was a workaround for primitive terminals with limited character sets. (That's also why it's case insensitive.) It was never intended to be especially English-like, or easy to survey for non-technical users - while both of these were goals for COBOL.
The problem with these tools is that they invariably have solutions to their own design problems that conflict with the system you need to build.
One of my old customers went with Tibco as a replacement for an internally developed system and have had no end of troubles with it. They were over 2 years late in their roll-out and the unforeseen limitations/lack of understanding of their tool have basically made them re-create their old C# application in Tibco in its entirety, thereby reducing Tibco to a second-rate cluster manager. I'm sure they did a number of things wrong in that effort, but that's an expensive lesson that they relearn every year when their gigantic Tibco invoice arrives.
I'm also in the process in migrating a system from the Versata business rules engine/ORM application that is hands-down the worst system I've ever seen in over 30 years of writing software. This is another client with their own set of problems, but I have literally been able to replace thousands of lines of bizarro-world copypasta a single SQL query running on top of a normalized database.
That's not to say that Tibco or these new cloud-centric tools aren't impressive and useful, but I haven't seen any of these tools that I would ever recommend for anything other than the absolute simplest glue code service. Additionally, I probably replace that service with something boring as soon as it gives me any backtalk at all.
> modern no-code languages such as Bubble are Turing-complete and require the same kind of programming logic that coding does.
> Programming (precise communication of logic to a computer) != code (precise, text-based communication of logic to a computer).
This is a recipe for disaster. Systems that are capable of Turing-complete computation are already hard to understand when written in code; I can only imagine they are harder to understand if they are communicated in pictures or something else.
Examples of dubious no-code (or less-code) environments include:
It gets super tiring to see that picture get posted every time LabVIEW or visual programming environments get brought up and the sentiment you stated quoted. It's as if people who have never even used the language dismiss 8 years of my professional career simply because they don't understand it.
I've said it before, and so I'll say it again. No proper LabVIEW engineer who cares about code quality would ever do this. The "problem" with LabVIEW is that it immediately showcases your spaghetti code. Spaghetti code in a text-based language looks like any other code, upon first glance. This is in fact a feature of visual programming languages.
LabVIEW has libraries (aka modules), clusters (aka structs), immutable value-based (not reference-based) OOP (something along the lines of F#'s records or Elixir's structs but with encapsulation, inheritance, and interfaces), VIs (aka functions), polymorphism, and more. Beyond that, LabVIEW even has some unique features like malleable VIs. These features are to be used to get modular, clean LabVIEW code.
I find that people who hold the opinion that you wrote have never spent any actual time with LabVIEW, and if they did, it wasn't for an extended period of time and/or they didn't treat as a programming language. The way I think about and write LabVIEW is really no different from the way I think about and write in F# or Elixir.
Lastly, LabVIEW is not a no-code or low-code environment. It is code. It is a language that compiles down to an intermediate graph representation that then compiles down to LLVM IR or, in the case of FPGAs, VHDL and Vivado HLS.
LabVIEW is stunning. Also works great for engineering since visualizing control theory is important in real-world scenarios more than it is in virtual.
I see flexibility as the biggest obstacle to no-code tools. Pick any no-code platform and that platform is inevitably going to have some limitations to it. Now for some applications that are fully thought out, this might be just fine.
The problem is for all the other applications. What if your app needs some new functionality and you realize that the no-code platform can't do it. What do you do then? The article mentions that you can write "low-code" but that just gets us back to where we started for the most part.
A big part of selecting your stack is making sure it's still open ended enough so new features can be bolted on later.
Until no-code platform standardize in some fashion (at least in the way AWS/GCP standardized), it's going to be a really hard sell. Sure this platform can do everything you need it to right now. But will that still be the case 3-6-9-12 months down the road? Without a magic ball to tell you the future it's almost impossible to predict this.
This looks like an IFTTT on steroids. Like, from writing code we go to designing circuits? How's that making it simpler? Can't wait to open a legacy circuit so big my new MBP can't load it.
I work on a no-code platform. I’m not saying it’s impossible for no-code to replace code, but I’ve noticed a few phenomena that makes me think it’s unlikely. The first is what I call lowering the bar. No-code platforms lower the bar for who can create something, which is good, but the bar is also lowered for what can be called a creation. I’ve used a Reddit clone implemented on Bubble. The quality bar was definitely lower. If the quality bar is low, then the no-code platform is unlikely to succeed. The second thing I’ve noticed is that it’s hard to escape the no-code platform’s vision. With code, everything is truly composable and each computational feature doubles the creation space. No-code platforms tend to have a linear relationship between new features and what can be created, so you end up only being able to create a narrow subset of things that have been envisioned by the platform creator. No-code platforms can succeed as design tools, but anything with complicated logic remains out of reach.
> The tradeoff for this is generality. No-code languages aren’t general-purpose in the same way a language like Python is, but for the vast majority of projects, this is a good tradeoff. Most programming work happens inside a well-defined domain like web development, so why shouldn’t it happen in a language specialized for that purpose?
I'm trying not to just react by saying "change is bad", but I am legitimately not sure I buy the argument in this article, even beyond the basic distrust of a prediction made by someone with a financial stake in the outcome.
He goes to great pains to say that no-code is not the same as WYSIWYG editing, but I'm trying to conceptualize how his explanation differs from them. The IDE is the language, got it. But, the fundamental problem I have with this is the same: your expressiveness with the language is limited to what the product owner decides to support in the UI.
So, you've moved away from having a language with elements that can be combined in infinite ways, toward something more like a MadLibs, where you can make some meaningful choices only within a strict framework somebody else has made for you.
Or, if that's not fair, then a more generous analogy would be something like writing free verse compared to writing a sonnet. You're using the same language, but one option is much more constraining.
Or, an even more practical example would be with something like WebFlow, which is the "no code" (note the quote marks) solution I've used. I think it's great, and you can do a ton of stuff with it without investing a lot of time into learning HTML, CSS, and Javascript. But, then you run into this weird situation where somebody decided that you can only absolutely position elements from the top or left, not the bottom or the right. If you want to do that in a "no code" way, you're out of luck, because nobody provided a button for you to do that.
And even if this kind of system isn't what the author intends to mean, I think it is analogous to the kinds of problems any highly-abstracted programming environment will run into.
I constantly hear Product Owners say that it's okay and acknowledged that ultimately, you hit walls with no-code/low-code. There was no button to do Thing X, so you just can't do it. But did anyone validate this with the end user? Is this actually what they want?
> So, you've moved away from having a language with elements that can be combined in infinite ways, toward something more like a MadLibs, where you can make some meaningful choices only within a strict framework somebody else has made for you. Or, if that's not fair, then a more generous analogy would be something like writing free verse compared to writing a sonnet. You're using the same language, but one option is much more constraining.
To be honest, I don't think this is a valid analogy as you are comparing apples and oranges. One is a tool to build simple CRUD interfaces which is typically used to quickly build business applications, and another is a coding language which provides lots of flexibility but is significantly slower to create an application and is much more complex to build.
IMO a good solutions designer or architect will be able to identify which solutions/problems will be better solved in a low-code environment and visa-versa. It's not a 'one is better than the other', programming languages will be better for some problems and low-code solutions will be better for others.
My first programming job was working with Asymetrix Toolbook, which was basically Hypercard with the ability save generated code in the final project. I still think it was kind of cool that I could write something like this in 1992 (syntax is obviously incorrect):
func doSomethingImportant()
hugFamily()
notifyThePresident()
end
set somePage.someButton.onclick = doSomethingImportant()
I could pop that into a console window, save the application, and the handler I assigned for someButton on somePage would be persisted across saves in the IDE.
That simple feature, which they apparently got rid of later, was a very gentle introduction to metaprogramming and I never had that with any of the other visual programming environments I've worked in since.
I've worked with Microsoft PowerApps and evaluated Mendix, Outsystems, and ServiceNow.
Low code will certainly be a part of the fortune 500 landscape, similar to how BPM (Business Process Management) and other visual tools have been used for decades. They work best when processes are relatively simple, and just need a little bit of "glue" between pre-built systems. The users are often semi-technical, sometimes called "Technical Architect" or "Programmer/Analyst" and they often work directly with the final users to document and implement the requirements.
The issues I've seen with low code are:
1. Most users are unable to decompose their requirements into discrete steps - a Business Analyst is still needed to do this work. Low code can be useful here, but the BA role is usually extended to do the work. Vendors claim low-code reduces the need for this position, but it does not.
2. The resulting work flows are often quite brittle and hard to maintain. For example, it is often easier to rebuild a MS Power Automate flow from scratch than to substantially modify an existing one.
3. Technical debt is also very real for visual diagrams. There are little to no refactoring tools on these platforms, and even simple business flows can rapidly become hard to read and update (much harder than code in fact) As the process becomes more complex, code becomes much easier to maintain than these visual tools.
4. Visual flows are really pure procedural code - there no meaningful way to do object oriented or functional programming on these. This can rapidly lead to "spaghetti flows", the visual equivalent to "spaghetti code".
5. Speed and scale are still issues - all of these are slow and choke on even medium sized datasets. Tuning can be difficult because they often hide the underlying data system.
6. The platforms are very proprietary and very expensive. For that money, you can recruit and train several engineers on modern open web standards and frameworks and the long term team productivity will be much larger. If these platform were sufficient for scalable rapid general development, FANNG companies would be using them instead of paying expensive custom developers.
These tools can certainly be useful in some contexts, but I expect it to displace precisely zero software dev/engineering jobs in the long run. Visual tools have been tried and failed many times in the last 50 years.
To me, research in next generation computer languages is much more compelling.
> The platforms are very proprietary and very expensive
Yes, just like "serverless", all that hype is here to serve a pricing model, nothing more. These tools don't do anything IDE like Dreamweaver or some form app generators did at the end of the 20th century. It's just "as a service" now.
This is exactly correct. In fact if you open Mendix studio pro, it will look very similar to Visual Studio 2005 or 2008. Almost all of the visual design elements in these tools have been tried and abandoned by Microsoft.
I’m going to be the devil’s advocate here and vouch for no-code.
The HN crowd is not the target, so do not expect to understand it. in fact, you should expect to NOT understand it.
I’d say that no-code tools are made with the same mindset as spreadsheets: to put into the hands of non-engineer specialists (accountants, marketers…) a subset of what engineers can already do without said tools.
it’s democratizing a (small?) part of the engineering mindset. As such, it is not a threat to engineers at all, as most of the difficult tasks of engineering are still unavailable (or hardly available) within the reach of these no-code tools.
I do not care that this or that tool is Turing-complete. Actually, I find it a vanity feature and it makes me smile at best.
Some no-code tools may very well succeed someday in some non-software engineering communities, and I wouldn’t feel threatened.
When you think about it, the music production tools have had such tools for ages and no engineer was hurt in the process.
I agree with your post and want to add a second reason why HN is not the target market - which is the number of users.
I think most people on HN are building large applications that are supposed to be highly scalable, ready to have hundreds or thousands of users.
Low code tools are often aimed at applications used by 1-2 people to perform some simple business process which would otherwise be done by paper and a spreadsheet. These users never get applications built for them because the IT team has a long list of priorities for development which come before dedicating time to make the lives of some low-level administrative clerks easier.
I built a simple billing tool in Retool in an afternoon which one person uses but which we could have never approved an IT team working on. The tool I built probably saves them 20% of their time, but if we went to IT they would have said that a proper tool built from scratch would probably take a team a few sprints to build and would have had a very long ROI because IT teams cost more than one administrator. IT teams do not want to spend the resources of several engineers to save the time of one administrator anyway.
So a key benefit of Low-Code to me is that problems can be solved in low-code that otherwise will go unsolved because IT teams don't want to / can't commit the resources to solve them 'properly'.
I would agree with your point yet the no-code tools are definitely not marketed as that. And we all know how marketing influences decisions by people remote enough from the tasks at hand. So what worries me is the prospect of having to support no-code which creeped into applications important enough to make management throw fits.
Excel is exactly what people should think of when "low code" comes up. All these other tools like Retool, Accern, UIpath, Webflow etc etc are immature and haven't fully proven their use cases, so of course they're easy for an experienced developer to start criticizing.
Ask those same developers if they'd want to use code for everything an experienced finance or accounting person uses Excel for. You can -- and there are cases where you should in fact be using Python or R. But generally, no. Excel is the perfect tool for its (very large) market niche, and all this current low / no code trend amounts to is people searching for more market niches.
I’m a competent Python programmer and am currently using PowerAutomate at work because Sharepoint. You know what’s scary about it? I can’t really write tests. My non-technical team understands why this is a problem, but it would never have occurred to them.
The problem is that no-code is not well-defined. It's used to label everything from Excel to Airtable to Zapier to Webflow to Bubble to Retool.
And within that umbrella, some of them are relevant to the HN crowd.
Your examples, like spreadsheets for supply chain planning or DAWs for music production, are indeed disconnected from what developers touch. Your Ableton projects don't concern them.
But other times, the tool very much impacts developers. For instance, I work on https://www.plasmic.app, which lets marketing teams build landing pages and other content on React websites. Here, the stakes are higher when it comes to page performance, design system consistency, component reuse, and so on. As such, developers heavily vet the tool, similar to picking a CMS, and virtually all of our customer adoption was driven by developers.
So relevancy to devs depends entirely on what specific tool/use case you're talking about.
Every business person knows no-code is the future and is the evolution of programming that's going to drive new innovation and make it cheaper than ever to develop products.
Everybody who has ever professionally programmed knows this is bullshit.
Every once in a while, a startup like this comes in, writes some advertorial blog post like this to promote their usually proprietary no-code platform. "The future is here, no code YAYY!". I WANT to believe this, it will make life easy for consultants and IT heads like me if it actually didn't have some important short-comings.
The first and most obvious one is proprietary - difficult to migrate logic. Once you sign up for these platforms, it's a death trap with no way out. Sure, you got to market faster than you competitors, but now you want to build your API for a government/large client? Whoops, you better have a billion dollars because we charge you per request or some other insane pricing model.
Oh, you want to customize your logic? You have to use this specific workaround that doesn't just make sense. Oh you want this particular feature X for Apple? Nope, sorry, we don't support it.
The most important of all - as a consequence of the lock in - When we have a 3 day outage because our engineer had a beer on Friday night and pushed a deployment, we take down your entire business with us! Nope, you can't even do a thing except watch all those cancellations on Stripe due to our mistake. Guess we'll give you a $20 rebate on your next billing cycle for our troubles. Sorry!
Like I said, I WANT to support no code movement. It WILL make my life so much easier if it actually worked the way I wanted it to:
1. No BS workarounds if I ever wanted customizability.
2. No lock in, I want to deploy across multiple cloud vendors for redundancy. Your deployments should not have to affect mine. The only way it could work is if you used a hosted image that is kind of open source that I can build and deploy on top of. No depending on you for everything.
The almost real no code exprience I was super impressed with was the one demo I saw using Open AI that actually wrote an entire portion of React code base with just a few clicks. Such a platform (if it exists) not only gives me full control of the code (If I want to), but I don't have to depend on you for deployments so you can charge me insane pricing for server costs, etc.
Until then, thanks, but no thanks.
No code only looks attractive for demos and investor slides, but for IT people like me, I'll pass, no thanks.
I'm not sure who you are using, but lots of low-code platforms let you self deploy across any cloud which will probably solve your 'number 2'.
It won't resolve your want to be able to migrate to another platform later down the line, but unfortunately that's mostly the same for most enterprise software (i.e. see all ERPs).
I'm personally in the 'all-code'/'semi-code' camp, but only because I enjoy coding and absolutely love solving problems. But, if I'm being completely honest, I also enjoy being known as a wizard wielding powers mere mortals can only dream of. I think that the empowerment of having a skill others lack makes us feel worthy and drives this vehemence to no-code. With that being said no-code is the future and is the logical progression. I'm not saying the future is here yet or no-code is developed enough to take over, but when it is, it will relegate purists(full-code evangelists) to either switch their skills to helping develop it, go down to lower levels to help push the boundaries of hardware, or work on maintaining / slowly modifying enterprise programs. I could ask for some examples of things to refute this, but they will likely be anecdotal one offs that aren't as useful or unique as we think.
Yea Yea enterprise code will live on for another millenia, but even the big sluggish machine I work for is constantly trying to find use-cases for no/low code solutions to save money. Let's be open and honest for one second, couldn't most(emphasis on MOST )enterprise and small business apps, dashboards, and helper programs be done with no code?
The article is an ad, we get it, but it's pointing out that you're still the wizard and master of the universe you (and most importantly the less technical plebs) perceive you to be. You may just be dragging and dropping pieces of logic to create a program, but you are the Sherlock Holmes of that solution. Not to mention that you can still alter the boilerplate pieces or create custom ones if you need it to do your specific bidding.
Can we stop with these ridiculous terms like server-less and no-code when neither is that?
I also have an issue with these over hyped new technologies that you must use but no ones knows how they work underneath. Just fancy magic, enter these commands and directly sudo inject it via bash into your system. That's until 2 years later and someone has to fix something or a system fails but the version you deployed is no longer supported, upgrade is impossible and everyone has moved on to the newest popular setup.
Serverless is just short for: you don’t have to manage your own server, no code is short for: you don’t have to write your own code. Just like c is no-assembly, Java is no-c/no-memory management.
Do you think every developer should understand the entire stack below his choice of abstraction? Do you know c, assembly, cpu micro code, tcpip, etc?
Do you think every excel macro user should know the entire underlying stack used to create excel?
> Do you think every developer should understand the entire stack below his choice of abstraction? Do you know c, assembly, cpu micro code, tcpip, etc?
Yes, they should have a basic understanding. Pretty much like a dentist understands biology.
Yes, at least a bit, because the people in IT are the ones that need to make sure the thing runs and that there are backups. Having Devs that don't have a clue about this getting managers to push this garbage on IT makes their life miserable. They are the ones that have run in the middle of the night because some containers aren't running. Not the dev that used some fancy command to deploy it.
No-code will never be the future of programming, because the phrase doesn't actually make any sense.
"No-text-code" I guess is more what they were going for. This is still not the future of programming because the fastest most fluent way for human beings to communicate ideas precisely is through words. Text-based code is not, and will never be, an anachronism, pictorial or graphical representation will never replace language in computers for the same reason that it doesn't outside of computers.
Devops interfaces will get better, GitHub co-pilot will continue to evolve, but you can't replace, or even touch really, characters and regular expressions as the best way to give computers instructions that they haven't gotten before.
You might find it interesting to know a lot of really important code is not written by text but using tools like Simulink and other graphical programming systems. This is used, for example, to program the critical parts of NASA spacecraft. It's a lot easier to reason around images and, from what I understand, makes it easier to formally prove the underlying software too.
There are many areas where preciseness is achieved through visual models. E.g., in architecture words will never replace the need for a visual representation of the building to be constructed. Some for 3d printing.
In architecture, you don't draw the fact that the building will be X feet high, you draw pictorial representation of the building, and communicate the precise values with symbolic representation, because precise values have to be communicated with symbolic representation.
I'm not a professional programmer, or even a good one I suppose, but I would never use this approach.
Ignoring the fact this is clearly an advertisement for a company product; this type of thing would need to be opensource and not tied to one company for it to succeed otherwise you're just stuck on a single platform at the mercy of the company managing it. Vendor lock in doesn't quite do it justice.
I think my main issue though is the abstraction involved in this. Because whilst moving from machine language to assembly, to C, to Python (or whatever higher level language route you want) these abstractions makes sense (at least to me though I'm always curious about what's going on under the hood) I'm not convinced about this abstraction. It doesn't seem helpful. I could program in scratch if I want...
>this type of this would need to be opensource and not tied to one company for it to succeed otherwise you're just stuck on a single platform at the mercy of the company managing it. Vendor lock in doesn't quite do it justice.
In the low-code/no-code space, this is a feature not a bug. Some members of upper management at the company I work for have bought into the no-code hype. The sellers of no-code solutions rephrase vendor lock in as their "walled garden", evoking images of Apple's ecosystem and all the success they've had.
Of course, people who haven't drank the no-code koolaid can see it's just a way to get you locked in and paying a huge cloud services bill to the vendor every month.
No code is less relevant through something like Bubble vs enterprise grade platforms that are well integrated into the business. O365 will continue to dominate in this regard with the power suite.
Bubble must assume there is a future of innovation that isn't removed from UIs and simple crud.
After reading that article, I still don't fully grasp what bubble in particular, or "no-code" in general, actually offers or provides.
This no-code movement strongly reminds me of the 5GL (or was it 4GL) snake oil pushed in the 1990's. None of it panned out for a variety of reasons. Except for some of the people pushing them, I guess. I presume they made lots of money.
86 comments
[ 3.0 ms ] story [ 153 ms ] thread- no automated testing
- no deployments other than to production (to be fair Retool supports being deployed into two environments… but some teams where I work have three)
- no history (e.g. git)
- logging is a pain (imagine if the logs for each microservice you deployed had to be viewed/searched using a different tool… yeah…)
I’m not saying they don’t have their advantages… but where I work we want to move away from Zapier and Airtable because of the pain they cause us.
Yah unfortunately where I work has 4 different deployments.
1. Sandbox for the devs to do whatever they please 2. Environment for the acceptance testing of features 3. Stable environment that mirrors production for sales and training 4. Production environment
So far, the driving force behind no-code is the limitations of the overall workforce. Data engineering is a field that is desperately needed in many companies, but without a sufficient workforce to meet the demand.
> no-code has the potential to massively improve the day-to-day lives of programmers
In this, I don't agree at all. It is not an improvement to someone who can write code to do anything they want, and force them to learn the quirks and limitations of a no-code environment. How many engineers want to spend their days managing broken configurations rather than solving problems? Simple things are often simple, but hard things become impossible. What then?
Going back to data engineering -- what I see is a large percentage of jobs that don't even require programming as a skill. How many people with more than 5 years of experience will apply to these specialized tools-based positions? What happens to the problem solving capabilities of your teams?
You may achieve a fully replaceable workforce when you take this path, but you also accomplish a brain drain. Worse for engineers -- as these tools fail to meet the needs of business, they come and go like fads. Unless you want to learn a new set of tools and their limitations every 2-3 years, it is impossible to remain employable in certain fields.
To me, no-code is exactly the wrong direction. Knowing how to solve problems in code is one of the most valuable skills for modern work. The problem lies in our education system, which has not embraced that it is as important as the "three R's". Efficiency of work would be greatly improved if more people knew how to write code (at least scripting) than if fewer people did.
I'm sure others are too.
While your critique of automated testing is valid, the others are largely solved. Even integration testing can be done with third party tools.
Bubble is awesome if you have a fairly simple CRUD app that isn’t likely to have millions of concurrent users.
Most of the best devs I know are bored to tears of building those kinds of apps anyway, so no code has a nice niche in that ‘in between.’
I work on a no-code tool that checks those specific boxes (shameless plug: https://www.plasmic.app), but the use case is very different from Bubble. The key is that it explicitly doesn't try to replace all code, and was designed from the ground up to integrate deeply with existing codebases. I don't think we need be the only one, other tools can also do the same. But this aspect is by far the most complex part of building this product. That, and the pressure to create vendor lock-in is real.
1. I am a fast typist, I am a slow tool user.
2. I find it easier to learn languages, I find it difficult to learn UIs.
3. I do not think visually, I think in language.
I have yet to meet anybody in this magical category that knows how to program except for the syntax, and if only they were given a way to draw their vision as a picture or write it in English, instead of have to stoop to "code" they'd be able to cut out software developers and go straight to their vision. But I assume as long as software is sold to "leadership" there will be a niche for these products - just not one in which they are actually used for anything.
So was ADA, allegedly. I don't find it more readable than C or C++, just more verbose.
The issue is that, syntax doesn't matter when one still has to understand concepts BEHIND that syntax.
Visual programming may help learning though. I learned OOP via Flash, learned SQL via some SQL editor, and learned basic ASP classic via Dreamweaver. But it's just a step, like ridding a bike with training wheels.
One of my old customers went with Tibco as a replacement for an internally developed system and have had no end of troubles with it. They were over 2 years late in their roll-out and the unforeseen limitations/lack of understanding of their tool have basically made them re-create their old C# application in Tibco in its entirety, thereby reducing Tibco to a second-rate cluster manager. I'm sure they did a number of things wrong in that effort, but that's an expensive lesson that they relearn every year when their gigantic Tibco invoice arrives.
I'm also in the process in migrating a system from the Versata business rules engine/ORM application that is hands-down the worst system I've ever seen in over 30 years of writing software. This is another client with their own set of problems, but I have literally been able to replace thousands of lines of bizarro-world copypasta a single SQL query running on top of a normalized database.
That's not to say that Tibco or these new cloud-centric tools aren't impressive and useful, but I haven't seen any of these tools that I would ever recommend for anything other than the absolute simplest glue code service. Additionally, I probably replace that service with something boring as soon as it gives me any backtalk at all.
I don't even need to read the article to know it's trying to sell something.
> Programming (precise communication of logic to a computer) != code (precise, text-based communication of logic to a computer).
This is a recipe for disaster. Systems that are capable of Turing-complete computation are already hard to understand when written in code; I can only imagine they are harder to understand if they are communicated in pictures or something else.
Examples of dubious no-code (or less-code) environments include:
* https://en.wikipedia.org/wiki/LabVIEW , e.g. https://blog.jki.net/a-recipe-for-spaghetti-code-in-labview-...
* https://en.wikipedia.org/wiki/Scratch_(programming_language) , e.g. https://www.how2shout.com/wp-content/uploads/2019/11/scratch...
> * https://en.wikipedia.org/wiki/LabVIEW , e.g. https://blog.jki.net/a-recipe-for-spaghetti-code-in-labview-...
It gets super tiring to see that picture get posted every time LabVIEW or visual programming environments get brought up and the sentiment you stated quoted. It's as if people who have never even used the language dismiss 8 years of my professional career simply because they don't understand it.
I've said it before, and so I'll say it again. No proper LabVIEW engineer who cares about code quality would ever do this. The "problem" with LabVIEW is that it immediately showcases your spaghetti code. Spaghetti code in a text-based language looks like any other code, upon first glance. This is in fact a feature of visual programming languages.
LabVIEW has libraries (aka modules), clusters (aka structs), immutable value-based (not reference-based) OOP (something along the lines of F#'s records or Elixir's structs but with encapsulation, inheritance, and interfaces), VIs (aka functions), polymorphism, and more. Beyond that, LabVIEW even has some unique features like malleable VIs. These features are to be used to get modular, clean LabVIEW code.
I find that people who hold the opinion that you wrote have never spent any actual time with LabVIEW, and if they did, it wasn't for an extended period of time and/or they didn't treat as a programming language. The way I think about and write LabVIEW is really no different from the way I think about and write in F# or Elixir.
Lastly, LabVIEW is not a no-code or low-code environment. It is code. It is a language that compiles down to an intermediate graph representation that then compiles down to LLVM IR or, in the case of FPGAs, VHDL and Vivado HLS.
I wouldn't consider LabVIEW no code either.
The problem is for all the other applications. What if your app needs some new functionality and you realize that the no-code platform can't do it. What do you do then? The article mentions that you can write "low-code" but that just gets us back to where we started for the most part.
A big part of selecting your stack is making sure it's still open ended enough so new features can be bolted on later.
Until no-code platform standardize in some fashion (at least in the way AWS/GCP standardized), it's going to be a really hard sell. Sure this platform can do everything you need it to right now. But will that still be the case 3-6-9-12 months down the road? Without a magic ball to tell you the future it's almost impossible to predict this.
I'm trying not to just react by saying "change is bad", but I am legitimately not sure I buy the argument in this article, even beyond the basic distrust of a prediction made by someone with a financial stake in the outcome.
He goes to great pains to say that no-code is not the same as WYSIWYG editing, but I'm trying to conceptualize how his explanation differs from them. The IDE is the language, got it. But, the fundamental problem I have with this is the same: your expressiveness with the language is limited to what the product owner decides to support in the UI.
So, you've moved away from having a language with elements that can be combined in infinite ways, toward something more like a MadLibs, where you can make some meaningful choices only within a strict framework somebody else has made for you.
Or, if that's not fair, then a more generous analogy would be something like writing free verse compared to writing a sonnet. You're using the same language, but one option is much more constraining.
Or, an even more practical example would be with something like WebFlow, which is the "no code" (note the quote marks) solution I've used. I think it's great, and you can do a ton of stuff with it without investing a lot of time into learning HTML, CSS, and Javascript. But, then you run into this weird situation where somebody decided that you can only absolutely position elements from the top or left, not the bottom or the right. If you want to do that in a "no code" way, you're out of luck, because nobody provided a button for you to do that.
And even if this kind of system isn't what the author intends to mean, I think it is analogous to the kinds of problems any highly-abstracted programming environment will run into.
To be honest, I don't think this is a valid analogy as you are comparing apples and oranges. One is a tool to build simple CRUD interfaces which is typically used to quickly build business applications, and another is a coding language which provides lots of flexibility but is significantly slower to create an application and is much more complex to build.
IMO a good solutions designer or architect will be able to identify which solutions/problems will be better solved in a low-code environment and visa-versa. It's not a 'one is better than the other', programming languages will be better for some problems and low-code solutions will be better for others.
That simple feature, which they apparently got rid of later, was a very gentle introduction to metaprogramming and I never had that with any of the other visual programming environments I've worked in since.
Low code will certainly be a part of the fortune 500 landscape, similar to how BPM (Business Process Management) and other visual tools have been used for decades. They work best when processes are relatively simple, and just need a little bit of "glue" between pre-built systems. The users are often semi-technical, sometimes called "Technical Architect" or "Programmer/Analyst" and they often work directly with the final users to document and implement the requirements.
The issues I've seen with low code are:
1. Most users are unable to decompose their requirements into discrete steps - a Business Analyst is still needed to do this work. Low code can be useful here, but the BA role is usually extended to do the work. Vendors claim low-code reduces the need for this position, but it does not.
2. The resulting work flows are often quite brittle and hard to maintain. For example, it is often easier to rebuild a MS Power Automate flow from scratch than to substantially modify an existing one.
3. Technical debt is also very real for visual diagrams. There are little to no refactoring tools on these platforms, and even simple business flows can rapidly become hard to read and update (much harder than code in fact) As the process becomes more complex, code becomes much easier to maintain than these visual tools.
4. Visual flows are really pure procedural code - there no meaningful way to do object oriented or functional programming on these. This can rapidly lead to "spaghetti flows", the visual equivalent to "spaghetti code".
5. Speed and scale are still issues - all of these are slow and choke on even medium sized datasets. Tuning can be difficult because they often hide the underlying data system.
6. The platforms are very proprietary and very expensive. For that money, you can recruit and train several engineers on modern open web standards and frameworks and the long term team productivity will be much larger. If these platform were sufficient for scalable rapid general development, FANNG companies would be using them instead of paying expensive custom developers.
These tools can certainly be useful in some contexts, but I expect it to displace precisely zero software dev/engineering jobs in the long run. Visual tools have been tried and failed many times in the last 50 years. To me, research in next generation computer languages is much more compelling.
Yes, just like "serverless", all that hype is here to serve a pricing model, nothing more. These tools don't do anything IDE like Dreamweaver or some form app generators did at the end of the 20th century. It's just "as a service" now.
The HN crowd is not the target, so do not expect to understand it. in fact, you should expect to NOT understand it.
I’d say that no-code tools are made with the same mindset as spreadsheets: to put into the hands of non-engineer specialists (accountants, marketers…) a subset of what engineers can already do without said tools.
it’s democratizing a (small?) part of the engineering mindset. As such, it is not a threat to engineers at all, as most of the difficult tasks of engineering are still unavailable (or hardly available) within the reach of these no-code tools.
I do not care that this or that tool is Turing-complete. Actually, I find it a vanity feature and it makes me smile at best.
Some no-code tools may very well succeed someday in some non-software engineering communities, and I wouldn’t feel threatened.
When you think about it, the music production tools have had such tools for ages and no engineer was hurt in the process.
I think most people on HN are building large applications that are supposed to be highly scalable, ready to have hundreds or thousands of users.
Low code tools are often aimed at applications used by 1-2 people to perform some simple business process which would otherwise be done by paper and a spreadsheet. These users never get applications built for them because the IT team has a long list of priorities for development which come before dedicating time to make the lives of some low-level administrative clerks easier.
I built a simple billing tool in Retool in an afternoon which one person uses but which we could have never approved an IT team working on. The tool I built probably saves them 20% of their time, but if we went to IT they would have said that a proper tool built from scratch would probably take a team a few sprints to build and would have had a very long ROI because IT teams cost more than one administrator. IT teams do not want to spend the resources of several engineers to save the time of one administrator anyway.
So a key benefit of Low-Code to me is that problems can be solved in low-code that otherwise will go unsolved because IT teams don't want to / can't commit the resources to solve them 'properly'.
Ask those same developers if they'd want to use code for everything an experienced finance or accounting person uses Excel for. You can -- and there are cases where you should in fact be using Python or R. But generally, no. Excel is the perfect tool for its (very large) market niche, and all this current low / no code trend amounts to is people searching for more market niches.
And within that umbrella, some of them are relevant to the HN crowd.
Your examples, like spreadsheets for supply chain planning or DAWs for music production, are indeed disconnected from what developers touch. Your Ableton projects don't concern them.
But other times, the tool very much impacts developers. For instance, I work on https://www.plasmic.app, which lets marketing teams build landing pages and other content on React websites. Here, the stakes are higher when it comes to page performance, design system consistency, component reuse, and so on. As such, developers heavily vet the tool, similar to picking a CMS, and virtually all of our customer adoption was driven by developers.
So relevancy to devs depends entirely on what specific tool/use case you're talking about.
Everybody who has ever professionally programmed knows this is bullshit.
The first and most obvious one is proprietary - difficult to migrate logic. Once you sign up for these platforms, it's a death trap with no way out. Sure, you got to market faster than you competitors, but now you want to build your API for a government/large client? Whoops, you better have a billion dollars because we charge you per request or some other insane pricing model.
Oh, you want to customize your logic? You have to use this specific workaround that doesn't just make sense. Oh you want this particular feature X for Apple? Nope, sorry, we don't support it.
The most important of all - as a consequence of the lock in - When we have a 3 day outage because our engineer had a beer on Friday night and pushed a deployment, we take down your entire business with us! Nope, you can't even do a thing except watch all those cancellations on Stripe due to our mistake. Guess we'll give you a $20 rebate on your next billing cycle for our troubles. Sorry!
Like I said, I WANT to support no code movement. It WILL make my life so much easier if it actually worked the way I wanted it to:
1. No BS workarounds if I ever wanted customizability. 2. No lock in, I want to deploy across multiple cloud vendors for redundancy. Your deployments should not have to affect mine. The only way it could work is if you used a hosted image that is kind of open source that I can build and deploy on top of. No depending on you for everything.
The almost real no code exprience I was super impressed with was the one demo I saw using Open AI that actually wrote an entire portion of React code base with just a few clicks. Such a platform (if it exists) not only gives me full control of the code (If I want to), but I don't have to depend on you for deployments so you can charge me insane pricing for server costs, etc.
Until then, thanks, but no thanks. No code only looks attractive for demos and investor slides, but for IT people like me, I'll pass, no thanks.
It won't resolve your want to be able to migrate to another platform later down the line, but unfortunately that's mostly the same for most enterprise software (i.e. see all ERPs).
Yea Yea enterprise code will live on for another millenia, but even the big sluggish machine I work for is constantly trying to find use-cases for no/low code solutions to save money. Let's be open and honest for one second, couldn't most(emphasis on MOST )enterprise and small business apps, dashboards, and helper programs be done with no code?
The article is an ad, we get it, but it's pointing out that you're still the wizard and master of the universe you (and most importantly the less technical plebs) perceive you to be. You may just be dragging and dropping pieces of logic to create a program, but you are the Sherlock Holmes of that solution. Not to mention that you can still alter the boilerplate pieces or create custom ones if you need it to do your specific bidding.
Anyways, how is everyone doing today?
I also have an issue with these over hyped new technologies that you must use but no ones knows how they work underneath. Just fancy magic, enter these commands and directly sudo inject it via bash into your system. That's until 2 years later and someone has to fix something or a system fails but the version you deployed is no longer supported, upgrade is impossible and everyone has moved on to the newest popular setup.
Do you think every developer should understand the entire stack below his choice of abstraction? Do you know c, assembly, cpu micro code, tcpip, etc?
Do you think every excel macro user should know the entire underlying stack used to create excel?
Yes, they should have a basic understanding. Pretty much like a dentist understands biology.
"No-text-code" I guess is more what they were going for. This is still not the future of programming because the fastest most fluent way for human beings to communicate ideas precisely is through words. Text-based code is not, and will never be, an anachronism, pictorial or graphical representation will never replace language in computers for the same reason that it doesn't outside of computers.
Devops interfaces will get better, GitHub co-pilot will continue to evolve, but you can't replace, or even touch really, characters and regular expressions as the best way to give computers instructions that they haven't gotten before.
Ignoring the fact this is clearly an advertisement for a company product; this type of thing would need to be opensource and not tied to one company for it to succeed otherwise you're just stuck on a single platform at the mercy of the company managing it. Vendor lock in doesn't quite do it justice.
I think my main issue though is the abstraction involved in this. Because whilst moving from machine language to assembly, to C, to Python (or whatever higher level language route you want) these abstractions makes sense (at least to me though I'm always curious about what's going on under the hood) I'm not convinced about this abstraction. It doesn't seem helpful. I could program in scratch if I want...
In the low-code/no-code space, this is a feature not a bug. Some members of upper management at the company I work for have bought into the no-code hype. The sellers of no-code solutions rephrase vendor lock in as their "walled garden", evoking images of Apple's ecosystem and all the success they've had.
Of course, people who haven't drank the no-code koolaid can see it's just a way to get you locked in and paying a huge cloud services bill to the vendor every month.
Bubble must assume there is a future of innovation that isn't removed from UIs and simple crud.
This no-code movement strongly reminds me of the 5GL (or was it 4GL) snake oil pushed in the 1990's. None of it panned out for a variety of reasons. Except for some of the people pushing them, I guess. I presume they made lots of money.