Reusable element properties and custom events are reusable expressions (scoped to front-end/backend)
A side by side for adding a new input to a page.
bubble:
add input element
select width and height
apply style
set input data type
add data constraints/checks (min max numbers etc)
set placeholder etc
add text element for label
select width and height of text
apply style to text
enter label text
combine both into group
change group height and width
change group style
add workflow/logic for data mapping
weweb:
add reuseable to page for input
add data to reuseable properties (label text, placeholder etc)
add workflow/logic for data mapping
in weweb everything can be wrapped up in the reuseable so you don’t have to repeat yourself constantly
bubble kind of do this but it’s super limited which restricts how reuseables can be used in bubble (hard to use them for inputs for example - possible but much harder than it needs to be).
weweb reuseables also have dropzones so you can create reuseables that expect other things to be dropped into them and that’s super helpful and powerful
one other super helpful feature of weweb reuseables is that they change in real time in the editor - so if you set a property and the reuseable has conditions running on that property then it’ll reflect to show the correct state… makes it so intuitive and easy
1 Like
Honest question, how fast do you find it on a NET basis. Meaning, let’s assume the front end is faster or better. How much time OVERALL are you saving when you also include using a different backend/DB?
Yes, I think though that people had been asking for it as a feature similar to styles or option sets where it is a sort of built in method rather than the combination of existing features.
That does sound nice
This is the kicker.
I love WeWeb’s front-end builder — it’s incredible and a huge leap forward from what you can do in Bubble.
But working with Supabase can be a real pain. Building the database itself is actually quite easy, and using workflows (add, delete, edit) is intuitive and fast — just as fast as Bubble. However, the main kicker is backend logic and edge functions. You have to write those in Supabase using code — there’s no drag-and-drop editor. AI helps, but it’s still a very developer-first experience.
Xano offers a great middle ground, but I find it too expensive for what it provides. You could try using Make or n8n for backend logic with a visual builder, but that can get messy quickly and may be too slow for many real-world functions.
This is why I still say Bubble is the best for MVPs — it’s super fast and easy to build out an idea. But it has serious limitations when you try to scale to thousands of users.
WeWeb + Supabase, on the other hand, is production-grade and can easily scale to hundreds of thousands of users. However, you don’t want to be constantly adjusting logic on the fly — it’s easy to break things, and implementing backend logic is harder. You’ll want things to be fairly stable before building edge functions, and you’ll need to understand database schema design and logic best practices — much more than you would with Bubble.
In short, Bubble is a fantastic training ground, thanks to all the guardrails it provides. But those same guardrails and the abstracted logic can get in the way when your app starts to scale and requires fine-tuning.
3 Likes
I recently had a client in a huge app want to change the icon set we use in the app…
In bubble that means searching for the icon element and manually changing it everywhere (500+ places).
In weweb the icon could be a reuseable (reuseables are clickable and triggerable unlike in bubble). If it was then I could have just changed it in 1 place in 5 seconds vs in bubble where it will take hours.
I had another client want to change from 40px high inputs to 48px high… that was even worse than icons and I just said to forget it - it wasn’t worth the effort. In weweb you can also set size variables which you can use throughout the app - this is another great innovation because I could have just changed the 40px size to 48px and it would have changed all reuseables/things that used that shared size.
This is something that the technical needs in order to integrate into Bubble is not so much that Bubble can not do this and add a feature that would work in tandem with the app search tool.
My expectation is that once they finish up some of their ‘Create’ flows for AI, they will move onto the ‘Update’ flows for the AI, and when they do that, I’d imagine they’d have a clearer understanding of how to implement features like that. If I already know what it would need to be, it is clearly not complicated.
1 Like
Thanks for the writeup, validates the choice for me to stay on Bubble. I think most of us are very very far away from this! But I also don’t have a very backend-heavy app (like a stock trading app or something).
This topic was automatically closed after 70 days. New replies are no longer allowed.