It seems like certain things would really benefit for a coding interface. Workflows come to mind, but also conditionals and other things. I can see a large, complex app getting to be quite difficult to manage with logic somewhat all over the place.
Keep the UI, but be able to drop into “code” mode, where there is just one file for all workflows, one file for all elements, etc.
Thoughts?
Try The Masonry
I’ve thought about this too.
For some things I use Javascript, it works within workflows with a plugin called Toolkit
I have a funny feeling once the dust settles the winner will be the platform that allows code/no code combo. No-coders can call in coders to code complexity and no code the rest themselves, coders can use no code to suit and speed up simple tasks etc etc. Could this be possible?
Just to be clear, I am not talking about inttegrating code (JS, python etc) with bubble. I am ok doing that with either JS plugins, or calling another server. I already have bubble sort of like a “fat front end” where it makes calls, or is called by another server running python.
I mean bubble’s native features could be really well served as code in some sort of syntax. Finding things, reusing things, diffing things are all so much easier with code. Combine that with bubble’s already excellent visual feature set and it would be a game changer.
If you want to explore using code with Bubble, there are several ways to do that. As mentioned previously, you can use Toolbox (Run JavaScript, JavaScript to Bubble element) to execute code via eval in a useful, but slightly clunky way. Other ways that are part of the Bubble ecosystem:
Plugins: If you want to execute code more efficiently, it’s worth learning the basics of creating plugins. The plugin APIs are quirky, to be sure, but can be very powerful. When starting out, it’s easiest to grok the Server Side Action API (though this is of limited use for client side stuff. Learning to create Element plugins (with their own Element Actions) is the most powerful at present for doing stuff on the client side. Client-side Action plugins are nearly useless due to deficiencies in the Actions API (e.g., can’t return values to the workflow). It would seem that the Actions API was designed for manipulating the DOM as there’s little utility to it otherwise (over Elements with their own actions).
FaaS Services via API Connector: While Bubble’s Server Side Actions let you do function-as-a-service type stuff, they have significant spin-up time, and are stingy with compute, memory and time-to-live. I’ve found that Google Cloud Functions are (1) super simple to write (2) work great with the API Connector (basically your function is a no-muss, no-fuss way of standing up an endpoint that does basically anything) and are (3) vastly faster and cheaper than running the same code on Bubble’s back end and (4) offer much more memory and more recent versions of Node while writing them is very very similar to writing an SSA plugin. This one’s a no-brainer. (But you could use others, but all of them are either more costly or harder to use.)
However, there isn’t really any code interface for managing elements/workflows/etc., except to the extent that a plugin you might write is fully self-contained and you can update its functionality in one place and that will be inherited everywhere (which I think is what you are wishing for). Workflows are just Bubble’s representation of functions and can (for MOST use cases) be replaced with plugins or custom code. Note that there are some restrictions to the plugin API that muck this up a bit: For example, a plugin cannot query (search) the database itself (Searches must be composed by the Bubble programmer) and similarly, the database actions can only be initiated by the Bubble programmer (e.g., Create New Thing, Make Changes to a Thing, etc.).
I haven’t looked at the custom plugin option, seems interesting.
Definitely +100 for GCP and functions! I prefer python, and combined with their cloud databases, it is easy and a free/cheap solution. That’s how I am approaching Bubble, as a front-end of sorts.
This is more of a wish - would be really cool if there were some coding interfaces to bubble’s features!
It’s the web. You write JavaScript. (Python is cool for Jupyter notebooks and the like, but JavaScript is the language of the browser and Node [JavaScript on a server] is the language of simulated browser environments on the backend, so just spend 10 minutes learning the diffs between JS and Python and you’re good to go.)
FWIW, modern JavaScript is the easiest and most powerful interpreted language ever. (I have designed array-oriented languages and/or “written the book on them” since the 1980’s and modern JS is super easy. It’s not array-oriented in the 1970’s “Fortran 77” sense, but browsers are the only interpreted runtime environment today.) So, don’t be afraid. The basics of the language are learnable in a few minutes… everything else is just an API with its own quirks and limitations, so language doesn’t matter in that context.
I was “meh” on early versions of JavaScript, but that’s changed in the last decade.
Also, when you’re in Bubble-land, you don’t have to worry about modern JavaScript tooling as there’s no support for that. It’s a great environment for just getting to grips with JS and the core browser APIS.
Oh I’m pretty comfortable with basic JS, but never had the patience for JS UI frameworks, which brought me to bubble!
I prefer python just because its data manipulation is so powerful.
Also, I started coding in the mid 80s (BASIC, C, then C++), so would love to know the book you wrote!
I wrote multi-volume docs for the array-oriented scientific data languages IDL (interactive data language) and PV~WAVE (which was basically just a licensed version of the former – yep, I did the same exact job twice and got paid for it both times). These are actually still in use in Sci-Vis circles (their modern forms are much more advanced than back then and are probably supplanted in many ways by Python, which is certainly influenced by those packages as they all come out of the academic data processing space).
Those languages were exactly the same model as the current JavaScript/browser paradigm – human-readable code that turns into platform-optimized machine code when executed at runtime. (Except that, in those days, the manufacturer was responsible for writing the compiler for whatever systems they wanted to support.)
Those languages were also (because they were about manipulating vectors, images, and higher-dimensional datasets) naturally array-oriented. It’s only in recent years that JavaScript has become something like an array-oriented language.
(Bubble itself is a not-fully-realized array-oriented system. I got interested in it because, on the face of it, it looks like an array-oriented language but hasn’t been finished/misses many of the rougher and finer points of what such an environment should look like and do. Also, as a full-stack solution, it makes certain parts of web development easier to the novice [or those short-on-time] than other approaches.)
In the CD-ROM multimedia days, I was part of the team at mFactory, which had a drag & drop, object-oriented development environment called mTropolis, which was both a more powerful and easier-to-use multimedia authoring environment than things like Macromedia Director (later Flash).
In addition to drag & drop / click and drag programming, it also had a scripting environment (“mScript” of course) that was actually very very similar to how JavaScript is today. (There is, in fact, nothing new under the sun.)
Simply because I was familiar with array-oriented concepts and worked closely with the engineers designing the language, some of those concepts found their way into mScript (like, I’m pretty sure you could take an array and do array * 2 and that would mean, take every value in array and multiply it by 2, because (1) why not and (2) what else could such an expression possibly mean, and (3) this is incredibly useful and natural syntactically).
Also, that system was event-driven (like today’s web environments) and object-oriented (not as trendy anymore, but this is still a super-useful concept) and once the web matured enough, I got interested in those subjects again.
Anyway, the reason I’m so cranky about Bubble is that it represents a lot of untapped potential that we can’t fully tap with the existing plugin APIs. However, the developers of Bubble know nothing of the prior art around systems like it, mostly because those systems were proprietary, are now lost-to-time, and “you had to be there” to see and experience it. But Bubble is basically tilling the same field (albeit with a less-sharp plow).
(mFactory, for example, was purchased by Quark – remember Quark!? – and promptly killed. Adobe would have done the same thing had they made an acceptable offer. And only real nerds know about scientific visualization languages and Fortran 77 and its ilk.)
Wow, memory lane! Very glad to have met you sir!
