I’ll continue to support newer versions of nodejs as long as possible but v8 and nodejs are extraordinarily complex and dynamic platforms. It is inevitable that one day this library will abruptly stop working and no one will be able to do anything about it.
I think I’m going to be the slight contrarian here, but here it goes:
I’m 100% pro plug-in. Kind of.
I just want to point out this little tidbit of information. Bubble appeals to a LOT of people who have never coded and don’t even know how to structure a simple db. And let’s face it, there are a LOT of such users using Bubble right now just based on some of the questions/problems posted here in the forum.
And I’m thinking a lot of them are also using plug-ins that they installed for free or purchased because it did something for them that was helpful (or even just plain neato to use).
If anything, I’d like to see Bubble promote and support the plug-in community even more.
Don’t forget: there are a lot of Bubblers who like/love/depend on plug-ins to get their apps done, and something like “run JavaScript” is (and will likely remain) completely foreign to them.
I would suggest that the general idea of plugins is 100% the best, if it was updated by paid devs. But the largest dev firms who through out the most plugins just keep coming back with “unfortunately we can’t do xyz thing, too much bad”. Now if they were like Keith and said, “hell yes, let’s do it”, then it would be phenomenal.
I believe that relying on a plugin has similar risk to using any external API service (similar, I know it’s not exactly the same). What I’ve been suggesting for months now is an improved Bubble Plugin Page. Imagine the Plugin page being as detailed as an app store page that included…
where it says when the last time it was updated
what version of the plugin api the plugin is on
when the plugin was last updated, what version was bubble on?
And etc…
I believe these changes would help everyone feel more confident
As some one who developed many plugins for personal, clients and open source I try to avoid plugins when possible. It’s not they are bad per say, but the developer in me always wants to stay native when possible
It’s also worth saying that many of the plugin that we have to develop are built on a fragile system; or the plugin editor/methods available can be dramatically improved. Let’s me try to explain
Bubble has the habit to just change things. This can obviously break things
Bubble ships with a large selection of open source scripts that we can’t easily access. For example why should include the Google Maps library when I can use the one included
Loading 3rd party scripts is a pain! When have no native method to know when Bubble actually loads it on the doc.
I can keep going one forever… We should adopt a system similar to WordPress where each plugin has an indicator to say something like “Works with your version of Bubble” or “Not tested with your version of Bubble”
It’s great to hear a lot of Bubble vets who also build with a native first paradigm. I thought i was in an echo chamber in that regard.
While there are plugins like Toolbox, Classify and List Shifter that i have come to rely on. I am pretty amazed at the things i have been able to do natively in Bubble.
Why would it be?
Everybody seems to fear that plugin may entirely break an application without notice.
Plugin version update is at application developer discretion, which has the duty to perform regression testing after update, like any change on any app.
The reason things may break without any notice would be for instance Bubble update messing up with node engine, unpkg, CloudFront, or AWS being down. But at this stage we will have much more pressing issues to take care of given the magnitude of the impact.
If you can’t afford being dependent on others’ development, no code is not for you.
There is a monumental difference between being dependent on the development Bubble (a company that is valued at probably somewhere between half-a-billion and a billion dollars and has over 100 employees) is doing and the development a “random” developer out there in the Bubble ecosystem is doing. I spend a lot of time in the forum, and I have seen plenty of ridiculous plugin/plugin developer-related things that have helped to shape my attitude toward plugins. That being said, there are plenty of awesome plugins and plugin developers out there, too, and every Bubbler has to navigate the ecosystem in their own way.
As for your question, @thekingshizl, the short answer is no, you might not be able to do everything you want to do without using a plugin or without learning how to use the plugin editor to make your own plugin. But, a lot of plugins are just things you can do directly in the Bubble editor, even if you have to get creative as to how you go about doing them.
I guess I could have made it clear in my initial reply in this thread that I am not scared to use plugins, and I would absolutely use them if/when I need to. I just don’t understand the folks whose default mindset when they need to do something in their app is to immediately go find a plugin that does it. It doesn’t make those folks wrong, of course. It’s just a different approach to the platform and one I would never adopt because it severely limits one of the most awesome benefits of Bubble… the ability to build something yourself.
That’s a perception.
At a code level there aren’t any difference.
A code works under specific environment and conditions. Full stop.
Everything else is litterature.
I was asked « How come GAFAM never go down?»
A: « They do, like everybody else ».
Let’s remember Facebook wiping out their root DNS records or entire AWS region going down.
Or perhaps more controversially for this thread, Bubble valued between half and a billion of dollar, breaking plugin execution environment and application for more than a day over the weekend, after which major plugin developers (including myself), earning dozen/hundredth of dollars per months, releasing emergency fixes to mitigate the issue within the first hour.
I should have been clearer, @redvivi, that I believe your point is extremely valid. Code or no-code, Bubble or some other no-code platform, plugins or no plugins… we’re all dependent on something. Heck, if you don’t go the plugin route when using Bubble, you are dependent on your own knowledge of the platform, and that’s tricky as hell because in the beginning, your knowledge, well, sucks, and the platform’s learning curve is super steep. So, at that point, you can’t really even depend on yourself. Then, it might be more of an investment question, and I simply chose to invest everything I have into learning the platform as opposed to investing (monetarily) in plugins so I could get an app out there a lot faster. I understand why folks choose to do the latter, though, because again, this platform is anything but easy to learn.
Code at a code level may be the same, but when they switch to Node 16 and PDF Conjurer needs an emergency fix, we all find out Vini gave up giving free support to take up painting classes months prior, what happens to the #1 PDF generation plugin with 15K apps that can’t make invoices anymore? There’s no financial incentive or obligation to maintain that plugin beyond hobby and good-morals.
With Bubble they have teams of engineers, if one wants to take up painting then another engineer can take over a crucial project. If AWS went down and some people called in sick that day, they had more to investigate it anyways. With investors watching their every move too…
I mean no offense if any comes across like that You know that I know that you make good shit, but hopefully what I’m saying makes sense… it’s like 4AM…
The code I’m not worried about, it’s the human factor
That have at least some responsibility over any major problem with the switch because they made a system for plugins that is anything but sane modern web development.
Bubble isn’t certifying or monitoring third party plugins, so it’s up to the user to figure out which ones are safe and legit. I usually search the forum to see if people are having a good experience with the plugin, and if the developer is responsive and active in maintaining it.
The main problem I see is when inexperienced users think every plugin in the library is vetted and risk-free, and without much thought they load up their apps with a lot of plugins. Then they are stuck trying to debug complex problems which are often caused by bad plugins.