No idea, but shoot a DM to the plugin dev. Sounds like this is an issue that maybe should be a little bit more “enforced” when approving plug ins.
Support replied,
“we recommend uploading any dependencies to Bubble instead of using unpkg because unpkg is known to be inconsistent sometimes.”
@jddmrgn I’ve reached out to @pedropedro to see if he would be able to do just that, or use jsdelivr instead. I have no idea how all that works. But since it’s a great little plugin making it super fast and easy to use AOS. I would say, shoot him a DM as well.
I also only have 4 non bubble plug ins (I recommend to use as few as you possibly can).
The only other one I use that’s calling an external library is feather icons, which is using jsdelivr.
UNPKG is just a CDN; they host javascript libraries for free on an extremely fast and otherwise reliable delivery network all over the globe. As a developer, using UNPKG is essential to be able to deliver plugins that add advanced features to bubble.
The problem with ^^ is you will never get any software updates, security fixes, bug fixes, etc., as UNPKG allows content to always use the latest version, the latest feature version, the latest full release, etc., so us plugin dev’s never need to go in, re-compile an entire library into a single, minified file, and re-upload, and then push a whole new release, for you to have to then go in and update the plugin. Instead, you always have the new version of the underlying library the moment the browser pulls it in (browser-side), without the devs or you needing to do anything (depending on how the UNPKG link is coded, either to use a specific version or always the latest).
jsdelivr does not solve anything, is also a CDN, and is subject to the exact same issues as UNPKG
It doesn’t go down every couple months. Just use a better CDN, bro. I use jsdelivr and have never had a problem. Also, for custom package delivery, just use the same one Bubble does. You can load sources to Bubble’s CDN in any instance of the plugin builder and viola, your files are just a URL away.
unpkg isn’t going anywhere, and barring plugin devs re-compile plugins where the original library devs only use unpkg every single time they push an update, I’ll keep using it.
Never said it was the best, but given that its free and we don’t want to re-compile when original devs are on unpkg, especially for free plugins, its a bit hard to justify monitoring unpkg constantly for updates and to constantly need to re-compile to jsdelivr or directly to bubble.
OP’s animate on scroll library is only hosted on unpkg, so the plugin dev is in the exact situation Im talking about. And the plugin is free; no way a plugin dev should need to constantly monitor one CDN/library for updates just to have to constantly recompile, reupload, and push new plugin updates to users.
This comment makes no sense. Your tude is why Bubble devs can’t have nice things. How is it “recompiling” to drop a different script tag into the Headers section and be done with it. Clown.
@keith bc there is no other ‘script tag’ (hrefs btw); unless the original publisher of a library bothers to support multiple CDNs, Bubble devs are left at the peril of what the original, pure javascript developer uses. The only way to get a different CDN than what the original, library poster uses (i.e., someone who wrote raw javascript on GitHub, for instance) is for us, the plugin developers to port the library developer’s code to a different CDN, something that we, the plugin developers need to update anytime the library developers make changes on the CDN of their choice. You clearly don’t understand how CDN’s work, so don’t give misleading answers on the forum.
It’s recompiling bc the library developer compiled onto UNPKG, in this case, and UNPKG only. We would need to host it ourselves, and often need to compile the code into a single file.
This does not solve the UNPKG issue at all, which is: if your CDN goes down, your site slows down as it is timing out waiting on a response from the (down) CDN; any CDN can experience outage, and just bc one CDN works today doesn’t mean it will tomorrow, which is what my point was. Swapping one CDN for another never eliminates the issue of connectivity issues, jsdelivr or otherwise, which is exactly what I said: “jsdelivr does not solve anything, is also a CDN, and is subject to the exact same issues as UNPKG”. OP’s concerns were with external services going down, so jsdelivr will not solve that concern.
For someone lacking basic knowledge of a CDN and how they work, this is extremely adult of you.
blindly load the latest library is bad practice, it “should” be ok if the library follows semver and the latest update is a patch or minor update. If it’s a major update or the mantainer doesn’t follow semantic versioning you can load a version with breaking changes and your plugin will stop working without any notice
most of the libraries do not choose to publiah on unpkg too. Unpkg automatically tries to published the library based on instructions in the package.json. You can choose to explicitly point unpkg to a specific file, otherwise it will follow the normal conventions.
most of the time you don’t need to build the library, it’s already distributed in its bundled version.
there is no free lunch: software requires maintenance. Dependencies needs updates and it is the plugin’s author responsibility to do that, test that everything is working and then publish an update. It’s the plugin’s consumer responsibility to check if a new version is published, update, test that the app is working properly and then publish the updated app.
Using an external CDN is a legitimate choice.
Personally I prefer to do the work and host all the dependencies in bubble to reduce the exposed surface of the app and potential points of failure.
I can see it’s useful to use an external CDN if you have the same dependencies on multiple plugins that can be used toghether in the same app. It avoids to load the same dependencies many times because the same file loaded in bubble’s CDN with 2 plugins will have different urls. Other nocode platforms handle the plugin development much better and don’t have this kind of problem at all.
This is part of the job, you can choose to avoid it by pinning a version.
In this specific case there is not a lot of work to do because it looks like the last version was published on 2018-10-03T22:56:09.663Z
This is the classical contraddiction of the javascript ecosystem: the package is pratically unmaintained but it works so it’s downloaded more than 50k times each week
Although I find this conversation fascinating, it is so far over my head that I won’t even begin to have an opinion.
Instead I’ll add the opinion of a Bubble rep that is far more knowledgeable about this than me.
I asked if Bubble had considered enforcing uploading dependencies and/or using an actively supported service like jsdelivr as part of the plug-in approval process.
And the answer was that yes, that has very much been part of internal discussions and this little episode has re-ignited that conversation.
So for what it’s worth, if you are a plug in dev, it might behove you to consider unpkg alternatives, since it may or may not become part of Bubble’s approval process in the future. From what I understand unpkg is also no longer actively supported, and known to have reliability issues.
I would very much like to see this, if it will free up bubble dev resources not having to track down issues in their eco system stemming from external problems that could be avoided. And it will also reduce nincompoops like me from throwing our hands up blaming Bubble for things out of their control, which I can only assume is a bit annoying, but could also tarnish Bubble’s image of reliability.
I totally agree with you @dorilama , I didn’t mean to say that not choosing a static version is a best practice, nor do I engage in it myself, I was just listing some of the reasons why CDNs are useful. I also agree that most of the time, a library developer will minify and compile the package into a single file for the plugin dev, but I’ve had to deal with instances of that not being the case when trying to build a plugin for bubble and need to use something like browserify or webpack to compile into a single file.
I think my overall point was just that if OP’s concern is with external services, there’s no difference between one CDN over another solely in terms of being an external service that can go down at any time and it 100% beyond Bubble’s control; some are better than others, and some are good now but can deteriorate later. Hosting internally via Bubble is always an option, and is extremely attractive for plugin dev’s when the library is pretty stable and well established and doesn’t need too many bug fixes, but sometimes CDNs do have their advantages.
absolutely, @dorilama, which is why I mentioned that
My point was that, especially if there’s a reason for it, there’s a variety of ways and reasons why using a semver range or latest is the plugin dev’s best option. It’s probably not most of the time, but especially if it’s a library where they are both the library dev and the plugin dev, there’s a reason.
I understand your point that this is a normal way, but when we’re talking about free plugins, not everyone is going to go this route, especially when the original library developer does not compile into a single file for the plugin dev to use, and may have used a non-static version or used a cdn for their own reasons, made the plugin for themselves, but took the time to also make it free and open-source instead of a private plugin just for them. I upload to Bubble’s direct content delivery, you may do it too, but we’re talking about someone producing an open-source plugin, for free; when dealing with open source, you get what you get, if you don’t like it, fork the plugin and make the changes yourself. That’s the point of open-source plugins.
Any API Connections pose the exact same risks if they are not robust to support things like versioning and API version control, so unless an app is going to be 100% inside bubble and not use any external services, APIs or CDNs or otherwise, we’re stuck with what we can do 100% in Bubble, which is an extremely old-fashioned way of web-dev, given that APIs and external services and driving the modern internet, and even blockchain tech relies on external services and interconnections. Also, as the bubble app developer, its your job to monitor you app so that the “unnoticed and unmonitored” bugs get fixed, just like its a plugin developer’s job to monitor their codebase. To your point, we’re all responsible for managing our codebase, plugin developers and bubble app developers both the same.
I’m not sure if you refer to me as the OP, I don’t think I initially voiced any concerns since I had no idea what was going on However, learning more during the discussions in the thread and talking to Bubble support. I don’t believe the concern with UNPKG lies in it being an external service, rather that it’s not a supported service with known reliability issues (despite it still being widely used) and other services such as jsdelivr have superseded it and are supported. Which would be 100% valid for Bubble to request as part of its approval process. The service you rely on must be a supported/stable service to safeguard the integrity of Bubbles’ ecosystem. And if at some point point a current service becomes obsolete etc, Bubble could again request plugin devs to move to a different service.
This is the recommended way from Bubble. And again, enforcing that, and where not possible give a reasonable explanation for not hosting on Bubble, would again be a valid requirement for tapping into Bubble’s eco system, I would think?
I mean… look at Apple for god’s sake, or even running an ad on Reddit. They will go over your page with a fine-tooth comb and a broken link anywhere on your site will see your ad campaign cancelled
UNPKG is still supported and the uptime issues are things they’re working on. It’s an active project thats powering approx. 10% of the clear web. That’s a pretty big task, and they’re doing their best for what is a free service. It’s not the top of the market like jsdelivr, but bubble plugin devs are often at the mercy of the original library developer who chose what CDN to use, and then we as plugin devs port their work into Bubble.
The day Bubble gets to tell me how to code my app is the day I quite using Bubble, barring illegal content or content that violates their terms of service. I code open-source plugins for my own use, and instead of making them private and keeping them to myself, I open them up for free for everyone to use.
There is no approval process, nor should there be one, for free/open-source plugins. I’d agree with you for paid plugins, but for open-source, like the plugin you originally mention, there absolutely should not be any Bubble oversight beyond ensuring that illegal or terms-of-service violations are not occurring. As a developer, Bubble telling me what I can and cannot do (beyond legality and terms of service) is frightening; on their end, they would have to charge a whole lot more to be able to support this type of screening (think the 30% markup Apple tacks on to its app store that developers have to put up with).
I don’t mean to make this overly nuanced or argumentative @keith@dorilama@casheets123 , and its probably strayed far from the original concern. I apologize if I came off a bit rude or snobbish, I’m not trying to turn the Bubble forum into StackOverflow and didn’t mean anything personal.
Wait what? There’s an approval process for templates (quite stringent too actually) but you’re saying bubble lets any ol’ stuff into the plugin marketplace?
I would say that’s a big problem since it’s injecting code into your bubble app, and it’s not something I was aware of. As users I think we should have full trust in that what’s part of bubbles eco system should have some oversight.
Again, as I’ve mentioned earlier over the years I’ve learned to limit the use of plugins. There are an incredible amount of atrociously bad plugins available that will wreak havoc in your application, or completely broken and not supported and so on. I guess now I know why…
However, learning more during the discussions in the thread and talking to Bubble support. I don’t believe the concern with UNPKG lies in it being an external service, rather that it’s not a supported service with known reliability issues (despite it still being widely used) and other services such as jsdelivr have superseded it and are supported. Which would be 100% valid for Bubble to request as part of its approval process. The service you rely on must be a supported/stable service to safeguard the integrity of Bubbles’ ecosystem. And if at some point point a current service becomes obsolete etc, Bubble could again request plugin devs to move to a different service.