Going to take the opportunity to respond to your original questions here - but apologies that you had a poor experience migrating your page to the new engine. We are still looking into ways to improve this process so any additional feedback here would be helpful.
Why new
- While the legacy responsive engine was great for making a basic page responsive out of the box, we were finding that users were quickly hitting the limit of what was possible with the old responsive engine. One of the top feature requests was the ability to have more control over the responsive behavior of their app, rather than allowing Bubble’s responsive algorithm to do most of the heavy lifting. When we explored ways to iterate on the legacy responsive engine, we kept hitting the same roadblocks - more control was not really possible with how the engine was created - and simply put, a lot of common responsive layouts were just simply not possible. More on this below. Furthermore, the world has evolved since 2012 and CSS flexbox is the industry standard for modern responsive web development.
Why so different from the old version?
-
The legacy responsive engine is essentially a giant javascript algorithm that runs on-the-fly calculations to resize and reposition elements based on user settings and best guess assumptions about desired behavior. The benefit of this approach is that simple pages will be largely responsive out of the box and this approach served Bubble and its users well for a number of years. On the other hand, if our assumptions were not correct, users would be forced to spend considerable time tweaking settings and creating workarounds (or even worse, using custom code) to get their desired behavior. In addition, all of these on-the-fly calculations meant a lot of rendering & scripting times on page load or page re-sizing resulting in generally poor performance & snappiness of bubble pages.
-
The new engine is based entirely on CSS flexbox & grid - the industry standard for modern web development. This new foundation solved the two big problems mentioned above - control & speed. By exposing these settings to users, no layout would be impossible and bubble pages would get a big boost in performance as CSS would be responsible for resizing and repositioning - not some big js algorithm. Our challenge, however, was to present all of these new responsive controls to users in a manner that was intuitive and allow them to opt into predictive responsive behavior rather than make best guess assumptions. To that point, I think we did a decent job - but there is certainly still a lot of work to be done to get the user experience and learnability where it needs to be. This is also why the responsive engine is currently in beta. We need users using the product to really know whats working well and what isn’t - but we also didn’t want to force anyone onto something new. From the beta so far, we’ve released a number of updates based on that feedback, and have a lot more to come.
-
Maybe the largest sticking point is the migration from old responsive to new responsive, as outlined above, these are based on two fundamentally different technologies. While we are investigating better ways to migrate existing pages, there are two options to upgrade: Maintain responsive behavior but add a bunch of new containers to the page or Migrate as is, but in fixed width. Users have found success using either option depending on their use case.
What is the result of the improvement?
-
Based on CSAT surveys and qualitative feedback so far, users actually prefer the new responsive engine over the previous engine. That might not hold true for everyone, but overall, there has been an improvement in satisfaction.
-
Almost any responsive layout is now possible. To test this in practice, we made sure we could easily build any of the layouts webflow’s flexbox website https://flexbox.webflow.com/. More features are also on the way based on user feedback to make the engine even more powerful and easier to use.
-
Performance. There is a notable performance boost on pages using the new responsive engine as compared to legacy pages. In addition to general page load speeds, the snappiness of a page as it is resized or content changes is better. New responsive doesn’t solve all of Bubble’s performance woes, but certainly makes a difference and helps unlock new performance optimizations down the line.
I hope the above helps answers some questions around why we chose to go down this path - and again, thank you for your feedback on the new responsive engine.
As for other claims around the profitability of companies built on Bubble, I kindly ask that you move these questions to another thread, so we can focus this thread on discussion and feedback around the new responsive engine.