Hi, This is Kamil Tarczynski. I'd like to welcome you to another episode of our podcast. Today we are going to talk to each other about one of the most popular, if not the most popular tool for building web applications, which is Bubble.io, which we also use at Havenocode. We're going to talk to each other about what Bubble is in general, what it's used for, what disadvantages it has, what advantages it has, what you can build with it. Today I would like to tell you exactly about this tool and how you can use it. I think there is no point in dwelling on it any longer. Let's get started! Okay, so let's start with what Bubble is. Bubble is a nocode platform in theory that allows us to build web applications based on JavaScript. Why did I say it is a nocode platform in theory? Because, of course, it allows us to build very advanced applications without using even a single line of code. Yes, if we encounter some insurmountable barrier that Bubble won't allow us to break through with its native functionalities, we can add our own code there.
In addition, not only can we can add code on each of the individual pages we add to Bubble, but we can also write plugins for Bubble that are based on JavaScript.
This gives us really unlimited possibilities of what we can build in this platform. Bubble as a builder is, on the one hand, a platform that allows us to build simple applications very quickly, on the other hand, it also allows us to build very advanced applications. And what I would like to point out very strongly, this may sound very highbrow, but Bubble is a platform for very many people. Why? Because, on the one hand, the entry threshold is very low. If we want to build the simple applications I mentioned, some simple applications, for example. We will be able to do it without using code in a way that is 100% so understandable to us. Yes, on the other hand, Bubble is a mature enough platform because it's already 11 years old and has been developed all this time. In 2021, I think it got another $100 million in funding for further development. It's working very strongly, closely with Microsoft.
It allows us precisely because of its maturity, the fact that it has so many features, it has a very rich community that writes a multitude of plug-ins for it. We can also write these plug-ins ourselves.
It's because of this that we can also build really very complex platforms, high-performance platforms or scalable platforms. Babel as a platform is based entirely on AWS, and that means that underneath it stands somewhere and AWS and the whole infrastructure is AWS plus Postgres. When it comes to the database plus a few other services there to provide just that reliability scalability and security like Cloud, CloudFlare, Snow Flake and those kinds of other services. So, as you can see, Bubble is such a very broad platform that allows us just without using code to build web applications. And this is one very interesting thing because of the fact that, as I said, Bubble has a very, very large community, we can add our own code there. It's also through Bubble that we can build mobile applications. Of course, they won't be native mobile apps, because Bubble doesn't allow us to do that. Bubblle does not operate in any native language or native framework. They will simply be so-called PWA, or Progressive Web Application, which is simply responsive applications that will be adapted to mobile devices, which we can also put in a so-called wrapper.
Wrapper is such a special native application, inside of which there is a web view, or page view, under which we simply shoehorn just our mobile site, so we can add native functionality such as Face ID, GPS cameras, etc. And with that we can also put this app in stores like Google Play or AppStore. So as you can see Bubble is not a toy. Of course, with it we can learn how to program, we can learn how applications are created, how they function. We can also build these applications very complex. Well, and how does this Babel even work? If it is a nocode application, how does it work? Let's start by breaking it down into its constituent parts. Bubble as a platform offers us opportunities to build a frontend. Which we have already talked about more than once. What the frontend is also, is what our users see. What they interact with, as well as allowing us to build the backend, which is what happens on the server. We also have a database available there, of course, which we define for ourselves.
We have local, stats, option sets so called in the bubble.
This is something specific to Bubble no and workflows, which can be fired just either on the application side, that is on the frontend, or just on the server side. And of course we also have the possibility to build there api end points, which will be publicly available or not. So building an application obviously frontend. As I said before, we have this white sheet to which we move elements from our entire fixed our list of elements. Whether it's going to be some shapes, whether it's going to be some elements, whether it's going to be text, whether it's going to be groups, whether it's going to be lists, whatever else we put there on that page, we're going to be able to create our entire interface right there from that. We'll also be able to style it the way we want, of course, because Babel also allows any style of these elements, of course, in a certain way. And again, if we don't have something available natively, then we can add CSS to it, or whatever else will be behind the drawbacks of having animations or the appearance of these individual elements.
Well, and that's how Bubble generates for us this HTML, CSS or JS code which is therefore responsible for this front end? And on the backend, when we want to build some sort of backend, we also have a workflow view available, where we set up a workflow for ourselves that when some button has been, clicked or when something has happened in the application every 5 seconds or when the page has loaded or when some group or some element on the page is visible then what should happen and we do step one, two, three, four, five and so on and so forth.
Where with the help of these very steps we will build our workflow? Of course, I'm not going to go into great detail here, because today is not a training on bubble and how we should build in it, I just want to introduce you to this tool in this way and also is generated code. And here note Bubble as far as the backend is concerned moves in node, which is such a JavaScript framework that allows us to build the entire backend. Of course we don't see it. What code will be generated there? We don't have access to it in the case, as well as from bubble we won't be able to export this code of our application. This means that if we create ourselves this Bubble application and we have all these elements of the workflow side, the backend, the whole created, the databases, the structure of this application, etc. created then, unfortunately, we will not be able to export this code in any way Bubble is not a platform that earns de facto from hosting our applications.
And for this reason, it is not possible to export this particular code, because the rendering of this entire application that we will create in the editor is the responsibility of their engine, which is called their Secret Sauce.
So, as you can see, all these also elements are so tightly integrated with each other that, de facto, for the person who builds this application, it is very understandable. All these connections between database, front end, database, back end between workflows, frontend and backend. All these connections are very, very clear and clear to us. And here we also have a very high degree of freedom in terms of how our applications are going to be built, whether they're going to be single page Apps, whether they're going to be multi page Apps, whether they're going to be applications that are going to be dashboards, or CRMs, or whatever. On the other hand, what we can build, we'll get to that in a moment. Now, in the next part, I would like to discuss what de facto benefits this brings, what de facto Bubble has the biggest benefits and what we actually gain here if we want to use this tool. The biggest benefit of Bubble, of course, is that it is a very agile tool that very quickly allows us to build and pivot, solutions that we have thought of or that we want to build.
Thanks to this tool, we are really able to build the first versions of this product very quickly. Of course, it is known that the further we go into the forest, the more trees there are, so it is known that the further we go, the more complicated the creation of these apps will become. Another very advantage of Big Bubble is that we can build really powerful apps there. Really very complicated apps. We can build Bubble, because even if Bubble doesn't natively support something, whether we want to do some computation on Big Data, or implement some AI algorithm, ML, whatever comes to our mind, then of course Bubble natively doesn't have that functionality, but first of all we can provide that code. Of course, JavaScript is not suitable for AI anything like that, but we can also integrate it with other applications that provide APIs, so we will be able to leverage those Bubble functions and functions of our application we will be able to implement. We'll be able to implement GPT Chat and we'll be able to implement Google Analytics Revenue Cata.
Whatever we think we want to implement and whatever the API puts out, we'll be able to implement. If, for example, you will want to build in Bubble simply the frontend, because it will be faster the backend you have somewhere of your own then go ahead, it is as possible.
If you want to build only the backend, and use another tool for the frontend, because you feel proficient in it, for example, so you think it will be better? Go ahead, as much as possible is possible. There will be no problem with it. Another advantage over other nocode platforms is, of course, that we can add code. And here, of course, Bubble should perhaps be called more low-code than nocode, but we still have bet more heavily on code than on custom code And here, this custom code should still be dressed up in plugins or simply code snippets, rather than relying on the fact that we will be able to take every element apart and edit it. That's why I called this platform nocode, and lowcode. Although it is still possible to use our own code in Bubble. We have in Bubble available very advanced fiches like SQL, connectors natively available API, connectors, we have available just integrations with databases etc etc, thanks to which we can leverage the functionality of this platform and use it for what we want.
Bubble is also based and its frontend on CSS grid. And now it is being rewritten in fact all of Babel to use pure JS, so that it will simply be a much, much faster solution than it has been so far, although so far it has not lacked any performance either, and every day users will not see in any way that this application is limping along.
Is cutting Edge. Another advantage, of course, is that it is 100 percent cloud-based and we have a very clear, simple price list that tells us what we de facto get in it. That is to say, we can choose the right price list for ourselves and the moment our application we will also have users that here, unfortunately, this price list will no longer give. It is not that we just have this application will turn off, it will scale down and we will just stay. Alternatively, it will still be our decision, because the application will eventually get off at some point and will not be able to handle more users. Well, but we will have clarity and a clear understanding of why, when and where and what de facto uses those resources of our server that we need to go to that higher Bubble plan to go. Of course, these higher plans are followed by several other functionalities, such as more collaborators, applications or more opportunities to create more branching for applications. Because another big advantage, of course, is that we can create there branches of that application, that is, de facto we can create for ourselves a real professional application development environment, where we will have several developer branch, UAT branch and, of course, a live version of the application.
These are the main advantages of this platform, its maturity, the fact that it is agile and that it allows us to build solutions very quickly, to pivot them very quickly, to edit them, to change them, to adapt them de facto to what we want. It allows us to really build the applications that we dream of. There's a very small slice of applications that we won't be able to build there, or animations, or anything else. And of course it's adding code. So once we know what advantages we have of this platform, we'll talk about what disadvantages it has, because it certainly has some disadvantages too. And it's no different in this case either. The biggest disadvantage of this platform, looking from our European point of view, is that unfortunately, at this point Bubble does not offer regionalization. What does this mean? It means that any application we build in Bubble is hosted in the United States. Here, of course, we have to give a small asterisk, or rather, even two asterisks for the reason that, first of all, the lack of regionalization applies to standard plans.
By using a standard plan we cannot choose for ourselves the region in which our application will be hosted.
It will be hosted in the United States, while Bubble is working on this organization and is said to be available this year. For a great many customers, this is not an obstacle. All it takes is a proper privacy policy that properly informs the user and as much as possible such an application. We will also, from a European perspective, be able to build, launch and offer it to our Polish or European customers. There is not the slightest hindrance to that. The second asterisk is about how. Of course we are not allowed to regionalize these standard plans, yes we also have the so-called Enterprise plans on offer. And what does that de facto mean? These Enterprise plans allow us to deploy the bubble on our own cloud, which is located in AWS, or to choose for ourselves at least the region in which de facto this application is to be hosted. Of course, there we have a lot more options when it comes to these Enterprise plans, a lot more performance for a lot more users.
We have the ability to configure how this application will be, how the whole cloud will be configured for this application. But these are things that we always have to discuss and negotiate individually with Bubble every time.
About what exactly is to be found there. Another disadvantage of Bubble is de facto what I said before, that is, the inability to export code. Of course, there are unlikely to be many cases when we get to the point where we would have to export the code, because most often such a situation could happen when, okay, we've reached a million users, half a million users, and we would like to build a really cutting edge technology application. Then we would rather not export Bubble code either, but mostly such solutions are then written from scratch. Simply to adapt them under what we already know the whole architecture, under the technological requirements, requirements for the number of users, environmental requirements, etc. And not, however, to base it on old code, which was built a little bit with a different thought, with different senses, with different knowledge, in a different place and at a different time. So how of course this can be seen as a disadvantage, I would rather call it such a virtual disadvantage, which is unlikely to ever apply in 90 percent of cases, because first of all we will have to get to the point where there will be a need to rewrite such an application, and Bubble assures that it is quietly carrying half a million users on standard plans.
Of course, again here a little bit with a pinch of salt you have to look at it, because the app is unequal. And what does half a million users mean? Then, of course, we can also go to Enterprise plan we will be able to pull more. Whereas it all depends on what we really want to do and what we want to build. That's why I say for me a little bit of a virtual disadvantage. Well, and well, if we already know what Bubble is, how it works, what are its advantages, what are its disadvantages, then let's talk about what we can use this platform for. This platform is great for building all kinds of SaaS, or Software as a Service, applications. This is the standard type of application that all of you are more likely to associate with at this point, which is all types of social media like Facebook, LinkedIn, anything like CRM, Live Spaces, etc., ERP to manage our businesses, Jobboard to post job listings e-commerce to drive sales, Marketplace to allow sales to join two shopping sites.
Mobile apps like Tinder or Instagram. These types of things as much as possible we are able to build.
And de facto you can take a look at our study of the applications that we have already built. You will see right there the whole, the whole range of applications and the kind of applications that we have already built, so you will be able to see by examples. Bubble also on its pages shows examples of applications that we can build. And there are just there Duolingo type apps type Netflix type Facebook type LinkedIn type Pinterest type Instagram etc, etc. Of course, their primitive versions, because no one is likely to give us a whole tutorial on how to build a super advanced application that some company spent millions of dollars on. And of course, let's not kid ourselves that these will also be such advanced applications and work in the same way, but they will be really very advanced, complex applications and the ability to build them. So if you're thinking about wanting to build this kind of platform whether it's to sell something, whether it's to manage your customers, whether it's to build relationships with your customers, whether it's going to be e-commerce, CRM, ERP for resource management?
Or jobboard etc. These are all as possible. These will be great applications that will work in a great way.
And you can, as I said, check it out from several sources. Look for yourself also on your site on your blog, Bubble also boast about the applications that have been built using it. On the other hand, what should we not use it for? Well, rather, we won't be able to use Bubble to build, for example, banking applications, which is rather understandable wherever very strong restrictions are needed, such as, for example, HIPAA, i.e. certification apropos of the fact that medical data will be stored in an appropriate manner, that is acctually compliance in the United States, which is required. Bubble has no such certification. All applications that somewhere on the backend will have to process gigantic amounts of data, Bubble also with gigantic, the kind where we have several million records processed non-stop. On a day-to-day basis it is unlikely to cope, it is not a dedicated solution for this. Then we can build the frontend in Bubble, but the backend is much better built in Xano tool, which already handles such operations very well and does not have the slightest problem with them.
As in any case, of course, what we can or can't use it for is also a bit difficult to speak in such general terms, because rather we should always talk about it on examples, specific examples of specific applications, that is, look at what we de facto want to build.
What kind of platform it is, what kind of users will use it, to whom we will want to make it available, how it should be distributed, what kind of environmental requirements it has, what kind of legal requirements it has, and whether these things this platform is able to meet. If it is able to meet it as much as possible, then, of course, it is always worthwhile to seek appropriate consultation, ask someone experienced, juxtapose it with, for example, a company like ours. Can we de facto build such a platform, or is it worth using another toolset here? Will this platform be suitable for this? So as you can see in the summary, Bubble is a nocode platform that allows us to build web apps and PWA-type mobile apps. It allows us to build them without using code, but it also allows us to add that code. It's not a toy that's just for building very simple apps, it allows us to build very complex tools, very complex platforms that will be able to support tens, hundreds of thousands of users.
We also already know how it works, that it's obviously a drag and drop, WYSIWYG editor we have access there backend, database, frontend, that kind of thing, APIs etc.
We know what the advantages of this platform are, i.e. fast pivoting, fast building, the ability to add custom code, the ability to add very advanced features, the ability to integrate with so-called third parties, etc. We know what the disadvantages are, i.e. this alleged lack of regionalization, which of course we can solve ourselves with higher plans and which is not always a disadvantage either, by the way, or the inability to export code. Well, and we also know what we can use this platform for, and what we should rather not, and that it should always rather be consulted individually. That's it from me today. The episode today was shorter as I wanted to introduce you to one particular platform. I hope you found it an interesting. That's it from me. See you in the next episode. Cheers!
.svg)
.svg){kind=small}
