The market for no-code providers for web applications is highly competitive. It feels like new providers are entering the market every day, making the choice increasingly difficult. However, there is still too little happening in the European market in particular. This is why European start-ups and companies often turn to big names such as bubble.io to develop their own minimum viable products (MVP) and prototypes. However, this can be problematic in terms of the General Data Protection Regulation, as Bubble's servers (and therefore the user data) are located in the USA. But with WeWeb, there is now a serious European alternative to Bubble on the no-code market. In this detailed comparison, you can find out how well WeWeb compares to Bubble and why we are already using the newcomer in some of our projects.
Bubble is one of the most successful and widely used no-code web app builder tools. Since its launch in 2013, a great community has developed around the US provider and the tool is now so comprehensive that it can be used to implement almost any application. In recent years, Bubble has raised more than 100 million US dollars in funding - another sign of the strong interest of investors in modern technology and the future role of no-code in companies.
"Build production-grade apps 10x faster" is the headline on WeWeb's homepage. The tool is still relatively new on the market compared to Bubble. The no-code front-end builder was founded in Paris in 2017 and, as a European company, is potentially more interesting for European customers. Meanwhile, WeWeb also has strong financial backers in the background - even if not yet to the same extent as Bubble. The range of functions is very similar to that of Bubble, but there are key differences, which we will discuss below.
The biggest difference between the two no-code providers lies in the provision of development levels. While Bubble allows users to develop user interfaces, workflows and databases for apps, WeWeb completely eliminates the database. This means that WeWeb always requires an external back-end to store your app's data. This can be your own SQL databases, such as MySQL, or back-end providers such as Firebase, Supabase or Xano. What sounds like a major disadvantage at first is normality in conventional software development. There, front-end and back-end technologies are always separate. Admittedly, Bubble is one step ahead in this respect, as projects can be implemented more quickly thanks to the existing internal database - because there is no need to connect external services. However, we will see in the scalability section that external back-end technologies have some advantages.
No-code tools stand for easy accessibility compared to conventional software development. However, it has to be said that the more extensive the functionality of the tool, the higher the learning curve. This may sound good, but it means a laborious entry and ascent, especially at the beginning of the journey.
So which of the two tools performs better in terms of user-friendliness? There is no general answer to this question, as the answer depends heavily on the user's level of experience.
What we can say from our experience, however, is that the user interface in Bubble feels much more cumbersome than that of WeWeb. It feels a little rough, less intuitive and unnecessarily complicated. But once you've got to grips with it, every click is easier and the possibilities seem endless.
This is roughly how we would visualize the learning curve for Bubble. So you shouldn't give up too soon. (Credits: VisualizeValue).
Even if getting started with Bubble takes some getting used to, an attempt has been made to greatly simplify technical terms in order to make the material more accessible, especially for newbies. For example, Bubble uses the word "Thing" for data entries. A no-go from a classic development perspective. But someone who has never had anything to do with software development will be able to relate more quickly to "Thing" as a term for a data entry than, for example, Data Entry. On the other hand, however, this tends to mean that people with development experience are unable to transfer the terminology one-to-one and that terms can sometimes be misleading.
The interface of WeWeb is more beginner-friendly compared to Bubble. It is very similar to other no-code apps such as Flutterflow or website builders such as Webflow. Everything looks tidy, clean and structured. However, one small thing that currently still greatly reduces productivity in WeWeb is the lack of a context menu when right-clicking. In Bubble, on the other hand, you can find various functions here, for example to copy, group or delete elements or settings. This function is currently still sorely lacking in WeWeb.
Workflows represent the back-end logic of an app. Alongside the design editor and the database, workflows are the third important component of Bubble. However, Bubble also leaves a lot to be desired in terms of workflow editor design. Light gray squares on a white background are not exactly evidence of sophisticated UI/UX design. Nevertheless - or perhaps precisely because of this - the structure of the workflows in Bubble is quite simple. Workflows always start with an event and always work according to the if-this-then-that principle. If (event A) happens, (event B) should occur. A trigger event is usually followed by a series of further events. For example: When the user has logged in, send the user to the homepage.
These can be expanded in any number of complex ways. Bubble's full power is evident in the possibilities and workflows. There is virtually nothing that cannot be represented with Bubble in terms of back-end logic. The only obstacle to unleashing this power lies in understanding the type of expressions in Bubble. However, Bubble supports this by immediately recognizing when there are errors in expressions or workflows. They have also recently updated their expression editor to more clearly distinguish between the individual components of expressions.
This is where WeWeb scores again in terms of user-friendliness. Workflows are not in a separate tab, but can be opened directly from the editor. In WeWeb, you can also see which elements have an associated workflow in the element navigator (what the element tree is in Bubble). With Bubble, you can only see this when you click on a corresponding element.
Workflows in WeWeb also have an advantage over bubbles in that they can have multiple branches. For example, a workflow can separate after a true/false condition. You can also define "On error" branches. These are workflows that run when errors occur. Such features are reminiscent of Zapier or Make editors. They are contemporary and make everything even more comprehensible and clearer. WeWeb workflows can also incorporate loops, something that is possible with Bubble but much more cumbersome.
Everyone makes mistakes - whether in traditional code or in no-code development. However, a major advantage of no-code development is that it makes debugging quite easy. Debugging is the process of solving errors in the app.
With Bubble, you can't even get the app to work if there are clear errors. The issue tracker helps with this. This shows all open errors before they become a bug in the app. However, some errors are not of a technical nature per se, but rather, for example, a logic error such as an incorrect variable or missing input. Bubble has a debugger to detect such errors. You can run it in the web browser parallel to the app and see step by step what is happening in the workflows. This makes it easier to understand why certain things happen the way they do.
At this point in time (December 2023), WeWeb does not have a visual debugger like Bubble does and, unlike many other features, this has not yet been announced for 2024. Nevertheless, you can debug workflows with WeWeb. You can follow the progress of these on the left-hand side (Logs) and see what happens in which steps. You can also click on "Test" for each action and only run this individual step. Then you can also visually see which path has been run, for example.
Unlike WeWeb, Bubble comes with its own database out of the box. This increases the speed of projects on two levels. Firstly, no complicated external database needs to be connected. Secondly, it can be assumed that the performance of the app benefits from the fact that API requests do not have to be constantly sent back and forth to an external database. In addition, Bubble's own database is very simple and easy to understand even for people without SQL experience. The creation of tables (called "Data Types" in Bubble) and data entries (called "Entries" in Bubble) in the respective tables is quick. And the relationships between the tables - something that is a science in itself - are also quickly understood with Bubble. Instead of cross-tables and n:n relationships, Bubble uses the term "list of" and allows you to maintain an SQL database without cross-tables. However, it is unclear how this affects the performance of the app with very large numbers of entries.
It is therefore often better to use an external database. This is something that is possible with Bubble and necessary with WeWeb. What at first sounds like a disadvantage for WeWeb is, on the contrary, actually a strength. WeWeb has saved itself a lot of work by providing native integrations to some of the best databases. The advantage of this is that the connections provided are easier to handle for no-coders. With Bubble, on the other hand, you either have to use plug-ins or even set up your own API connections to the database providers. WeWeb apps therefore benefit from the specialization of the database providers in terms of performance and scalability.
If you want to extend your app with functions that a no-code builder does not offer, it is often necessary to incorporate custom code. These are snippets of code, often HTML, CSS, JavaScript or similar, that enhance your app - visually or functionally. Both Bubble and WeWeb allow the use of custom code. However, WeWeb makes this process easier for you. If you want to insert custom code into the global header or body script in Bubble, you have to do this in the settings. Curiously, this can be found under the SEO settings. For individual subpages or elements, you can insert custom HTML code at the end of the corresponding property editor.
WeWeb offers the option of working with custom code in many more places, including directly in workflows or elements. WeWeb also allows you to define your own functions, which you can later call up and reuse in workflows, for example. This means that you write code once (e.g. in JavaScript), save it as a function and can use it again and again throughout the app. You can even make use of an AI assistant that helps you to write or configure exactly what you need. Bubble has announced its AI assistant for 2024. So we remain excited!
At the moment, neither Bubble nor WeWeb allow you to build native mobile apps.
However, Bubble supports the optimization of web apps for mobile. Bubble also offers third-party plug-ins that convert a classic Bubble app into a progressive web app - a form of mobile app that can be made available via a link rather than via the app stores. The web app builders Glide and Softr provide such links out of the box. There are also so-called "wrappers" that can convert your Bubble app into a native mobile app so that you can publish it in the App Store or Google Play Store. However, Bubble has announced that it will support mobile app development in 2024.
WeWeb offers an in-house option to provide web apps as PWAs. However, WeWeb has also announced that it will enable the development of native mobile apps in 2024. This will give Flutterflow, Adalo and co. a lot of competition!
Developers who want to increase their productivity traditionally rely on the reusability of components. The same principle applies to no-code. Build something once that can be reused several times via the same app. Bubble provides all the central functions here: Style classes, component library, custom events and reusable elements. However, we still have to make compromises here and there.
WeWeb has recently followed suit in this respect and published or improved two new functions that simplify the reusability of elements.
Style classes describe styles that can be defined for buttons, text elements and groups (div containers in WeWeb). CSS (Cascading Styling Sheet), i.e. a display language, is responsible for this in the background. This allows every external property of an element to be changed. However, instead of having to write source code, Bubble provides a selection of defined attributes that can be easily configured in the user interface. These include background color, font, font size or color and a few others depending on the element type. If I set up a style class for a button, for example, I can configure it once and apply it to any number of buttons in my app with just a few clicks. Adjustments therefore only need to be made in one place. In the style tab of the bubble interface, I can manage all classes in one central location. One disadvantage of style classes in Bubble is that you are limited to the attributes defined by Bubble. If I want to change a property of an element that is not listed in Bubble, I cannot add it independently, but have to integrate it using custom code that I have written myself. Fortunately, CSS is easy to read and simple to understand, so it's not that difficult to get started here.
WeWeb's version is also easy to use. The settings can be made and saved via a visual interface. With WeWeb, the style tab is very reminiscent of the structure of CSS code. The terms are also those of CSS. This is not the case with Bubble. The advantage here is that people with CSS experience can find their way around WeWeb more easily. Previously, you could only define typography and colors in the UI library. Now you can also define spacings and classes. The special thing about this update is that you can share these elements across different projects. For example, developers can easily copy entire corporate identities into a new project or simply transfer individual elements that they liked in old projects to new ones.
These are ready-made sections such as login or registration screens, navigation menus or tables that can be added to your own app with a single click and customized. Both apps provide a selection of pre-built components right from the start. With Bubble, however, you are limited exclusively to the components provided and the selection is still very sparse at the moment (November 2023). In the future, it is planned that both custom components and components from the community can be added. In the WeWeb UI Library, on the other hand, you can already add your own components at this time.
Reusable elements, or reusable components, are specially developed modules that can be managed centrally and installed anywhere in the app. These building blocks are perfect for efficient construction with low maintenance. Bubble masters this function very well and has made further improvements with the latest product updates. This allows you to convert any section, container or similar into a reusable element so that it can be used anywhere. The latest additions are parameters (so-called properties) that can be transferred to such an element so that they can also receive and process data from different areas. A reusable element can, for example, be a table that you use on different pages. One and the same table can be visible in the admin area and in the user front-end. But thanks to the reusable elements, you don't have to build it twice. And if you want to change something in both tables later, you only have to do this in one place.
WeWeb has finally covered this feature since December 2023. These can also be found in the UI Library, where they can be managed and customized centrally. These components can also be created in a project and then shared across multiple projects. This feature has been long awaited and will make working with WeWeb even better and more scalable.
"Can I get the code that was written in the background when building my app downloaded from Bubble?" This is a common question we receive and the simple answer is unfortunately no. In Bubble, it is not possible to export the code behind the developed app. This results in a so-called vendor lock-in effect, as the app is tied to the provider. You have to weigh up the risks involved and what you want to achieve by developing in Bubble.
WeWeb, on the other hand, has a code export function that allows developers to export all HTML, CSS and JavaScript code and use it in their own environment. The end product is a vue.js app, a JavaScript web framework for creating single-page web applications.
"Is no-code even suitable for scaling?" This is another common question that we are increasingly able to answer with "yes". However, it always depends on the individual use case. Is it about simultaneous user sessions that can be served by the platform? Is it about the storage and processing of data records in the back-end? Is it about data volumes that are transferred via interfaces?
The fact is, platforms like Bubble or WeWeb can handle several thousand user sessions taking place at the same time. Ultimately, these technologies run on Amazon Web Services, where resources can be added as needed.
In classic development, several developers work together by working in their own branches of the code ("branching"). The whole thing is cross-checked with version control systems and merged ("merging"). Bubble works in a similar way. Collaborators (as they are called in Bubble) can work on an app at the same time. Branches can also be used from the $119/month plan. However, two developers cannot work on the same page of an app at the same time.
WeWeb, on the other hand, recently released a revolutionary feature. Similar to tools like Miro or Figma, the WeWeb Editor allows you to see in real time where the collaborating developers are located so that you can work on the same page at the same time. This is where Bubble has to catch up.
First of all: We cannot and must not make any binding statements here because we are neither authorized nor in a position to make a professional assessment. In this case, please contact a legal expert. The following information is purely for classification purposes, but does not provide any information as to whether an application actually meets the requirements of the GDPR.
Data protection rules can be set up both in the bubble database and in most external back-end tools (WeWeb) to ensure that users only see the information that they are authorized to see. It is important to make this data inaccessible to unauthorized persons at database level and not to filter or hide it in the front-end. Here there would always be the possibility of gaining access to the data, as it has already been downloaded by the browser in the background.
Another issue is the transfer of data to third countries, e.g. the USA. As both tool providers use the infrastructure of Amazon Web Services (US region) to provide their platforms, you already provide the providers with personal data in the form of your own IP address when you access the apps developed with them in the browser. Since, in the case of Bubble, the database for the app also runs via AWS, all other personal data that you enter when using the app (e.g. email address for login) is inevitably processed on a US server. One way to prevent this (at least somewhat) would be to have Bubble provide you with your own Bubble server instance on a European server. Unfortunately, this is very expensive (from 3,000 US dollars per month). Another option is to use an external back-end for Bubble, such as Xano. It is important to note here that the data transfer takes place via non-server-side API calls. This happens when you use Bubble's own API connector. In this case, the data is sent from Bubble and thus runs via Bubble's own proxy server to the back-end. To set up client-side API calls, in which the data is sent directly from the user's browser to the back-end, you can either integrate your own JavaScript code or use a suitable plugin (e.g. Xano Connector Plugin).
On the other hand, WeWeb offers client-side API calls by default via the back-end integrations provided. This means that no further configuration is required.
No matter how great the features, they are of little use if the costs of the tools go beyond what is financially feasible. It is therefore important to look at the cost structure or pricing model of the tool in question as early as possible.
Bubble offers five different pricing levels, from free to $349 per month, as well as an Enterprise version with no fixed price. The features are linked to the pricing plan. The free plan allows you to build unlimited apps, but you can only publish them from the first paid plan. Some features such as recurring workflows or two-factor authentication are also only available with the paid plans. With Bubble, there is another relevant component to the classic tiered pricing model, namely usage-based pricing. Usage-based pricing is more or less like a taximeter - the more you drive (use), the more you pay. At Bubble, the relevant unit is called "workload units" (WLUs). Each monthly subscription includes a number of WLUs. If these are exceeded, you have to pay extra. Unfortunately, Bubble is not very transparent about how WLUs are calculated - let alone how you can reduce them in your own app.
We have recorded a whole podcast episode on Bubble's new pricing. Listen to it here.
WeWeb's pricing is similar to that of Bubble. There is a free version, but this does not allow the app to go live. With the paid plans, which are priced at $39 and $149 per month, there are additional features such as custom domains, unlimited plug-ins and more in addition to the live app. WeWeb even has two usage-based pricing features: monthly app visits and GB data storage. The storage limit is standard and easy to control thanks to the transparency. The monthly app visits, on the other hand, cannot always be clearly influenced. Compared to Bubble's WLU, however, monthly app visits are at least clearly traceable.
However, there is another catch with WeWeb's pricing: the external back-end. Because you have to use an external database, you have to factor in the monthly costs of Xano, Airtable and the like. In total, the whole thing can therefore be several times more expensive than Bubble.
The wish list for features for Bubble and WeWeb is long. Both in community forums and on X/Twitter, there are always requests for new features. And thanks to increasing competition on the no-code market, the pressure is great. And that's why you have to give both providers credit for delivering. Updates and announcements with new and future features are constantly being released. As of December 2023, WeWeb's roadmap for 2024 looks like this:
But Bubble will also be stepping up its game. Bubble has announced that it will allow native mobile app development and AI-supported development in the future. Other announcements for 2024 may sound less significant to those not familiar with Bubble, but will make working with Bubble a lot easier. These include the launch of a new expression editor and the ability to perform data operations in bulk. Bubble is thus taking an important step towards ensuring the scalability of no-code apps.
So which horse should you bet on for your next no-code project? Of course, it depends on what you want from the tool. There is no clear winner as the "best no-code tool for web apps". Our conclusion is as follows:
Bubble is a pioneer in the no-code space and scores particularly well when it comes to the combination of front-end and back-end. This allows anyone to set up and test projects quickly without having to worry about which back-end is the right one or what to look out for in the first place. Bubble also has a huge community that not only responds quickly to questions, but also creates templates and plug-ins. This makes Bubble Stand more expandable than WeWeb. Due to this and the nature of the expressions and logic, Bubble is more suitable for inexperienced developers - even if it is still a relatively difficult no-code tool to learn.
WeWeb, on the other hand, is more for developers who want to write less code than for non-developers who want to build something. We wouldn't categorize WeWeb as a low-code tool yet, but it's definitely closer to that category than Bubble. In our experience, WeWeb's strengths are the editor, the easier self-hosting option and the ability to export code. In addition, the separation of front-end and back-end - although more expensive and possibly more complex - is a good basis for scalability.
If there are no clear K.O. criteria for your case, such as code export, then the only option is to play around with both tools and see which one suits you better as a no-code developer.
We at VisualMakers work with both Bubble (+ Xano) and WeWeb (+ Xano) and are fans. So if you have any questions about your project, feel free to write to us! Come to our Slack Community. There are over 750 other no-code enthusiasts waiting for you and your questions.
