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 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!"
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.
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.
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.
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.
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.
> 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).
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.
As far as I know - investment amount / % shares of company - so if your cap table has total 10% for 100k it's a 1 mil valuation - whether an investor is willing to bet that is a different matter however :)
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.
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.
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 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
<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.
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.
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.
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.
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...
> 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.
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.
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.
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.
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.
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 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.
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'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.
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.
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)
> 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.
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.
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.
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).
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.
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.
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.
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 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.
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.
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 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.
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.
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.
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.
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.
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.
No there is no problem with no code approach for a recursive design. It will scale flawlessly.
If amount of time to learn is the problem, they will come with a better design that will be smooth for a user to build. its a UX problem not entire product's problem.
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.
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.
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.
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.
I think regardless of whether what you say is correct or not - there is another benefit you are missing, the same one that Unity brought to game development - i.e. removing the developer as the bottleneck / gatekeeper for making changes - lost count of how many times our designer has created tickets to just update small styling things, or our PO wants wording or small flow changes. A tool that solves this at scale for teams will be worth it's weight in gold. #fulldisclosure am CTO of HarmonyCB - this is exactly what we are trying to achieve. Rightly or wrongly we still use a nocode moniker though, as it explains the area of work to non-tech people rather well.
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.
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.
"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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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. :-)
(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).
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.
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 :)
> 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.
> 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.
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.
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.
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!)
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.
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 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.
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.
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.
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.
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.
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.
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.
326 comments
[ 1.9 ms ] story [ 174 ms ] threadThe rest of the stack looks good but yeah wtf indeed
cries in legacy code
One day maybe it'll be a lucrative niche for contractor legacy-maintenance warriors.
That'll happen before I convince senior management that startups with React and Typescript can run rings around us, and that I can't find anyone fulltime who wants to work on our stack (or has even worked in not-React)...
If anyone wants to chime in with their stories about using Decaffeinate, I'd be interested!
https://github.com/decaffeinate/decaffeinate
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]
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.
Looking at you, Python, YAML, and Coffeescript.
At a certain point we should be able to declaratively describe entire businesses, and have the computer work with vendors and other people online to carry out business processes while we macro-manage it from a bird's eye view.
Something that could probably make lots of people very rich is a tool that allows anyone to start a SaaS within a few hours or days rather than months or years.
In my experience this is the hardest part of coding, to a large degree.
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.
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.
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 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.
*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.
> 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.
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.
https://en.wikipedia.org/wiki/No_Silver_Bullet
Isn't that just code?
I'm convinced that for sufficiently complex "no-code" solutions, you just end up with a poor mans programming language.
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.
Nope. There is more to programing than the imperative paradigm.
Often some spreadsheet has grown organically to solve some problem, with or without code.
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.
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).
Again, not sure how these companies last and compete where everyone else is learning how to code.
I can't foresee a mature product that is achievable without coding, at all. I always thought companies that uses those builders will, at some point, move out from MVP and hire some coders.
Well, I guess there're always market for everything.
You're conflating website builders with web app builders.
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.
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).
Repl.it and peers seem to be on the right track here
Do open source projects have an obvious "run this script to configure your complete dev environment in respect to this project" ?
I would be happy to spin up a new VM for every project on that basis.
I was waiting for something like this for years, it’s great.
Try it out https://Gitpod.io#https://GitHub.com/gitpod-io/website
PS. If you aren't impressed by a JavaScript app then take Kubernetes for a spin!
https://github.com/gitpod-io/template-k3s :-)
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.
One of the latest OSS projects I checked required gcloud and some online account to run make, it wad absurd...
As a fulltime working parent, 50 hours a month is more time than I am likely to spend anyway.
Awesome. Thank you!
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?
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.
./configure
1) Install an appropriate compiler toolchain.
2) Install whatever other tools are needed (like pkgconfig).
3) Install the necessary *-dev packages for the library dependencies.
4) Figure out which options to pass to configure to include the features you want and exclude the features you don't want.
5) ./configure
6) Go back to step 3 because you had a wrong *-dev package version, or you missed a library you care about.
7) ./configure
8) make
9) Diagnose the error messages and scream in frustration, because the compiler you installed in step 1 is too old/too new/too not gcc.
10) Install gcc version x.y.z
11) ./configure
12) make
13) Get the same error messages, because you didn't deinstall the first compiler and configure helpfully selected it again.
14) Give up in disgust and let someone else fix the bug you found.
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.
0.4) autoreconf --install
1) ...
> [...] 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.
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...
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.
I can't think of a reason it'd be impossible to build a no-code app that scales as well as code, and I don't have evidence that Bubble has failed.
If felt like there was a missing level of abstraction - everything was too intertwined. Making changes to anything becomes harrowing once the app becomes large - it was slow, and you don't know which UI elements are being accessed by any blocks - so it's really easy to break things without realizing. And the undo system gives you no visual clue as to what is being undo-d if it was in a different view. It was the most fragile system I've worked on.
However, many of those issues could be fixed, improved, or redesigned. If you were doing "regular" use-case stuff it was... fun! Our designer could get in and implement/test things really easily.
My gut feeling is that there could be system that scales well - but the escape hatches need to be reliable when you hit the edges.
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.
Let me guess, you are one of the brilliant ones.
I've met some dim people in science research tracks.
That's not really proving your point about them being "smarter than any developer". Lots of developers are smart enough to build their own tools.
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.
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.
Our microscope acquisition code is a single 25k LOC C file.
IMO Bubble is only ms-paint+ (entry point lowcode) and Photoshop (or Figma) is yet to hit the market.
I'd argue, no.
Bubble will not provide good handmade applications in the vast majority of cases.
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.
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.
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.
[1] https://twitter.com/Abishek_Muthian/status/14199150634906050...
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.
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 guessing many people would get this right up until the last step and see how much juice they could squeeze out of the prototype which I would imagine could be fatal in many cases.
I still wouldn't suggest this route for anyone.
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.
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 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.
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.
https://github.com/amplication/amplication
It's similar to Shopify, I can put up a store in ~20 mins and start selling immediately. I would be extremely misguided to try to "build an platform" when that problem has already been solved.
Same with no-code. Why code it from scratch when it's been solved already? If you want to go super deep, sure. Seems like the hate comes from a cross of not-invented-here syndrome crossed with only 10 billion dollar companies in 2 years are cool.
Here's an example of a Bubble biz. https://goodgigs.app/
“Your browser was unable to load some necessary resources, contact your IT network administrator and ask them to allow access to
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.
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.
There is library basically for anything you can think of. Out of the box you get all the batteries you need
Most code builders don't even give the devops/authentication bits.
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.
Math used to be written in prose. Arguably symbols are better.
I think feedback systems are a good example of where diagrams are nice.
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.
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
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.
Much in the same way that Home Depot is not for me.
* 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.
The advantage of no-code comes mostly for people who don’t have that same background.
If amount of time to learn is the problem, they will come with a better design that will be smooth for a user to build. its a UX problem not entire product's problem.
A vast majority of our day is spent focusing on the business end.
So if you don't know if a particular task will grow to that level of complexity, it is probably better use of resources to use a nocode/lowcode solution until it is clearly insufficient, and then take the pain of migrating to code.
I've worked with '4G' since Mimer, Mapper and all kinds of other contenders and until a few years ago (roughly until 'Mendix') low code / no code was a limiting environment.
But Mendix got it right and there are plenty of valid domains of application for the current crop. Plenty of success stories of companies that used it as RAD and validation tool. Once the money rolls in you can always do a rewrite, it is much easier to do that when you are successful then to try to find success on a platform that is slower to develop for. Like every other tool: use where appropriate, there are plenty of domains where this approach would not work.
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.
In the past I have found that as soon as a server push action is required things break down pretty fast.
IE display alert at a certain time but not if the user has focus in a text field. Show an message indicator instead.
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.
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.
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.
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?
Where before concepts like a logic branch and a loop were very foreign I think a lot more people know what they mean.
Also the industry has learned that 80% of the uses cases are around CRUD and different ways to enter data and view data.
The same way things like Twilio/Stripe/AWS speed up standard development also make no-code development more valuable.
I suspect the answer is that they don’t require you to buy seats for all the users, but wonder if anyone is familiar with both.
Not being Salesforce ;)
I worked on a bunch of Salesforce stuff for about a year, including building an app. Can't say I relished that time. I think the thing that seems attractive about Bubble is it doesn't carry the other baggage that you get included with Salesforce.
Total failure,
From reading the comments here, sounds like the no-code, the rebranded RAD, has the exact same problems again.
Creating fixed UI is extremely easy to understand. You just put a control, snap it to grid for consistent spacings and that's about it. Everyone can do it, very fast with very little time spent on UI.
Modern computers are highly variable in size. Small smartphones, large smartphones, tablets of all sizes, laptops, 5K mac displays.
Smartphones and tablets expect full-width applications. It's not appropriate to design your UI for 320 px fixed width. It'll be too terrible on larger phones. It's expected to have fully stretchable UI at least.
But that leads to very complex to understand creator UI. Xcode, Android Studio, Java Swing. They have powerful layouts, but their GUI to build those layouts are incredibly complex. You might spend lots of time for very simple thing. It's nowhere near good old Delphi, when I could put few buttons around and call it a day.
Of course I'm not arguing that layout managers are not needed. Another feature is internationalization and it was terrible with Delphi, when you had to translate a button but translated text could not fit into its fixed width. What I want to point out is that there's still unfulfilled need for layout manager, which is powerful, yet very easy to use.
May be we need some AI for that.
What killed RAD tools was the web, not them being a failure.
Minor nitpick :)
VB6 never had tooling to integrate with .NET.
Rather, .NET could provide an "interop" layer to allow you to consume components written in VB6, or just COM in general. You can also create COM visible components written in .NET that could be consumed by VB6 or even scripting languages such as VB script. But the tooling for that was delivered through the .NET SDK/VS.
But on your other point, you're right, there are probably a bazillion unknown VB apps out there still chugging along doing their one thing for a specific department or company.
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. :-)
(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).
I feel the view of ‘no code / low code’ is a bit primitive here. It used to be like that but last 3/4 years, the entire thing paradigm has changed fundamentally.
A previous company forced devs to switch/add a no/low-code tool. We were given 3 to evaluate: dell boomi/mulesoft/some other crap.
Most devs were gone within 6 months of that mandate coming in to effect.
Horrible, immature, limiting tools.
Do you think the A team devs are building these no-code tools after their initial prototype? No, they're being farmed out to design and development by middling product managers and devs - which never ends well.
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 :)
[1] https://easymorph.com
It's a basic error of attribution.
We need complex systems, and we build them typically by text source, which is the most efficient way of coding a system (as we've found over the decades).
Because the source looks arcane to an untrained eye, people attribute the complexity to the form of the code: text source, and not to the nature of the systems being built, which have some natural level of complexity.
Hence we try to alter the source form in some visual "friendly" way and believe we've achieved further simplicity. Demos looks attractive by connecting 3-4 high-level blocks together that make milkshake, or whatever.
In real world projects, using these visual systems end up even more complex and much less flexible than text source. Rinse and repeat.
Text is so amazingly intuitive that don't even think of it as graphical, but it is. As you also point out, the reason it looks complex is because software is complex.
A full-blown general purpose text-based programming language is of course always more powerful, but a task-specific GUI can be much more efficient for the particular tasks they are designed for.
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.
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.
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 were so many quirks and limitations that I wouldn't ever recommend it to anyone. It's to app development what Macromedia Dreamweaver was to web development back in the day, except worse because you can't edit the code.
I don't want to be overly negative so I'll say that I do see value in it for those who have no technical skills or programming knowledge to create some sort of prototype, but that's about it.
If you're willing to spend 4-8 hours going through tutorials to understand their metaphors & setup, then you can find plenty of interesting ways to use it that are faster than "normal" coding.
But if you just jump right in on the assumption that your coding knowledge will carry you through (which is what I did the first time I looked at it and sounds like what you did as well), then you're going to have a bad time and end up without an accurate view of what it's good at, bad at, and where the trade-offs are.
Can’t say I’ll use it again but good on them for continuing to improve it.
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!)
Automata are automata. But, ok, sure, I get it. That's too abstract for the intended consumer. So what we are selling as 'no-code' is something that can allow you to preserve your identity as not-a-coder. Hmm. Scratch seems to be the language that strikes me as something you could sell as 'not code'.
I've thought lately that 'Everyone Should Code' concepts didn't make sense. But maybe it does make sense -- if everyone uses computers to get their work done anyways, the "Here is how you can leverage your interaction with the computer to get your work done better/faster."
Data science type tools often only have the small group of people doing the complex computations themselves as users.
The final output in graphs and reports is what is consumed by non-experts and is again where Excel crosses paths with programming again, in a much easier and plug-and-play form than making your own charts/graphs (which in my experience is quite a challenging exercise code wise but again with way more freedom).
I’d imagine a spreadsheet with a form builder interface is the fundamental implementation of what Bubble is trying to do.
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.
Meanwhile Bridge Engineering, a 4000-year-old discipline, is still inventing new ideas and is still done almost entirely by human engineers. They use computers to multiply their expertise, but in no way are the computers "designing the bridge" for them. Why would automation make software engineers obsolete when that hasn't happened to bridge engineers (and shows no sign of coming)? Apps have been "building themselves" for decades: it's called a compiler.
How do you manage complexity? With software engineering. Writing software without writing code is like trying to design a bridge without doing math.
And if it's those crappy, un-maintainable, un-reusable CRUD applications you're saying no-code will replace, then I say: good riddance! But even if no-code is more successful than its wildest dreams, it's still just automating that lowest tier of programmer. Meanwhile, better abstractions, programming languages, type systems, mathematical advances, training programs, techniques, and architectures have been raising that water level every year for a long time. Even a good no-code solution has a very limited expected life when it's competing with that.
To your point, can I call the cement mixer a self-made building material that resulted in an accumulation of 4000-year-old of knowledge?
Every known industry has different levels of production to reach the final product. Which may be a tool builder to automate the industry. Exactly the same way the building evolves to the prefabricated. The limitations are with the raw material which is clearly to the advantage of the software industry.
> Meanwhile, better abstractions, programming languages, type systems, mathematical advances, training programs, techniques, and architectures have been raising that water level every year for a long time
I totally agree with all of the above. But that can be done along with investing more in the essential no-code tools. And if some has decided to go further good luck.
The argument about we need to do more so please let's stop the entire direction of automating because somewhere they still using CRUD, old-fashioned and unmaintainable code is similar to let's stop space discovery because we still have problems on the planet earth. We can do both.
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.
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.
At the same time, a tool like Bubble is incredibly empowering, and I want to to make it clear, I don't have any issues with the product, just the sentiment in the title of this article.
[1] https://github.com/Budibase/budibase
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.
https://bubble.io/blog/about-bubble/
I hope Bubble will innovate on this.