BLUF: if you want to learn Bubble you have to build things in Bubble. It is worth learning Bubble so you can build rapidly.
My favorite thing about Bubble is that everything is integrated together. The database, permission logic, workflows, UI, etc all know about each other automatically. So if you add a field to the database and give it a type (ex. number) the UI elements that interact with the field instantly know it’s a number and only show you appropriate options.
Of course, this means Bubble has strong opinions about how you’re going to build your app.
My least favorite thing about Bubble is that you don’t have all options available at all times. Most of the options are buried several levels into the stack where they actually get used. They are only discoverable by actually building the entire stack to the point where that option is useful and then using that option.
So I suggest the best way to learn Bubble is to build several apps. You can’t learn Bubble by reading the documentation or bringing in your intuition from other tools. The only way to work with Bubble is to build a mental model of Bubble’s structure, where certain options appear, and how to get to them.
As for what you can do in Bubble, it’s awesome for CRUD apps and terrible for manipulating data.
if you can get by just storing and retrieving facts you can get up and running in Bubble in a day (with experience) and probably scale big. If you need to do math, or complex queries, or analysis, you aren’t going to be able to do that in Bubble itself. There are a couple little things you can do, and the team is adding one or two more things every now and then, but you shouldn’t rely on it.
Bubble has a “no code” metaphor that breaks down pretty quickly when you actually need to do work. What Bubble offers instead is basically code that you build using pulldown menus. There are also an increasing number of ways to use actual code. The workflow system is the weakest part. It’s very linear and hard to organize. For example, if you need a branching path, you can’t use one logic operator (like an if-then or switch). You have to put redundant logic into each branch of the path. There also isn’t a built in way to comment-out a part (you have to hack it by creating an if that will never happen). There is a similar linearity problem in the conditions on UI elements where you have to reproduce the same logic across all the condition statements.
An annoying problem in some circumstances is that the client side downloads the entire record (all fields) that are allowed by permissions. So if you know optimization is important it can be worth splitting data across tables from the beginning. Like if you know you’ll have a lot of different information for a user, but it’s all relevant in different situations, you might put it in different tables so you don’t have to download all of it when you access the user.
A trick that will help save you some headaches is that Bubble’s stack does know about elements and their changes, but you can’t hot-swap elements. For example, if you have element A and elements B, C, D, E, F, G, H, etc all depend on A, and you want to replace A, you’re going to have to go fix the link in elements B-n. But if you make an element just to be the nexus of all those links, then you can swap out element A and only fix one link.
If you know your interface needs to work well on mobile (small screens) you should build the UI in the smallest width you support and have the responsive logic pull things up onto the same line, rather than the other way around. The way the UI is built and the way it displays is tightly coupled. For example, the actual number of pixels between elements in the editor is an important part of the responsive logic. I’ve had bugs where responsiveness got all screwed up and eventually found it was because a group that was 320px wide changed itself to 322px wide, which made it wider than the screen group it was inside of, which totally changed the responsive logic. Along the same lines, the relative y position of the elements is extremely important and there’s no insert or wrapping like in a text editor. It’s good to get in the habit of designing your pages in the editor with empty vertical spaces between them, putting an invisible group in that space, and setting the group to collapse when invisible. That way the displayed page looks right, but the editor page has room for you to insert new elements without having to manually reposition all of the lower elements.