Monthly Community Update -- June 2022

Hi all,

This is our June community update! Read last month’s update here.

May was a pretty heads-down, productive month for us; we made a lot of headway on various projects and released quite a few things, although that was marred by some rollout-related incidents, discussed more below. We also continued to expand the team at a steady rate. New hires include:

  • Rob, Michael, and Abel, joining as engineers
  • Leon, joining as an engineering intern for the summer
  • Christine, joining as a designer

If you’d like to join us, our open roles can be found here. We always value previous Bubble experience when hiring, particularly for our Technical Product Support Specialist role.

Changes we made this month

We continue to prepare for making our new responsive engine the default for new apps: this month we took the updated plugin editor out of closed alpha so that all our plugin builders can start porting elements to the new engine. For most plugins, this should not be much work, so we strongly urge plugin developers to do this. As a reminder, we would also like to get as many of our templates on the new engine as possible.

Our performance optimization for pages with lots of invisible elements also went live as an experimental feature. We are monitoring for potential bugs and will release it to everyone once we are confident it is stable. Early testers are reporting very significant speed improvements to their pages!

We also launched a number of long-requested features:

In addition to those features, we are experimenting with in-editor educational resources: new accounts may see video popups on the Data tab and Option Sets tabs explaining those features in more depth.

We also published a number of blog posts you may be interested in:

As well as news coverage of Bubble:

Finally, one other thing to mention is that we have been dealing with an increasing number of bad actors using Bubble to send spam or host phishing or other fraudulent content, and have been making some changes to shut these activities down, including mandatory verification of Bubble user emails and additional free plan limitations. We may make additional changes over the next month or two: we will do our best to communicate transparently with the community and limit any impact they have on legitimate Bubble use cases.

This month in numbers

  • New conversations via bug reports or support@bubble.io: 9,698 (up 11.3%).

  • Average first response time to messages: 2h 15m during business hours (up 69.2%)

  • Average response time to messages: 2h 26m during business hours (up 50.5%)

  • Open tickets being investigated by the engineering team: 63 (down from 65)

  • Of those, tickets that have been open longer than 7 days: 24 (down from 25)

Things on our minds

As mentioned above, we had several rollout-related issues recently, primarily related to the multiple parameters on custom events project. While we are glad that project is out the door, the negative impact to our users from the issues was very high: we broke apps in production, some for an extended period of time, and some on the Scheduled cluster. We just completed an internal retrospective on the project and rollout issues to understand what went wrong and how to prevent it in the future. The key issues we identified were:

  • We made a non-backwards-compatible change to the way we store applications. This was the main reason the user-facing impact was as severe as it was: we were not able to immediately revert the change once we realized there was a problem because apps had already been altered, so we were forced to solve forward to fix the problem which was a significantly longer process. It also meant that transferring apps between the Immediate cluster (which had the new code) and the Scheduled cluster (which had the old code) was not safe.

  • Our testing process for this feature was focused on the custom events feature itself, but the changes touched code that was shared with other features (the Draggable UI plugin, Schedule API Workflow on a List, Set/Cancel Recurring Events, and On Error Events). Our test plan did not recognize that those features could be impacted, and we did not manually test them. On audit, we discovered that the automated tests we have that were supposed to prevent those features from breaking were either placeholders or only covered a subset of functionality.

  • During code review for the feature, the senior engineers reviewing the code felt unsure about approving the pull request but could not vocalize any specific concerns. This led to to the pull request being approved and deployed despite those reservations.

  • We released the feature shortly before a long weekend, with lower team staffing levels, and our response time to user bug reports was longer than usual. Since we do maintain weekend coverage, we are conducting a separate retro on why there was a delay in the issues getting escalated.

We are still discussing action items coming out of the retro, but likely next steps include:

  • Making sure that future changes to the way we store applications are done in a backwards-compatible way, so that it is safe to revert code. Also, we may make heavier use of the experimental feature flag so that the likelihood of needing to revert a feature that users have already begun to incorporate into their applications is lower.

  • Writing tests to cover all the gaps in our automated test coverage that we discovered (already in progress)

  • Working with our outsourced test provider to build integration test cases based on more real-world examples to better capture unknown unknowns

  • Modify our project planning process going forward to ensure that the test plan includes checking for other features that could be impacted by the change

  • When reviewing code, setting expectations around reviewers having the right to ask for more time or flag things as potentially risky even without specific concerns to encourage hitting the brakes on changes that we feel uneasy about

We know issues like this can be incredibly disruptive to businesses built on top of us, and we are very sorry for the negative impact. We are committed to learning and improving from mistakes and evolving our processes and technology to make them rarer and rarer.

What we’re currently working on

As discussed above, we are preparing our new responsive engine for a full rollout; at this point, the majority of the work is coordinating with our ecosystem to get things ready, as well as porting over plugins that we built in-house.

Following up on our latest post about pricing, we are continuing to do technical investigation work on capacity and auto-scaling. As mentioned in that post, we intend to do further rounds of community feedback once we have completed the technical investigation work, and do not anticipate releasing anything disruptive that would jeopardize anyone’s ability to build on Bubble.

Other ongoing workstreams:

  • We finished collecting feedback on our mockups of our improved version control user interface. Feedback was very positive, and we are planning to start engineering work mid-June.

  • We are nearing launch for the next phase of work for generating HTML and CSS upfront instead of on the fly. This will be an intermediary release that will still involve on-the-fly generation of the HTML, but will lead to significant performance improvements and pave the way for future work.

  • We are close to launch for performance optimizations to make bulk data manipulation via backend workflows faster.

  • For the overhaul of our network architecture and infrastructure, we have built out draft gameplan for the first piece of work, and hope to staff engineers against it in June.

  • In order to increase our overall reliability, we are working on the way our alerting and observability systems work, so that we can be more proactive about tackling impending problems

  • We are actively working on our project to improve how easy and fast it is to build beautiful apps on Bubble. The project involves improvements to managing colors and fonts across the app, and a replacement of our under-used element templates feature with a more mature component system. This workstream led to the release mentioned above of padding support for more elements.

  • Our push to migrate code of CoffeeScript continues; we are now down to 36.9% CoffeeScript in our main codebase.

Thank you so much to everyone who participates in the Bubble community!

Josh and Emmanuel

70 Likes

:heart::heart::heart::heart:

Great improvements from Bubble! Looking forward to more in the coming months :slight_smile:

1 Like

Hey, @josh,

Do you have any ETA?

Thanks in advance :slight_smile: :computer:

Thank you !!!

Dear Josh,

Thank you all of the Team, yes, if you are on the edge of development & innovation,
those failures can happen. I did not recognize a problem, but the

  • improvement in page loads is a great step, next to other great steps on the way.

Cheers,
Alexander, Secondra.com

1 Like

I’m currently working on getting use to the new responsive engine.

This sounds great - will this affect the css load as well? :slight_smile:

Really exciting stuff!

Thanks
ZubairLK

1 Like

Hi Josh,

As Bubble is migrating to Typescript, does this mean that we will be able to create our own components using JSX and add them to our apps? What are going to be the possibilities and limitations? If this enables us to use this syntax, I believe it would be a solid bridge to connect the No/Low Code world with the Traditional code universe. Looking forward to hearing more about this!

4 Likes

I’m super interested in and excited about this!

Great work all around!

Great question! We haven’t actually looked into this. Off the top of my head, the answer is that they are likely independent – the build pipeline for our code is different than the build pipeline for user-built plugins. But, registering this as a request to allow JSX in user-built plugins!

5 Likes

A bit off topic. Does bubble have plans to improve the editor’s performance?

I’m taking about the lag it creates and the memory consumption when there are many elements on a single page you are editing.

2 Likes

This didn’t fully register in my first reading, but if it’s referring to a graphic/UI/UX designer joining the team, then this is tremendous news!

:smiley:

2 Likes

Holy smokes I hope everyone knows how much of a big deal this is. This is going to speed up bubble apps a lot! Had asked about pre-rendering HTML back in 2020 so very exciting to see it coming. This is an infrastructure change that is going to cement Bubble as one of the best if not the best platform to quickly build performant apps on. So pumped!

7 Likes

Yep, IMO this is the last step Bubble needs to basically remove any “limitations” of the platform. This should improve site audit speeds, and search indexing.

2 Likes

Thanks for the update, any ETA on the new pricing structure?

2 Likes

Great update and progress. Fast Company though sucks. Good they had a positive article. So unusual. Keep it up. Wish you had offline capability, but so far I’ve been lucky with WiFi being available. :+1:

1 Like