[Upgrade to Bubble Version 21] Improved Runtime Performance

I’m sure this has been asked before, but I’m having trouble finding an answer in the forum. If we upgrade our test version to check out bugs, is our live version also upgraded, or can the two versions of our app be on separate Bubble versions? I’ve honestly been quite nervous to even test this because we now have users on our app pretty much from 4a - midnight or later. It’s really not clear in the docs if changing your Bubble version changes all app versions or just the one you’re currently editing.

@samnichols You have to deploy to “Live” to change the version. Text found in the Live version. In any case, it takes 10 seconds to go back to version 20.


:green_circle: image


1 Like

Respectfully no offense intended… just my thoughts.

With the new V21 some folks may have run into issues with third-party plugins and feel that Bubble should ensure they continue to function. With respect to all: This is simply not feasible. That said; it can be done since Apple does it. However if you have ever developed a major project with Apple you will find out just how arduous and costly the process is. Get ready to sell your house.

So, Bubble takes a more community approach with the risk that some of the plugin contributors do not really anticipate and trap all issues that can arise. Such as using $( document ).ready without an additional event such as $(’#MyID’).isvisible(function() {… trigger to address elements that become visible after page load is complete. This is the difference between good and better.

I suggest that if we as a community want Bubble to truly be the guardians of all the work of others then we should expect to pay a lot more and we all know how that would go over!

Otherwise as the saying goes “caveat emptor” with respect to third-party plugins.
John

7 Likes

I do no think what we are asking for is like what you suggest. Here are a few points for consideration:

  • We are not saying that Bubble has to make sure all plugins would work. That is not expected. What we are asking is if there is a way to check which plugins might be affected. And I understand that that may not be possible either. But you know small guidances like “If your plugin requires you to assign ID to elements, then you may want to test it out, as it will be affected” would help great deal, as Bubble only knows what would be affected. No-coders won’t really know the inner details.
  • Frankly, point about elements with custom ID getting affected came after we probed. Original message could didn’t seem to be well thought out from all those angles and it created a fear in mind as to what else could we be missing. This gets accentuated for people who are creating serious applications and are no-coders. If things go wrong users go really annoyed and it may not be easy to figure out exactly what is going wrong.
  • You are comparing a no-code platform with a coding based platform. The no-code platform by its nature comes with expectation that users won’t need to dig into code and for changes there would be a solution in a no-code way to detect issues
  • Even if that is not possible, at least give a way for us to apply this change on some pages (or elements) or to skip this change if possible. New responsive engine was launched in that way and everyone applauded what was done with new responsive engine. Right now it is a part of this full version and it would be applicable to full application. One naturally would be worried about what if they miss to check some parts of application and how do they go about checking everything.
  • The way announcement was done (original message) for this change, there was no clarity at all. Details about items with ID references might get potentially affected came out on probing. With all this and many other things that keep going wrong there is a justified fear in minds of people who are building serious applications and are not coders.

Thanks @nick.carroll for the reply. Sorry I missed to see your message earlier.

Thanks for clarifying that css on ID elements won’t be affected. That helps. Clarifications and warnings of this nature for the things that we can’t think of would be of good help.

I understand that it would be impossible for Bubble to check all plugins on how they are written and whether they will be impacted.

Precisely for that reason, I think following can be done:

  • This change can be implemented differently. It can be implemented the way new responsive engine was implemented. We can have a control on which page/element do we let this change be applicable to. That would give us chance and time to test and correct each page as we find time.
  • It can also be made such that we can skip it. Right now it is a mandatory update that we would have to get and would need to test all our applications’ functionalities to see if they are broken or not.

I have updated and can confirm the whole app is much faster - especially single page ‘native’ apps. You can of course use Bubble’s app search facility to find all workflows that use OnPageLoad to check impact of upgrading.

Thanks Team, much appreciated!

2 Likes

You do make valid points @mghatiya with respect to guidance and other comments. I do greatly respect your perspective.

Rather than providing guidance after the fact I do believe it would be in Bubble’s and the communities best interest for Bubble to produce a “best practice Application Architecture Standard for Plugins” that anyone who wishes to produce a commercial plugin must comply with. Then they could strictly enforce these “standards” which should be part of their Application Architecture and coding Standards. Since they set the “Standards” and ensure compliance they could anticipate the issues - in advance. This could be funded in the same manner Apple does, by charging an annual Commercial Developers Fee. (Not applicable to Free plugins). Apple’s approach although annoying at times does ensure (for the most part) best practice apps in their store.

Yes, Bubble is a “no-code” platform however Plugins are by their very nature - code or at least code-able. I would not suggest that Bubble should enforce their architectural standards on Free plugins, since this could be overwhelming for them. Notwithstanding that there are some very good Free plugins that are well constructed and everyone creating Plugins with custom code would be well served if they did follow the Standards. Of course, Free Plugins should expose all the custom code as with the typical MIT license. This would allow community - peer review.

As a side thought… it seems that many of the issues we as a community encounter are a symptom of (possibly) weak internal business processes not the lack of exceptional technical talent.
Respectfully, John

1 Like

I appreciate it! I’ll have to test out v20, at least, on dev and see how it goes. From others, it sounds like v21 may need to simmer a bit longer.

1 Like

+1 for important announcements via email! CC @kathleen

2 Likes

Seriously! I have no idea why Bubble is relying on the forum for stuff like this. Every single user should be getting an email.

1 Like

Hello!

I have a problem after updating to version 21.
The group is cut off and instead of the “colored background” there is a white stripe. The fix and deployment of the new version helps, but exactly 1 time. At the next start, everything repeats.
Rolled back to version 20.
+Apparently, background updates slowed down the loading of my application built using the BDK. White screen instead of 1 second loads from 10 to 15 seconds.

Someone knows how to fix this?
I suspect that rolling back to previous versions won’t help.

1 Like

Think I might have the same issue. Got a white stripe at the bottom of my app that shows up about 50% of the time. Nothing I can do to fix it. Reported a bug on Sunday and no word from Bubble on it.

Also, load time actually increased since upgrading to Version 21 even though I have a SPA.

1 Like

@kathleen @nick.carroll bumping this question as it is important.

Since it’s using server resources not clients - how this update influence the capacity of the app?

1 Like

This is a good point. And this is also one of the reasons why this feature should be optional at the page (or element) level as then we can choose which pages we are okay to have higher client side processing as compared to server side processing.

I have a similar issue on Native BDK where I now have a bottom margin when I scroll down that is not there in version 20. It also happens in browser when I scroll down and the top navigation bar of chrome disappears it creates this bottom margin out of nowhere. Had to roll back.

Yes, you can downgrade your app back to version 20 without the need to revert a branch. If you deployed a branch to Live with version 21, you’ll need to deploy a new version back on version 20.

2 Likes

Sorry to see you are having issues, have you filed a bug report yet so our team can investigate?

have you filed a bug report yet so that our team can investigate?

There may be a marginal increase in capacity usage when pre-generating some assets, but not by enough alone that it would cause a user to have to buy more capacity to compensate

3 Likes

Hi @nick.carroll I did last Fri, we’re in communication and working on it! Thanks!

1 Like