No-code startup Bubble raises $100M
reuters.com
reuters.com
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!
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) ...
_carbyau_: Simple command to configure your complete dev environment in respect to this project" ?
layoutIfNeeded: configure
adwn: No, because ...
> [...] 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.
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
dhtiece9044ep.cloudfront.net
dd7tel2830j4w.cloudfront.net/
d1muf25xaso8hp.cloudfront.net”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.
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.
We have worked on over 20 client projects in the past 1.5 years using bubble.
Specialising exclusively in bubble now.
A way to describe the platform would be WordPress for Web Apps.
There was a census recently. ~75% clients are startup/MVPs ~25% SME making business tooling
Out client portfolio is similar.
I've hired fresh graduates in Pakistan, trained them in 2 weeks. And now have them working on a customer production app.
I've also taught bubble bootcamps. After 8 weeks of weekly 2 hour zoom sessions, I doubt you'll get much progress in a coded bootcamp. But these guys were building their app ideas. All sorts of backgrounds. Accountant. Art student. Podcast editor etc.
I have a client who needs a quick 2 week MVP. Done. I have a client whose 40+ employees use bubble app daily across four counting. Core business tooling.
The four pieces needed for a web app are Design Logic Data Hosting.
Bubble combines all that and reduces the barrier to entry.
No need to make comments like the famous Dropbox comment. Why not just SSH sftp xyz.
NoCode is definitely rising. We have won bids against coding agencies due to cost/time. The competing coded agency suggested 3 months. I quoted 2 months.
The day rate is somewhat similar. The speed is much faster. Very much needed for MVPs
That being said. There are drawbacks. You can throw 30 software engineers and have a system and increase velocity that way. However, bubble/NoCode is more suited to small teams (afaict yet)
Feel free to ask me anything.
Bubble.io coach, bootcamp instructor, agency owner here. Bubble all day every day.
Email : hn@azkytech.com
This makes absolutely no sense at all. You obviously have not read _The Mythical Man-Month_, and judging by what you've written I completely doubt the entirety of what you've said.
Speed is one thing. The long-term maintainability and usability of a system is another thing altogether. I have serious doubts about this 'no code' movement.
However, in the context of the other comments the GP made, I interpreted it as, "You can have a larger team with a properly built system with usability and maintainability, with good separation of concerns, and speed things up that way, but we have a smaller team and so bubble serves us well by allowing us to get things done quickly".
> I have serious doubts about this 'no code' movement.
I think the GP was pretty transparent about what it is good for and what it is not - I think the "wordpress for apps" is a good description. Wordpress is great for a particular class of problem, and then when you get to a certain level of complexity, you end up throwing it out and rewriting it, or putting so much on top of/around it that it is unrecognizable.
You’re right about the mythical man month, but I have a feeling this person is trying to grind an axe more than make a coherent point.
I really really miss git, version control systems, pull requests, automated ci checks etc.
Imagine a world without git and version control systems. Then apply that to NoCode.
Who changed which line. When did it happen. These things are normal with code/git. But not with NoCode/bubble (yet Jul2021).
Which file is the master. Which change to merge.
And then throw 30 software engineers at the project. Chaos will happen.
The comment was less about architecture and more about version control and merging which is still early days in the world of bubble compared to software engineering
When logged into bubble, add ?debug_mode=true in URL.
See the bottom toolbar. Step by step through any workflow action. (Event based paradigm) or inspect any element and check any state/property. Not chrome inspect tools. Bubble has its own debugging.
Backend debugging is slightly trickier. The logs are harder to read. Sprinkling some database entries makes it easy
If it is a business that needs Standard CRUD, relational dB backend, a front end. The web app is in a zone that is perfectly viable and can stay in bubble.
Cosmetic Limitations can easily be overcome with custom plugins built using nodejs. We had to parse a large CSV once and wrote a bit of JavaScript to overcome it.
What I wouldn't do in bubble - make a game. Tricky stuff. - intensive math on bubble server. E.g. any machine learning should be done elsewhere. - make something like bubble in bubble. Nope. Don't.
The business tooling is built to stay in bubble. SME/Cost. Many MVPs died. Some still MVP stage iterating.
Tried a few other platforms (wappler, adalo) but not much luck. Focusing only on bubble now.
Sports venue sign up and configure their fields (5v5 indoor, 11v11), onboard to Stripe Connect Express. Public booking page for the venue.
Players booking and reserving. Sharing invite URL with other players who can add themselves to the roster and make payments.
Venue sees bookings and payments.
This one is half done and I'm really excited about it.
https://nocodefounders.com/interview/revetize-interview
0 results on the Apple app store, but there is an app on the Play store called Revetize with "10+ downloads". Perhaps that's it?
https://www.divertsessions.com/pages/challenges-app (Instagram for action sports. App in app store is bubble by us)
Lots of business tooling ones that are a bit more sensitive. Booking systems for SMEs.
https://www.islamicfinanceguru.com/halal-investments/
This is iframed
"I'm afraid many are only showable on a Zoom call. Please book a consultation call and I'll share a project that aligns closest with what your project."
30 projects
0 images
0 gifs
0 videos
0 company names
0 case studies
Hmmmmm.
When turning down work and struggling to scale, our own website https://azkytech.com takes a hit.
Also, I'm working with a coach and his words are correct. Need to figure out ideal customer profile first and then invest in these.
E.g. have worked on 3 mobile apps . And they are really hard with bubble. The divert challenges app [1] is one of our projects. But just today I asked a guy to find someone else to work on their mobile app..
The tricky part would be user authentication. It's built in. So those would need to slowly migrate and need a strategy.
1) They really are a fast way to get an MVP that can be shown to investors and customers and even process customer transactions for simple businesses. Many simple businesses don't fit into pre-packaged SaaS platforms like Shopify, but don't really need a fully custom solution built from the ground up. No-code is good for these.
2) No-code quickly hits a wall when things start to get more complex or as the scale grows. At some point, trying to coerce the no-code solution into doing what you need becomes increasingly painful and a custom solution becomes necessary.
In reality, I think many small businesses and simple startups are actually a good fit for no-code websites. The Wordpress analogy is a good comparison because we all know how unnecessary it is to write a blogging platform from scratch in 2021 (unless for hobby, of course). Likewise, it's going to become silly to write a custom backend and frontend solution for a client whose entire business is basically a couple of web forms and simple workflows.
It's all about picking the right tool for the job, and no-code tools can be the right tool for many jobs.
But they're not the right tool for every job. Knowing the difference is important.
Totally right about the right tool for the job. And yes NoCode is the right tool for many simple crud apps.
There were so many quirks and limitations that I wouldn't ever recommend it to anyone. It's to app development what Macromedia Dreamweaver was to web development back in the day, except worse because you can't edit the code.
I don't want to be overly negative so I'll say that I do see value in it for those who have no technical skills or programming knowledge to create some sort of prototype, but that's about it.
If you're willing to spend 4-8 hours going through tutorials to understand their metaphors & setup, then you can find plenty of interesting ways to use it that are faster than "normal" coding.
But if you just jump right in on the assumption that your coding knowledge will carry you through (which is what I did the first time I looked at it and sounds like what you did as well), then you're going to have a bad time and end up without an accurate view of what it's good at, bad at, and where the trade-offs are.
Can’t say I’ll use it again but good on them for continuing to improve it.
I know Microsoft tried to allow non-developers to create apps without developers, and they have been trying for decades. But failed! They built an app that allowed you to drag and drop blocks, and they tried a visual query builder(not sure what the exact name was) for SQL. They added a workflow builder to SharePoint.
They all worked great during the marketing demos. But as soon as you had to execute a slightly complex process/workflow/idea, it broke. And that happens almost on day 2 after deployment. The only success they found in automation was by getting non-devs to learn development using VBA macros for MS Office.
How is the current suite of no-code apps different. How will they solve the problem with non-trivial tasks?
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 :)
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.
When I first looked at Zapier about 2.5 years ago, as a developer I found it limiting and just not useful compared to writing custom webhooks that I sometimes glued together with cron jobs, etc. But since late last year, Zapier has matured so much I am able to use it for almost every integration I need. It has probably saved me ~100 hours of development time in the past year alone.
I wonder if Bubble might have passed a similar threshold of utility, so that it is useful even to people who DO have good coding skills.
As a developer, you can't come in thinking you'll just get it. Bubble has renamed things for simplicity to non-technical folks and you need to take the time to learn their system.
Something I found great is Bubble's API Connector plugin and their REST Data API to. It lets you to call out to external APIs and CRUD into the bubble database. When my partner's app had a bit of "complex" backend logic that couldnt be easily done in the Bubble UI, I wrote a lambda function and they call it using the Bubble UI.
Bubble has been great for them. As their product / company grow that may not always be the case. But I think it'll hold up for longer than most developers believe, well beyond the initial prototype phase.
(With Zapier, I have used their so-called "Webhook" connector for that - set up an endpoint on my webapp that accepts a POST with a JSON payload, then make a zap that send data there in response to some trigger.)
But the biggest issue is that learning curve is even higher than tools like react. And the steps to do basic things are so tiresome it’s just easier to write code. UI prototyping is fast, sure. But not much faster than tailwind.
You want something pushed into a spreadsheet when you receive an email? That's Zapier.
Pushing something into a spreadsheet is certainly a widely used zapier idiom. In 2021, it is capable of far more complex tasks, though.
We need a, open source, community driven, no-code tool.
Using existing tools I often suffered from these things: - closed source. - expensive monthly fees. - Any apps build with it are not really property of the developer, but are intellectual property of the low code tool corp - either bad ux ui or not horizontally or vertically scalable - Datamodel, Algorithm or business logic can not really be extracted from the low code platform. - You now need to become a specialist in this low code platform. These low code platforms outdate faster then the typical programming language. - The best developers look down on it so you get "lesser" developers. - If a feature is not available in the low code platform then you are stuck. - If there is a real bug in the low code platform you are screwed because you now need to open a ticket, but the engineer looking at the ticket is more help-desk then engineer. The majority of tickets they solve are from dummies not understanding the platform and they assume you are one of them. Will take several months to convince them it was a bug and was never solved during the time I was on the project (2 years). - You cannot run it on premise, unless you have deep pockets - They have non or terrible git integration. Or other collaboration problems. - Due to their dynamic nature are often slow in performance. - Corps HR department runs a different low code platform then their finance department and now it becomes a political shit show.
Terrible situation when you grow beyond the low-code platform and need to move away from it.
I do agree 100% with your assessment that is incredibly painful to migrate your systems from one of these onto a mature, open-source web development ecosystem. I've witnessed the tail end of one of these Herculean efforts and it wasn't pretty.
The existing LC/NC platforms claim that their sweet spot is prototyping or MVP-style products. Even if one shaves a few months of development time off with this (and even that is not clearly the case), the extra work of building the new system, migrating all the data, hosting, etc, doesn't pass the smell test for me.
Open source web dev has gotten infinitely better for basic CRUD style apps. Hire a few devs with a couple years of experience, maybe even a few out of college, with one experienced engineering manager, and I can guarantee you will get a better proof of concept with React/Node, or any of the other widely adopted open source web dev platforms currently on offer.
Budibase (cofounder) - https://github.com/Budibase/budibase
Saltcorn
Hugo is static site generator for building websites.
We use Hugo for the Budibase website.
We use Budibase for a multitude of use cases, include: Applicant tracking Api documenting CRM OKRs Growth management Onboarding and about 100 other use cases (dashboards, admin panels, data collection, client portals, and more)
Amazon, NHS, Deloitte, F1, Audi, and others have used it. We had 50,000 downloads last month.
I think this tradeoff is pretty well reflected in how ServiceNow's workspaces feature failed when it first launched in 2018 -- and why it has since been overhauled. Sure, they kept the original plug-and-play no-code UI, but they retooled it to work on top of a full-code framework that fully interoperates with the no-code UI. It's the best of both worlds: you can rapidly slap together a UI, then replace individual components of the UI with your own code as you go.
Most no/low-code tools also really suck at version control, in my experience. That's enough to make me loathe working with them, even when they do save me time :/
What is with the obsession of devaluing technical skills so that non-technical business users can increase their profit?
Charge for your cost saving/tech-enabling tools.
Stop devaluing tech.
What rational person would build the foundation of their business on a closed source, proprietary web development framework? Only the less experienced or less than rational would choose this setup. We have decades of evidence that companies that develop these will inevitably:
1. Not support the use cases your business needs as you grow, despite your pleas.
2. End support for a necessary feature that you need. If you're lucky, you can continue to operate on an older version or a fork. But then you don't get any new functionality going forward.
3. Simply charge you more.
4. Go out of business.
There is a niche in exploiting the naivete of such business owners. That doesn't seem to be the goal of Budibase given that you can always pick up where they leave off in any of the above scenarios.
Without details it's hard to tell if the problem truly was in the app complexity, or because the "non-technical BAs" did not receive proper training, or because of something else.
Automata are automata. But, ok, sure, I get it. That's too abstract for the intended consumer. So what we are selling as 'no-code' is something that can allow you to preserve your identity as not-a-coder. Hmm. Scratch seems to be the language that strikes me as something you could sell as 'not code'.
I've thought lately that 'Everyone Should Code' concepts didn't make sense. But maybe it does make sense -- if everyone uses computers to get their work done anyways, the "Here is how you can leverage your interaction with the computer to get your work done better/faster."
Data science type tools often only have the small group of people doing the complex computations themselves as users.
The final output in graphs and reports is what is consumed by non-experts and is again where Excel crosses paths with programming again, in a much easier and plug-and-play form than making your own charts/graphs (which in my experience is quite a challenging exercise code wise but again with way more freedom).
I’d imagine a spreadsheet with a form builder interface is the fundamental implementation of what Bubble is trying to do.
The consultant does a lot of internal app prototyping and initial development in Bubble for Wal-Mart corporate so I imagine app builders are doing some substantial land grabbing in other large enterprises with their raised money.
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).
The 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!
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.
There are no video demos on their site for one simple reason: when you do find one on the YouTubes you'll see that it is very much programming. If you can create correct CRUD by dragging around "dynamic expressions" (yes, they're really called that), you could write them in TS.
As frosting on the cake, they offer gig workers to no-code for you! My father would make a comment here about wiping one's own ass.
Again, not sure how these companies last and compete where everyone else is learning how to code.
I can't foresee a mature product that is achievable without coding, at all. I always thought companies that uses those builders will, at some point, move out from MVP and hire some coders.
Well, I guess there're always market for everything.
You're conflating website builders with web app builders.
https://raganwald.com/2012/01/08/duck-programming.html
I’m much more interested in how they manage all the software engineering _around_ the low code than I am in the low code itself, e.g.
- version control
- testing
- developing at scale
———
* Way back when, some of us used Hypercard to do low-code prototypes and mockups of apps. It was absolutely a good tool for iterating quickly on working prototypes, and Bubble could be that with high-fidelity today.
"no-code" just seems like a marketing term.
Hopefully that makes sense. I think the key bits here are "it's being built through a GUI" and "you are building an application that will be executed later."
E.g if I want to crop a photo I'm not going to do it in Java even though Java gives me all the power to do that and more. And of course LaTeX is Turing complete so I could mine bitcoins with a document.
So in one sense it is arbitrary but in another the marketing is useful to give some idea of how much power/flexibility the application will allow.
I think you can argue Excel is a low-code application.
Personally, I think low code is a farce. It’s useful for prototyping but beyond that I wouldn’t use it in any production system.
"QuickBase Application Developer 11-15 years of experience. QuickBase application development and implementation, specifically in building/updating custom applications, developing custom pages, building dashboards, and translating business needs into technology specifications."
https://www.indeed.com/q-Quickbase-jobs.html?vjk=5024b4c17aa...
Budibase, Baserow, Appsmith, Saltcorn (shameless plug).
So those who can't code are then expected to self-host?
The lock-in is clearly a part of the business model.
I have zero interest in running a hosting business
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.
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.
Anyway, at least in their case you had access to the final source code.
EDIT: I just wanted to add that you are probably far better of if you hire a random guy from India on Fiverr to the app for you.
Recently I witnessed some friends get quite far by using a game engine called Unreal which allows people to use a “no code” alternative to C++ called Blueprints.
It can get a bit unwieldy when enough logic is created but if you’re disciplined about the diagramming etc it can be mitigated.
The right tool in the right hands can be like a torch in a dark abyss. (But please don't bring a torch in a cave full of ignitable gas)
Meanwhile Bridge Engineering, a 4000-year-old discipline, is still inventing new ideas and is still done almost entirely by human engineers. They use computers to multiply their expertise, but in no way are the computers "designing the bridge" for them. Why would automation make software engineers obsolete when that hasn't happened to bridge engineers (and shows no sign of coming)? Apps have been "building themselves" for decades: it's called a compiler.
How do you manage complexity? With software engineering. Writing software without writing code is like trying to design a bridge without doing math.
And if it's those crappy, un-maintainable, un-reusable CRUD applications you're saying no-code will replace, then I say: good riddance! But even if no-code is more successful than its wildest dreams, it's still just automating that lowest tier of programmer. Meanwhile, better abstractions, programming languages, type systems, mathematical advances, training programs, techniques, and architectures have been raising that water level every year for a long time. Even a good no-code solution has a very limited expected life when it's competing with that.
To your point, can I call the cement mixer a self-made building material that resulted in an accumulation of 4000-year-old of knowledge?
Every known industry has different levels of production to reach the final product. Which may be a tool builder to automate the industry. Exactly the same way the building evolves to the prefabricated. The limitations are with the raw material which is clearly to the advantage of the software industry.
> Meanwhile, better abstractions, programming languages, type systems, mathematical advances, training programs, techniques, and architectures have been raising that water level every year for a long time
I totally agree with all of the above. But that can be done along with investing more in the essential no-code tools. And if some has decided to go further good luck.
The argument about we need to do more so please let's stop the entire direction of automating because somewhere they still using CRUD, old-fashioned and unmaintainable code is similar to let's stop space discovery because we still have problems on the planet earth. We can do both.
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.
If yes, I can see that being reasonable as a solution to sliwly migrate from a no code software to a fully coded software.
I understand and appreciate the idea of prototyping without code, however this goes end in end with the reality that if adoption is big and you suddenly have to make something performant and it's impossible on the no code tool, you might have a big problem to do (write from scratch) with a tight timeline (performance exploding), potentially losing customers.
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.
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.
1) Apple will throw out your apps quickly. They say it is a templated app. Our app at them time had 100k active installs. They basically shut down a portion of the appstore.
2) The web version of 'no code' is a sick world of godaddy guis and broken html.
Bubble is great if you can't code and you want to save $5k on a developer (if the project is >$5k then its probably already too complex for no code!)
An engineer might get the task to make some feature, and the manager goes and uses bubble to make it and sees it only takes an hour, the engineer sits there for 5 doing it, you can imagine the rest.
The engineer might take care to make the code maintainable, fast, and expandable for some other feature that is planned, but nobody up the chain of command cares about stuff like that.
It's the kind of thing that makes the developer's lives harder, the apps more bloated, all to get the features out faster to the users for a few years until it all breaks down and you have to rewrite it.
I'm not convinced. I read this entire thread, but I never see a real benefit for users or programmers, just managers who enjoy pumping up some metrics so they can advance their career.
I hope Bubble will innovate on this.
Adobe Illustrator has a learning curve too; that doesn't mean that I should go back to coding SVGs by hand.
I hope the investors realise this.
Programming is just the act of solving problems in a repeatable way using computers. Excel is programming. I've seen plenty of Excel formulas that would make experienced programmers shy away.
This just makes the no-code movement look even stupider. The entire movement is predicated on selling to clueless vice presidents who have no idea what their expensive programmers are actually doing.
"No business" software startups are kind of possible. If the software/product is useful, important, unique or cheap enough the business side would be trivial. An iphone equivalent for $50 doesn't need any marketing. A script that automatically optimizes any and every AWS setup to save money. A consistently profitable algorithm trading. Sales will be trivial, fundraising, etc.
In reality though, it's very hard to be that good on one axis. In a competitive game, you usually you need to perform across multiple areas. Great product and decent marketing. Great marketing & decent sales. etc.
This applies to Low/No code setups too. Maybe you can build twitter, airbnb or Tinder using Bubble. But, that'll mean that your product is very unlikely to be as good as those built using a more powerful toolset. The software itself can't be your competitive edge.
People have been competing with Amazon, without code, since viaweb. You're just never going to launch aws.