Any plans for native apps? Or more mobile friendly programming (mobile first?)?
I personally do not know anybody who uses desktop or laptop computers anymore (just for work, never at home) - only smartphones or tablets for basically everything (take a look at China, they skipped the desktop computer era entirely !) ! Please don’t become obsolete in the next decade …
This is probably the most important thing I read in this update. @josh is an absolute savage when he has his engineering pants on—I have no proof of this, but I like the thought.
@josh I appreciate just how hard this devops/incident/comms challenge can be! Props for recognizing that and continuing to tackle and improve. To me, one of the biggest (and not talked about enough) pros of building on Bubble (vs. a full code solution) is that you and the team are the ones to manage this incredibly complex uptime and incident management challenge - I don’t have to worry about being “On Call”!
That’s fair. I do love Bubble and think a lot of companies have right to be scared.
However, we’re dealing with a post VC raising company now.
Prior to VC, Bubble listened to their customers and bootstrapped a solution to a very complex technical problem.
Almost immediately after the VC infusion, the pricing change bomb dropped. Do you think the bootstrapped profitable founders suggested that, or was it the VCs who want their 10x in 2 years?
I don’t know a single Bubble developer that was excited about what they saw with the Component Library and the fact that Bubble management seemed taken aback by the instantaneous requests of “community components” means to me that they have not been talking to enough Bubble developers during planning.
I hope I’m wrong, but I also lived through the price gouging of Intercom after their Series B.
Everything you’re saying is correct @csakon - More broadly, it seems like after the VC push, the focus appears to be more on mass market/website builders vs. power users with specific needs (like dedicated servers across seas, “native” app wrapper, more CPU power, more “big data” capability such as increasing CSV limits/decreasing processing time).
Which I can understand: Go for the 100,000+ mass market of folks looking for websites with SOME light dynamic needs/database/API vs. 1,000+ power users who will tax Bubble with complex databases/calls and require investments into the platform that are costly…
We all pay the same prices - If Bubble can find someone to pay $29/mo and use a fraction of the power Bubble offers, that person is significantly more profitable than me and my 1000s of workflows, endless Webhooks, and scheduled workflows running every day/night.
Nature of the beast.
Actually, this is how you kill a startup. The key is to hyper-focus on your most enthusiastic users. All other types of users, the laggards, the late adopters, the confused masses, they’re way too expensive to market and convince them to adopt your service.
The path to explosive growth is to foster an incredibly passionate group of early adopters first. We see this time and time again, from Github, Slack, Facebook, Webflow, Figma… they all hyperfocused on building something amazing.
I think their efforts to attract new users with “low hanging fruit” features that are uninspired are a distraction to say the least. They do not attract new users and upset power users who slowly feel like they’re forgoten (we helped your company grow when no one else believed in you!!).
I think they are focused on removing technical debt and a couple of long standing issues, see their focus on coffee script & the improved version control interface. They also need to take into account market demand and/or trends, thus the Components feature.
Totally agree.
Agreed, problem is… It’s been 10 months from the (second) pricing fiasco and bubblers are still in the fog as to what the future will look like. If I cannot answer my clients and my team mates the simple question “are we going to be able to afford Bubble in the future?”, there’s a huge problem. What does this problem bring with it?
I’m a big time fan of Bubble, but not the 2022 version, the version where we had “real” transparent, consistent and meaningful updates. It’s nice to know that they reached 100+ employees (yay)… But since the investment round, sorry but I’ve just seen other solutions (even the open source ones) going full throttle on improvements and features while I still ($!"/&&") can’t use an API “thing” (or it’s json) and still have to create half assed workarounds that will be applied in serious production softwares.
I (and many others) by looking at this forum and by looking at the popularity of our friends at Xano, Wasabi, etc. have just abandonned the idea of having our data hosted at Bubble. First : We’re a few days from 2023, legislation and data privacy laws require MANY bubblers to host their database in the country used by their clients, you want that here? It’s gonna be a few thousands a month please. (Wait what?!) And second : The reason we decided to host ALL our data and workflows elsewhere is to be able to easily jump ship if it sinks.
Why does it take a few days for independant developpers making features that should be built-in to bubble and beside a few basic necessities, I haven’t seen much improvement for a long time in my editor. (Got so many examples in mind but I already feel like I’m just whining lol)
I repeat, i love Bubble… But man, it just seems they’ve taken the weird path of doing more “business management” than their initial reason of success… making life easier for devs and creating a new class of “citizen devs”.
If that’s true, then maybe hopefully the heavens will provide a more SEO and speed friendly service. I’ve been bucking the trend of Webflow marketing site and Bubble app by leaning fully into 100% Bubble. Hopefully this pays off.
How about a mini-sprint to allow the client-side Actions API to return values to the workflow. Pretty please with red and green sugar sprinkles on it.
I’m wondering if there is potential the advanced filter would perform faster if the user could call a backend API, advanced filter on the server side, then return the value to the client
Hey @tylerboodman - you can do this already, e.g., by triggering a backend workflow that creates some new thing on which there is a field that holds your filtered search results and then (in the client) you just watch for that thing (basically returning the results to you).
Let me just save you a bunch of time as I just tested this (though I knew the answer going in) and it’s WAAAAY slower than doing it in the page.
A client-side search for 10000 of some items and :filtered (advanced) for this item's name contains some string (obviously not the way one should do that, but this is a benchmarking experiment) takes about 8 seconds in the page (personal app).
The same done in the backend has a total roundtrip time of about 60 seconds.
So, even if you could otherwise “return the results to the page” there’s no way it would ever be faster than advanced search on the client side.
Basic set up:
Client side search and advanced filter:
Same search done in the backend, returning a new object with our filtered results:
Widget for performing the tests:
Benchmark results in console. First the backend (total roundtrip from button press to when new object comes back to the page 60.2 seconds):
Now the client side (from button press to when custom state is set 9.8 seconds):
Good to know, thanks!
And… actually… I think this was an unfair test as I think that Bubble sees my client-side advanced filter as being stupid and does it “the right way”. But anyway, it would never be faster. @tylerboodman
(though in some cases its going to be “comparable” 
it’s kind of a thing one wouldn’t desire to do for a lot of reasons)
Could not agree more. We would love one in the EU as well
TOTALLY AGREE +1 Vote 
Amazing - First step. Probably wont use as-it though.
Keep focus on the functions of the components pane - Especially ease of saving our own work - rather than the components themselves. Don’t spend time adding more of your own. The community and others services like Atomic Fusion, does a much better job at designing. Tough but true.
Doing quality UX/UI is easier to do one self and then reuse designs knowing how where and what to change, rather than manipulating someone else’s designs or building on top. Same principle applies if you are good at bubble and know exactly what you want, then building it from scratch
Bubble adding basics components has value (which is really good) to beginners and MVP apps with low UX/UI quality requirements.
Consider these features (top of mind) to add more much needed functions than Atomic Fusion and others can:
You obviously want to have someone dedicated to this, so it can run its full course.
…and take over direct, personal leadership of the engineering team
Good choice. Thank you!
I wouldn’t say taken aback by community components, this has always been on the roadmap for the Component Library 
Would custom events returning values do the trick, or must it be an API Workflow?
Both 
