I have a question. If I upgrade my free hobby app, will I lose its status? I know the plan was removed and I’m afraid updating will change my app as well as I do want to keep it as a hobby plan… edit: not sure if it’s called hobby plan. It was removed last year I believe and those of us who hadn’t updated yet were allowed to keep our old plans.
Yes, if you upgrade from any legacy plan or the hobby plan you will lose it as you’re upgrading to a new plan.
I learned that Bubble Support has no way of reinstating it too.
We made 130K this past year with our bubble app (www.rapide.ly). It’s not the engine that makes the profitability, but what the app can do for its users I think.
I love the new responsive engine as it allows me to have a much more professional looking app than before. Working right now with a UX/UI designer and most of what we put in place would not have been possible (or very difficult) with the old one. And it’s so much faster.
Hope it answers your questions.
For those who would an opposing viewpoint to what is being posted here, check out this post on the Bubble blog written about me:
Solo founder with no prior technical experience who built the whole product himself 100% on Bubble, no outside help whatsoever, and profitable.
My profits from bubble is a combination of income from products I sell (saas) and also from development for my clients.
One of my clients is now doing over $20,000,000 a year since we launched his app called organflights.com.
Clearly, bubble applications are helping people create highly profitable businesses.
Btw bubble doesn’t create success. Solutions to big problems create success.
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.
- 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 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.
Thanks, @nickc. Awesome overview and explanation.
And along with slaying the “giant” comes lighter weight pages by virtue of fewer DOM elements comprising the page. That is, Bubble pages are far less of a “div soup” with the new engine (which plugin devs will certainly appreciate). These 2 factors alone - less JS and fewer elements - are no doubt responsible for a large fraction of the performance gains.
Looking forward to Bubble getting even leaner, meaner, and easier to use.
@nickc, thanks for this comprehensive overview.
I’m new to Bubble, coming over from Webflow, so I quite like the move to CSS flexbox and started building using the new responsive engine right away.
I’m having a few challenges with this, but it sounds great! Any possibility to have a look at how you guys have replicated this?
Also, one big thing that seems currently missing is to have more control over Flexbox properties in conditions.
Something that’s been an issue for me multiple times already is the fact that I cannot change a container’s layout from “Row” to “Column” on smaller breakpoints. Especially that part seems to be missing when I try to replicate some of the elements of the Webflow example you mentioned above.
Is this feature on the roadmap? Or is it somehow already feasible?
As a professional developer/agency owner, Bubble Bootcamp Instructor and content creator who has a responsibility to teach others how to use Bubble (students, employees, subscribers) and was 100% proficient in the old engine, I can feel your pain when it comes to change. Definitely not something I was excited about having to spend the time to first learn it myself, and then to create new materials to teach others. I also didn’t complete understand the reason for a complete redesign of the system, rather than a tweak to the existing.
However, I completely understand why Bubble did it and get the benefits moving forward.
I also have experience with Bubble making changes to the platform that affect the early adopters, namely with the change in pricing of subscriptions and I can vouch from that experience that Bubble is true to their word. They stated that they would grandfather in existing applications for 2 years, and 2 years to the day they took that away. I wouldn’t see any reason to not trust Bubble when they say if you want to remain on the old system you will be able to.
Congratulations! Sounds like once you get the funding you will be in a great position to spend some of that on a developer to transition your existing designs onto the new responsive engine so your app will benefit from using the new engine while you will then be free to do all the hard work the company leader would need to do.
Good luck with everything moving forward.
@nickc Any ETA on when the conditionals will allow for max/min width and height settings?
I am trying to recreate the designs from here Visual CSS flexbox builder | Webflow and I can not without the ability to control the height and width settings conditionally based on the page height and page width as part of a conditional dynamic expression.
Has anybody been able to recreate the fluid-grid design? Doesn’t seem possible in Bubble.
Surprisingly, none of the designs on that page seem to be mobile responsive - i.e. the layouts don’t adapt (stack) on smaller screen widths. Instead, all the cells/columns just get narrower. Am I overlooking or misunderstanding something there? Or maybe those examples are just not intended to demonstrate breakpoints?
(Can’t wait for padding and breakpoints in Bubble.)
I was trying to test in practice myself and although some are kind of possible at the moment, most are not.
What? Drag-n-drop is gone? Sounds weird. Will check out the new engine soon.
I love the new responsive engine.
Agree, that’s an essential feature!
EditorX cant do anything like Bubble can. Go build a social network or marketplace on EditorX and let us know how it goes.
Bubble Response Engine thoughts after migrating my multipage app to a new single page one
Perhaps this might be helpful to some of you. I’m no programmer but I’ve just migrated an app that we had made in Bubble in the last 12 months to the new responsive engine. Here are some of my thoughts and suggestions as a result (it may be that there are somethings I just don’t know how to do in Bubble that may have made this easier so feel free to enlighten me!)
The App we had developed was 12 pages in size and had roughly 400-500 workflows (most often controlling button actions and navigation elements). It was designed to be used on web and mobile devices.
Moving to the New Responsive Engine
- Whilst migrating the app I decided to turn it into a single-page app for performance, so my experience may also reflect on the process of merging 12 pages.
- Initially I tried ‘upgrading’ my pages using the Bubble one-click option. This worked I suppose as the pages were still responsive, but it was almost impossible for me to follow what was going on, as Bubble seemed to add in many extra groups of Rows and Columns. I could not follow the logic when I looked in the elements tree.
- So, I went back to basics, I watched a number of helpful tutorials, copied a few, and got the hang of using the new engine. I then started building my new page from scratch and copying across page elements and workflows. Naturally, quite a lot of clean up needed to be done in the process.
- I added this new page into the same Bubble instance as my original app so that I could access all the data which made testing easier.
- I got the basic structure of my page working first with the header, footer and key lefthand navigation pane behaving properly. Only then did I start copying across page elements.
- When I copied across elements I would copy popups first, and the main page/canvas elements second - this seemed to ensure that I had less errors to fix later.
- I always copied using Copy with Workflows and Paste with Workflows. To make sure I was pasting them into the correct groups/sections I would select the element I want to paste it into in the Elements Tree and then click on the Edit menu at the top of the page to select Paste with Workflows (NOT using the right click menu as sometimes I inadvertently deselected the object I wanted to paste into).
- When I copied across page elements I did sometimes attempt to clean up the page - by removing redundant groups. Having extra and unnecessary groups just meant that there was more than needed “fixing”,so deleting them makes good sense - just make sure they do not contain any logic, especially Custom States! (Note - if you have put the majority of your Custom States on the Page object your life will be tougher as this is the one object you cannot copy into another page. Not sure what to do about that other than rewire all the workflows… that’s what I had to do)
- Then begins the task of changing MANY groups and elements from being Fixed elements - to either Column, Row, etc. This is painstaking and laborious! But the best way I could find to do it was to open up EVERY branch of the elements tree and click on each one in turn to check its settings. Usually every single item needed to be changed in order for the responsiveness to work (uncheck “Fixed width” and change Minimum width to 0).
- Managing Workflows: as I was copying across a group/page at a time, I would move all of the associated workflows into their own Workflow folder for that “page”. This helped me to be able to work-through/revise the workflows in a more orderly manner.
- Firstly I fixed errors that emerged as I copied elements across. Sometimes this was where Custom Workflows did not come across. Not a responsive task, important as I moved to a single page app.
- For a first look at the responsiveness I would normally Preview the page and check it out in my browser (so I can see real data in the page). Then move the edge of the browser window or use the Developer Tools in Chrome to preview different device types.
- My experience was normally that I had missed some elements and left them as FIXED by mistake, this had the effect of making the page wider than I wanted, or causing some elements not to be responsive. I would then have to try and find the rogue elements and change them - this is tricky if you have a big elements tree!
- Putting the Bubble canvas in Responsive mode was quite helpful as I could show elements and click through each item in the elements tree to see what effect it had.
- One tip I came up with (which sounds a bit extreme) was deleting a whole group of objects, testing to see if this fixed the responsiveness of the rest of the app, and then pressing Undo. Sounds crazy I know, but if you have 500 elements in your tree, finding the offending section can be hard. This at least narrowed it down on occasion.
- Once I had it working I would normally do a final test on a mobile device (as occasionally I would find something new out).
Improvements I’d like to see Bubble Make
- It would be great if I could delete a group from the elements tree without deleting its children (but rather have the children become children of the element above). This would be so helpful for getting rid of redundant page elements from the old engine!!!
- It would be amazing if I could search for Fixed width elements somehow, or have Bubble highlight them in the Elements Tree. Finding these rogue elements was a pain in the butt.
- It would be helpful if there was a feature in the Responsive Canvas view that said “the Page width is this size as a result of this element being fixed width” - similar to the margins message in the old engine responsive tab.
- I did also find myself making the same 4 or 5 changes to many many groups (e.g. change container layout to Row, change container alignment to Space Between, change horizontal alignment to Centred, uncheck Make Element Fixed-width, set the Minimum width to zero.) I might have had to do this on 50-200 objects! Some type of Macro or copy with formatting function would have been very helpful.
- Add ‘Copy with Workflows’ and ‘Paste with Workflows’ to the Right click menu when I right click on an item in the elements tree.
- Not to do with the responsive engine, but I’d like to be able to select multiple Workflows and move them into a folder in one action.
- Again, not to do with the responsive engine, but I’d like a visual indicator to see if an object has Workflows associated with it (perhaps as an icon at the top of the Properties box) and if it has Custom States attached to it.
Overall it was a pretty reasonable process and I’m pleased with the result. The new engine makes it easier to enforce commonality across the site, easier to get the page to perform the way I want, requires far less groups and fiddling, and it seems pretty fast. I think it is a big improvement even though it took me a while to get the hang of it - oddly I can’t really remember how I used to work in the old engine now. Hope that helps.
In QA right now
Super helpful, thanks for the feedback!
Not sure if this was mentioned – thread is too long to read…
Idea: When defining the layout of an element the default units are px rather than %. This seamed to make sence before, but maybe now it might be better to default to %.
My though process: All child element sizes are relative to the parent, henc px shoulld be avoided if possible. I typically define the highest order Parent as px (in most cases the page) and then use relative sizing for all child elements. The only typical exceptin was images, but ( "genius " ) the Bubble Architects have included Aspect Ratio - which negatest the need for this too.