I get the vision, however ... [What about text-based import/export]

Idea
1

Greetings Bubblers!

I get the vision of this project, and to a huge extent it makes a lot of sense …

However

Doing everything via drag-and-drop does not scale well to multiple projects or huge projects with a lot of underlying workflow.

Question

Is it contrary to the vision of Bubble to be able to import and export application definitions in something that looks like plain text?

Without the ability to import and export application definitions to some kind of code or text, the following pitfalls are cause for some concern:

Detailed examples

  • How does one organize application sub-components and share those components so that they can be used as libraries?
  • How does one avoid repetition fatigue when one has to create multiple input forms where each form differs only slightly from a core form type?
  • How does one do “refactoring-tasks” that do not translate easily into the “drag-and-drop” domain
    ** for example how can one globally search and replace variable names or labels to conform to a new convention because a specific client wants their app to match the conventions of another system?

Actually, this list could be much longer, but for now it seems reasonable to just ask the question directly.

By the way, it looks great!

1 Like
2

Indeed, if there was an XSD for Bubble apps and you could import/export XML that conforms to that XSD it would be really nice

3

and would be even able to make transcoders out of those XML documents to produce apps for other platforms (that is could use Bubble as a dev tool) and also maybe to import some things from other platforms (see http://zoomicon.com/tranxform [VB6FormToWebForm tool] for example, where I had made a tool in the past to take a VB6 form and make an XML out of its design, then spit out an ASP.net webpage via XSL transforms)

2 Likes
4

For me, as someone who literally does not understand a word of what you guys have written here, I’m delighted and amazed with what Bubble can do. Or should I say, what I can do with Bubble!

6 Likes
5

That’s a great and very valid question, and something we think a lot about.

You may be right we need to get back to text at some point, I honestly don’t know. What I know for sure though, is that we haven’t pushed the limits enough there, because in the past (and still a lot today), there is this idea that you can’t do something interesting with a computer without writing text/code. So our thing is to push this limit. One day, we might have to fall back to text for some stuff, but I don’t think we’re there yet.

Practically, we’ve been adding features as users get bigger apps (@NicolasDap can talk about it :stuck_out_tongue:), and that has led to a few features to help maintaining apps when they get bigger. For instance styles, App search tool, replace elements, clone pages, bulk operations, reusable elements, etc. I’d like to push this as much as we can, so if there are some situations where you think text editing is needed, let us know.

In your examples, you can use reusable elements/copy pasting when the same forms are needed or to organize stuff. We don’t have a good solution for modifying more than one element at once (except using styles), but that’s typically the kind of things we can look at when that becomes an issue.

Importing code is a different story, that’s very much what we want to enable people to do. A bit early for us right now, but you can already do a lot with blockspring. And that’s def the vision.

4 Likes
6

btw, exporting the whole app to some XML document (that is defined by a [versioned] XSD document) would also make someone feel more safe they have control of their app (both for backup reasons and future proof - I know you’ve promised if Bubble goes does down you’ll opensource it, but still many want to have something tangible backed up locally for their work)

having such an XML would also allow one to generate reports, compare vesions of their app (show/examine how it evolved), place it in a version control system etc.

1 Like
7

What we save is a big JSON file. Not sure you would be able to do much on this to be honest, it’s a description of the app, but the editor is needed to convert this into something readable.

1 Like
8

Problem with JSON was originally that you couldn’t have a schema for it (like you can with DTD or even better with XSD for XML), but this area has evolved and there are now schema languages for JSON (and schema inferencing tools from JSON data I think too, like there has been in the XML world). There should also be versioning support (when the scema evolves) I think in those schema languages

see:
https://www.google.gr/search?q=JSON+schema&ie=utf-8&oe=utf-8&gws_rd=cr&ei=fp2jVpPMD4a4sQHk14LYCg

If one could download the JSON file for their Bubble app it would be nice I think. It might not work with newer Bubble versions but they could adapt/fix it by hand if they need to restore some older backup of their app. That would also imply allowing to upload/import a saved JSON file of course at a new app

Supposing that the schema doesn’t change often, keeping this JSON file in version control would be helpful too to see what you’ve changed in case something goes wrong with your app’s behaviour if it’s a big one

9

btw, from a JSON file one can make an XML file and then use XSL to spit out other stuff (say a graph in one of the various graph description languages), but one could work directly with the JSON file too if they want to make a transcoder/generator of something else from the Bubble app’s UI+data+logic design if all of that is in the JSON

10

This touches on the Core Vision of bubble.is!!

This very point is very salient, and it seems reasonable to emphasize.

It could be JSON, it could be XML, it could be YAML, it could be an INI file or LISP or some top-secret proprietary format, that’s a little bit beside the main point that is hopefully introduced by this thread.

We have evidence in this very thread that hashing these things out in detail can potentially confuse people attracted by the simplicity and approachable friendliness of the visual paradigm.

Yes, I get it!

However, this addresses a potential pitfall: drag and drop will reveal limitations and potentially frustrate users if it is the only way to program an application in bubble.is. There are going to be people who love this approach, and then they will hit a wall that may make them reconsider whether it was a good idea.

In order to emphasize this point, here is a thought exercise: if you hired engineers to re-invent bubble.is from the ground-up, using only drag and drop visual programming (heck, even allow them to use blockspring too), how much longer would it have taken to get bubble.is where it is now?

Please note, this is not a criticism against visual programming or an attempt to say it is not feasible (no doubt you have heard this a million times)! Hopefully bubble.is will succeed famously, and bring on a new generation of tools!

However …

If the JSON format (or whatever text/code format bubble.is is using) were capable of import/export, and supported as just another way to create bubble.is applications, (first-class citizen) then you would open up a whole new base of potential customers.

However …

If the JSON format (or whatever text/code format bubble.is is using) is considered “in-house-only” and treated as a second-class citizen, there’s a potential pitfall where bubble.is will be something of a novelty, and a great way to introduce people to the world of programming, but it will be struggle for bubble.is to be taken seriously for any kind of large-scale application, or for anyone who discovers the “wall” that one hits when drag-and-drop is simply too tedious.

In a world where things like revision control, unit-testing, workflow-automation, regression testing and internationalization are the norm, this seems to be worth some serious consideration.

Best wishes, and congrats on the success so far!

2 Likes
11

For me, the problem is that I don’t have the time or the desire to learn about JSON (which, I’d never heard of until just now). I get that there might be an easier way to set up my 50 data inputs, but it’ll only take me an afternoon or two, and I can get all Zen about it. I don’t think Bubble is trying to compete with large scale applications. It’s trying to let me, a creative person with a good idea and no money, have a crack at it.

I had a straightforward online shop website built for me 10 years ago that cost far more in terms of MY time having to explain the requirements, send pages back because the company had just cut and pasted something from another client etc. So with Bubble, I can have my vision, hack away at it, and get going. Yes there are tears and tantrums, but the FUN is all mine!

2 Likes
12

If there’s a file format out there (JSON, XML or whatever, can transcode between those easily, especially if they’re text-based), then other programmers can even make wizards that spit out Bubble apps if you get what I mean. They could take you step-by-step through some questions and then give you the app as a file (generate it) that you import into Bubble website. Then you can take it further with the visual editor.

Same goes if Bubble editor had automation, when I started porting from my Ionic Creator draft of Class Project Assistant app (http://creator.ionic.io/share/c3ca7ca7e823) to Bubble (http://bubble.is/site/cpa), if I had such a file format description (or a Bubble editor automation API), I would have created a tool to import from Ionic Creator’s generated HTML into a Bubble app and then take it from there to evolve my app with the visual designer and add interaction and business logic to it

1 Like
13

As I said in my previous answer, we might get there at some point. Right now, I think we can do more within the current paradigm, so let’s push for that first. Using text is an ‘easy’ fallback, so I’d rather stay away from it right now. Also, I’m not sure we’re ready to expose something yet. This is something we need to do carefully. Once you’ve exposed a public version of the app, you need to start thinking about ascendent compatibility, etc. This can become a burden as you try to you evolve the product.

So we have this in mind, but give us time :slightly_smiling:

3 Likes
14

Yes, that makes perfect sense. One question is, once you have gotten adept at using bubble, and you are satisfied with the results, what happens if your idea is a huge overnight success, and you now have to scale your application, or provide the source code to the company that wants to buy you out?

If you never have that scenario, and bubble.is is mostly for fun, then you are right. You will probably never need to know what is going on “under the hood” and drag-and-drop is more than likely enough.

You may in fact never hit that “wall” that was addressed earlier. This question is instead posed to those who probably will, and those who do.

Thanks for the input and your viewpoints! Great discussion.

1 Like
15

Some of our users are already scaling, and we have an enterprise version of our code that enterprises can run on their own infrastructure. So not too different from code, actually. The main difference is just that non tech people at these companies build the product (which is what Bubble is all about).

In the case of a buyout, the same answer would also apply. In this case, the company would buy the target company with the existing relationship we have with them (the enterprise plan). But keep in mind this would happen with any framework (Angular, Meteor, RoR, etc.) or backend as a service.

Our ambition and vision is definitely to go for users that scale and make big apps (and probably 30% of the recent infrastructure work and features was to accommodate their needs).

1 Like
16

A problem I have is that I cannot a full printable report of my app’s design in case doom happens and I need to recreate it. I believe Bubble editor could generate such a thing, but I could generate my own too (not that good looking as Bubble using its current styles could I guess) if I had my app’s formal description (say the JSON or XML data)

17

and it is not only for backup, it is to provide reports on what work has been done. Now you have to use screen capture and navigate all events, property editors, pages, hideables (and also capture all the screens at runtime as usual [there are tools to automate that last part like http://www.page2images.com/]) to make such a report

18

Right, but why would someone run “enterprise bubble” if they are no longer in the market for a ‘non-techie-friendly’ drag and drop programming language? At that point they already have a product deployed to production, right?

Once an application has caught on, and a business is built up around it, is there really going to be a ‘drag-and-drop’ ecosystem sufficient to thrive alongside that application?

How is a non-technical person going to maintain (let alone understand) the code-base of bubble.is itself? If the JSON that bubble.is outputs is not even usable, what does that say about the code behind bubble.is itself?

Again, not finding fault with bubble.is itself, as it looks really nice. The question here is really more of how ambitious is the vision, and how closely does it coincide with a strong chance of success and adoption?

Perhaps, strategically, bubble.is is exactly where it needs to be, and the Vision is going to work perfectly, as a gateway for ‘non-techie’ people to become permanent business partners with bubble.is.

Perhaps the value proposition is simple: you are using a visual programming language invented by bubble, and if you do anything with it that is successful, bubble.is is along for the ride. This may very well be an excellent way to partner with non-technical people who do not have the inclination or ability to hire developers and bring their vision to light.

If so, that’s great and it’s definitely going to be exciting to see what non-technical people can do with this tool.

However, the vision seems very ambitious, especially if it is an “exclusively drag-and-drop” game that’s on the table. It will be interesting to see how many ‘non-hobbyists’ will be on board with this project.

Definitely wishing bubble.is the best, and looking forward to the future of this project!

Best wishes to you guys, all your input and feedback is most appreciated.

19

That may well be one of the targets, but it is difficult to see how this would fully realize the full potential of a drag-and-drop-based programming language.

This is especially so since bubble.is is spending time and resources to help people not only build things, but build things that could potentially be “the next big thing” and provide business-scale reliability.

It’s a great vision, and how bubble.is executes on that vision is definitely going to be crucial.

That’s precisely why it seems reasonable to strongly encourage bubble.is leadership to reconsider the importance of the ‘code-based’ ecosystem, alongside the ‘drag-and-drop’ model.

Again, these are not the words of a naysayer, but someone who would love to see this project succeed and spread like wildfire.

1 Like
20

Well, that’s exactly our goal. Not saying it’s going to be easy, but that’s the vision/goal. Wouldn’t it be better if product people (aka non coders for most of them) at Airbnb, or General Electric (since some IT people have to design internal apps) could build the product themselves. You’re right currently such businesses have enough money to hire engineers, but if we do our job properly with Bubble, that will be a waste of money. What we’re trying to achieve here is having product people build the product, and engineers (who code) add plugins to Bubble so that if something is missing, they can add it. I envision this working pretty well for large organizations.

It’s already happening by the way. Without Microsoft and Windows, each company, no matter how big it is, would be developing it’s own OS. But Windows made something which at that time was quite impossible to imagine: have the whole world on one OS (okay, macOS came back, but way after). We just want to push the current trend a little further. We’ve been hearing a lot the points you’re making, and they’re really valid. But that doesn’t mean it’s impossible does it? It’s hard, yes, but if we succeed, it’s going to be pretty cool.

(and I never said “the JSON that bubble.is outputs is not even usable”, it’s of course useable, we just want to take our time before exposing this kind of things. See my previous answer about that).

11 Likes