I joined a startup that didn't have any deep coding skills - but had a great idea and vision for a product. They had made a pretty decent prototype with Bubble and could quickly implement suggestions from the beta testers.
When I joined I instantly suggested re-writing it in a "real" stack. But when I dived into it, there was a lot of built in features of Bubble they were using that would be a pain to write or integrate. The rewrite would take some time.
Instead we launched with the Bubble app as it was. It targeted a niche market, and that market came flooding in - it really proved there was demand for the product and the feedback helped shape the end result - months ahead of where would have been if I re-wrote it.
But as the app grew we ended up with "spaghetti no-code", slow loading times, crazy hacks, giant bundles (that we had no control over)... but again, it was good enough to launch with and validate the company, and it was fast to try out ideas.
We eventually did a full rewrite once we were happy with the overall structure of the app, but the process changed my perspective on the value of no-code tools in the right hands.
I believe no-code is incredibly underrated by many early stage startups. Rewrite only once you found your PMF and there's a real performance issue (or other technical reason), just you like you did.
One of the best thing about no-code is that you avoid painful, timewasting continuous refactoring while trying to iterate on your products the first months. It's much easier to design & structure the code to be as close as possible to the business (DDD-style) when you write it from scratch after reaching PMF.
Being able to iterate fast early on is such an important part of startups. I think code is not great at this.
I'm guessing many people would get this right up until the last step and see how much juice they could squeeze out of the prototype which I would imagine could be fatal in many cases.
I still wouldn't suggest this route for anyone.
Can you say more about these problems? I'm curious what they're like in practice, if/how companies using Bubble can work around them, and whether Bubble might be able to fix these kinds of issues in the future.
Repl.it and peers seem to be on the right track here
Do open source projects have an obvious "run this script to configure your complete dev environment in respect to this project" ?
I would be happy to spin up a new VM for every project on that basis.
That said it's still way too hard to make web apps the "proper" way. I think there's space for something easier but I bet it will look more like Mathematica than LabVIEW.
I’ve been programming with bubble from “technical aware founder PM/founder” and bubble is liberating.
In the past i’ve built a webapp that :
- Renders desktop
- Renders mobile
- store in database
- after a conditional form
- create a complex journey of to do list with defaults based on answers of previous cond. form
- connects to an external system with cron daily
- sends email daily from backend
- uses plugins from community
- much more
The deal with bubble is : - resources cutting 10X - if you manage to understand the adequate scope (serving up to multiple thousands) with no such fancy ui, with not blazing extreme loading perf (since no focus on static)
Bubble is : - Build 10x faster a custom ish layout with custom logic to get your first 10k users. (NPM available if you code)
Does it scale to infinity? No
Will you need code after that. Most probably. But you got there with 10x less ressources
They also need to invest heavily into UX and the ease of figuring out how to do something. I've used Bubble and similar tools, and they share something in common with coding - you need to watch/read a bunch of tutorials to figure out how to do what you need.
What they save is an initial headache of devops / authentication / wrangling which is bad enough as a programmer but extra hard for a non programmer to contend with.
Here is another idea for someone - a yes-code tool that lets you write everything in code, but handles devops/authentication and some common stuff for you. Basically Heroku + some NodeJS starter kit that is meticulously kept up to date.
Most code builders don't even give the devops/authentication bits.
There is library basically for anything you can think of. Out of the box you get all the batteries you need
A vast majority of our day is spent focusing on the business end.
It's similar to Shopify, I can put up a store in ~20 mins and start selling immediately. I would be extremely misguided to try to "build an platform" when that problem has already been solved.
Same with no-code. Why code it from scratch when it's been solved already? If you want to go super deep, sure. Seems like the hate comes from a cross of not-invented-here syndrome crossed with only 10 billion dollar companies in 2 years are cool.
Here's an example of a Bubble biz. https://goodgigs.app/
I truly appreciate the problem these platforms are trying to solve, but they're just not there yet. I wouldn't say it's easy to build a no-code platform, but it's much easier without the constraint of needing the output to have good performance - that's the hard part.
“Your browser was unable to load some necessary resources, contact your IT network administrator and ask them to allow access to
dhtiece9044ep.cloudfront.net
dd7tel2830j4w.cloudfront.net/
d1muf25xaso8hp.cloudfront.net”All you do with no-code programming is outsourcing writing the actual code to some other company, who already did all the work for you, and you just plug it together. To me, that doesn't reduce complexity, or mental load, it just offloads it to someone else. There's no "no-code" here, they just let you use the code they engineered.
So if you don't know if a particular task will grow to that level of complexity, it is probably better use of resources to use a nocode/lowcode solution until it is clearly insufficient, and then take the pain of migrating to code.
I've worked with '4G' since Mimer, Mapper and all kinds of other contenders and until a few years ago (roughly until 'Mendix') low code / no code was a limiting environment.
But Mendix got it right and there are plenty of valid domains of application for the current crop. Plenty of success stories of companies that used it as RAD and validation tool. Once the money rolls in you can always do a rewrite, it is much easier to do that when you are successful then to try to find success on a platform that is slower to develop for. Like every other tool: use where appropriate, there are plenty of domains where this approach would not work.
I can't think of a reason it'd be impossible to build a no-code app that scales as well as code, and I don't have evidence that Bubble has failed.
If felt like there was a missing level of abstraction - everything was too intertwined. Making changes to anything becomes harrowing once the app becomes large - it was slow, and you don't know which UI elements are being accessed by any blocks - so it's really easy to break things without realizing. And the undo system gives you no visual clue as to what is being undo-d if it was in a different view. It was the most fragile system I've worked on.
However, many of those issues could be fixed, improved, or redesigned. If you were doing "regular" use-case stuff it was... fun! Our designer could get in and implement/test things really easily.
My gut feeling is that there could be system that scales well - but the escape hatches need to be reliable when you hit the edges.
Could you do everything with pure Python or C++? Sure, but it would be much slower. Low code is useful if your need is not covered by an available application, and on the other hand you lack the resources and/or time to develop an app from scratch.
But I fully agree that "No-code" is a marketing term only. Even the easiest "No-code" app requires a good understanding of concepts like "if/then". The term "Low-code" is more honest.
If a toolchain that allows to deliver fully functional software of appropriate complexity without writing code was even remotely feasible, Apple/Microsoft/Google would have already been pushing hard each for their own take on it.
Considering the immense upside for whomever of the big tech that manages to do it first, and that they can throw much more resources at it than the best-valued SV unicorn, presumably they’ve tried (probably more times than we know); and presumably what they’ve found is that at a level of no-code tool sophistication where it’s good enough it becomes indistinguishable from programming—so they’re trying to attract more people into software engineering instead.
Snark aside though; do whatever floats your boat. Tools that allow non technical folks to start building useful products is still a win (even if I personally wouldn’t make that tradeoff).
In the past I have found that as soon as a server push action is required things break down pretty fast.
IE display alert at a certain time but not if the user has focus in a text field. Show an message indicator instead.
We have worked on over 20 client projects in the past 1.5 years using bubble.
Specialising exclusively in bubble now.
A way to describe the platform would be WordPress for Web Apps.
There was a census recently. ~75% clients are startup/MVPs ~25% SME making business tooling
Out client portfolio is similar.
I've hired fresh graduates in Pakistan, trained them in 2 weeks. And now have them working on a customer production app.
I've also taught bubble bootcamps. After 8 weeks of weekly 2 hour zoom sessions, I doubt you'll get much progress in a coded bootcamp. But these guys were building their app ideas. All sorts of backgrounds. Accountant. Art student. Podcast editor etc.
I have a client who needs a quick 2 week MVP. Done. I have a client whose 40+ employees use bubble app daily across four counting. Core business tooling.
The four pieces needed for a web app are Design Logic Data Hosting.
Bubble combines all that and reduces the barrier to entry.
No need to make comments like the famous Dropbox comment. Why not just SSH sftp xyz.
NoCode is definitely rising. We have won bids against coding agencies due to cost/time. The competing coded agency suggested 3 months. I quoted 2 months.
The day rate is somewhat similar. The speed is much faster. Very much needed for MVPs
That being said. There are drawbacks. You can throw 30 software engineers and have a system and increase velocity that way. However, bubble/NoCode is more suited to small teams (afaict yet)
Feel free to ask me anything.
Bubble.io coach, bootcamp instructor, agency owner here. Bubble all day every day.
Email : hn@azkytech.com
1) They really are a fast way to get an MVP that can be shown to investors and customers and even process customer transactions for simple businesses. Many simple businesses don't fit into pre-packaged SaaS platforms like Shopify, but don't really need a fully custom solution built from the ground up. No-code is good for these.
2) No-code quickly hits a wall when things start to get more complex or as the scale grows. At some point, trying to coerce the no-code solution into doing what you need becomes increasingly painful and a custom solution becomes necessary.
In reality, I think many small businesses and simple startups are actually a good fit for no-code websites. The Wordpress analogy is a good comparison because we all know how unnecessary it is to write a blogging platform from scratch in 2021 (unless for hobby, of course). Likewise, it's going to become silly to write a custom backend and frontend solution for a client whose entire business is basically a couple of web forms and simple workflows.
It's all about picking the right tool for the job, and no-code tools can be the right tool for many jobs.
But they're not the right tool for every job. Knowing the difference is important.
Totally right about the right tool for the job. And yes NoCode is the right tool for many simple crud apps.
"I'm afraid many are only showable on a Zoom call. Please book a consultation call and I'll share a project that aligns closest with what your project."
30 projects
0 images
0 gifs
0 videos
0 company names
0 case studies
Hmmmmm.
When turning down work and struggling to scale, our own website https://azkytech.com takes a hit.
Also, I'm working with a coach and his words are correct. Need to figure out ideal customer profile first and then invest in these.
E.g. have worked on 3 mobile apps . And they are really hard with bubble. The divert challenges app [1] is one of our projects. But just today I asked a guy to find someone else to work on their mobile app..
This makes absolutely no sense at all. You obviously have not read _The Mythical Man-Month_, and judging by what you've written I completely doubt the entirety of what you've said.
Speed is one thing. The long-term maintainability and usability of a system is another thing altogether. I have serious doubts about this 'no code' movement.
However, in the context of the other comments the GP made, I interpreted it as, "You can have a larger team with a properly built system with usability and maintainability, with good separation of concerns, and speed things up that way, but we have a smaller team and so bubble serves us well by allowing us to get things done quickly".
> I have serious doubts about this 'no code' movement.
I think the GP was pretty transparent about what it is good for and what it is not - I think the "wordpress for apps" is a good description. Wordpress is great for a particular class of problem, and then when you get to a certain level of complexity, you end up throwing it out and rewriting it, or putting so much on top of/around it that it is unrecognizable.
You’re right about the mythical man month, but I have a feeling this person is trying to grind an axe more than make a coherent point.
I really really miss git, version control systems, pull requests, automated ci checks etc.
Imagine a world without git and version control systems. Then apply that to NoCode.
Who changed which line. When did it happen. These things are normal with code/git. But not with NoCode/bubble (yet Jul2021).
Which file is the master. Which change to merge.
And then throw 30 software engineers at the project. Chaos will happen.
The comment was less about architecture and more about version control and merging which is still early days in the world of bubble compared to software engineering
https://nocodefounders.com/interview/revetize-interview
0 results on the Apple app store, but there is an app on the Play store called Revetize with "10+ downloads". Perhaps that's it?
https://www.divertsessions.com/pages/challenges-app (Instagram for action sports. App in app store is bubble by us)
Lots of business tooling ones that are a bit more sensitive. Booking systems for SMEs.
If it is a business that needs Standard CRUD, relational dB backend, a front end. The web app is in a zone that is perfectly viable and can stay in bubble.
Cosmetic Limitations can easily be overcome with custom plugins built using nodejs. We had to parse a large CSV once and wrote a bit of JavaScript to overcome it.
What I wouldn't do in bubble - make a game. Tricky stuff. - intensive math on bubble server. E.g. any machine learning should be done elsewhere. - make something like bubble in bubble. Nope. Don't.
When logged into bubble, add ?debug_mode=true in URL.
See the bottom toolbar. Step by step through any workflow action. (Event based paradigm) or inspect any element and check any state/property. Not chrome inspect tools. Bubble has its own debugging.
Backend debugging is slightly trickier. The logs are harder to read. Sprinkling some database entries makes it easy
The tricky part would be user authentication. It's built in. So those would need to slowly migrate and need a strategy.
The business tooling is built to stay in bubble. SME/Cost. Many MVPs died. Some still MVP stage iterating.
Sports venue sign up and configure their fields (5v5 indoor, 11v11), onboard to Stripe Connect Express. Public booking page for the venue.
Players booking and reserving. Sharing invite URL with other players who can add themselves to the roster and make payments.
Venue sees bookings and payments.
This one is half done and I'm really excited about it.
Tried a few other platforms (wappler, adalo) but not much luck. Focusing only on bubble now.
There were so many quirks and limitations that I wouldn't ever recommend it to anyone. It's to app development what Macromedia Dreamweaver was to web development back in the day, except worse because you can't edit the code.
I don't want to be overly negative so I'll say that I do see value in it for those who have no technical skills or programming knowledge to create some sort of prototype, but that's about it.
If you're willing to spend 4-8 hours going through tutorials to understand their metaphors & setup, then you can find plenty of interesting ways to use it that are faster than "normal" coding.
But if you just jump right in on the assumption that your coding knowledge will carry you through (which is what I did the first time I looked at it and sounds like what you did as well), then you're going to have a bad time and end up without an accurate view of what it's good at, bad at, and where the trade-offs are.
Can’t say I’ll use it again but good on them for continuing to improve it.
I know Microsoft tried to allow non-developers to create apps without developers, and they have been trying for decades. But failed! They built an app that allowed you to drag and drop blocks, and they tried a visual query builder(not sure what the exact name was) for SQL. They added a workflow builder to SharePoint.
They all worked great during the marketing demos. But as soon as you had to execute a slightly complex process/workflow/idea, it broke. And that happens almost on day 2 after deployment. The only success they found in automation was by getting non-devs to learn development using VBA macros for MS Office.
How is the current suite of no-code apps different. How will they solve the problem with non-trivial tasks?
It's a basic error of attribution.
We need complex systems, and we build them typically by text source, which is the most efficient way of coding a system (as we've found over the decades).
Because the source looks arcane to an untrained eye, people attribute the complexity to the form of the code: text source, and not to the nature of the systems being built, which have some natural level of complexity.
Hence we try to alter the source form in some visual "friendly" way and believe we've achieved further simplicity. Demos looks attractive by connecting 3-4 high-level blocks together that make milkshake, or whatever.
In real world projects, using these visual systems end up even more complex and much less flexible than text source. Rinse and repeat.
Text is so amazingly intuitive that don't even think of it as graphical, but it is. As you also point out, the reason it looks complex is because software is complex.
A full-blown general purpose text-based programming language is of course always more powerful, but a task-specific GUI can be much more efficient for the particular tasks they are designed for.
First of all, no-code tools are not intended for developers. Although, developers can and do benefit from them by using them occasionally for prototyping and mundane automations. The main beneficiaries of no-code tools are "citizen developers" - people who get paid for something else than software development (e.g. marketing analysts, accountants, lawyers, etc) but who need/want to automate things to be more productive in their main work. For them, no-code is a godsend. It's like not having hands and asking someone else to do something for your with their hands all your life, and then suddenly getting your own pair of hands. No-code is a super-power to them because now they can do things they need but couldn't do earlier. For instance, querying databases without knowing SQL, pulling data from web APIs without having a clue about HTTP, or renaming a thousand of files in a loop. No-code is not about doing everything. No-code is about being able to do something, because previously its target audience could do nothing. Remember that excitement when you wrote your first Hello World program and it worked? This is exactly how "citizen developers" feel about no-code.
Second, no-code is not a replacement for general-purpose computing and never meant to be. There is only a limited set of tasks, that can be efficiently automated using no-code and high-level abstractions - ETL, file/folder manipulations, RPA, certain things from gamedev and ML, and maybe robotics. However, these tasks are very common and no-code saves a lot of time and money for them.
Third, no-code creates a new class of people that can do programming, because no-code is programming. It just uses higher-level abstractions and can be imperative, declarative, or functional. This class of programming is here to stay because it works.
I'll stop here because I can talk about no-code for hours :)
I feel the view of ‘no code / low code’ is a bit primitive here. It used to be like that but last 3/4 years, the entire thing paradigm has changed fundamentally.
A previous company forced devs to switch/add a no/low-code tool. We were given 3 to evaluate: dell boomi/mulesoft/some other crap.
Most devs were gone within 6 months of that mandate coming in to effect.
Horrible, immature, limiting tools.
Do you think the A team devs are building these no-code tools after their initial prototype? No, they're being farmed out to design and development by middling product managers and devs - which never ends well.
What killed RAD tools was the web, not them being a failure.
Maybe what killed that push was proliferation of cheap journeymen: everyone’s niece wanted to be a web dev, everyone’s nephew a web designer, so it was easier to have your nephew or niece build your site than research which low code boxed software of the age would let you do it yourself.
The niece went down the path of PHP, Rails, and node.js+Angular/React, the nephew down the path of Dreamweaver, Creative Suite, Sketch, Figma. Plentiful cheap hands you can pick up the phone and boss around, nobody needs low code.
Now the tide has shifted. Nieces, nephews, cousins, anyone with a knack are all doing it, but the demand outstrips this supply.
So the demand needs more workers or more automation. Code camps aren’t keeping up, but boxed software is now web delivery. Advertising puts it under general public noses.
Anyone can find a way to build a thing (there are a thousand drag and drop app/site builders now), and the average small biz owner reading the marketing then dragging and dropping doesn’t have a clue whether that’s limiting or good idea.
So yeah what killed RAD tools was the web, but also kids. Now the kids on the web are building the next gen of RAD. And the circle of life continues. :-)
Minor nitpick :)
VB6 never had tooling to integrate with .NET.
Rather, .NET could provide an "interop" layer to allow you to consume components written in VB6, or just COM in general. You can also create COM visible components written in .NET that could be consumed by VB6 or even scripting languages such as VB script. But the tooling for that was delivered through the .NET SDK/VS.
But on your other point, you're right, there are probably a bazillion unknown VB apps out there still chugging along doing their one thing for a specific department or company.
(i) higher coding literacy, either from folks already knowing something or companies taking a more active role in providing trading for some minimum set of coding skills.
(ii) more compliance burden and control, i.e. while in the old days people might have been allowed to use Excel macros, some development environment etc., today tools are more likely to be locked down. So a controlled environments allowing people to do limited development and adaptation are of interest.
(iii) Low hanging fruits partially picked. There are tasks that could be automated but where gathering the requirements is too expensive. For example, small tasks done by a few people only - but there are a lot of those. So allowing people to partially automate themselves is a good idea.(and yes, these tasked could well be pretty trivial).
The same way things like Twilio/Stripe/AWS speed up standard development also make no-code development more valuable.
People (on the customer side) want automation that people who nominally aren't coders can build.
People (on the seller side) want sweet enterprise sales with maximum vendor lock-in.
Nothing, really, has changed... that's been the story forever.
> I know Microsoft tried to allow non-developers to create apps without developers
Hence, Excel, Access, PowerApps...
Also, really, the low-/no-code capabilities and empower analysts vs. devs to build tools or perform tasks that would otherwise take one-time dev or DBA time is also a selling point around a lot of the SQL Server ecosystem, e.g., SS[R/I/A]S.
> I know Microsoft tried to allow non-developers to create apps without developers
Yes, and have lots of success and lock-in from doing that.
> But failed!
No, no they didn't.
Oh, I mean sure, their no-/low-code tools require a lot of the same skills to build decent apps that arr required for other software development because coding was never the hard part. But, from MS’s point of view, that's irrelevant to the problem they are solving.
Where before concepts like a logic branch and a loop were very foreign I think a lot more people know what they mean.
Also the industry has learned that 80% of the uses cases are around CRUD and different ways to enter data and view data.
Total failure,
From reading the comments here, sounds like the no-code, the rebranded RAD, has the exact same problems again.
Creating fixed UI is extremely easy to understand. You just put a control, snap it to grid for consistent spacings and that's about it. Everyone can do it, very fast with very little time spent on UI.
Modern computers are highly variable in size. Small smartphones, large smartphones, tablets of all sizes, laptops, 5K mac displays.
Smartphones and tablets expect full-width applications. It's not appropriate to design your UI for 320 px fixed width. It'll be too terrible on larger phones. It's expected to have fully stretchable UI at least.
But that leads to very complex to understand creator UI. Xcode, Android Studio, Java Swing. They have powerful layouts, but their GUI to build those layouts are incredibly complex. You might spend lots of time for very simple thing. It's nowhere near good old Delphi, when I could put few buttons around and call it a day.
Of course I'm not arguing that layout managers are not needed. Another feature is internationalization and it was terrible with Delphi, when you had to translate a button but translated text could not fit into its fixed width. What I want to point out is that there's still unfulfilled need for layout manager, which is powerful, yet very easy to use.
May be we need some AI for that.
I suspect the answer is that they don’t require you to buy seats for all the users, but wonder if anyone is familiar with both.
Not being Salesforce ;)
I worked on a bunch of Salesforce stuff for about a year, including building an app. Can't say I relished that time. I think the thing that seems attractive about Bubble is it doesn't carry the other baggage that you get included with Salesforce.
When I first looked at Zapier about 2.5 years ago, as a developer I found it limiting and just not useful compared to writing custom webhooks that I sometimes glued together with cron jobs, etc. But since late last year, Zapier has matured so much I am able to use it for almost every integration I need. It has probably saved me ~100 hours of development time in the past year alone.
I wonder if Bubble might have passed a similar threshold of utility, so that it is useful even to people who DO have good coding skills.
As a developer, you can't come in thinking you'll just get it. Bubble has renamed things for simplicity to non-technical folks and you need to take the time to learn their system.
Something I found great is Bubble's API Connector plugin and their REST Data API to. It lets you to call out to external APIs and CRUD into the bubble database. When my partner's app had a bit of "complex" backend logic that couldnt be easily done in the Bubble UI, I wrote a lambda function and they call it using the Bubble UI.
Bubble has been great for them. As their product / company grow that may not always be the case. But I think it'll hold up for longer than most developers believe, well beyond the initial prototype phase.
(With Zapier, I have used their so-called "Webhook" connector for that - set up an endpoint on my webapp that accepts a POST with a JSON payload, then make a zap that send data there in response to some trigger.)
But the biggest issue is that learning curve is even higher than tools like react. And the steps to do basic things are so tiresome it’s just easier to write code. UI prototyping is fast, sure. But not much faster than tailwind.
You want something pushed into a spreadsheet when you receive an email? That's Zapier.
Pushing something into a spreadsheet is certainly a widely used zapier idiom. In 2021, it is capable of far more complex tasks, though.
We need a, open source, community driven, no-code tool.
Using existing tools I often suffered from these things: - closed source. - expensive monthly fees. - Any apps build with it are not really property of the developer, but are intellectual property of the low code tool corp - either bad ux ui or not horizontally or vertically scalable - Datamodel, Algorithm or business logic can not really be extracted from the low code platform. - You now need to become a specialist in this low code platform. These low code platforms outdate faster then the typical programming language. - The best developers look down on it so you get "lesser" developers. - If a feature is not available in the low code platform then you are stuck. - If there is a real bug in the low code platform you are screwed because you now need to open a ticket, but the engineer looking at the ticket is more help-desk then engineer. The majority of tickets they solve are from dummies not understanding the platform and they assume you are one of them. Will take several months to convince them it was a bug and was never solved during the time I was on the project (2 years). - You cannot run it on premise, unless you have deep pockets - They have non or terrible git integration. Or other collaboration problems. - Due to their dynamic nature are often slow in performance. - Corps HR department runs a different low code platform then their finance department and now it becomes a political shit show.
Terrible situation when you grow beyond the low-code platform and need to move away from it.
Budibase (cofounder) - https://github.com/Budibase/budibase
Saltcorn
I do agree 100% with your assessment that is incredibly painful to migrate your systems from one of these onto a mature, open-source web development ecosystem. I've witnessed the tail end of one of these Herculean efforts and it wasn't pretty.
The existing LC/NC platforms claim that their sweet spot is prototyping or MVP-style products. Even if one shaves a few months of development time off with this (and even that is not clearly the case), the extra work of building the new system, migrating all the data, hosting, etc, doesn't pass the smell test for me.
Open source web dev has gotten infinitely better for basic CRUD style apps. Hire a few devs with a couple years of experience, maybe even a few out of college, with one experienced engineering manager, and I can guarantee you will get a better proof of concept with React/Node, or any of the other widely adopted open source web dev platforms currently on offer.
I think this tradeoff is pretty well reflected in how ServiceNow's workspaces feature failed when it first launched in 2018 -- and why it has since been overhauled. Sure, they kept the original plug-and-play no-code UI, but they retooled it to work on top of a full-code framework that fully interoperates with the no-code UI. It's the best of both worlds: you can rapidly slap together a UI, then replace individual components of the UI with your own code as you go.
Most no/low-code tools also really suck at version control, in my experience. That's enough to make me loathe working with them, even when they do save me time :/
What is with the obsession of devaluing technical skills so that non-technical business users can increase their profit?
Charge for your cost saving/tech-enabling tools.
Stop devaluing tech.
What rational person would build the foundation of their business on a closed source, proprietary web development framework? Only the less experienced or less than rational would choose this setup. We have decades of evidence that companies that develop these will inevitably:
1. Not support the use cases your business needs as you grow, despite your pleas.
2. End support for a necessary feature that you need. If you're lucky, you can continue to operate on an older version or a fork. But then you don't get any new functionality going forward.
3. Simply charge you more.
4. Go out of business.
There is a niche in exploiting the naivete of such business owners. That doesn't seem to be the goal of Budibase given that you can always pick up where they leave off in any of the above scenarios.
Without details it's hard to tell if the problem truly was in the app complexity, or because the "non-technical BAs" did not receive proper training, or because of something else.
Automata are automata. But, ok, sure, I get it. That's too abstract for the intended consumer. So what we are selling as 'no-code' is something that can allow you to preserve your identity as not-a-coder. Hmm. Scratch seems to be the language that strikes me as something you could sell as 'not code'.
I've thought lately that 'Everyone Should Code' concepts didn't make sense. But maybe it does make sense -- if everyone uses computers to get their work done anyways, the "Here is how you can leverage your interaction with the computer to get your work done better/faster."
Data science type tools often only have the small group of people doing the complex computations themselves as users.
The final output in graphs and reports is what is consumed by non-experts and is again where Excel crosses paths with programming again, in a much easier and plug-and-play form than making your own charts/graphs (which in my experience is quite a challenging exercise code wise but again with way more freedom).
I’d imagine a spreadsheet with a form builder interface is the fundamental implementation of what Bubble is trying to do.
The consultant does a lot of internal app prototyping and initial development in Bubble for Wal-Mart corporate so I imagine app builders are doing some substantial land grabbing in other large enterprises with their raised money.
Looking at you, Python, YAML, and Coffeescript.
cries in legacy code
One day maybe it'll be a lucrative niche for contractor legacy-maintenance warriors.
That'll happen before I convince senior management that startups with React and Typescript can run rings around us, and that I can't find anyone fulltime who wants to work on our stack (or has even worked in not-React)...
If anyone wants to chime in with their stories about using Decaffeinate, I'd be interested!
The rest of the stack looks good but yeah wtf indeed
There are no video demos on their site for one simple reason: when you do find one on the YouTubes you'll see that it is very much programming. If you can create correct CRUD by dragging around "dynamic expressions" (yes, they're really called that), you could write them in TS.
As frosting on the cake, they offer gig workers to no-code for you! My father would make a comment here about wiping one's own ass.
Again, not sure how these companies last and compete where everyone else is learning how to code.
I can't foresee a mature product that is achievable without coding, at all. I always thought companies that uses those builders will, at some point, move out from MVP and hire some coders.
Well, I guess there're always market for everything.
You're conflating website builders with web app builders.
https://raganwald.com/2012/01/08/duck-programming.html
I’m much more interested in how they manage all the software engineering _around_ the low code than I am in the low code itself, e.g.
- version control
- testing
- developing at scale
———
* Way back when, some of us used Hypercard to do low-code prototypes and mockups of apps. It was absolutely a good tool for iterating quickly on working prototypes, and Bubble could be that with high-fidelity today.
"no-code" just seems like a marketing term.
E.g if I want to crop a photo I'm not going to do it in Java even though Java gives me all the power to do that and more. And of course LaTeX is Turing complete so I could mine bitcoins with a document.
So in one sense it is arbitrary but in another the marketing is useful to give some idea of how much power/flexibility the application will allow.
I think you can argue Excel is a low-code application.
Hopefully that makes sense. I think the key bits here are "it's being built through a GUI" and "you are building an application that will be executed later."
Personally, I think low code is a farce. It’s useful for prototyping but beyond that I wouldn’t use it in any production system.
"QuickBase Application Developer 11-15 years of experience. QuickBase application development and implementation, specifically in building/updating custom applications, developing custom pages, building dashboards, and translating business needs into technology specifications."
https://www.indeed.com/q-Quickbase-jobs.html?vjk=5024b4c17aa...
Budibase, Baserow, Appsmith, Saltcorn (shameless plug).
So those who can't code are then expected to self-host?
The lock-in is clearly a part of the business model.
At a certain point we should be able to declaratively describe entire businesses, and have the computer work with vendors and other people online to carry out business processes while we macro-manage it from a bird's eye view.
Something that could probably make lots of people very rich is a tool that allows anyone to start a SaaS within a few hours or days rather than months or years.
In my experience this is the hardest part of coding, to a large degree.
Isn't that just code?
I'm convinced that for sufficiently complex "no-code" solutions, you just end up with a poor mans programming language.
Often some spreadsheet has grown organically to solve some problem, with or without code.
Anyway, at least in their case you had access to the final source code.
EDIT: I just wanted to add that you are probably far better of if you hire a random guy from India on Fiverr to the app for you.
Recently I witnessed some friends get quite far by using a game engine called Unreal which allows people to use a “no code” alternative to C++ called Blueprints.
It can get a bit unwieldy when enough logic is created but if you’re disciplined about the diagramming etc it can be mitigated.
The right tool in the right hands can be like a torch in a dark abyss. (But please don't bring a torch in a cave full of ignitable gas)
Meanwhile Bridge Engineering, a 4000-year-old discipline, is still inventing new ideas and is still done almost entirely by human engineers. They use computers to multiply their expertise, but in no way are the computers "designing the bridge" for them. Why would automation make software engineers obsolete when that hasn't happened to bridge engineers (and shows no sign of coming)? Apps have been "building themselves" for decades: it's called a compiler.
How do you manage complexity? With software engineering. Writing software without writing code is like trying to design a bridge without doing math.
And if it's those crappy, un-maintainable, un-reusable CRUD applications you're saying no-code will replace, then I say: good riddance! But even if no-code is more successful than its wildest dreams, it's still just automating that lowest tier of programmer. Meanwhile, better abstractions, programming languages, type systems, mathematical advances, training programs, techniques, and architectures have been raising that water level every year for a long time. Even a good no-code solution has a very limited expected life when it's competing with that.
To your point, can I call the cement mixer a self-made building material that resulted in an accumulation of 4000-year-old of knowledge?
Every known industry has different levels of production to reach the final product. Which may be a tool builder to automate the industry. Exactly the same way the building evolves to the prefabricated. The limitations are with the raw material which is clearly to the advantage of the software industry.
> Meanwhile, better abstractions, programming languages, type systems, mathematical advances, training programs, techniques, and architectures have been raising that water level every year for a long time
I totally agree with all of the above. But that can be done along with investing more in the essential no-code tools. And if some has decided to go further good luck.
The argument about we need to do more so please let's stop the entire direction of automating because somewhere they still using CRUD, old-fashioned and unmaintainable code is similar to let's stop space discovery because we still have problems on the planet earth. We can do both.
If yes, I can see that being reasonable as a solution to sliwly migrate from a no code software to a fully coded software.
I understand and appreciate the idea of prototyping without code, however this goes end in end with the reality that if adoption is big and you suddenly have to make something performant and it's impossible on the no code tool, you might have a big problem to do (write from scratch) with a tight timeline (performance exploding), potentially losing customers.
I agree that when this type of sentiment crosses over into an "us vs them" (non-tech vs tech) mentality it's problematic. Having a confrontational mindset towards any integral part of a business is a recipe for disaster. However, if you look in the Bubble forums you'll see there are a number of posts reaching out for a cofounder/technical person or advising to find a technical cofounder when scaling becomes a reality (successful proof of concept).
Personally, I find products like Bubble to be a great opportunity to reduce risk in the startup phase for all parties involved. New ideas can be tested in the wild for a lot less time and money. After a market has been shown to exist then a focus on scaling and technical architecture can happen. It's also easier to attract a talented CTO when you can prove that a market for the product exists.
At the same time, a tool like Bubble is incredibly empowering, and I want to to make it clear, I don't have any issues with the product, just the sentiment in the title of this article.
1) Apple will throw out your apps quickly. They say it is a templated app. Our app at them time had 100k active installs. They basically shut down a portion of the appstore.
2) The web version of 'no code' is a sick world of godaddy guis and broken html.
Bubble is great if you can't code and you want to save $5k on a developer (if the project is >$5k then its probably already too complex for no code!)
An engineer might get the task to make some feature, and the manager goes and uses bubble to make it and sees it only takes an hour, the engineer sits there for 5 doing it, you can imagine the rest.
The engineer might take care to make the code maintainable, fast, and expandable for some other feature that is planned, but nobody up the chain of command cares about stuff like that.
It's the kind of thing that makes the developer's lives harder, the apps more bloated, all to get the features out faster to the users for a few years until it all breaks down and you have to rewrite it.
I'm not convinced. I read this entire thread, but I never see a real benefit for users or programmers, just managers who enjoy pumping up some metrics so they can advance their career.
I hope Bubble will innovate on this.
Adobe Illustrator has a learning curve too; that doesn't mean that I should go back to coding SVGs by hand.
I hope the investors realise this.
Programming is just the act of solving problems in a repeatable way using computers. Excel is programming. I've seen plenty of Excel formulas that would make experienced programmers shy away.
This just makes the no-code movement look even stupider. The entire movement is predicated on selling to clueless vice presidents who have no idea what their expensive programmers are actually doing.
"No business" software startups are kind of possible. If the software/product is useful, important, unique or cheap enough the business side would be trivial. An iphone equivalent for $50 doesn't need any marketing. A script that automatically optimizes any and every AWS setup to save money. A consistently profitable algorithm trading. Sales will be trivial, fundraising, etc.
In reality though, it's very hard to be that good on one axis. In a competitive game, you usually you need to perform across multiple areas. Great product and decent marketing. Great marketing & decent sales. etc.
This applies to Low/No code setups too. Maybe you can build twitter, airbnb or Tinder using Bubble. But, that'll mean that your product is very unlikely to be as good as those built using a more powerful toolset. The software itself can't be your competitive edge.
People have been competing with Amazon, without code, since viaweb. You're just never going to launch aws.