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:
Parentheses
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…
Iteration
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.]
Way too many people ignoring privacy rules.