Budibase cofounder here - we are super excited to finally ship the dev experience of 2.0 and can't wait to see what the community build with the new dev experience. Happy to answer any questions or hear any feedback that anyone may have!
As I mentioned in the post, this was a truly special moment for the team here at budibase. Open source can have its challenges, but moments like this make it so worthwhile. I'm more than happy to answer any questions anyone has.
Automations are simple by design - the general automation steps are kept simple so they are easy to configure and create. We do however have a JS and a bash automation block. These blocks let you perform looping, iteration and logic using either JavaScript or bash.
The reason we use JavaScript is simple. Most software engineers can write or at least express simple constructs in JavaScript. Being a C family language, this makes it easy to pick up for engineers who have been exposed to other languages like Java, for example.
The problems you are describing are actually something that we have felt before, when budibase did not have JS support, we had users reporting that the templating/handlebars syntax was not good for logic, and was new to them. It was esoteric and required in depth knowledge for advanced use cases.
Using an off-the-shelf high level or more specific expressive language has some serious drawbacks, especially if you create it yourself. The first is education - writing extensive docs around how to write and use that language. The next is maintenance - maintaining your own custom PEG grammar or programming language is a huge project in itself, not even including the research required to execute it well.
By using JavaScript, we can leverage the already existing plumbing for executing JavaScript, and provide something that has much for familiarity to the general user.
I'm currently evaluating this for use at our healthcare company, and I can tell you that 100% of the reason why I'm even willing to consider a low code platform like this is because of the excellent job you've done with open source, and the fact that it fits in seamlessly to our existing nodejs and javascript environment and skill set.
Had you guys made the decision to create your own grammar/DSL, it's very unlikely that I would be seriously considering using it.
Our app metadata is stored as JSON documents in CouchDB, but entire apps can be exported to .txt files that can be imported into budibase also. Our templates work through this method.
We do not currently support git based versioning, although it's certainly something we could support in future, given the fact an entire app can be represented in a .txt file.
Thanks for the comment. We have just undergone a full security audit as of 2 weeks ago - any infrastructure or code vulnerabilities are currently being worked on.
Many JavaScript projects contain huge dependency trees - it is unfortunately the nature of a 3rd party module-heavy ecosystem, and can be hard to tame the sheer size of the tree. We will update or pin dependencies as needed, to solve the security issues being reported by NPM.
I should also mention that since budibase is self-hostable, it can be run inside all of your existing infrastructure and network - providing additional layers of security that you can control.
Appreciate the feedback, and the information regarding transitive dependencies - interesting article.
Hi, thanks for the feedback, sorry to hear you had some problems.
The Mongo connector in general could probably do with some love - there's a few features in mongo such as projections that budibase does not support. We'd love to know more about what you were trying to build and how we could help you achieve it.
We move quickly, however, and the platform has come a long way in even a few months. We hope you try the platform again soon and continue to provide feedback as to where it could be improved.
Docs are a big focus for us over the coming months and they will see significant improvement in short order.
I'd be happy to help out on the mongo side if you'd like. Maybe some github issues with a related label to help triage those issues would be helpful for folks to lend a hand.
I'll concede that no/low-code solutions have never historically worked out at my organization (context: I am cofounder and director of engineering at a wireless ISP). Theres always a set of tradeoffs that make it really hard to deliver value when you're dealing with business domain constraints that are hard to generalize.
That said, I am always willing to give things a fair shot and have a long list of small use cases that I use for prototyping when I go down that rabbit hole.
