You are right @aaronsheldon but the whole point of Bubble WAS to simplify the life of people that do not know what a websocket is. They had one job, and they completely winged it.
7 Likes
To be fair, if someone can/needs to setup a server-side timer to do whatever, then they would be an advanced enough builder to understand websockets. To be honest it’s overkills like these that lead to the WU pricing structure.
While Bubble makes building easier, Bubblers should not take for granted the costs of resources that are required to keep our apps running and with good performance.
For a platform to mature, so must the userbase. If you are making money from Bubble then you must find the time to learn the hows and whys Bubble does things.
5 Likes
Hi @josh I’m reading the blog post about optimizing apps and came across this section below
“Can I cut down on how many database searches I’m performing?” Even if they’re part of the same process, each search will impact workload.
For SEO purposes, the page data such as Facebook/SEO for Title, Meta Description and Images, it is not possible to reference any datasource other than the page’s current thing, or to do a search.
I’ve done a lot of work trying to optimize my apps for SEO purposes and the lack of abilities for the URL data to be extracted as a type (ie: my path is a custom data type and on extraction of URL data with Get data from page URL and I select the type to be a custom data type) and returned properly when using a Slug means the only way I was able to get the SEO to work for page title, meta description and image is to use a search for each of those sections, plus all the sections of my pages structured data.
Two things that could and in my mind should be done.
-
Make it so the page HTML data such as title, meta description, image and header can properly reference and use an alternative data source other than the current page thing or a search. I’d like to be able to use a group element data as the datasource or the URL data.
-
Make it so the Get data from page URL can properly recognize and retrieve the single entry when using either slug or unique ID for both parameters and path items. Not only would this enable more functionality within page SEO settings, but help enhance ability to structure clean URLs for SEO, as well as reduce the number of searches through migrating away from a search with the URL path value as a constraint, and instead making them a single value search return, which will help optimize for workload unit consumption.
Up until now, the best thing support as been able to offer is to add an idea to the idea board (Not sure when I first added it), and to suggest to just use a search in each field (title, title SEO, meta description, image and all other values for structured data)…now, on one page, just simply to try and get about as good an on page SEO as possible in Bubble, I have 17 searches (all the exact same search), which in the old way was fine seeing as I was told that the same search will only be performed once if all are on the same page.
Could you please verify if the same is true today, that having multiple of the same exact search on the same page will actually only count as 1 search as related to workload unit consumption? Also, please please push forward on the feature enhancement requests. They will do so much toward being able to optimize for workload units when it comes to data retrieval.
5 Likes
Does anyone have a link to the webinar? I’m not seeing it on Bubble’s YouTube channel. 
can’t find it either
Recording hasn’t been published yet.
Hello @artemzheg
These are my notes from the webinar. Hopefully they can be of some help 
9 Likes
I mean, there are people asking for a webinar link that happened 24 hours ago. Still complete silence from the team, no proactivity, no nothing. @emmanuel these are small details that tell a lot. I would rather be worried about these things than retweeting irrelevant tweets. You are making it harder every day to keep going with bubble 
2 Likes
I have been a bubbler for 3 years and here is my take @emmanuel first of all thank you for creating the noCode movement and empowering designers and non Technical dreamers to have the power to build their ideas. I have greatly admired what you guys have been building. I had kept immense patience when I built apps only to find they were not scalable so rebuilding them after reading Peter Amilie’s books, then again rebuilding after a new responsive engine, and then again rebuilding the backend on xano after realizing how slow bubble backend is and now THIS. I have simply lost my patience to stick anymore and burn my brain cells.
Here are my 2 satoshis. The only way bubble will survive is if you literally click control + shift + delete and delete your entire backend codebase, spend whatever money you have to redesign the editor, and make it a frontend tool that has capabilities to import html/css/js, and even the ability to export it to self-host.
Pivot to becoming an IDE instead of staying a vendor lock-in platform and trying to milk cash out of your users. People are waking up and moving away INCLUDING ME.
It’s been a pleasure living in the “bubble” pipedream for the last 3 years.
Good luck.
Best Regards. 
5 Likes
Im feeling that we spend a lot of years learning bubble and now wasted that time and we need learn a lot of things about the new bubble, and we need “optimize” our apps without tell about the cost/time
1 Like
Thank you for saying this. I was shocked by the webinar - it was not at all what I expected and did not feel helpful.
I expected to hear from Bubble engineers (or similarly informed people) with concrete information on the new system and how we are expected to build (or refactor) going forward.
Instead, it felt like people saying I tried this and that - now go grind up your time testing a bunch of stuff yourselves.
2 Likes
1 Like
If I was a betting man my money would be on no such thing as wasted time. We are developers / entrepreneurs whose everyday calling is to solve problems among a plethora of other things. This one is another one in my book. Let’s keep grinding 
1 Like
2 Likes
Might have been a good idea to do this first?
1 Like
on page 2: I thought that bubble stops searching when the condition id true. So when the first result is not empty the condition is true and it wouldn’t be a huge amount of users to search for. Am I wrong with my understanding?
Better version of the webinar replay with @keith commentary:
7 Likes
Watching parts of this optimisation webinar bring me no comfort.
IMO, Bubble ought to publish two indices:
(1) What is their markup for WUs for various functions over underlying compute costs?
(2) What is this as a price in relationship to efficient coded equivalents?
These - as a COST BASE - indicate how price competitive the platform is, and how much of an advantage vs penalty, Bubble’s implementation of nocode is. In competitive markets, these ratios indicate if it is possible to be competitive for devs or if activities are scalable at all.
It is not just about MAKING DEVELOPMENT EASIER if this leads to excessive pricing or price gouging. If you’re going to lead with massive statements like “THE BEST WAY TO BUILD WEB APPS WITHOUT CODE” and “BUILD BETTER, FASTER” it is really important to disclose any key commercial consequences that affect business viability - otherwise these statements are misleading and before long, may risk legal action from Bubblers who feel they have been misled or deceived by these. The advantage of better development is negated if TCO (total cost of ownership) is way higher than better development patterns.
How can the Bubble team claim in good faith that anything data intensive and SOTA (i.e. what it takes for modern development to be competitive) is best built on Bubble with WU units as they are? Surely social networks, marketplaces, many SaaS apps, dashboards, CRMs in 2023 are all HUGELY data intensive and not remotely viable on Bubble given current pricing models? I welcome being proved wrong here… but what kinds of costs would Bubble anticipate per user per month for a apps with lots of DAUS - a social network like Twitter; a local classified site; a dashboard; a CRM? Are these price competitive relative to code options? "@Josh - would love you to answer these questions. You haven’t responded to any of my many comments.
1 Like
@emmanuel: genuine question. your logic is: those who spend more WUs should pay more, right? now, suppose - with enough confidence imo - that at least 30% of top WU spenders will turn to Xano (if not leave at all) as a backend at some point in time as prices increase. so, now you will only have 70% of big bubble users paying for WUs. have you thought of this scenario where your policy might actually backfire? Do you expect users to keep going with bubble if Xano is much cheaper as a backend? Why shouldnt users move to Xano when they reach a certain maturity point?
On a general note: unless you do a webinar (or similar) with TRUSTED bubble OGs such as @keith @eli @aaronsheldon @TipLister etc., asking similar poignant questions, confidence in Bubble will keep going down the drain. I dont want to alarm you but your business is seriously in trouble and a self-congratulatory webinar wont help much . Thanks
4 Likes
“For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled.” - Richard P. Feynman
At the very least, it would be ethical to communicate competitive disadvantages over building on Bubble, instead of using words like “best” and “better” without qualification?
2 Likes