I have just tested and evaluated Bubble.is by building a social network app.
I started with zero knowledge about the platform/service, but I have been creating both desktop and mobile front and backends for a long time coded with Javascript, Java, Objective-C, .NET, PHP, R, Python, ColdFusion, JSON, etc.
In the past, I have used both small websites hosting companies and IaaS, PaaS and BaaS such as Google Apps, Jelastic, Parse, Stackmob, Cloudbees, Stamplay, IBM BlueMix, RedHat OpenShift, AWS EC2, AWS AppSync with GraphQL, AWS Lambda and AWS API Gateway and Adobe Business Catalyst, etc, so I thought this would be no problem.
I built my app with a mobile-first design approach for the web. With my laking understanding of the platform, I decided to keep it clean and uncluttered, by making one page for each use case, which wasnât that easy to achieve.
After one week of intensive development I ended up with nine pages:
- A login/register page.
- A page where the user could configure settings and profile.
- A front page flow where user-created events and flash-ads will scroll by or pop up (pop-ups could be viewed and then dismissed), sorted by a ranking algorithm.
- A drill-down page from the front page flow, where visitors could learn more about the event and post comments, share it and like it.
- A page where the user could post events, including a camera photo or video.
- User profile page with a list of the userâs activities and a basic biography.
- A drill-down page from each of the userâs events where the user could edit or delete a specific event.
- A leaderboard (top ten), with a top list of contributors sorted by weight created by a magic algorithm.
- An admin page where the admin could add things to the backend such as new event types.
Pros
-
You can have a team of non-programmers developing in parallel.
-
You get immediately rewarded if you succeed with your struggle to make it work (?).
-
You get feedback on the webpage and can step through the workflow. Compare that to debugging R code inside a Python function in an AWS Lambda function.
-
Some of the hard parts is taken care of such as auto binding, user authentication, and authorization flow.
-
The thing metaphor is both a blessing and a curse. You can quickly build a new thing from anywhere on your dashboard even when you shouldnât, but on the other hand, you donât have to make resolvers in YAML or GraphQL templates or rebuild the DynamoDB database.
-
You donât have to deal with promises, callbacks, asynchronous- or higher order component functions.
-
You can use ready-made plugins (if you can understand how they are intended to work).
-
No backend to backup, patch or upgrade (thatâs true for other PaaS also such as Lambda and BlueMix).
-
No dependency hell. You donât have to manage NPM, PIP, APT packages that depend on another package that depends on another package, that after a while will have bugs and be depreciated and brake your Serverless backend.
-
You donât have to code for both the client and server as you have to do with a React.js or Angular solution.
-
Scalability. Is it scalable? Probably - if you fork out cash, optimize workflows, minimize the number of groups on a page, delete unused plugins and maybe add Cloudflare (but itâs probably edge cached with AWS anyway).
As far as I know, Node.js and Progress DB is used on AWS and also Cognito (probably the reason why sometimes users email is already taken), possibly even Lambda for background workflows and some session cache solution such as REDIS key store and fast NGINX front end so the backend is as fast as it can be for a traditional server stack.
Cons
-
Everything is hidden. You donât have a good overview of the workflow, and itâs hidden content. Usually when you code you have its source visible in your editor and can follow your workflow and see what you have done and then iterate and test based on it.
-
With a zero-code approach, the only way to document or keep an overview of what you are currently doing is to take a screenshot or a video (!!).
-
No code insights or IntelliSense. Usually, when you develop, you have help related to the context of the function. Instead, here you have a long drop-down with everything including junk from the different plugins. Itâs very easy to end up in a meaningless loop of frustrating efforts to make it work, and the help tooltip is always in the way when you want to delete something.
-
Lost of repetitive micro-actions is needed to build the most simple functions or layouts even if you group and reuse content, although itâs good that you can copy and paste workflows and also part of workflows. It seems to follow an anti-DRY mantra. If you code, you usually make a template for the static part of the site and then you donât have to touch it.
-
Auto binding is lovely until it bites you in the back when you try to use objects relating to other objects in a search query, then you have to use advanced filters or good beware put lists in a database field (which I have managed to avoid). A simple search query: Eventâs typeofthing is not âthisâ is no problem but trying to exclude things from a search query based on another related thing is almost impossible.
-
You donât know if your search will work even if it marked green and you canât do a quick test query in a terminal.
-
Most plugins have inadequate or nonexistent documentation.
-
The contextual help is too general to be of any real help.
-
Long boring videos of the most trivial concepts that you canât bother to watch.
-
It feels as if you do things backward and are using anti-patterns. The most obvious design patterns arenât so obvious when you try to zero-code it.
Whatâs the verdict?
Was it a slow process to zero-code? No, probably I couldnât build it faster with any other platform or tools.
Was it a smooth and non-frustrating experience? Nope, it was incredibly frustrating. Itâs still programming but visual, and it sometimes makes it more difficult. You have to do things in a specific order, but you donât have enough visual clues to follow that order. The time sinks are in different places than you are used to, it reminds me of Adobe BC, Stamplay or some old virtual reality development platform.
Initially, I had a floating top bar and a floating menu bar at the bottom like Instagrams mobile app, but it was not practical to have, both regarding development and mobile design aspects. I only found a floating slide-in menu to be practical. The repeating group is useful, but it has some strange issues, for example, the index does not work if you only show one cell.
Overall I think the Bubble team has made a tremendous effort to make it into a useful product, and I know how hard it is to create frontends.
). In other words, there were many times Bubble worked seamlessly for me when I know I would have encountered more problems coding (for instance, my credit card processing system was set up almost instantaneously and integrated with a complex free trial system that I created in a day). Also, most problems that seemed âintractableâ at first were really due to me not thinking properly about the problem.