Thoughts on a this up and coming NoCode solution?

Questions
1

Hi Bubblers,

I’m curious to know if anyone has used WeWeb.io , seems a bit wrong to be talking about a potential competitor, but I figured Bubble ought to know about what they’d be competing against.

From the outlook, what WeWeb sells is fairly attractive looking, option to export code, it looks more easily scalable since it’s primarily a front-end no-code builder. But paired with Xano, it looks to be a fairly competent solution. I’m not certain, but there’s talks of it having offline-mode capabilities. Whereas with Bubble we seem to be stuck with the pseudo-offline(Was online, don’t close the browser, went offline) The builder itself makes Bubble’s looks a bit outdated (Though I can’t speak for the capabilities of it quite yet). It’s popularity seems to be rather small as it’s pretty hard to find any information on it. But it’s overall road-map and proposed platform seem interesting.

If anyone has any experience about the advantages of Bubble over WeWeb or vice versa, it’d be welcome.

Outright, one of the main advantages I’d say Bubble has is the plugins and community…but for now…

Thoughts?

2

It doesn’t have its own database. That’s how Bubble has a “language” (the expression builder). Now, there are aspects of Things that are dumb/needlessly-limited (e.g., there is literally no way to proxy a Thing in the front-end), it looks like WeWeb is just a front end builder with an API-connector-like feature.

The power of Bubble is the expression builder, which is why I’m constantly hounding @Bubble to complete its missing features. (I’m being somewhat flippant here, but this is the one thing that sticks out in a back of napkin comparison.)

If one were building Bubble today, one might build the front-end with such features and then model the backend on that (and one would in fact land on a backend that looks exactly like the Bubble database). But that’s how time time goes: only forward.

The WeWeb folks also aren’t particularly detail oriented. Note the title on the second link you posted. Doesn’t bode well.

7 Likes
3

Oh, i actually linked the wrong, URL, for whatever reason they have an article that compares Webflow vs Bubble AND also WeWeb vs Bubble

Correct one.

Anyhow, from what I thought I perused, yes, WeWeb only handles the the no-code frontend. But it does have some version of simplicity of expressions after-the-fact of building out your backend with a no-code backend builder like xano or other options.

But admittedly, I haven’t tested it out yet, I’ll get around to it and report back. But from the EXTREMELY sparse info about WeWeb vs Bubble, apparently there’s a few supposed expert bubbler that even recommend or enjoy WeWeb more.

4

I think that @dorilama has some experience with WeWeb and might have some insights here, particularly with respect to “plugins”/extensibility…

5

I actually enjoy it, and also other new platforms like flutterflow toddle and noodl. Each one of them has nice things to have.
Like Keith says the power of bubble comes from being a complete bundle of things you need, with the other new tools you need to pair a couple of services. It can be a good thing or a bad thing, it depends mostly on your preference. Maybe flutterflow with its integration with firebase comes closer to what bubble offers.

5 Likes
6

Thanks for your input @dorilama. Would you be able to share some of your experience on what each builder is generally geared more towards? I’ve been delving into Bubble for the past 4 months. and I remember choosing Bubble over Flutterflow after intensive research, but honestly can’t remember why anymore…Never heard of the other two mentioned.

I’ve actually made some decent progress on a web app building with bubble. (It’s a business management/hr/accounting/training app for internal usage across my company’s restaurants) I’m finding global variables a bit cumbersome to deal with Bubble. Another thing my company will be working on is a customized POS system (yes, we know there’s a great many POS systems out there, but its a POS system outside of the US market and will be geared towards Mexico’s competition).

7

Absolutely not wrong at all :slight_smile: (there is the new ARTICLE thread category too for things like this).

Was very impressed with WeWeb. It is quite Bubble like in the way it does things, so maybe that was just because I felt at home. API Connector is very nice.

However, I hear of initial teething troubles with some of the more complex functionality. Which is, of course, entirely to be expected. People have not really stretched it yet, like they have with Bubble. The downside of that is that quite a bit of Bubble now looks and feels quite old.

@keith makes an important point, though, Bubble’s database is so tightly integrated it just fits into the Expression Builder.

It will be interesting to see how more complex databases work with WeWeb. Because if you can screw something up with your database in Bubble then you can screw it up to the same (or more) extent in Xano, mySQL, Firebase, Mongo whatever. I guess there is a question of what is more tolerant of a messy database.

4 Likes
8

The obvious difference is with flutterflow that is oriented mostly on building android/ios app.
The other tools are actually more flexible , expressive and customizable. While in bubble everyone is dreaming about returning values from custom events, in the other tools you have that, plus real control flow. But, again, you need to pair them with other tools/services to get the other features included with bubble.

I think the debate around what nocode tool to use is similar to the debate around what programming language should you use to build your product.
The answer is probably whatever you know and feel comfortable with. Any tool has quirks and needs workarounds at some point.

4 Likes
9

…is how quickly you need to grab some code. For example you can’t do a Webhook without code.

That for me is the main differentiation for me. Bubble’s need for code is quite far in the distance, here you seem to need code quite soon.

3 Likes
10

There are tons of these things coming to the party now and one or two even look pretty promising (Toddle being one). But Bubble has such a lead on them in terms of features and capabilities and just all round completeness, not to mention that it’s thoroughly battle-tested and market proven. I saw one the other day (which shall rename nameless) that only started development 9 months ago, has just got a pre-seed round, is still in alpha/beta but they have an “Us Vs Bubble” page on their web site giving you a list of how their product is better :rofl: Give me a break! I mean it looks promising but they’ve got a long long way to go. Although a fairly well-known member of the Bubble community tweeted that they had switched to it (calling Bubble “a limited traditional no-code tool”. Again :rofl: )

The big thing all of these new tools are hitting on is that they generate code. As a coder and software developer for a more than a couple of decades I have to say IMHO this is a red herring. I just don’t care! Having all the business value of your app tied up in code that becomes legacy every 4-6 years is not a great model. It’s best to have it tied up in meta-data in a development platform like Bubble where someone else is responsible for keeping it technologically relevant and you’re responsible for providing and enhancing the business value. I know all of the arguments, vendor lock-in etc but you’re always going to be locked into something. I’ve got the code from apps I wrote in the mid-90s and the 00s and it’s useless because it’s locked into some antiquated development toolkit or language. And what if you’re not a coder, how can having the code be of any use or value to you without it costing an arm and a leg?

Flutterflow looks interesting but it’s got it’s flaws and it’s one of those harping on about generating code. Even worse is the code it generates is Dart, not Javascript or anything else mainstream. Good luck with that one.

I will say that Bubble has to keep innovating and being attractive to newcomers and especially developers/coders like myself coming to the No-Code space. They have a huge advantage presently but it could be eaten away if they’re not right on their game and their heels could be getting pretty hot sooner than they think.

Nigel is bob-on, I am still amazed at just how far down the line I can get without touching code in Bubble with the ability to add in code when needed so there’s no real cliff-edge. Although returning values from custom workflows, objects in memory without a created data Thing (as Keith alluded to), variables in back-end workflows etc etc etc would all be very welcome too :crossed_fingers:

3 Likes
11

Well, that’s how Flutter manages to deploy on multiple platforms. Flutterflow is build on top of Flutter so… :man_shrugging:

12

Yup and that’s how Google finally found a use for Dart. Goodness knows how many ways they’ve tried to foister that thing on developers over the years and found that no-one actually gave zwei scheiße about it :wink:

13

There is plenty of developers using dart. Apparently more that swift.

1 Like
14

Maybe, but that’s only since the advent of Flutter I would suspect, before that it was very niche despite Google’s best effort.

Again my point is about the illusion that code avoids lock-in. It doesn’t. The code you churn out from Flutterflow is tied to the Flutter framework and the Dart language, it’s useless outside of that. And that’s not just in relation to Flutterflow, it’s everything, you’re always locked into something. Code or No-Code, you’re tied in. I’d rather be tied-in to something that keeps my app relevant despite the underlying technology changes.

As a developer who is long in the tooth, I’ve written apps for text-based DOS, Windows, JS3, Flash/Flex and JS5 and HTML5. All of those apps had the business value held in 10s or 100s of thousands of lines of code and tied to a technology and when that technology shifted to make that code legacy, the business value was also lost. So having something churn out code is not the saving grace they say it is. Yes, there are viable counter-arguments to this, I respect them but for me they’re not overriding.

Also as a developer, it would be a nightmare to have 10s or 100s of thousands of lines of auto or AI generated code, that I had no hand in writing, that I now suddenly have to maintain because someone no longer wanted to be locked-in to a no-code platform and now iteration of the app slows to a snails pace and then suddenly , lo and behold !, Google now decide that the main language for Flutter is … drumroll … Kotlin! Now you’re up a particular creek without the necessary manual propulsion tool (they did that on Android btw, from Java to Kotlin, Apple switched from Objective C to Swift, so it’s not beyond the realms of possibility). Bubble switch from Node to say Dino or Python or .NET core or Go or anything else that emerges in the future and takes their fancy, it effects me not. It’s a beautiful thing :grinning:

Flutterflow looks good but I would stick to using it as a no-code development tool and don’t get sucked into the “it generates code” hype. If it all goes belly-up you can pick up another no-code tool and re-develop it in a matter of weeks or months. If it’s in code, it’s months or years. Give me no-code everytime.

Just my two pence/cents from long experience anyways.

5 Likes
15

I was just saying that dart is not a niche language like you suggested.
I do agree that the main values of these tools is not code export.

1 Like
16

I agree that it’s no longer a niche language and my point re Dart was that it’s now only popular because of Flutter and that Google have finally found a place for it where it has gained traction. Prior to Flutter, Google tried their very best to fit it in everywhere they could but no-one was interested outside of very select niches. I was around when they were trying everything to get people to adopt it and failed miserably. One of the most amusing things I’ve seen is the creator of the Dart language talking with the creator of Typescript, probably over 10 years ago. Both are Danish and the Dart guy was so obviously breaking his heart that Typescript had exploded but he couldn’t get this language to have any level of appeal despite the backing of Google.

So yes, we can agree that now, Dart is a popular language, although outside of Flutter, I still maintain you’ll find that Dart is not widely used.

17

Thank you all for your input, it’s well received and useful. I suppose when looking at other no-code builder’s editor. The 'shiny’ness of it all really did attract me. When you I look back at Bubble, it definitely does ‘look’ old. But I haven’t actually had much issues understanding or using its editor.

I agree, code export is a tad bit of a over-used reason to excited about.
I think the comfort of having the ‘option’ albeit even if it provides bad results makes people feel safe. But primarily…my reason is that, I can self-host and scale more easily. But of course that’s a matter of if my ‘dreams’ come true. That’s why I keep hearing Bubble is a great MVP(Which based on my experience does seem to be true), but not necessarily that ‘scalable’. But as these no-code platforms keep improving and improving. One does get tempted when a no-code solution can say they will be both your MVP and your future scalable ready platform.

The two shiny’s I’m most caught by is WeWeb and FlutterFlow.

Flutterflow even more now, considering that it’s being a little more marketed as a web app maker with it’s later version, it again add’s shiny-ness by talking about AI generation, which given by the progression of it, will undoubtedly become a useful tool through time and will likely provide good code as well. All of which makes it look like a lot of money, and time is being spent to improve flutter flow. Where as for my past months on Bubble, it ‘feels’ like it’s playing catchup and just kind of strolling and trying to get itself more stable and efficient. Whether that’s more positive than negative, I suppose is up to the user.

My main things wanting from Bubble will always be offline-mode and I doubt that’s on the roadmap.

The only one to have an edge over that would be Flutterflow.

My other minor gripes, which could just show my inexperience is that customizable components aren’t a thing yet with bubble. Reusable elements is not the same. It’d be similar to Bubble’s new intro of ‘Element Templates’. Moving data around from reusable elements to element is doable but cumbersome. Oh and workflow management and organization doesn’t feel that efficient.

1 Like
18

I’d agree with you on the components front. Reusables are great but if they were just a little bit more “componentised” it would be more in line with proper development methodologies.

I think the issue of whether Bubble is scalable or not is more about the back-end and the database, which neither WeWeb or FlutterFlow include anyway. Since I first looked at Bubble 3 and a half years ago, the improvements in speed and scalability are incredible and I think this widely-held myth that it’s not scalable belongs to the past. I suppose once something has got a reputation then it’s difficult to change even when it’s no longer true.

I do agree, that a revamp of the UI in Bubble would help a lot, compared to the newer tools which have slick and modern UIs, it is looking old. They were close to releasing an update a couple of years ago but postponed it in favour of more important issues such as the responsive engine which is now standardised in Bubble.

I don’t think they’re strolling, although it can feel like that, I think it’s more about growing pains. I think once their expanded team are fully embedded we’ll see some massive and rapid improvements.

Also remember that Bubble maybe have to move a little slower as they have to take their millions of users with them. New tools that don’t have a user base to speak of yet can make breaking changes without it having any effect. Bubble have to tread very carefully.

Obviously the newer, code-generating platform are going to extoll the virtues of getting your code out if you want, but as I’ve tried to highlight in this thread, it’s almost useless as what are you going to do with it once you’ve got it? You’ll then have to do everything yourself, you’ll need a team of coders to deal with development, dev ops and everything else. Also think of it this way, these new platforms *have" to generate the code because that’s their runtime or rather they don’t have a runtime, they just rely on the browser or a complier to be their runtime. Bubble have developed a very optimised runtime engine which is developed specifically so there is no need for code generation. Code generation takes time by the way and has to be done every time you make a change and execute the app, which is why Flutterflow is very slow at initial execution as it also has to compile the code. Bubble makes the development cycle much more rapid. I don’t blame these newer tools, it enables them to develop their system faster if they don’t need to develop a runtime, just churn out the code and let the browser run it and while they’re at it let the user have access to the code if they want and then claim it as a feature! If I were developing a no-code tool, I’d do the same!

Anyways, it’s easy to look at Bubble’s shortcomings, real or perceived, and decide to look elsewhere for newer and shinier things. Overall, while not perfect, Bubble is the best and greatest software development tool and environment I’ve ever used in my 25+ years as a developer and nothing else at the moment can come close to it, although if they’re not careful that time will come.

19

Yea, the front-end is typically not the concern for me in terms of scalability, it’d be the backend. And I believe because the other builder rely’s on external backend builders, that’s one of the…perks and yet at the same time obvious downsides of the tool. On one hand, immensely well integrated Bubble integration with admittedly ‘hypothetical’ issues with scalability. The other, less fantastically integrated backend, but seemingly more dependable and scalable backend as that all that they do.

Agreed

Yeah, I agree.

As @dorliama mentioned, it does seem to just be a matter of weighing the pros and cons of each platform and the needs of the project. Perhaps, it’s also a fallacy to believe a no-code developer should only learn one ‘best’ platform anyways. These options of no-code tools can probably do the job well enough for the projects at hand.

1 Like
20

The only other No Code app builder that I’ve used that I’ve really liked and is great for mobile is Appgyver. I really like it although like the other it’s not got a back-end. However SAP acquired it a couple of years ago and renamed it “SAP Build Apps” and spun it off into it’s enterprise offering including a back-end service and left a free community edition for the rest of us, although there is a free tier for the non-community edition. I’m not entirely sure what’s going on with the community edition, there’s not a lot of info out there about it but there’s a lot of doom and gloom on the forum.

If SAP are killing it off for the independent developer it would be a real shame as it is a really nice tool once you get into it especially with it’s logic flows, similar to workflows in Bubble, but probably nicer to work with. I’d hesitate to recommend it because of all of this but it’s worth looking into because it can be run offline. It’s also pretty straightforward to connect it to a Bubble Data API or your own API workflows. Anyways, worth a look.

1 Like