[Small performance optimization] boolean operators can now shorthand

Hi everyone,
I would like to let you know that we have just rolled out a small change to our evaluation engine, which we believe could lead to significant performance benefits to some apps.

When Bubble evaluates an expression in general, any modifier will evaluate its own properties (the fields that you see in the property editor’ slidable panel) and its argument (the right side of the operation, if there is one) before it evaluates the result of the operator.

For something like “A and B”, Bubble used to evaluate A and B regardless of the outcome.

Since the outcome can sometimes be determined just from evaluating A (if A is false, then regardless of B, “A and B” will be false) and in order to match this very common programming optimization, we have implemented the following shorthands:

A and B, but A is false → return false and do not evaluate B.
A or B, but A is true → return true, and do not evaluate B.

This should help speed up things such as conditional properties which depend on two conditions, the first being much lighter to compute than the latter. For example, “Only when Page width < 700px and Do a search for Things:count > 100” will not even attempt to do the search if the page is too wide.

As a small asterisk, this has the potential of being a small breaking change, which however unlikely, is something we would like to communicate:

  • if “A and B” is shorthanded, that means that B does not get evaluated at all. If B had any side-effects (maybe through an external API call) these side-effects won’t be triggered.
    This pattern is quite rare, but if you are affected by this change, you should alter your expression such that any side-effects happen on the left-hand-side of the expression.

I hope this helps everyone build more performant apps,


this is big. Thanks!

1 Like

Great job ! I though it was already the case so i always begin my conditions by simplest query, it’s a really good news that’s its implemented now !


Thanks @aless!

Me too, to be honest!
Such a welcome change :blush:


This is important to have in mind! :+1:
Now, when reviewing my app I will remember to take a look in the order…. Make sense.

So awesome! Thank you! :slight_smile:

1 Like

A lot of small things can make a big difference, cheers


I’d say that’s more than just a small update!


Awesome, thanks!


Can someone give a real-life example of this?

Lets say I have a workflow condition - When “User role is Admin and Day is Wednesday”. Does this mean that workflow would go through as soon as user role is Admin without checking the day?

I thought that’s how Bubble already works :slight_smile: Thanks!

Hey there, @myflappd… I believe it means that in your example, if a user’s role isn’t Admin, the system no longer checks the day because the condition of the user role being Admin and the day being Wednesday cannot be true given that the first condition (the user being an Admin) is false. So, the system is “saving time” by not evaluating the second condition when the first condition is false.

1 Like

Thanks @mikeloc .You are correct. I checked it as well.

1 Like

Great update - thanks Bubble team :partying_face:

This is great. Now to go through my conditions and make sure they’re in the optimal order.

Great to know! Thanks!

Awesome! Thank you team :slight_smile:

This is a nice update. Performance has always been the key question mark for us as we build in bubble (albeit, we haven’t launched our app yet).
Does this impact how expressions are resolved throughout the app - i.e., in workflows, as well as conditions in elements?

Stack all the conditions :joy: