An Update to Our 10-Year-Old No-Code Manifesto

Hi everyone,

Josh and I published our original no-code manifesto back in 2014 to advocate for a future where computers learn to speak our language instead of the other way around. We’ve come a long way since then, and a lot has changed, including some of the nuances of our vision. But the heart of that vision is stronger than ever.

So today, we’re both doubling down and updating that manifesto with this piece on the blog. A lot of this came out of the enthusiastic discussion we heard coming out of BubbleCon last year, and we’re excited for you to read it. If it resonates with you, we hope you’ll consider sharing it. We look forward to hearing your thoughts!

— Emmanuel and Josh


Great :+1:

Great vision :wink:

Great Manifesto. Its really nice to see that you’re still passionate about the work you’re doing with Bubble after all this time and that you’re still aligned with the original vision, which is a great vision.

But I appreciate the slight shift of tone; still envisioning democratisation as an end-goal but simultaneously recognising that right now we are programmers.

“Because we’re not the ones who will prove that this is true programming: you are.”

I couldn’t agree with you more on this, and i’m glad the founders recognise this. As you said, other no-code companies chose to cater to a greater set of people and sacrificed platform power and versatility. It might seem that they are achieving programming democratisation more than Bubble, but they will never be able to impact anything long-term.
You made the right choice. Sacrificed a bit of democratisation in the short term in order to give users more powerful tools which can actually compete and outperform traditional coding. But that means that right now we’re still real programmers. Some technical knowledge/learning curve is inevitably needed.

On your end, it’s hard to balance democratisation and platform capabilities, but it needs to be done.
On our end, we need to produce robust, reliable, secure and powerful software, which actually has the power disrupt industries.

Bubble has reduced the learning curve by orders of magnitude, and we should be grateful, but not all corners can be cut.

Btw I love the new notice that pops up on editor load saying: ‘There are NO privacy rules on your app. Are you sure this is a good idea?’ Great place to start raising the bar :slight_smile: Way too many people ignoring privacy rules.

Thanks for your work!


Quality sentence


Clearing the terminology a little bit. If Bubble is a no-code platform, then we shouldn’t call people who use Bubble as coders or programmers. Bubble lets you model the software and auto-handles the technical stuff under the hood. So, we can call them modelers which is a more appropriate name. Modeling and programming are two different tasks. I did both for many years, completed a Ph.D. in modeling software, and am currently teaching both at the undergraduate/graduate levels. So, I am confident in this naming :slight_smile:


I really don’t view Bubble as a no-code platform. You still need to understand a hefty amount of the basics of application development - including database design, conditional logic, system design, and a helluva lot more - to be remotely successful here. In my eyes, Bubble allows me to abstract away the complex (and costly) overhead that would normally be allocated to an internal platform and/or infrastructure team so that I can focus on creating value-add business logic for my customers. It’s a simple as that. The more we can educate non-Bubblers on this way of thinking, the better.


Love your vision and even more excited to continue this journey with you!

1 Like

There’s no doubt that Bubble users are web developers, whether they understand that or not (or want to develop the requisite skills). And, absolutely, using visual programming environments is programming, and users of visual programming environments are programmers. (What attracted me to Bubble in the first place was my long history with 4GLs, array-oriented languages, and other visual/drag-and-drop environments for developing multimedia/music/graphics/etc.)

It’s great to see a commitment to “raising the bar”. But this isn’t just a definitional issue (“Bubble user is programmer”). It’s also an issue of whether Bubble is an effective programming environment.

How about, instead, “Update Your 10-Year-Old Code?”

It’s a little funny, don’t you think, that @adamhholmes’s Bubble programming challenges—which revisited classic, elementary programming challenges—generally required obtuse workarounds, silly hacks, absurd data type transformations, and other inefficient solutions due to various deficiencies and oddities in Bubble’s core programming features? [Apologies to Adam for dragging him into my screed.]

And, in real production applications, Bubble users—out of necessity—do absurd, inefficient, and generally whack-a-doodle things to work around the same limitations exposed in those exercises.

Further, while it’s terrific that Bubble even has a plugin architecture so that traditional web developers/programmers can extend the platform, that architecture and API hasn’t significantly changed/improved in years. Surely there is no successful Bubble application of any sophistication that doesn’t rely on multiple third-party or custom plugins. But Bubble is fond of noting that all such applications are “built entirely without code!”

Now that Bubble users are programmers, can Bubble please start treating them as such and finally get around to finishing the missing core programming features? I’ve commented on this so much in the past, that I won’t overly belabor these points, but to quickly recap:

Nevermind, we finally got those. phew! Remember how those enabled a vast number of expressions that could never before have been evaluated? Think of the possibilities for what follows…

Bubble aspires to be an array-oriented environment. Of course, in array-oriented environments, one can argue that we don’t need loops because those arrays would be iterable and, thus, any array is fundamentally a looping construct in disguise. This point is correct… as long as your environment actually provides the ability to iterate over arrays.

I have the sense that this is one of the reasons that vanilla Bubble doesn’t offer any explicit looping constructs beyond the recursive backend workflow. (And some of us have been here long enough to recall the before times when even that did not exist.) Unfortunately, the Bubble team seems to have never finished the essential array-oriented features of the environment.

We get that Bubble pre-dates ES6 and the array-orient-ification (to coin a phrase) of JavaScript. But it’s a shame that Bubble started out with what were some superior ideas about array-oriented behavior, but didn’t really follow through (on finishing up what it started) and keeping up (with universal browser support for ES6).

For the zillionth time, adding a .map() equivalent would solve about 99% of client-side iteration needs. Adding this wouldn’t even require changes to the Expression Builder as this could simply be added to the :filter dialog as an optional data type selector and expression field.

Related, why did anyone spend time creating List :format as text instead of List :map? The former is just a special case of the latter. Again, the point is that all of this basically already exists in the Bubble internals. How long could this possibly take to implement?

Similarly, there are a number of operators that are deficient vis-a-vis array based (list based) operations. Again for the zillionth time, what else could numeric_list + 1 mean except “add 1 to all elements of numeric_list”, especially since Bubble lists are only 1-dimensional?

Again, Bubble programmers jump through all sorts of stupid hoops just to do stuff like this. (And yeah, I include using my own plugins like Floppy and List Shifter to do this in the list of “stupid hoops”. They are better than nothing, though! Thanks for patronage, folks!)

Set-wise Behavior of List Operators

This is both extremely clever—with respect to Things —and ridiculously painful, all at the same time. While not as easy as implementing .map(), why not add a checkbox for “Array-like behavior” to operators for which it makes sense? Or, just add new operators for :push (alternatively, the more “Bubbly” :insert <item> at <index>, :insert <item> at first, :insert <item> at last) and similar :remove at <index>/first/last operators for when one needs array-like, as opposed to Set-like behavior. (And don’t get me started about modifying an item at a specific position in a list. :change <index> to <item>, anyone?)

All of this is implemented in Floppy as element actions, BTW (and in List Shifter with a less streamlined user experience). Which brings us to…

The Plugin API

Most of my plugins are really just “Actions”. Why oh why do we (plugin authors and Bubble programmers) have to create an Element in the DOM, add an Element Action to a workflow, and then retrieve a result from the Element’s exposed states, when what we really want to do (the vast majority of the time) is just perform some action in a workflow step and have that value appear as the Result of Step X's State_Y?

I get that the plugin API was created in the long-long ago, but the fact that excitement about Server-Side Actions wasn’t about, well, actions in the backend, but about the prospect of returning values to the workflow should have been a clue that a next-gen Client-Side Actions API was (and still is) sorely needed.

[Edit: not sure how to implement this? Why not dupe the SSA API and—instead of passing code execution to the Bubble backend and await the results—pass execution to a web worker, which is now universally available in the browser?]

Server-Side Actions went into beta in 2018. That’s 6 years ago.

It’s fine if Bubble wants to lean so heavily on plugin developers to address desirable functionality. But give us the tools to do so.

OK, end of rant. Please to enable your “programmers”.

[Edit: I’m tired of making these points so didn’t continue with the issue of Things being the only objects in Bubble. And so I will just say, “Client-side Things, please.”

It would be nice if someone… anyone… from Bubble would acknowledge that they understand all of the issues mentioned above. Tons of seasoned Bubble programmers (I’m not calling Bubble programmers fat, BTW) understand and chafe at all of these issues, but it has never become clear to me that anyone at Bubble does.]


All good points @keith. I like to believe there are some people at Bubble doing the research part of the high-level language they created but after everything I have seen at the forum, I don’t have high expectations. The technology aspect of the platform would have improved much faster if they let people add extra functionality to the built-in types (such as lists).


I partialy agree, at the end it depends of how do you define programming, in my case I like this definition from a coursera article I found a while ago:

Programming refers to a technological process for telling a computer which tasks to perform in order to solve problems

Even if you don’t write a single line of code, you are still using a technology to tell a computer what to do. On the other hand, I don’t think it is a good strategy to get too far from “coding”, even if Bubble define itself as an all in one No Code tool, you can still create plugins and integrate external solutions using code, so it is fair to say that Bubble is (in a way) a Low Code platform too and that’s totaly fine!

More coding means more flexibility and anyone that have been around using Bubble for at least 1 or 2 years know that No Code comes with their limitations that only “free coding” can break.

My hope is that Bubble with time will start investing more into plugin development or coding fratures, otherwise, with a growing No Code community that every year is eager to learn new stuff and break the limits of No Code, Bubble will slowly fall behind. I will never get bore of saying it, Low Code + AI is the future.


Indeed… one of my main motivations for starting those ‘Challenges’ was to highlight, and thus hopefully inspire/influence/pressure Bubble into resolving these rather basic omissions from the platform…

Starting with the lack of any proper client side looping/iteration (one of the most basic and fundamental of programming functionalities).

At the time of these challenges (mid July 2023), I had contacted Bubble several times about this and they told me they were working on some form of native client side looping feature which, they said, was planned for release in the Autumn of 2023. I chased them up in September, and they again confirmed it was due for release some time in Q4 of 2023.

Well, it’s now late January 2024, and there’s been no mention of such a release publicly… so it seems to have disappeared from their road map in favour of some silly AI stuff, and native mobile app features…

I love Bubble as a platform, but in the 5 years I’ve been using it I can’t help but feel as though my own skills/knowledge as a developer have increase faster than Bubble’s development as a platform (in terms of its capabilities), and none of the main limitations (lack of iteration, no ability to perform complex server-side data queries, lack of control over what data gets returned from the database, no support for non-Bubble objects, etc.) have been addressed in that time (despite much talk about them, from both forum users, and from Bubble themselves).

There have been loads of really great improvements to the platform and editor in that time, which make working with Bubble better/easier, but the only real major change that improved Bubble’s capabilities (as far as I can recall) has been the switch to the flexbox responsive engine… (which was a game-changer for Bubble as far as I’m concerned). But in terms of what Bubble is capable of, natively, I’m not sure there’s anything I can do in Bubble today that wasn’t possible when I started using it in 2019. (ok… the addition of multiple parameters for Custom events was also a big improvement, although we’re still waiting on the ability to return a response… and the recent addition of multiple properties for reusable elements has also made a lot of things more viable…).

The recent January Community Update mentioned the goal of “making bubble as flexible as traditional code”.

…well, that’s a great goal to have, and I sincerely hope they achieve it eventually, but without addressing the current limitations mentioned by @keith, there’s a long way to go, and I feel that they may never get there… which would be a shame… because the potential is huge for Bubble, if they’d just focus on these fundamental things.


Really a shame that your priceless rants aren’t being heard by the bubble team. They don’t seem to get or value the feedback of their biggest evangelists. And it’s not until you venture out to tools like Xano that you realize just how much bubble can’t do with the ubiquitous json object/list/array.


Sorry I strongly disagree with that statement. I started using Bubble March 2018 when I had an app idea with absolutely no technical background, except for basic understanding of Excel from a Uni course and a tiny amount of experience with HTML. Of course, it took a bit of time to learn how to really build well on Bubble, but still, it is true that people can build learn to build on Bubble without any coding or programming experience.

Very very true…most of the new released features are just allowing for functionalities that existed previously to be more easily achieved…nothing has really been implemented that add new functionality



This just reads like pure hype with no substantive delivery of improvement. As we say in England, all fur coat and no knickers.

I left Bubble in May after their pricing debacle but was enticed back with a client project in November. Despite all of the promises of improvements to justify the massive price increases, I was shocked to see it more buggy and more unstable than ever before and with virtually no improvements, the only exception begin properties on reusables.

Having been around Bubble since 2019, virtually nothing substantial has changed with the exception, as Adam says, of the responsive engine (something which every alternative had out of the gate anyway). There are still no ability for client-side loops, no return values on custom workflows, no ability for else conditions etc etc. These should be an intrinsic part of an app development platform, not left to 3rd party developers to implement.

The interface hasn’t been improved one iota, it’s so worn and old and devoid of any design elegance. They promised us a new modern UI within months of me starting with Bubble, 4 years ago, even put samples on their web-site, but it’s still not seen the light of day. They’ve got a team of 100+ people now, how many does it take to implement some CSS classes to get us something that actually looks and works like we would want to spend our days there?

I honestly loved Bubble, and some of that love is still there, despite everything they’ve done. But once I looked around at alternatives you realise just how much the whole thing has stagnated and how much better other platforms have implemented the no-code dev experience. I’ve jumped over to Toddle which is just a joy to use, is Turing-complete and is very well designed for the developer experience. And they’ve developed it at a lightning pace. In just 8 months of using it, my experience is like night and day compared with Bubble’s over-promising and under-delivering. Having worked on a Bubble project in the middle of working with Toddle, every day is like jumping behind the wheel of an Aston Martin DB12 and then having to jump into a 2010 Volvo. Then being told the Volvo is better because it’s got bigger boot/trunk space. No thanks!

Come on Bubble, if you wanna lead the industry you need to get a move on. We don’t need renewed manifestos or big promises, just deliver on providing a better dev experience with core development capabilities. Cos where you are now, you’re already playing catch-up with those who arrived years later.