New Bubbler Question: The ‘ecosystem’ of community-made plug-ins is a big part of why I’m choosing Bubble. But I’m already struggling to find which plug-ins are current, etc. The marketplace does not seem 100% synchronized between what I can see on Bubble’s website vs. what I can choose from within the editor, etc.
I am torn between needing to rely on some of these plug-ins for things not currently in Bubble vs. trying to recreate the capabilities myself just to be “safe” long-term. This is NOT the time I want to be doing a lot of extra up-front work on the new app I’m making, so I don’t know
Example: I just purchased the round slider and it’s excellent, works perfectly for me, and seems well worth the price. It’s also a crucial element for a big part of my UI.
My question is NOT specific to that slider (which I hope I will never need to redo ) but about the wisdom, safety, reliability of using custom plug-ins for key elements, and whether there is a way to know which plug-in makers can be trusted as third-party vendors vs. which have made lovely free plug-ins, but no intention of supporting them through changes in underlying tech etc.
It is a little concerning for me that Bubble appears far more capable – thanks to the large and diverse plug-in marketplace – that it might actually be, for those who are not (at least for now) making their own plug-ins. I wish there were more granularity than just “Official” and “Community”, so that the “Community” ones could be more easily grouped by how likely they are to be updated etc. As someone NEW to this community, I don’t KNOW who the trusted/long-term devs are vs. someone who made a cool free plug-in once as a homework assignment
As a newcomer, going through old posts here and elsewhere on the web, it DOES seem like a lot of functionality that was once only in plug-ins has been ‘promoted’ into Bubble itself, which IS super encouraging.
(And the only reason I care is that I’ve already made the decision that it’s worth all my energy to learn and build my new app in Bubble. And I’m loving it
Cheers,
Kathy
Just one person’s opinion here, of course (and it seems to be the minority opinion these days), but when I started with Bubble about 5 years ago, I immediately adopted a native Bubble or bust mentality, and that mentality has definitely served me well over the years.
I actually think it’s crazy that a tool like Bubble exists (i.e., a tool that gives us the ability to build pretty much anything we want), and folks willingly choose to use the tool to become reliant upon other people (i.e., the developers of the plugins they use). Don’t get me wrong, I understand the value plugins add to the ecosystem, but all of your questions/points are extremely valid, and in my opinion, the ecosystem is somewhat of a mess these days.
So, for what it’s worth, it will always be native Bubble or bust for me, and again, that approach has served me very well.
Agreed, I try to stay away from randomly installing some guy’s plugin and putting it directly into a very crucial workflow…
I mean you must have some like Toolbox and some others?
I know there’s a conflict because Bubble probably doesn’t want to step on the feet of plugin devs and start replacing them with 1st party versions like Amazon Basics.
I think there needs to be a formal plan put in place where if a plugin reaches X amount of installs, and the dev gets a heart attack then Bubble takes over the development for it.
Or it’s just a business decision like everything else, to pick and choose the most reliable vendors for plugins in this case. Which honestly I agree with too
As soon as I saw official Bubble docs referencing Toolbox I was like okay this fine to install. That is an example though, if even Bubble likes Toolbox what happens when Misha decides he’s switching hobbies? It’s free so there’s no monetary conflicts, and everyone is using it… I feel like Bubble should take some responsibility?
I don’t think that Bubble plugins are a less a source of problems for a given application compared to crazy solution architecture I come across combining Bubble, externalized database, externalized backend and multiple APIs with along with webhooks all implemented without retry or acknowledgments capabilities.
All those components that are intertwined, interdependent, will produce data or processing inconsistencies at the first outage of a single one.
If you are concerned about plugin reliability on the long run for your application, especially knowing that plugin version update is at your own discretion, you should perhaps be more concerned about other areas such as change control for any feature you implement and therefore use automated regression testing or CI/CD pipeline for any change you publish.
Oh my… I’m only a couple weeks’ in and I had already convinced myself Toolbox WAS part of Bubble (because I can’t Bubble without it).
But y’all give compelling reasons to assume it’s reasonably ‘safe’ to use THAT 3rd-party plug-in.
Thanks everyone. So it seems my background queasy feeling around the plug-in situation is reasonable.
That means I’ll need a better way to weigh trade-offs of “how much time it would take me to do this part myself” vs. taking the risk of relying on something that could just… stop.
For now, I’ll try to limit myself as much as possible. Besides Toolbox (which y’all seem to agree is ‘safe’), the one I’m so far willing to risk using is @wesleywsls Circular Slider. If the worst happens in the future and I haven’t yet built my own version, I fall back to a native slider.
I’ll try VERY hard not to depend on anything 3rd party without a damn good reason.
(I’m thinking somewhere in my long-term future I’ll be looking for a serious course in how to build plug-ins. For now, I haven’t even figured out exactly how to get my own css applied to native elements.)
But it is and it isn’t even as good as it could be, @mikeloc. Toolbox (when I say this I’m specifically talking about Run JavaScript / JavaScript to Bubble element) is an example of a very straightforward plugin that simply provides an interface to some specific JavaScript function (in this case eval()) or some browser API that is not natively supported in Bubble. There are lots of plugins like this and there’s no reason not to use them.
Aside: “Run JavaScript” is literally just this: eval(script)
(There’s nothing for Bubble to “buy” here and there’s nothing to “support”, you know? It just is what it is.)
The thing with developing web apps is that there are a huge number browser APIs which are very very useful when one needs them. And these APIs are constantly evolving and new ones become available to us on a regular basis.
It’s impossible for a point and click environment like Bubble to support ALL of them. (Though there are some really silly omissions in Bubble – e.g., why isn’t Intl.DateTimeFormat().resolvedOptions().timeZone exposed in expression builder? But then, if you need that you can just use my Browser Timezone and Locale plugin. Which is another very simple example of a straightforward plugin that “doesn’t do anything” as I like to say.)
If something can be done efficiently and satisfactorily in vanilla Bubble, by all means one should do that something in vanilla Bubble. But there’s a huge number of useful things one might need to do (ahem - iterate over some array) that Bubble provides almost zero support for. This is of course silly, but the plugin interface provides us a way to either implement specific functionality that our specific app needs, or provide a mean for other Bubble programmer users to generally access such functionality.
If one goes entirely plugin-free one is also stuck with whatever native visual elements Bubble provides. This is probably the biggest “promise” of plugins, and probably what Bubble intended them to be used for, but there’s actually not a lot of great visual plugins, mostly because developing them is a giant pain in the butt.
Well, I was thinking about the fact that it’s installed in almost 375,000 apps. I think something that plugin developers forget (and no offense here… it’s just that you folks are a million times smarter than I am) is that Bubble is a no-code platform, meaning that the vast majority of folks who use it (myself included) don’t know how to code. So, if the Toolbox plugin “went away” tomorrow, there would be a lot of folks who would lose their minds because they wouldn’t know what to do. You are not one of those folks, of course, Keith, but then you are not even close to being the average Bubbler, either.
The other thing I’d add with respect to plugins is that, when one uses them, you are accessing yet another part of the Bubble codebase that’s prone to breakage.
Bubble does on occasion break things in the various plugin APIs and such breakage does on occasion affect all plugins (even some of Bubble’s). I would give examples, but in general this is less of an issue than it was in the past as there’s a larger user base and a larger community of plugin devs who notice this crap pretty quickly when it happens. (This wasn’t always the case. Some years ago Bubble borked the “Initialize State” parts of the plugin APIs and this went unnoticed for days until someone asked me, “hey, Browser Timezone and Locale doesn’t publish anything anymore”.)
It’s true I’m a weirdo, @mikeloc. And, in truth, I don’t think there’s anything keeping an open source or commercial plugin from being removed by the developer. (Though existing instances of it would still exist in projects that use it.)
So, when I fantasize about deleting List Shifter, you know like I do, it really wouldn’t hurt anybody except future users.
Just wanted to add… I think it’s rather a miracle any of this works at all, so… I’m both incredibly impressed with what Bubble does and makes possible, and also still worried about how it’s going to affect me and ultimately my users.
I’m trying to start out on a good path and I’m grateful that I’m not an early adopter and that all y’all smart folks – the Bubble devs and community – have already leveled this whole thing up so much. In my searches, I stumble on YouTube videos from just three years’ ago and see people finding clever workaround for things that are just part of base Bubble now. I appreciate where it is at now. But it’s always a Big Deal when you’re – at best – a very mediocre coder AND slow learner – to ‘hitch your wagon’ to a platform. My brain isn’t that agile, and I’m doing this alone. I figure it’s worth the learning curve.
I hated EditorX. I made things, but for whatever reason it was just painful. I DID enjoy doing it myself in VS Code and Firebase, but realized I’d likely not have a working app in my lifetime
Bubble with Toolbox seems to offer me at least 70% with very low pain.
Now it’s about learning enough to know if most or all the remaining 30% is just more learning I have to do (with help from some professional Bubble tutor/consultants), or if I will still need to rely on third-party NON-official stuff.
Anyway, I’m overall thrilled that Bubble exists AND that I’m discovering it at this (later) stage. I’ve fallen in love before with tools that broke my heart when they didn’t survive (anyone old enough to remember Apple / Kaleida ScriptX?
@ponyopsmail it’s pretty wild that there do not seem to be any competing solutions to Bubble that offer the ability to be extended in any meaningful way. Despite my complaints about the current state of the Bubble plugin APIs, it’s way better than nothing and there’s literally no equivalent in the market.
(If any other plugin devs know of anything remotely comparable, let me know.)
While “Run JavaScript” is handy for very simple tasks, it’s actually not much harder to create custom plugins to handle such things and there are many performance and maintainability benefits to doing so. I consider the plugin API/plugin builder to be a core part of Bubble and it’s worth exploring and learning to do simple things in it (of course, if that isn’t really on your radar it might be worth waiting a few months before tackling that as I expect we might see some really cool improvements to the plugin API soon-ish).
JavaScript by itself (as a programming language) is incredibly easy to learn and use and outside of the web development context (where we are concerned with HTML, CSS and JavaScript as a unit) it’s kind of a pleasure to use. And despite its flaws, the plugin builder is pretty cool (though there’s a dearth of really helpful instruction in its use - maybe someday I’ll do some videos on how I use it).
As I mentioned in a previous post of yours, most plugins are just lazy CSS or is that someone put a few lines into and post hoping to make a few bucks. There are exceptions, but probably 5-10 max that I’m happy to use of I need to. But 100%, stay away if you can. Making your own CSS is free, and 100% stable.
) but about the wisdom, safety, reliability of using custom plug-ins for key elements, and whether there is a way to know which plug-in makers can be trusted as third-party vendors vs. which have made lovely free plug-ins, but no intention of supporting them through changes in underlying tech etc.
- my resolution is to make more offhand comments that instill fear and loathing!
