It works best for prototyping and rapidly testing ideas.
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.
People (especially the kind that hangs out in HN) dont seem to understand that there’s a vast ocean of fairly smart people, much smarter than the average (or even above average) programmer, who are unable to build what they can imagine because of the coding bottleneck. I know many, and it’s not for a lack of significant effort that they are not able to learn to code in a way that’s meaningful. I suppose there’s something in your brain that needs to click to write code? Anyways I’d much rather trust a product created by a team described in this comment than one written by a pure group of engineers.
To write code is much like to instructing a person who is doing work-to-rule. That person won't do anything outside of instructions given and will stop at the very first time it can (encounter an error).
If you can cope with instructing work-to-rule workers, you can code. No extraordinary smarts required.
As of "much smarter than above average programmer", programmers in average are at IQ 115. If we take "above average" as +15 points (IQ's standard deviation) and "much smarter" as another +30 points, we end at 160 IQ points person. Four standard deviations make that person one in roughly 16 000, or sixteen thousands. I think you should know a lot of people, much more than 150 or so of average person, to know many of them.
And to offer you my experience, my brother seems not to have any problems with coding in Python. He is well into 40-s, most of his career he was at the C*O positions and right now he decided to change venues one more time.
> As of "much smarter than above average programmer", programmers in average are at IQ 115. If we take "above average" as +15 points (IQ's standard deviation) and "much smarter" as another +30 points, we end at 160 IQ points person. Four standard deviations make that person one in roughly 16 000, or sixteen thousands. I think you should know a lot of people, much more than 150 or so of average person, to know many of them.
Nice example that if you define the terms to suit your argument then you can make any argument. Also, the word 'smart' has much wider scope than just IQ. It is also possible that the people OP knows are not sampled randomly from general population (he might be in a chess club for example).
I'm happy that these no-code/less-code/visual programming tools are putting the web-apps in focus again, It's changing from 'I have an idea, I need to find an mobile app developer' to 'I have an idea, I can create a prototype on web myself'.
Personally as a coder I have workflows, tool-chains developed over several years that writing a code to create a MVP is faster than learning no-code tools, also the end product is lean and stays with me.
So I haven't used these tools but tried notion for the first time yesterday to export my kindle highlights(HN comments)[1], So I can see the value in these no-code tools in automation workflows for even coders.
> who are unable to build what they can imagine because of the coding bottleneck
Sounds to me like a generally applicable thing to be honest. Even as a programmer I can't just pick up my favorite language and use it for any type of software. There is mature/user-friendly infrastructure and libraries for X/Y targeting Z, for a limited set of permutations.
Totally. I use this analogy where if photoshop did not have this low-code interface and all artists have to do was program strokes code by code, how many artists who couldn't learn or understand "coding" would be left out?
IMO Bubble is only ms-paint+ (entry point lowcode) and Photoshop (or Figma) is yet to hit the market.
Squarespace, Illustrator, Photoshop, Maya, After effects - whatever - its a different way to think about exposing the interface - they all have algorithms under the hood, but they wont expose it in the same language (of difficulty) as the algorithms - have a visual interface on top of it. Why can't web developers be treated as people who need high level components? (, databases, APIs, file systems, queues)
I know excellent mathematicians who cannot code. The guy can solve Math Olympiad problems and puzzles but he despises coding. Old school chalk/board or pencil/paper for him all the way.
A professor I know solves the quantum mechanical equations of metabolites to predict their MR spectrum to optimize their pulse sequence, and then does it directly on patients.
His QC simulation code in matlab would write the output of each iteration to a file because he didn’t optimize the object sizes. A simulation that should take an hour now takes 20 lol. It’s probably like in the Sherlock show how Holmes says he doesn’t want to waste neurons memorizing constellations.
Absolutely. It can't be said enough how much of a bubble there is here. Smart entrepreneurs who know how to get shit done don't want to waste their time learning a bunch of rote arcane commands to reify their vision. That said, these kinds of no-code panics happen twice a year around here, and looking back long enough, they're never more than a niche product. We'll see about this one.
I like to consider myself one of those people. I find the hosting/infrastructure side much more of an obstacle/hassle than the code. Getting the infrastructure out of the way and letting me write business logic and tools is what I'm most interested in.
In life sciences the people are smarter than any developer but software is IT-captured so all they can work with is Excel. No code is meant for these people. Software developers will never deliver what life sciences needs without no code.
I've watched life science people spend months manually clicking boxes in the tools they have, because they don't have a developer embedded in the team to write some 10-liner automation scripts. Same with stats, there are all kinds of systems like GraphPad Prism which try to bridge Excel and 'real' stats, where 30 lines of python and a CSV file would save them months.
More, they weren't even aware that these things could be improved. So no, I'm not convinced life science is intrinsically harder or the people there smarter. I attended some biochem and genetics classes at uni and once you have the foundations the concepts are actually pretty simple, there's just a lot of new terminology and random facts to memorize.
Agreed to some extent. "Life science" is quite broad so there's a wide range of topics with varying degrees of complexity and difficulty. I dipped my toes in various apects of life science during a biomedical engineering major. There are specialties overlapping with most traditional fields; from specialties comprising a large part of memorization like physiology, tissue engineering, and biochemistry (medicine), to hardcore organic synthesis (organic chem.), biomechanics (mechanical eng.), systems biology (control and graph theory), biosensors (physics, chem, biochem), imaging (CS::ML & physics), protein engineering/polymer science (chem, phys), bioinformatics (CS) which got me into CS/SE and programming, and many more.
Often there are multidisciplinary research teams and depending on how little a specialization already overlaps with CS/SE-ish topics, having at least someone who realizes which mundane stuff can be automated can be invaluable.
If they are really that much smarter, why don't they code their own tools? It's not like there's a programming guild which enforces the monopoly held by certified software developers.
I was once hired to do exactly that - develop real software to replace the weird hacks those life science folk built by themselves. Boy were they happy after that. So I guess your mileage will vary by lots.
I was a LS PhD, now I’m a developer. I can assure you that the average developer is far inferior to most PhD or post docs in any reputable university. Doesn’t mean they are absolutely smart though, I’d argue the biggest issue in research today is that there are a lot of not-that-smart-hustlers in it compared to what researhers used to be 60-100 years back.
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.
This feels like the one valid case to me. Non technical founder prototypes with no code until they can validate their idea and raise and then completely re writes.
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.
Thank you for a strikingly helpful testimonial. I’m skeptical of no- and low-code but based on your account, I’m now intrigued enough to give bubble a look.
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.
The "slow editor/loading times" and "giant bundles" is just technical, so should be "easy" to fix!
The hard bit I think is the "spaghetti no-code" problem that I've seen in nearly all visual-type programing environments. Just because it's no code, all of the logic still needs to exist somewhere. When we code we can break it apart in many ways, and how you break things apart and abstract things depends on the system.
But no-code tools are fixed, and you only have one way to divide up the logic. In Bubble's case, it means there's a "design" section with UI and data-binding, and a "workflow" section with all of the actions that happen: UI interactions and business logic are smooshed in together. You end up with thousands of boxes indicating actions, in a giant list. You can kind of group them, and you can colourize them - but everything is held together by convention. A single logical flow can require many UI elements, and tracking that logical flow through the various unrelated boxes is... spaghetti!
In Structure and Interpretation of Computer Programs it says "Every powerful language has three mechanisms for [combining simple ideas to form more complex ideas]:
* primitive expressions, which represent the simplest entities the language is concerned with,
* means of combination, by which compound elements are built from simpler ones, and
* means of abstraction, by which compound elements can be named and manipulated as units."
Most of the no-code tools seem to miss (or have a too simple version of) the final mechanism: "means of abstraction". So the entire system is built of combinations, that are poorly tied together.
About 6 months to switch - probably twice as long as it should have, because it was happening in parallel with maintaining and improving the no-code version, and the product requirements were evolving.
Switching off the no-code version was a happy day. We'd pushed it further than it was designed to go. The initial advantages of quick prototyping slowed down, and it was getting harder (very hard) to add new features without breaking old ones. Customizing the design (to our designer's high standards!) was... tough.
The coded version was better in every way - but part of that was because we learned a lot from the prototype. I personally probably wouldn't start a fresh project with it - but I would recommended it to (technical) non-programmers who want to get an idea out of their head to see if it's any good.
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.