No-code is the future of programming. That's great news for engineers
bubble.io
bubble.io
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.
The No Code movements shines a light on how bad we let things become for programmers (and aspiring ones). Building a modern full-stack website these days involves a lot of knowledge, everything from docker to react, to how to use github, npm, vscode, the command line, etc.
No Code/Low Code recognizes that most of that is "accidental complexity", and removes it. In a sense, it really lets you focus on the actual program (the "essential complexity"), in a way that "real" coding does not.
The problem with No Code is that "code" is actually important, by which I mean functions and types and values. Things that are composable and decomposable - you can look under the covers and there's more code, or you can combine two things together to make a bigger thing. That's as opposed to "wizards", which many (not all) No Code tools are.
We can remove the accidental complexity without removing the code though. I've been referring to this idea as "Just Code", and there's a bunch of tools out there which fit the bill: Darklang (disclaimer: I work on this), Glitch, and Repl.it are the ones I know best.
The vision for Oil (https://www.oilshell.org/) is "Just code" + "Just shell", i.e. one other language for "control plane" / configuration / automation.
That is, Oil puts all the "glue", which is often YAML these days, under the category of "shell". (This requires adding features to shell, i.e. "the missing declarative part".)
The status quo YAML often contains shell, and is sometimes generated by Go templates when logic is needed, so "Just Shell" is simpler.
So I basically agree with you that "No code" is ambitious for most problems -- "Just Code" can be better and handles a wider range of problems.
But I also think "Just code" is ambitious. Because what do you do about load balancing policies, scheduling policies, authorization policies (collaboration), SSL certificates, backup policies, deployment, build, tests, performance, monitoring, etc.
You can try to make it all "data", and that certainly works for many simple apps. But when simple apps are successful (have many users), they turn into complex apps that need control flow, iteration, and abstraction in their control plane, configuration, and custom tooling.
In other words, the plain YAML basically never cuts it, which is why you see shell embedded in it, why Go templates generate it, and why people create Lisp-ish languages in YAML (e.g. look at Gitlab / Github CI conditional expressions in YAML; Kubernetes YAML has sequencing and more)
Otherwise you get a combinatorial explosion of hard-coded policies in the platform, i.e. a little YAML flag to specify a hard-coded algorithm for every piece of policy that any user could possibly want. Platforms have a lot of heterogeneity their usage patterns, i.e. a power law shape with respect to almost every dimension.
Totally agree with this, and this is what we're doing with Serverless Cloud (which I work on). Developers (generally) want to write code, but having to implement the same boilerplate or cloud infrastructure configurations over and over, or wire together cloud primitives every time to build a solved use case, is both inefficient and prone to human error. Baking most of this into a platform, and then letting developers just write business logic is a powerful abstraction.
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.
> 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.
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.
- 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.
We should not reinvent programming languages. They have been expertly crafted to be the most powerful and expressive abstractions. Specializing them into DSL is counter-productive: specialized DSLs lack all the nice features of mainstream PL that have been iterated on for many more manhours that could ever be sunk into any startup's DSL. I would argue that the best of both worlds are embedded DSL, but the best embedded DSL are simple libraries that do not require staged meta-programming. Of course, normal libraries provide no-lock in so it has less commercial values.
Most of the benefits of those so called no-code or low-code platform is not in the coding abstraction but in the platforming aspect that makes it easy to deploy and integrate your apps with secrets, schedule and permissions. This is exactly the minimalist approach taken by windmill.
Exactly!
This is what the "serverless" model was supposed to solve but that got hype cycled into something else.
Now the same thing is happening with nocode.
I like the idea behind windmill but I would prefer writing the code in my own ide and checking it into git. Is this possible?
There is a github action to automatically deploy from github to windmill: https://github.com/windmill-labs/windmill-gh-action-deploy
That gh action is what I use myself for the public templates that hydrate every workspace on:
https://github.com/windmill-labs/windmill
Fun fact, the way it works is that it just tarball a subdir of your repo and send it as an input of a normal windmill script that then just extract it to your workspace (for all the diffs that it finds).
Note: It is still a one-man, early startup for now. I am looking for a technical co-founder and applying to YC. The stack is Rust, Svelte and Postgres :)
Note2: I am also looking for early customers and would be happy to customize windmill to your needs if you were to trust us.
I have to disagree here. Most of the popular languages are procedural and is mere evolution of writing for a machine--machine code, assembly, C, and scripting languages have the same structure.
I fully support new program building systems that breakaway from this. It could be in the form of DSLs (in particular declarative), visual programming, Excel formulas. This is still a kind of code, but not the procedural code which I think includes many incidental complexities not inherent to problems to be solved.
I am a functionnal programming zealot too (although I am mostly doing rust these days) but I think it is less about procedural vs functional than it is about the abstractions used and the overall "power" (as in, it does a lot of work for you) of the compiler. My argument is that a more generic but extremely powerful compiler (because it had more work and iteration that went into it) will beat any specialized poorly made compiler any days.
Python, Rust, Typescript, Scala, etc, etc... they all support lambdas in one way or another and have reached some kind of local optimal for the tradeoff that they are making. My claim is that you are never better off these days inventing a non-embedded DSL, and if embedded DSL you build, do it as a simple library in one of the nice modern language.
These modern languages with lambdas are what enable writing in a functional style. One can choose to use single-assignment 'var's and map/filter etc, at that point you're not using the procedural aspect of the language which is great, but why not start with a language that more than allows it.
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'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.
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).
It was one of the first mass-audience "no-code" platforms. It democratized web apps and games, allowing people who had no engineering background to build whatever they wanted.
But did it? They would build what they wanted. And then, to their dismay, it performed like shit.
Often, they would release their shit-performing product anyway. If you're an engineer, and you looked at what they did, you'd realize they made some mistakes - but they didn't know that. And they released their shit.
And then millions of people would use their product/game/app/whatever they made (which performed like shit) and they would say to themselves:
"Flash is a piece of shit".
Adobe (and the Flash brand) never really recovered from this. They eventually stopped supporting it. This is personally a big problem for me, because I have some games that were written using Adobe's platforms (Clicker Heroes and others). But you live and learn.
I believe this will be repeated, forever, for any/every no-code programming environment that ever gets popular. Inexperienced people will make great things that piss off a lot of users and they will blame the platform.
In the heyday of Flash, the internet itself was an entirely shitty experience performance-wise. Nobody had any expectations. My connection was so slow that I could watch images load one line at a time.
Then we had a few good years of fast computers and decent connections before code bloat sucked the air out of it again.
It's hard to generalise but where I have seen no-code succeed is with non-tech teams automating away some of their monkey work without having to come up with a budget for a developer or buy in from management. In that situation nobody cares if the app takes 5s to run when it could take 1s.
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?
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 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.
set somePage.someButton.onclick = doSomethingImportant()
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.
You can use paid IDEs (think IntelliJ offerings) and get really close to the productivity level of a no-code platform, without the exit trap.
No code tools, are a bad business decision if you are going to base mission critical infra on them, unless you can articulate a good exit strategy.
To my understanding, IDEs are environments - which can stand independent of the language.
To give an analogy: if music is a 'language', I can write/record in with whatever DAW/'IDE' I supposed fit the case - e.g. Reaper, Protools, FL Studio, Garageband, etc. I therefore find it really difficult to grok what it means to have an IDE so closely attached to the language. (In which case we'd have an equivalent to programming in Java, where because of its verboseness, programming in it without an IDE can be an absolute nightmare.)
There's that, and how, from his explanation, it means that no-code is basically a mix-and-match coding solution. Outside of specialized tools for a special purpose (e.g. the Blueprint Visual Scripting system in Unreal Engine) I don't imagine this as a general-purpose tool will succeed at all.
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.
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.
"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.
printf("The result is %d\n", result);
OTOH, my wife (a classicist teaching Latin over the internet) uses a few services like IFTTT, and likes it.
I don't even need to read the article to know it's trying to sell something.
Bubble must assume there is a future of innovation that isn't removed from UIs and simple crud.
Everybody who has ever professionally programmed knows this is bullshit.