I think the biggest problem with this approach is at some point, they necessarily reach a level of complexity that it takes the same amount of time to learn how to use their "no-code" tools than it does to just learn how to code.
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 wonder if a more useful category would be "just-code". I.e., even today you have to know quite a bit of auxiliary stuff about computers, your environment, tooling, networking, to realistically contribute to a real codebase (much less start one from scratch!). I think this is the real unnecessary barrier. Logic doesn't go away, but plenty of smart people can do logic who don't want to learn esoterica about fixing their path when they try to brew install a different version of Python and the only way forward is to go learn what "chmod" is
Repl.it and peers seem to be on the right track here
Likewise, I've used several OSS projects that I'd be quite happy to fix bugs in or develop new features for, but every single time I've been put off by having to decipher some mostly undocumented or otherwise horrendous build process.
Ironically (or perhaps obviously) the OSS projects I've used that have approachable build processes and requirements don't seem to have easily-fixed problems...
<3 from the Gitpod team. Yes, indeed condensing CONTRIBUTING.md into a Dockerfile and then offering a single URL to "get ready to code/contribute fixes" from any device, anywhere is exactly what Gitpod is all about.
Seconding Gitpod, I really wish every repo would take the couple of seconds (to minutes, depending on how complicated) to just create the Docker config for developing it.
I use VS Code devcontainers a lot locally, and it's the same concept. This really ought to be something we aspire to as a standard IMO.
I've submitted several Gitpod + VS Code Devcontainer setup PR's to projects to spare others the pain of having to figure it out.
> 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.
Have used Vagrant for that, worked well, but not popular these days. Spins up a VM, you check in a script to install everything you need inside it.
Docker Compose isn’t bad for that either. Can specify a bunch of components such a databases, and a Dockerfile can specify what you need in your main container such as particular versions of Java or whatever.
Not to say all projects are using these things. But they’re out there, and can be used if the developers want.
What I'm talking about is a solution for people who don't even want to know what a "script" or a "VM" is. Allowing them to learn and write only what they would actually need to care about: code.
"What I'm talking about is a solution for people who don't even want to know what a "foundation" or "mortar" is. Allowing them to learn and build only what they would actually need to care about: a house."
Sounds pretty ridiculous, doesn't it? Why is it that people think that all this computery stuff like syntax and semantics, compilers, and operating systems is superfluous fluff invented by programmers to gatekeep their profession, instead of tools we created to actually do our job?
Well, there is a lot of complexity on them that comes on them that could theoretically be removed, at a pretty reasonable cost.
This is the original idea behind IDEs, in that they would come with everything set-up, and you could just jump into the code. But we lost this, maybe because of the web, or the great IDE extinction of the 00's, or the proliferation of non-integrated OSS, or some other thing that happened at the time, and now IDEs are about as hard to configure as a normal build environment.
Sorry, I just realized that the above workflow is wrong: Since you want to fix a bug, you'll probably clone the development branch of the repo, which doesn't even have a configure script – only source releases have that. So prepend these steps:
0.1) Install the autotools.
0.2) Run autoconf, no wait, automake, no wait, autoreconf, no wait, autoreconf --install.
0.3) Delete all files in the directory and checkout a fresh copy.
1 through 3 (I rarely encounter 6 and never 9) are baked into most OS installers and can be done once then saved as a VM or Docker image to be cloned. That level of pedantry is akin to saying "To compile the project applepie.io from scratch you must first create the universe."
_carbyau_: Simple command to configure your complete dev environment in respect to this project" ?
layoutIfNeeded: configure
adwn: No, because ...
I don't see any pedantry on my part. Also, this:
> [...] and can be done once then saved as a VM or Docker image to be cloned
is like that infamous HN comment proclaiming that nobody needs Dropbox, because you can simply "get an FTP account, mount it locally with curlftpfs, and then use SVN or CVS on the mounted filesystem". The original question asked about a simple command to configure a complete environment.
If ./configure just would work for that project out of the box, that would be great, but it seems more like an exception, because usually it's not sufficient and it breaks on some dependency issues that are easily solvable if you know the dev environment and pretty much need mailing list assistance if you don't know how their project works and you just want to fix an off by one error.
I went down a foolish path once of trying to create a simple flow-diagram -> code generator for the business people to use in order to do some basic logic with regard to email escalations. Got it done and ..... the logic was still hard for them. Oh well. Guess that's why we're paid well.
Yeah maybe the point is that it isn't the actual code that's hard, it's the thinking. Like, you wouldn't try to make a no-equations maths system. It's not writing down e=mc² that's hard, it's figuring out that's what you want.
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
Most of the time I spend with devs is figuring out objects and their respective data models. Low code is great but it sure doesn’t save 10x on resources, not for me at least.
I just looked through there website and I fail to see how it would be quicker or better than spinning up a quick rails app with a bootstrap template. Most of my time developing is thinking about the domain model and workflows. Once I've decided on that it takes a matter of minutes to code features and then you are not restricted in your ability to adjust and enhance after the fact.
I think there's a lot here that even as an experienced engineer I hate to start doing from scratch. Now combine that with time to focus on the business
* Where to deploy?
* Where to store the code?
* Which library to send emails with?
* Which 3rd service to send emails with?
A long time ago I spent 2-3 weeks building something to do all the above. After completion, I started going to customers and realised those 2/3wks were basically wasted time because I could have just put a google form and would've done just as good a job. Except now you get something a bit better than that.
If you can solve your issues with a google form then use a google form. I would never start a simple project as an app. All my coded projects are more complex than that. Some might be able to be done with no code tools but it would definitely be a pita to execute.
Your approach requires learning HTML, CSS, Bootstrap and Rails documentation in order to create a prototype.
You may as well be saying that getting furniture from IKEA isn't any simpler than buying lumber, saws, wax and paint from Home Depot and building your own.
I already know all those things and learned them for pleasure. Once you know it, nocode vs code is like the difference between using a GUI with a mouse or learning the keyboard shortcuts and using the command line. GUI with mouse just slows you down and is less flexible in general. Fine for lots of things but it's hardly a substitute for complex apps. Nocode apps are basically approximations.
I use nocode tools all the time, just not for building products. They’re great but they are also limited. If you hit any kind of success with your prototype you have to be ready to do it for real.
Having that background is what trained me to be able to think logically like you do to build systems which is the hard part. I wasn't born knowning this stuff either. In fact I only learned it properly in my late 20's.
I hope with $100m they can solve this. I think the only way to solve this is to hard-code so many different use cases into the gallery of controls, workflows and repeaters etc. that anything you dream of is easy to build.
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.
Suspenders is what you describe for Rails. It bakes in lots of opinions, obviously, but the idea is that you can go to production with this code by pushing it to your heroku repo.
Exactly. I had my tries with a few code builders, and soon enough I realized that it's often better (and sometimes faster) to simply learn how to code.
Most code builders don't even give the devops/authentication bits.
Well, learning how to code is not the only issue. Tooling installation, deployment etc is, at least for me, even after having written code for almost 40 years, a huge annoyance. I want to think about problems and logic; I couldn't care less about what editor I use or any of that and I care even less how it's deployed. As long as it's up and fast, I don't care. And this is still not that simple still, after all these cloud advancements to do except for the most trivial cases (static-ish websites).
This is why we vertically integrated most of our tool chain. Deploying our software involves emailing a customer a link to a zip file or importing a json configuration file for them in a web portal.
A vast majority of our day is spent focusing on the business end.
I think the problem is that you don't need a "mature" product to make millions of dollars.
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.
The problem here is that if Bubble gets _huge_ before solving the very obvious performance problems, the web is going to be in an even worse place than it is today. That Goodgigs site has a first load weight of over 5mb, when it could really be done in much less.
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.
I'm not affiliated with either site. Just thought it was cool. I don't think one could argue that building an MVP/SMB on a platform is more buggy than a 1-2 man shop building from scratch, though. At least not in the same amount of time.
It's frustrating. Especially now that I'm nearing 15 years as a professional coder, I already spend less and less time typing and more thinking and working on different views on the problem. Typing or reading text is not difficult!
This touches on the real issue here -- the assumption that, somehow, the logic gets easier to understand if it's in diagrams instead of text. Text is the arguably the best way to reason about logic, since there are millions of people wo do nothing else but read text-code all day, me included.
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.
> the assumption that, somehow, the logic gets easier to understand if it's in diagrams instead of text
One advantage of diagrammatic/block/flow-based programming is that it lets the programmer avoid fiddly syntax. Many experienced programmers have internalized this to the point that it barely registers as a concern except when learning a new language, but for novices doing things like correctly using tags/brackets/semicolons often lead to more failure and frustration than correctly implementing "hard" concepts like recursion.
For examples, check out the Alice project's papers from Dann, Cooper, Pausch, et al.
Yes but most problems are simple. It also happen that Excel-sheets become too complex for their own good, but most excel sheets are pretty simple and never grow to that level of complexity.
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.
Clearly you haven't actually used any of these tools or you likely would not have written it.
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.
My issue with no-code/low-code is that it puts the cart before the horse, or rather, the developer before the user. When you look at the amount of time spent staring at a screen, your users spend way more time (person-hours) looking at your app than you do coding it. Why all this focus on what is arguably the least important actor in the system?
Perhaps this is obvious but the answer is: cost. Developers are expensive. Delivering a viable poc cheaper, sooner, even if you end up having to redo it all anyway, can be an excellent trade off.
Wonder if there will be similar businesses and freelancers who will start to specialize in the migration from no-code to code in the same way that there are for on-prem to cloud.
Interesting thought. I was also thinking it could be good if you could reify your no-code solution into some sort of generated code, as an escape hatch. I suppose the trick is generating something vaguely sensible.
You can rephrase what you said as "This approach is better for low complexity apps", and in my experience, that's probably 80% of what businesses need.
I worked on a Bubble app that definitely hit the limits of how big apps should be. The work flow box things still give me nightmares. It's very hard to figure out the order things were executing, and we had to resort to A LOT of JavaScript blocks to break out of the normal workflow to get features working that weren't achievable with the built-in tools.
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.
"Low code" tools like Sikuli, Selenium IDE, UIPath or UI Vision are often used for test and process automation. They work well and have their place.
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.
My read is that there is a big unmet need is small line of business apps. Things that are currently managed with awkward email/spreadsheet workflows that aren't worth an investment in custom development. No-code apps can automate these with much less cost and time. This will overlap a bit with what's currently being done by teams of specialists but it will mostly be a new market niche. That may change in a few years though.
We try to solve precisely that with Amplication, where we combine low-code with custom code. We generate a node.js and react application based on low-code configuration and push the code to your GitHub repo
I (possibly wrongly) apply the reverse of the “$100 note on the ground” parable to no-code tools.
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.
That’s when they hire “yes-code” people to simplify their setup.
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).
I find the data modeling portion of Bubble to be very intuitive. Some of the UI configuration is also intuitive. The responsiveness of the solutions built W Bubble is lacking.
It seems like all the comments here are from non bubble users.
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.
I think two things are simultaneously true about no-code apps:
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.
"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."
At this point in time, there is more demand for bubble than supply of service providers.
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..
> You can throw 30 software engineers and have a system and increase velocity that way.
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.
I think you can read the statement through a charitable or uncharitable lens - the uncharitable way is "throw 30 engineers at a problem and it'll get faster"
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.
Given the kind of cocky tone elsewhere in that comment, I read it as “the biggest problem with Bubble is that if you’re an engineering manager who likes maintaining a fiefdom of 30 engineers, you won’t get to do that anymore”. No-code folks often try and make it seem like their biggest antagonists are corrupt middle managers, because they make for better rhetorical punching bags than individual contributor developers.
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
Incidentally the only Bubble app I've seen online was mentioned in the Bubble FB ad: Revetize. It actually made me do some research when I saw the ad last week as it seemed so absurd.
What are the limitations? You say it's suited well for MVPs. Is it well suited for our typical web app that has evolving and increasingly technical logic as business needs change?
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.
Sounds like a great case for MVPs and startups. Perfect for basic CRUD web apps I imagine. Also the extensibility with plugins means you can still "code" in things you need, which helps with edge cases.
How easy is it to debug something in Bubble for a dev and non-dev? They're using Javascript for the custom code part of the platform. Is it the same for the no code part?
Debugging the NoCode part in bubble is super super super easy.
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
Very cool! I have not tried a ton of Nocode but have been watching with interest from afar. My main question is: How do you go from Nocode MVP to a fully productionalized system? It seems like there's a gap there that would still require a team of engineers building the thing with code. Or do tools like Bubble provide ways to incrementally transition?
I left my job (Embedded software engineer, linux, raspberrypi, no web, no javascript) to dive into NoCode and started bubble freelancing and then quickly a bubble agency by hiring/building a team in Pakistan..
Tried a few other platforms (wappler, adalo) but not much luck. Focusing only on bubble now.
I had to use this for a client project once (per their request) a few years ago and as a developer it was an absolute nightmare. But I guess it's not meant for developers...
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.
You definitely can edit the code, but it's hidden within their plugin system.
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.
They had only just introduced plugins when I used it so I guess they weren’t as advanced back then. I can see they’ve added in many new features since.
Can’t say I’ll use it again but good on them for continuing to improve it.
Can someone help me understand the no-code movement and what supposedly has changed in the last few years?
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?
> Can someone help me understand the no-code movement and what supposedly has changed in the last few years?
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.
This is an excellent comment, I love how you phrase it. I've had people (even on HN) get angry at me when I suggest that we do have a wonderful visual/graphical was to write software: text. Text is a graphical representation of ideas. One that, as you point out, has been honed over hundreds of years for expressing ideas, and decades for expressing code.
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.
Text also has the best tooling around change management. Every developer I interview these days knows how to use source control, do diffs and code review, use local / staging / production environments and do rollbacks and hotfixes (etc etc). Sometimes the allure of these no code platforms in solving some important problems overlooks that even if they can do that well, they _also_ need to be just as good as change management, and likely the person building said app needs to understand all these concepts well.
I remember similar sentiments among geeks when GUI's became more commonplace compared to command line interfaces like DOS. But the reality is that for the majority of people using a GUI is much easier than a text based interface.
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.
Command-line interface isn't simply text, it's a conversational UI.
People who claimed GUI lost something were right, and that's why what was lost keeps coming back and it's still with us.
Google Search, Siri / Google Assistant, and the prompts in almost any video/graphics/3D-modeling software or other professional packages, not to mention the recent craze in "chat bots", all of those are essentially CLI reborn.
I design and develop a no-code tool [1] for the last 7 years. I see many software developers on HN struggle to understand the point of no-code. I'll try to explain.
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 can talk about one of the low code/no code product: Power Platform. It is a Microsoft’s low-code/no-code platform that let users create apps, develop workflows, develop chat and desktop bots and also use commoditized AI models. The platform is now in business since 4+ years and I know many Fortune 100 companies who have got 5000+ apps - both for internal org and for business with external partners, subcontractors etc. It is a massive thing. A simple license gets you a storage space in cloud, works with Teams, Office 365, Sharepoint etc and also apps thus developed (all using no code/low code approach) can scale (without rewriting using code) to talk to Microsoft’s business apps aka Dynamics 365 and 400+ other systems (inc Oracle etc)
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.
Let me know when you can do proper software engineering, with unit/integration tests and deterministic performance testing/scaling on them.
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.
Visual Basic was incredibly successful. From VB3 adding database support until VB6-ish started integrating with .NET, 10s of millions of developers built applications that you've just never heard of.
What killed RAD tools was the web, not them being a failure.
Would the low code equivalent from the era be MS Access? And the webification of that being MS FrontPage for UI w/ MS Access .mdb behind? You also had ColdFusion wizards, Dreamweaver app helpers, etc.
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. :-)
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).
Integrations, and the number of API-as-a-service tools like Twilio available today. The core idea's the same as previous shots at no-code dev, but the number of things you can do, the features you build into a product, just by integrating with another service, is staggering.
The same way things like Twilio/Stripe/AWS speed up standard development also make no-code development more valuable.
> Can someone help me understand the no-code movement and what supposedly has changed in the last few years?
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.
Back in the day RAD tools created forms with fixed layout, fixed sizes. Everyone used similar computers with similar displays. There were some simple ways to create windows with dynamic size, but those were very primitive and most dialogs were fixed.
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.
I’m interested in what these things do better than Salesforce, which is incredibly powerful Apps for gaps foothold, and allows both code and no code development.
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.
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.
Salesforce's pricing model is quite clearly aimed at large organizations. People still consider it to be primarily a CRM that can be customized to build web apps.
Some people here are giving examples of using Bubble a few years ago, and found it too limited to be useful. Have any developers here used it recently?
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.
Yep. My partner is non technical and has been using Bubble since October. I have great impressions. The responsiveness editor could be better, or maybe just better documented.
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.
Thanks, this is the exact kind of intel I was looking for. Especially that they have a API connector and REST API - I was betting they DID have that, as it's a moderately easy thing for them to ad that makes custom extensions possible.
(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.)
Yes, last moth. Bubble is such a nightmare to use and learn that it’s simply easier to learn something like Vue with Firebase. Just to get a basic value from JavaScript code to display in UI, you need to put together this weird pipeline sort of logic. The back end requests aren’t really back end, the logic is still front end regardless of where the code is executed. The result is there is no way to implement a queue. Using an API that rate limits, can’t use it in Bubble. For API calls things have to map into their weird data types and in their world, a phone number is an integer.
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.
Would not characterize it this way. I mainly use Zapier for marketing automation tasks, as do quite a few other people - regardless of whether that is what it is "aimed" at, marketing is a major use case for zapier in practice.
Pushing something into a spreadsheet is certainly a widely used zapier idiom. In 2021, it is capable of far more complex tasks, though.
Having myself used some no/low-code tools (service-now, mendix, outsystems), I do think they are the future, but...
I think they suffer from their business model, which often aims complete vendor lock in to milk their customers as long as possible. This is currently their only way to earn back the hard invested money of developing such a tool.
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.
No. It's an open source low code platform for building internal tools / business apps.
Hugo is static site generator for building websites.
We use Hugo for the Budibase website.
We use Budibase for a multitude of use cases, include: Applicant tracking
Api documenting
CRM
OKRs
Growth management
Onboarding
and about 100 other use cases (dashboards, admin panels, data collection, client portals, and more)
Amazon, NHS, Deloitte, F1, Audi, and others have used it. We had 50,000 downloads last month.
I'm not sure I share your enthusiasm for LC/NC as being the wave of the future. That being said, I have only spent a few afternoons with any of them.
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.
Another ServiceNow developer here -- I feel that no-code tools are great for internal tooling, but that they fall quite short when it comes to crafting a proper user experience. To put it another way: there will always be a crossover point where the platform goes from helping you to hurting you. You'll usually have to rely on forcing your users into training as a crutch, unless you're willing to invest considerable time in hacking around limitations and maintaining those hacks. This works just fine if you have a captive audience (internal employees, customers with contractual lock-in), but is basically unacceptable when it comes to the cutthroat world of commercial app development.
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 :/
Rational non-technical business users are exactly the reason we need open source tooling.
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.
I used to work for the client who bought a no-code solution all devs advised against. It was meant to make it so simple to write business logic that even non-technical BAs could do it. Nobody understood how it worked and the devs spent six months trying to make it work before business admitted it's useless.
Operationalizing an application within an enterprise is its own challenge, and it's adjacent to the creation of said application. There are many custom business applications that were not operationalized even when they were written well, covered all requirements, were tested and accepted. Oftentimes the businesses and vendors have no idea how to get from "the app is ready" to "the app is in use" state.
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.
Is Excel 'code'? If you answered 'No' considering cell formula expressions like cell references and arithmetic, does your answer change if you use functions? Flow control?
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."
I’d call Excel a database with a simple interface and relatively thin layer of optional coding that can be combined into very complex combinations that mimic programs. But a lot of programming is via building your own interfaces and input methods, whereas Excel is better for the computation (found in ‘backends’) and data science-y parts.
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.
A friend launched his startup recently with a product development consultant who built 1.0 and a lot of 2.0 in Bubble, in just a few months. The iterative mindset is a big part of why they moved so quickly but my friend reports that the tools helped and meant he could contribute with a lot of direct text entry and view layout, if not logic building.
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.
That is how I often feel about cloud providers like AWS. If you have to invest most of your time in becoming an AWS pro in order use it correctly, why not just learn how to build out a cloud using open standards.. at least that way you actually learned something useful, and not just a vendor solution that serves little purpose outside of its locked-in ecosystem.
Can you really compare these two without completely ignoring reality? With Bubble you can do some limited MVPs. With AWS you can deploy services to billions of people.
> With AWS you can deploy services to billions of people.
Yeah for tens to hundreds of thousands of dollars per month. You can do the same for free or a fraction of the price with other services (Cloudflare, etc).
And AWS has a ton of crossover knowledge with using any open source operating system (not even just limited to servers but using Linux desktops) and plenty of other deployment systems both hosted and self hosted.
So your expertise is much more easily transferred in or out of AWS. Making the lockin argument less persuasive.
Compared to learning the complex interface of one app like Bubble for building ‘no code’ apps which only has some value to some junior programmers looking for basic expression of ideas to get them motivated and/or some limited mental analogies to the real work of programming.
I think there are network effect benefits to having a few standards. Much as I detest vendor lock-in, it is helpful to have an existing pattern such that you can find and hire people who already know it. Right now there exist quite a few proprietary no-code platforms, but I suspect a possibly open standard will emerge, analogous to OpenStack versus AWS, or at least a few “winning” platforms.
Ah yes, one of the many languages where designers were like "you know what sucks about writing code? All that damn punctuation you write! It takes so long to type those curly braces. We're going to make a language where all our punctuation is invisible! Our code will be so much cleaner when all these important control-flow and context-determining marks are unable to be seen anymore!"
I'm right there with ya cries in not even Coffee version 2.
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!
I do hope for their own sake that Bubble looks at migrating away. At scale an untyped de facto abandoned 'language' is going to catch up to them sooner or later and limit their ability to iterate safely at scale.
[Disclaimer: used to work at Dropbox, but had no involvement in this project other than massive appreciation for the amount of effort involved]
> I do hope for their own sake that Bubble looks at migrating away. At scale an untyped de facto abandoned 'language' is going to catch up to them sooner or later and limit their ability to iterate safely at scale.
Looks like they founded in 2012, which is right on time for Coffeescript. So, there's a good chance it's not just Coffee - could well be Backbone, jQuery, Handlebars etc all mixed in there, too. You can definitely work React into a codebase like that (we have) but that could be a ton of work to get away from. Those codebases often ended up as un-unit-tested spaghetti.
Codebases from that era are a tech-debt albatross. Sure, you can make them work, but at some point something's going to come along built with modern tooling and just move so much faster.
Coffeescript already had a lot of the features we use in es6, and one can argue it’s terser. What’s the misery about? Sounds like you guys were ahead of the curve.
I still use it daily since I find it so much easier to write and read than having my code littered with semicolons and braces, and it enforces correct whitespace. I do see its limitations, and I wish efforts to marry Coffeescript with Typescript would be more serious.
It's really not. Coffeescript might be nice with fresh development and a small codebase but it's really bad when you're trying to figure out someone else's code.
Ah, good ole CASE. It's back like mold every few years and this year it's hot and humid.
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.
I look at No-Code the same way I look at Canva — one can create powerful designs in Canva that were once the exclusive domain of expert photoshop/illustrator designers. It does not replace them but reduces the barriers to entry for others which is a fantastic thing! There are many ideas that can be set free and realized with No-Code platforms that otherwise wouldn’t due to the difficulty. I say this as a software engineer. No-code won’t necessarily replace us but it will elevate the game.
The market is comparable to Wix? Divi from wordpress?
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.
Well it would be nice to have a no-code solution that elegantly can be moved into a coded solution, but I suspect that a company that makes no-code software has little incentive to help ppl stop using no-code.
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
Which is not to say that the low-code tooling for single developers or extremely small groups is not interesting and valuable in its own right. It’s just that this other stuff is even more interesting if a tool is to escape a small (but still incredibly valuable*) niche of making prototypes quickly.
———
* 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.
What's the difference between no/low-code and just an application? Most of these just seem like a solidly built application that allows users to do complex things. MS Word is a no-code application to generate documents, Photoshop is a no-code application to generate images, Chrome is a no-code application to explore the web.
I think it's more or less continuous from data -> application -> no/low code -> programming languages. Where you get more flexibility at each step.
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.
No-code platforms allow one to create applications via a GUI or similar. Word, Photoshop, Chrome are all applications. No-code applications like bubble allow users to define workflows graphically, and then execute them later as a part of an 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."
As far as I can tell, "no code" just means you can create automation workflows with a visual editor, "low code" means you have some extension points that support scripting. The terms only make sense in the context of automation I think.
I wonder how long it will take until I see “must have 10+ years of X-low-code-solution experience” in job searches and cold calls/emails from recruiters
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."
Have they ever addressed what would happened to the app you build if their company disappear one day? It doesn't seem safe to build your system on Bubble or any SaaS for that matter unless you know the company will never go away e.g. Salesforce.
At least two of those (Budibase and Saltcorn) are available as one-click apps on DigitalOcean. Saltcorn has users with no coding skills who have done this, budibase probably does as well.
I have zero interest in running a hosting business
I could see that use case inside a business though, where your non-developer staff can build their own line of business apps and your normal ops people can deploy them internally. I guess the other tradeoff there is support though.
This would be my concern also, same as with other tools like repl.it, etc. But it could still be useful for a prototyping phase. (Potentially. I have not used it.)
What's the next 10x technological innovation for no code? What would it take to remove programming from web development? Bubble seems excellent, but it is in a competitive field.
Declarative goal based development. You type in English what you want the application to do, and some developer tool generates thousands of variants (maybe through a genetic algorithm?) until you reach a design and functionality you're comfortable shipping.
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.
Because modern coding is still too low level to allow quick development of full blown applications. It would be really annoying if you had to tell a Subway employee behind the counter how to use their hands to pick up ingredients, how many ingredients to pick up, when to move the sandwich down the line, when to stop applying mayo etc. Instead we can just tell them to make a BLT sandwich and they'll do it with little to no intervention. This is the same ideal we should strive for in our compilers and interpreters. Maybe the request is too vague and the employee has to ask for clarification - and that's okay! That's still far faster than micromanaging their muscle movements. Modern coding is micromanaging muscle movements. We want to evolve to a point where we can just ask the computer to make us a cake and be able to eat it, too.
Just like everyone who thinks no-code solutions are a good idea, you are fundamentally misunderstanding what programmers do. We're not assembly-line workers banging out code as the product. The assembly line is the compiler. We're researchers, engineers, and artists; the code is the design document. You're saying you'd like the sandwich maker at Subway to make you a brand new sandwich that has never existed before without having to micro-manage what they actually put on it.
Writing code is nothing like micro-managing muscle movements, unless you're development an action that has never been done before (in that particular environment, circumstances, etc.). The level of abstraction in programming has been increasing every year since the 50s, and most of the code I write is me simply stating what I want to have happen at a very high level. When you want a BLT, you call getBLT(), unless a BLT is a brand new thing that has never existed before.
The "don't reinvent the wheel" crowd massively under-estimates the size of the problem space we are exploring. The space of possible problems to solve is unimaginably huge. There's always reason for new wheels when there are 10^10^400 different terrains to drive on.
From my understanding the OP was addressing using English to code and how that might look at the fundamental level. Not critiquing or misunderstanding what software developers do day-to-day.
It’s instead about different layers of abstraction. Which is the world we work in as programmers and one normal languages meant for communicating to other people is ill suited for and would be way more overly detailed.
So what OP is doing he is disregarding how complex the world is.
He is disregarding how much effort and how many moving pieces are needed to have an employee with which you can order a sandwich and have it done the same way each time.
For starters you have to have ingredients ready, standard ways of storing them and much more. That is what Subway worked on for years to have standards and be able to hire someone to "make a sandwich".
OP disregards that people hired in McD or Subway get !detailed! instructions how to make a sandwich and which ingredients should be put in which type of sandwich. Then their workplace is optimized to do so.
List of ingredients is very limited as list of sandwiches you can order in Subway. List of ingredients in software is unlimited and there is no standard workplace and people imagination about what software to build is unlimited.
There is lots of magical thinking in OP comment. He would like to magically remove all those layers of abstraction and gives simplified example, that breaks down when you think about that example more than 1 minute.
I think our fundamental disconnect is that you see a world in which all software is unique, special, and does completely different things. I see a world where every website I use has the same stupid follow button that does the same stupid thing, where every navbar comes with a logout button, where every social media app is trying to look like the demon spawn of Clubhouse and Snapchat.
I see a world where every single mobile app wraps a UITableView with a few changed properties.
You're trying to tell me that there are thousands of engineers out there designing cars with alternatives to gas pedals and steering wheels, and yet every car off the line still has the same gas pedal and the same steering wheel from 20 years ago. It just isn't reality. Almost all of this stuff is cloning existing stuff and tacking on some new feature. "But steering wheels today have so many more buttons!" Okay. Take a steering wheel, add some buttons to it. Is it really that alien from a steering wheel without buttons?
And yeah! That new feature, that nobody has ever done before? You'll need to describe it to hell and back. Because of course the computer won't know what you're talking about. But the point is to get you 80% or 90% of the way there using common language, from there you can hire developers to finish the feature themselves or you can write a design spec for the computer to build. And now that the computer knows the feature? Well, you can create derivative works off that stored knowledge, and you won't have to spend your time writing the boilerplate and scaffolding needed to support that feature.
I don't think I'm disregarding how complex the world is, I think you're disregarding how utterly predictable software is.
Everything you describe from my perspective is already solved.
*Every social media app...* - I have worked on warehouse automation projects, worked on multiple "specialists help tools" where logout button or just putting a text box was negligible effort.
Building HN like site - for me solved problem - there is bunch of clones on GitHub you can "git pull" and have it running in minutes. With docker it is even faster.
There is Wordpress, Salesforce you name it, you don't need to have any code and no low code. Hosting providers let you setup whole blog/e-commerce site with a single click.
In MailChimp I can create landing page with working email form without even knowing that HTML exists.
Using any of the frameworks like Rails or Django gives you that 80% or 90% that you describe, login/logout for free no coding. So if you just want to put some buttons and text boxes it is all solved already.
What developers are busy is filling in those 10% gaps that you point out, because it is still complicated and one has to understand things from multiple angles.
Using open source code and tools doesn't work if you don't know how to code. Paying someone else to do the work for you is no different from the current model and makes you dependent on their company leadership and business model. The best software development tool would be the one that replaces both of these.
> What developers are busy is filling in those 10% gaps that you point out, because it is still complicated and one has to understand things from multiple angles.
But to get 90% of the way there is not as trivial as you are making it out to be. The smallest useful software projects take weeks, anything with some amount of complexity is at least a few months or years. Even with Rails nobody is pumping out a PoC in under 6 hours. The goal is to make it take hours what used to take years with hundreds of thousands of dollars in dev costs.
This complexity does not come from "coding is hard" and developers writing "basic elements from scratch".
It all comes from requirements that business has and that world is complex.
I am just re-reading "No Silver Bullet – Essence and Accident in Software Engineering" by Fred Brooks. Everything that I am writing about is not simply my ideas, but something that is understood in the industry. That developers more and more don't address accidental complexity but essential complexity that is those 10% that you mention.
Even if that was written in 1987 - I totally agree with what is written there, because there is no General AI in sight that would do what you expect. All of it is even more so true with all the things I mentioned earlier.
No, because programming wraps around the instruction-based model that processors use to execute programs. When you elevator pitch a product, you don't give them a list of instructions the product carries out, you tell them what the product does in broad terms.
The theoretical next level of programming is being able to pitch your software to the computer, having it build it in real time, and playing around and tweaking it until it matches your vision in your head. This is not what programming is today because you have to spend far too much effort dealing with low level problems.
The theoretical next level of programming is essentially just a programming language for product managers, I think.
This is a longer term goal that we're interested in at Story.ai (https://www.story.ai). We think that the future is presenting the computer with a problem (in the same way you might present to a consultant) and through a process of disambiguation with your domain expertise, come to a solution.
Taking the history of a spreadsheet file, seeing what has been added to it over time, and where, and automatically generating a web application from that.
Often some spreadsheet has grown organically to solve some problem, with or without code.
10 years ago I worked for a startup that wanted to exactly the same.
Basically it was a toolbox where you could add things such as a map, an image gallery, texts, documents.
It was back in the days where everyone wanted to have an app even if they didn't needed. For example restaurants.
The project failed, it was just way too complicated, both for the end user and the development of the project itself.
Also a lot of stuff was faked.
When some one would order the App, it would still be "Compiled" by a developer and "compiling" meant basically coding what the customer had ordered within 2 days.
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.
I am an optimist about low code platforms and apps. I think sufficiently patient people with a disposition for a bit of logic can successfully achieve solid work.
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.
There are tens of thousands of everyday businesses running on WordPress and the WooCommerce plugin. That's no-code all the way, but since WP sits outside the Silicon Valley hype machine, it doesn't get talked about.
I used to work at a company which was doing "AWS Lambda" before AWS lambda was official and Bubble had just started. Unfortunately that company I worked at didn't make it through the journey - but Bubble did...and it's awesome for them. As a developer I tried Bubble and got frustrated but I can totally see how people that don't know too much about code can simply learn the platform and build ton of useful things with it.
Some can also make a living out of it. So that's good!
I also wanted to add that there's other nocode tools and then the "retool" startup that was here on HN a couple of times in the past....they branded themselves as No-code for enterprise?
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)
I am not expecting developers to welcome the new "No-code" movement. But eventually, it will happen. An app that's capable of building itself, supposed to be the next generation of building apps. Take a look at web development. It's revolutionary and changing fast. Users have more power than anytime before. More flexibility is being added every day with the rising of third parties services that make development faster and more reliable than ever. The question should be about complexity. How to manage the "no-code" complexity. Is it better for the user or it will add a new burden of learning? Does the no-code mean a special team to learn how to build without coding. Is it cheap, or hiring a specialist is better when it comes to fixing bugs and shipping new features.
The vast majority of software being written today is still CRUD applications centered on a database using a groupthink architecture where every noun gets a table and everything you ever want to know about that noun goes into that table. They're extremely brittle, completely un-reusable, and virtually un-maintainable. Meanwhile the front-end tech is iterating rapidly because we're at the very beginning of that sigmoid curve, not toward the end. Software engineering is still very much a baby discipline. We are brand, brand new, and not nearly as advanced as you seem to think.
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.
> Apps have been "building themselves" for decades: it's called a compiler.
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.
I feel less like I'm asking to stop space discovery until we fix Earth, and more like I'm cautioning against the claims of crystal healing and homeopathy. I would have no issue with a well-conducted, good-faith research study into crystal healing -- after all, simply coating a surface in silver dramatically increases its anti-bacterial properties, so clearly some "dark-ages alchemy" level claims are actually true. But with our current priors, given a random claim about crystal healing, what is the probability it's backed by solid research vs. the probability it's quackery?
Similarly with no-code. Should we stop trying to build no-code solutions? No. In fact there are limited used cases where it goes well, such as the Blender material designer. But with our current priors and given a random claim about what some no-code solution will be able to do, the probability it's BS is very, very high.
Maybe that's actually the answer: the place for no-code is not in replacing general-purpose programming languages, but in small, limited-purpose DSLs like shader languages (and even then, only in specific contexts). SQL is an example of such a thing, so if someone came out and said "I have a great no-code solution that's meant to replace annoying repetitive SQL queries in a limit set of circumstances", I would take that person much more seriously.
Do these tools provide an "integration path"? For example, is there any of these tools written having in mind the fact that they will be replaced by a full fledged software if successful, and as such provide some "injection points" for manualky written software to be executed?
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.
Credit to Bubble for raising such a large amount after years of hard work and dedication. I admire their tenacity, community and product but I don't agree with the sentiment 'make tech cofounders obsolete'. Why do you want to make a highly skilled individual obsolete?
I feel, in many ways, this sentimentalism is what negatively affects the no-code / low-code industry. We need developers and non-developers to work together, not make the other redundant.
Because it is exactly what their target customer base wants to hear. A non-technical person with an idea doesn't want to go into debt or give up significant ownership of their company just to see if their product idea is worth anything.
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.
In the act of transparency, I am the cofounder of Budibase [1], an open source low code platform, and have felt the unease and confusion this type of sentiment brings to young developers.
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.
also it's not just the industry that's going to fail if it hits the fan, but also all the other companies which rely on the no code platform. and if those companies are saas, they'll cause damage too somewhere else. or am i missing something? this seems like domino
I worked at a 'no code startup' for a few years in 2014. Here is how it goes.
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.
The most basic point of these tools is that they offer as basic things as possible. and in this way they can reach a real customer base. tech people's comments on this are often just "useless". yes, I don't think it will work either, but they can find customers.
Yeah there is also stuff like ionic, even Vue has something like that with GUI. With stuff like this is great to prototype create a MPV. Machine generated code is hard for humane to debug, at some point, it will hit a limit that becomes harder and harder to debug and make changes.
their website is obnoxious on mobile. im trying to scroll down the page to see what they are about but it keeps focusing on the email sign up box which scrolls me back up to the top of the page and opens my keyboard. i guess ill have continue not knowing what bubble have to offer
If Bubble is not a bubble, a coder should be able to sit down and figure things out intuitively and start getting better results than they would busting out create-react-app, or their java spring framework backend. Wait, that's not that unbelievable!
It's all fun and games until you get a requirement that requires you to code. Now you have to code anyway, but using something that has 0.001% of the support online in terms of docos, solved problems, stackoverflow answers, and ongoing support from Oracle/MS/Facebook etc. of mainstream frameworks.
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!)
I know I'm the old man screaming at the clouds here, but the biggest problem I see with this is that it leads to engineers being pushed to outcompete these systems in iteration speed, which is impossible.
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 don't think that's gonna be a real problem after a short adaptation time. Managers will learn the limits of the tools.
Of course, if a product made by bubble is sufficient to solve the problem, than the engineer did a bad job when making a custom solution.
That's fair, but you might as well just outsource all development if you're not going to use any code at all. It's the same liability, same opacity, etc.
Everything made from somebody else that you are supposed to configure in some way only works as long as you do things with it that were specifically thought of. This is true even for code, where you have a library or piece of whatever code that should do X, but you want to do X with a bit of Y, and you can't because the author didn't consider it. I don't want to be critical of Bubble specifically because I haven't tried it, but I do feel this is a very difficult task simply because it's hard to imagine all the things people might want to do. Whereas a programming language is just kind of a general purpose thing, that can do anything you want (with more work of course, and if you're able to). I see a need for this, but I'm curious how are they going to pull it off.
I really like Webflow and I think it's amazing for build marketing pages for startup but they lack features for CMS, Multilanguage and layout reutilization.
People writing programs in Excel while telling themselves that's not what they're doing is part of the problem. Excel is absolutely a programming environment; it is not a no-code solution! I'm not even talking about VBA: it's a 2D programming language (with a limited 3rd dimension in tabs) with great REPL support, integrated data, strong statistical and financial built-ins, and awful everything else.
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.
I wish we had No-business solutions. Like you only have to write code and the business side of things is being solved for you by a script, just watch money flow into your account.
No experience with ransomware, but from reading on HN it seems they have to have substantial "customer" support teams to help victims actually buy the bitcoins and stuff.
I know this is tongue in cheek, but it's actually an interesting frame.
"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.
I think nocode won't compete with code but more with internal workflow and non-public apps. Basically what we do in Google Sheets to track internal company stuff atm.
