I think the thing that "coding without code" fundamentally misses is that learning to actually write Python or Java or whatever is not the hard part of being productive in a business context. The hard part of creating useful software is that you have to understand a business process and its requirements so precisely that you can write it down for the computer to do.
I work with business stakeholders creating internal line of business apps a lot, and most of the time the requirements that they are able to articulate are some variation of vague, ill-specified, and flat out wrong. And it's not their fault at all, it's just that unless you've gone through the process of writing code it's impossible to understand just how pedantic and explicit you need to be when building software versus, say, giving your human colleagues instructions.
And by the time you've got enough experience to be able to do that, tools like this just get in the way compared to writing some Python or SQL or C# or what have you.
I think you are radically underestimating the perceived barriers to entry with programming. You sound a lot like the Linux advocates who think everyone should just memorize a bunch of commands, and get used to using shell. This type of insider view is often referred to as 'the curse of knowledge'.
I think you're right about perceived barriers to entry, and I certainly didn't say (nor did I mean to imply) that anyone should "just" learn to code. But I think the promise of "apps without code" is a siren song, always ending in frustration.
I'd never tell anyone that learning to code is easy (only that most people can do it with some hard work), but I would also never tell anyone that tools like this will make it easier because I do not believe that to be true.
My counterpoint (to your original point) is that it's not about writing code.
Making an app like this and putting it online (with roughly the same level of features) requires:
* Learning a backend language, like Python
* Learning how to design a data model
* Learning how to design an admin interface
* Managing authentication, security, and performance
* Learning HTML, CSS, and Javascript
* Learning how to set up a uwsgi server
* Learning how to set up an nginx server
* Learning how to set up an AWS VM and deploy the above to it
* Learning how to use a VCS
I'm an experienced programmer and sysadmin who has done all of those things and more over the last 20 years, and I still can't imagine going to the trouble of actually doing all of that if I can just log into HoneyComb and make everything nice and quick and just get it done.
There's value in learning how to do it, but there's also value in spending your time somewhere else. If you're making a simple CRUD app, bashing it together with Django and deploying it to an EC2 VM is almost definitely not your differentiated value proposition. If it's just a throwaway app to handle some mundane task, then it's definitely not wort hthe time it takes to make it if you don't have to.
> I still can't imagine going to the trouble of actually doing all of that if I can just log into HoneyComb and make everything nice and quick and just get it done.
That sounds all nice and good until one inevitably runs into limitations of the software. And then it has to be made again, this time from scratch.
> bashing it together with Django and deploying it to an EC2 VM is almost definitely not your differentiated value proposition
It never -was- the value proposition. Customers simply do not care about what stack you used in the first place. They will care when features don't get rolled out because of limitations. Or when bugs arise because developers duct-taped solutions together because of the limitations of their software-making software. Not that traditional apps are perfect, but that's one issue they don't have.
Yes, it is complicated, and if you're making a toy app it probably will suffice. But I would never rely on it for a business.
You sir have options. Every place I have ever worked has at least one app that someone hacked together through some combination of PDFs, Excel and Access. This is a tremendous opportunity for those folks. The ones who will never learn to code, never learn to deploy an application and never get enough visibility to have a developer assigned to their project.
For the everyteam, these types of tools are exceptional. I continue to be amazed by what dedicated people pull-off with these no-code solutions.
> Every place I have ever worked has at least one app that someone hacked together through some combination of PDFs, Excel and Access... I continue to be amazed by what dedicated people pull-off with these no-code solutions.
VBA, SQL, etc, which is probably what these apps are
written with, are code though.
Honeycode is a language of it's own too, it's just a trade off between flexibility/power and learning curve.
Agreed. When I was a teenager a worked at an organization whose entire business was run on internal applications built out in FileMaker Pro largely by non-programmer teenagers and young adults. It was actually pretty awesome, and I was still able to drop into a basic scripting language on the few occasions I needed to implement some non-trivial logic.
Why wouldn't you? People have used excel scripting for real business tools for decades.
I fail to see how Honeycode outright disqualifies for everything related to vast field of "business" because of its limitations. In fact, I think that is very much, where it will be able to solve a lot of problems efficiently.
All of them? No, just like any other tool. They all come with their set of drawbacks.
It's interesting to me that Excel had a low barrier of entry, but more advanced stuff gets pretty unwieldy. I'm used to wiring complex SQL queries, but some Excel stuff takes me a while to understand.
I don't understand why Microsoft (or Google) never worked on making the formula bar easier to read. It doesn't seam hard to imagine a more visual mode to help work with complex formulas.
Sounds to me like something like Honeycode is exactly what is needed then, as a replacement for Excel in a business context. It is yet to be seen of course whether or not they can achieve this, or just replace one unwieldy mess for another.
Spreadsheets are a very good model, and they have tremendous potential (which has been fully utilized) due to their "visual programming" aspect, but the excel formula language, array formulas and VBA are not the best places to ramp up to when things get more complex and advanced. There's quite a bit of horror stories of Excel gone wrong [1]
I've been positively suprised that Microsoft seems to have started to finally improve this situation with things like XLOOKUP and increasing Python support in Excel.
Disclaimer: I've published in a group doing research on Spreadsheet improvements, this is the professor's publication history [2]
I don't have any that I can share publicly, but I've had to debug some fairly horrendous sheets.
Spreadsheets are a great tool that allows people to leverage computers without knowing how to code, but they can easily get awful to debug. Even excluding stuff like VBA; which is code, but gets included via google-driven copy/paste development.
For example, excel formulas from other sheets can modify cells in the existing sheet. This modification can be logically driven from changes in a 3rd sheet. So cell 1 in sheet A gets modified for some reason when something changes in sheet C. Formulas in sheet B are changing these values, but good luck figuring out that. Breakpoints aren't really an excel thing, debugging complicated sheets is very hard. Unfortunately, most of these sorts of files aren't available online, as they are viewed as the 'secret sauce' for the businesses using them.
Your landing page is too few on details, so maybe you have solved this problem, but from your comment it seems that you haven't had to approach it from this angle. Trust me, businesses run critical decisions on excel sheets with creation dates in the early 2000's, and the amount of tweaking can turn them into behemoths. That is why the low/no-code solutions scare me- easy to start doesn't mean that you won't have an unsolvable hairball in 5 years.
I have yet to hit the issues per se, but what I am partially betting on, is that once spreadsheets are just an interface rather than datastore (where possible), some of those issues can be resolved. One will loose realtime reactivity, but what they were trying to achieve anyway was to access a "canonical" data point.
I should have a video and more details on the website in a day or two
Very interested in this concept, I just am unclear how the interface & data can be separated in a way that is easy for spreadsheet users to understand. Users see the cell as the canonical data point, after all, they see all their data in front of them. Perhaps the problem isn't the interface but the way the underlying logic is hidden.
I'd be interested in discussing this more tomorrow, my email is my hn username @gmail if you want to hit me up when you have more details to share.
Think most people are missing the point. There are thousands of Excel users who can write fairly complex formulas using declarative rather than procedural approach. They currently share spreadsheets by email. The entire spreadsheet - all data and all formulas are shared. Maybe they want to share only a subset with some folks, and maybe they will start small and keep enhancing the apps.
That's what this tool looks like will accomplish. A new class of apps will be built - that have never been built before. The so called app market will expand.
This doesn't replace the current apps, or the current set of engineers developing these apps. This grows the overall market to be 10x larger than what it is now.
Yup sharing all the data is definitely a pain point, A question I once asked someone during a customer interview is what is that employee left? what happens to the data?
1) Agreed. Writing the code is the easy part. Determining and defining what to build? That's the magic.
2) In the wrong hands, making things too easy can be detrimental. First, there's add too much, simply because you can. For instance, WordPress n00bs are notorious for adding too many plugins. Why? Because they can.
The second reason is, changing too soon without enough data, without enough user input. Yes, iteration is helpdul. But if it's borderline pivoting then that's likely to end badly. Again, in the wrong hands.
Agreed on 2), software development has become too easy, look at all the rubish people are putting online and in the appstores.
Javascript, java and python have made it too easy to write software. Would be better to return back to the days when everything was written in C and Assembly.
I wasn't talkind about engineerss. I was talking about no-code and the type of people who use such tools. That is, typically, no training, no understanding. They don't understand "Just because you can, doesn't mean you should."
I'm not knocking Honeycode and similar. I think they're great. But they are simply tools. They are at their best when they are paired with a user with some understanding and sufficient knowledge.
To add to that - Determining and defining what to build is not magic unless you write simple and elegant code that delivers on-time and on-budget.
You can have all the magic in the world upfront with planning and have it fail spectacularly without the right execution that is accurate, on-time and on-budget.
That's true. Until you realize that the accurate execution that was on time and on budget actually built something that didn't actuslly meet the business needs. Then what?
Yes. Execution matters. But it's only as good as understanding the target. Miss that target (read: meet biz needs) and no one will say "Yeah. But it was great execution."
True. I just see projects fail more often than not due to time/budget and/or shit code. Rarely do I see it fail because what was built didn't meet the business needs.
Although if you're in start-ups, they plan and then build terrible products all the time so the attention to upfront planning and the business needs is way more important in that realm.
Point of low code is to get rid of those smart ass developers who know those magic incantations and demand loads of money for their work.
What you get in low code reality are smart ass business consultants that know magic configuration options and demand loads of money for their work.
Just look at SAP, Salesforce etc.
From my point of view any barrier to entry doesn't matter because at some level you just trade one complexity for the other.
For non complex stuff excel works fine and low code is not advertised as alternative to excel.
Doing anything nontrivial in SAP and Salesforce also requires coding, only now you're doing it in proprietary scripting environments like ABAP and Apex respectively instead of general languages like Java and Python.
Presumably we would agree that writing a web app is more economical in Python, Ruby, Go, etc than in C or ASM. Both C devs and HLL (higher level language) devs are well-paid and well-versed in their tool set. The difference is that HLL devs can deliver value at a higher rate than C devs for this domain.
If we can agree on the above, then presumably it's conceivable that the same abstraction principle applies with low code solutions--yes, low code users will know their tool well and earn loads of money, but they will probably move faster than traditional programmers for this domain.
In my mind, this only holds as long as these low-code tools are really more abstract and not just a visual/graphical programming language (I'm sure there are very low-level visual programming tools that would allow you to manage your own memory, etc). It also depends on the domain being amenable to abstraction--if you have to drop out of the tool with some regularity to do things the tool doesn't support (e.g., performance, custom analytics, etc), there's a threshold at which the overhead of calling into a lower level language exceeds the benefits of the tool. I don't know where this threshold is, largely because the domain isn't well defined.
But I do think low code solutions are conceivable for certain domains. I would make the argument that Microsoft Access and Excel either qualify as "low code" solutions or they are at least proto-low-code solutions, and they both deliver tremendous value. I would perhaps even say that Access/Excel are to client-side applications what these new low-code solutions are to web applications. Not a perfect analogy, but I think there's something insightful in there.
There is nothing "low code" about work in SAP. Any time you need something remotely custom you need to blow the dust off of ABAP and code it yourself. This happens a lot.
Salesforce even requires you go write up some Apex when you want to get into heavy customization.
Now take a look at honeycode templates, those look exactly like things that SAP and friends promise you won't have to code. Inventory management and customer tracker, this looks like they try to sell the same things. Even if SAP is not marketing their stuff as low code or even if you have to write a lot of code there.
Perceived barriers are just that though. This doesn’t remove them - someone still has to learn this system, and you’ve got to pay them to work on it. With a system like this, you’ll quickly come to the cases that business people love to create anyway: you can’t do X with Honeycode but you need to make it happen anyway. And then you’ll wish you’d just done the whole thing in Python.
> you’ll quickly come to the cases that business people love to create anyway: you can’t do X with Honeycode but you need to make it happen anyway. And then you’ll wish you’d just done the whole thing in Python.
If doing the first versions in this thing meant you got to that position 6 months earlier than you would've otherwise, you shouldn't wish you'd just done it in Python from the start - your business would be missing even the functionality it has now for another six months.
You will, though, need to get creative and figure out the fastest way to get something close enough to X to make them happy in the tool, or with a hybrid tool+adhoc script approach, etc, though.
So there's still a lot of benefits there to knowing the fundamentals.
it's very hard for a business process to do with "good enough" code. in many situation either the output is complete and correct or it's of marginal utility.
it is also geared heavily toward internal software, so it has a very narrow scope, it's not really for startup, it's not really for large enterprise with their it deps, it's not really for jim in accounting with his excel honed trough year of hard work...
it will find a niche for sure, but the harder part of the use case it covers is modeling workflow interdependencies and that complexity doesn't lie in the software
The third option is a small army of temps to clean up the data - either incoming or outgoing, in order for the "good enough" code to work acceptably well. Judging from how many of these so-called second-class employees exist in the valley, I'm not convinced that it's actually possible for code to be better than "good enough" - but that doesn't stop me from trying!
Writing a first iteration fast with no code is a smart move. You can later on create a second iteration with more traditional languages and tooling like Python.
I tend to disagree here. The thing that makes writing business software take a long time (using code, to be pedantic), isn't the fact that it's in code -- it's the fact that the requirements are often so fast and complex that there's no way to capture them in the application without taking a good chunk of time. If you want an application that doesn't actually meet your requirements, but at the very least, exists, get a group of competent-enough engineers together and they'll be able to whip you something up pretty quickly, I reckon. About as quickly as non-techincal people would be able to make something of equal usefulness in a non-code tool.
If you have access to only engineers, why would they learn this new non-code tool? If you want an application that meets a very sparse, loose set of requirements, just get them to create it using their normal tools -- it won't take relatively long.
If you have access to both engineers and business folk, there's no reason to have the businesspeople write such a requirement-lax application using a non-code tool, since if all you really want is an MVP that doesn't really meet your requirements, get the engineers to do it -- I'm sure they'd be happy with the freedom to throw requirements out the window. And then when you want to expand on it and flesh out those requirements, the engineers don't have to port the whole thing over from whatever proprietary non-code tool the businesspeople could have used.
If you only have access to nontechnical people, you're kind of screwed. Sure, you can have business-savvy folks whip up an MVP using one of these tools, but then when you want to expand on it, what do you do? You need technical people somewhere in the pipeline to make this work. If you didn't have access to engineers in the first place, this is the juncture at which you could hire some to port the application, but is the technical debt you've introduced worth it?
I don't know -- tools like these seem to target aspirational nontechnical people who don't have the foresight to think two steps ahead.
It has been my experience over and over again that having a mix of engineers and business folk, does not lead to the business folk getting the engineers to do what they want. Which is why we see so many things built in Excel and Access - the business folk know what they want, but their bosses send the engineers off is some crazy other direction.
A MVP is quite often exactly what these people need to get the bosses engineers working on the right product. And often it's not enough and the business folk end up using Excel for 20 years with a string of failed products coming out of engineering.
As a programmer, I'm very lucky, but none more than here. I have access to an infinite amount of programmer time. Okay, realistically that's bounded by the number of productive hours in my life, and more realistically, my level of interest in a thing. But it's easy for me to tell someone else "oh yeah, just get a programmer to do it" - because if I had those same desires, that programmer is me.
But looking at the job market for programmers and the salaries commensurate with the demand for them (both in and out of the Valley), "access to a programmer" is something that many people still have to reach to get, and "learning to code" is not a quick or easy process. Honeycode isn't the first product in this space, nor will it be the last.
Indeed, I've observed that while programming seems easy, a large fraction of people find learning to program is utterly prohibitive. This includes many really smart people. And I don't think we understand why.
But here's what I think you give up if you don't have code. Over the past 70 years, one of the problems that computer science has studied is how to manage the size and complexity of programs and development teams. This complexity includes not just the program you're working on, but potentially the entire ecosystem of algorithms and solutions available for your use. Nothing comes close to "code" for addressing this problem.
As a result, I think if you're going to give up code, you have to accept that your projects will run out juice if they get too big or complex, or that you will have to solve some interface problems with manual steps. That might be perfectly OK.
> one of the problems that computer science has studied is how to manage the size and complexity of programs and development teams
Did we though? Can you point out some books, or PHDs or whatever slightly more scientific and substantial than blog-post anecdotes?
I honestly believe as an industry we completely don't know how to scale development and I would love to read something that helps understanding this challenge.
Well... I have to admit that I'm not a CS'ist, and I just assumed that a lot of the progress has come from CS.
But I'm just thinking of something like the transition from BASIC to Pascal (which I experienced in 1983). There were rules of thumb that we learned in BASIC (avoid global variables and GOTO's) that were formalized in Pascal, and Pascal also let you create much more elaborate named structures, and control the scope of names more precisely.
That's just one really simplistic example, but it rather profoundly improved my programming. On the other hand, I can believe that scaling is still a struggle -- there is still a point where we run out of juice, but it's a lot further than you'd get with BASIC, or with Excel-sans-macros.
> You sound a lot like the Linux advocates who think everyone should just memorize a bunch of commands, and get used to using shell.
But they should. People aren't stupid, shells aren't horrifically complicated if you try a bit and once you climb that hurdle you're suddenly a "tech genius".
Just like some developers should learn that developers are users too, and not all of us enjoy doing the stuff the hard way just because it feels better somehow.
I hope you don't really believe that people use the terminal because it is "the hard way". That simply isn't true. There are things where the shell makes it _easier_ to do things - the most common being batch operations. There have been attempts to build GUIs around such tasks but they actually take more effort to understand than using the terminal.
Just like every tool, the terminal has its place. So do GUIs.
I agree. The shell, just like all other programming languages, allows you to trade the time spent learning a domain specific skill for an easier method of doing things.
Using the batch operations example -- if you know shell scripting, you can save yourself time doing things manually -- but you need to have already traded in the time to learn Shell scripting.
GUIs allow you to reduce time spent learning a domain specific skill at the expense of overall efficiency.
Yes I do, my UNIX experience goes all the way back to Xenix and I have used most of the UNIX commercial clones, and also did porting across multiple platforms.
Whatever the UNIX shell provides, can be more comfortably over an interactive graphical REPL, which even allows for proper graphical debugging tools when pipelines don't work as they are supposed to be.
Secondly, since UI/UX has always been one of my focus, I have seen too many throw away CLI tools that don't respect the users of the tool, because "hey they are developers as well, they can fix it, deal with its issues".
Grandparent said "that learning to actually write Python or Java or whatever is not the hard part of being productive in a business context". I think that my response was reasonable, and directly addressed one of their most important points.
writing a good (english) novel is not just about learning the english language and grammar. But it is required that the novelist understands the english language well, but it's not sufficient - the novelist also needs a good grasp of more abstract concepts and have creativity as well.
I think he's partially right, and you're also partially right.
Learning to code is an extremely high barrier to wntry, but its also highly transferable. If you can write Python, there's tons of jobs you can get writing Python, and with a little extra work, you can pretty easily transition to another language with a whole other world of opportunity.
The problem with these "visual" languages, is its a lower barrier to entry, but its still takes a detail oriented person, and ends up being very specialized, so there's less opportunity to leverage that to another job. So if you're a person than can learn a visual language effectively, you might as well go the extra 30% and learn to code in a "real" language.
The only thing low-code solutions do is lower perceived barriers, not real ones. A low code solution has done it's job if it got you to sink enough time into it that you're stuck with it. They're great for prototypes and simple tasks.
Low code solutions work by presenting a simplified view of the world to the user. Once your vision doesn't mesh with their abstraction, you end up having to dive under the hood if you're lucky enough to have a solution that lets you. In the best case, you've now had to learn the underlying tech and the abstraction.
There are enough bariers in the earlier steps for those barriers to entry with programming not to matter.
1. Understand the problem
2. Break the problem into subproblems. Goto 1 till subroblems
are small enought to be tackled.
3. Develop the algorithms for each of the subroblems you got
after step 2. No handwaving allowed.
4. Implement the algorithms.
I'd say for majority it ends around the step 2. Programming only matters at step 4.
I think you are doing software engineering at step 2 as well (base case and build recursion for example). The reality is, CS skills are useful even in low and no code scenarios.
I think the emphasis here ought to be on "perceived".
Having taught people to code, there's a lot of "perception" about what is hard that you need to overcome, but in practice, people learn that part comparatively easily.
When I made the move from native software (Windows applications w/GUI in .NET) to web applications, I found the transition to be _extremely_ overwhelming.
And for the most part, the frustration came from trying to manage setups and dependencies, and keeping up with the bazillion of packages.
I can absolutely see a beginner getting turned off by the initial process of just setting everything up, before a line of code has been typed out.
>>the requirements ... are some variation of vague, ill-specified, and flat out wrong. And it's not their fault at all, it's just that unless you've gone through the process of writing code it's impossible to understand just how pedantic and explicit you need to be when building software versus, say, giving your human colleagues instructions.
I (mainly) work in inventory management and this is so very true. For our specific requirements, there wasn't anything in the SaaS space that would work short of SAP or Oracle, no other vendor had all the requirements in one package.
However, our quality control department had tasked me with writing standard operating procedures (SOPs) for most of our receiving & warehousing processes. I swear, those .docx files took longer to write than the custom inventory solution I ended up coding. However, most of that SOP time was sitting in front of a whiteboard trying to figure out how to explicitly define all the processes in detail. This experience was incredibly valuable though, I'm convinced that having to define the business process beforehand made the software vastly easier to write. I spent more time getting django configured & setup than coding the business logic, and the business logic was complicated enough that I couldn't find an off-the-shelf solution.
I've since done this for some other projects at the same company (I wear a lot of hats), and spending 1/2 a day bothering the 'customer' with my incredibly pedantic questions while we drew up a flowchart or bulleted list saved so much time down the road with catching edge case bugs. Note that I'm not talking about waterfall style dev, this only focuses on the actual business process and not at all on software. There aren't any questions about how the software should function, but instead 'if a customer has this problem, what do we do?' The trouble is, this strategy wouldn't work if you can't force the user to spend quite a bit of time on what is an unpleasant process for everyone.
I think its good to realize that the waterfall method really encourages this. Thinking through everything before building can really help formalise informal workflows.
... then you get into standardised work flow diagrams and you are so far into UML that it just becomes programming again.
Tools like this are great for getting 80% of the way there, which is often enough in some contexts. I look at these tools like I look at spreadsheets: you can stick a surprising amount of business logic in them, and while the thought of using them might make developers shudder, they get the job done.
If you need that extra 20%, hand the resulting project off to professionals to build an application out of it.
That's the theory, but don't forget the time you spend upgrading Python because some dependency needs it, but some other part isn't compatible with the new version so you spend an hour on Google trying to sort that out.
Or the time you spend trying to debug some basic functionality you've written 20 times before because it isn't quite working with everything else for some reason...
That is true, but, equally, you are underestimating the time you spend trying toi do something that your no-code framework can't do, and the extra cost of working with it.
Is there even a way to update Python on Windows? I haven't figured out any way other than duplicate installs, a bunch of manual copy/paste/extract of older packages, and hoping for the best.
I can't agree enough with what you wrote, but I can add some colour.
'It is impossible to automate this club with 100 membership options and 300 members, it is just too complicated'. I think there is some complex psychology behind statements like this. There are elements of not knowing what is possible, elements of not knowing how to break down a problem, but also an element of not wanting someone from IT to come along and show you that the job you care about and you have to work hard at can be automated away. I tend to approach these things by building rough prototypes of the simplest case, and using that to find the edge cases. All the while using lines like, 'this will allow you to concentrate on the sales part of your job, rather than admin'. But here is the truth, most people want stability in their work life, and are terrified of what systems people might change.
In another sales-order flow project I worked on I was suspicious of the time taken to manually intervene with orders (I was worried it was stopping us from scaling), so I started asking questions like, 'what takes you a long time?', 'what could be improved?'. Apparently nothing, it was all fine. We started to map the process out and began the tedious work of finding out how the manual process works....one day the person was frustrated with one element of their job and let slip about a process that took hours that had apparently slipped their mind previously. This was manna from heaven. I attached two senior developers to the team and they fixed that problem in half a days coding, but it couldn't go live because x needed doing first. I let them do x, and they found y..so it took around three months more to fix this simple flow, I would say there are in the order of 1000 loc generated in total. I agree, it is the human part of these kind of systems that is hard, not the coding.
I'm pretty skeptical of your assertions, here's why I think this will be big:
Many people aren't even going to try to do anything involving code, and it doesn't matter if they could if they tried, because they won't.
Lots gets lost in communicating with a developer.
Creating one of these honey comb things is going to force who is working on it to be precise, in a much better way than talking to a dev (or writing a story). In no small part because one can play and experiment without being intimidated by a dev. It might be buggy but the feedback loop is tight, the creator can see errors and fix them fairly immediately.
The result probably won't be beautiful, but neither is anything I end up producing.
There always will be a developer, it might be some business person instead of dev but that will be an owner of some app. You don't want to create new application each time. Most of applications are there to be maintained.
You hire new accountant and what he does just throw away all records and build his own app from scratch?
Someone will create that honeycode thing and then he will be responsible for changes in that application.
In the end you have a maintainer on that app and lots will get lost in communication with him.
On the other hand you might have one off apps that are needed for specific task, but that is what excel is for. Reading about honeycode I see it is not about throwaway one off apps. So there will be someone who is "developer" who has to know details of honeycode and application he maintains and bunch of people with requests who don't bother learning what that honeycode thing is.
Like the parent says, there are absolutely going to be people who will be defeated by Honeycode (or any other solution no matter how easy) because they simply can't or don't develop a model of the domain that an app can serve as an interaction point for.
As you say, there are absolutely going to be people who can do that, with Honeycode or something else, but are put off by the specific arcana of some language/dev environment. Just like there are people who don't think of themselves as developers but do an awful lot of spreadsheet work.
~20 years ago, I spent a year or so mostly creating and updating Lotus Notes 'apps' for internal use at my employer. Most of these were CRUD apps to support existing business processes.
The v1 of each one, which was immediately useful and used, usually took me 4 to 8 hours to create. That includes the time talking to the main user to understand what they needed.
I can't achieve the same speed with Django or Flask. Maybe others who are more experienced developers can?
That's interesting. Personally, learning Django to be comfortable with it takes quite some time for me. Translating the business process to code means you have to be comfortable with the framework, no matter what you're using. What do you often you feel you're stuck on?
It's not that I get stuck. It's just that, with Lotus Notes:
- authentication was already taken care of
- adding a field at a particular place was one step (rather than updating a model, updating a view and running a database migration)
- I could make small changes in production (ok, maybe that's not so good!!)
- adding events between different Lotus Notes apps on the same server was a snap
- the learning curve to become productive was just a few days
Of course, I'm not saying every type of app fits this model. Or even that every app that fits this model can be strung together with Lotus Notes functions and without using 'proper' code (Lotus Notes had its own variant of Visual Basic).
But for many use cases, you could do a lot in a very short time without very few lines of code.
Yeah, that's definitely a good fit. I think most companies would be much improved if they can find someone to help with those kinds of apps day to day instead of having to outsource a shiny app that gets unmaintained or takes too long to develop.
Great insight. Since the process of creating software must be pedantic, then it seems we must push towards ways of sharing the burden with as many people as possible, and not just ones that can understand the "computer way". And I agree with you that a new-shiny-tool is not pushing towards this direction.
Just this week I had a lengthy 2 day discussion involving 4 other employees, 8+ long emails, and hundreds of words in chat ... all to figure out that we need to add an if/else statement and two simple lines of code.
The code took 2 minutes. The discovery took 2 days.
Of course it's not the code itself that is complicated, but what do you want the overall system behavior to be (are there upstream/downstream/breaking effects?) and why. And do you understand the system well enough to know the right way to make the change - sure it only took you 2 minutes to code it but that's because you already understood the system well enough to know the right place to change the behavior.
I've worked with multiple companies who've had some form of no-code products. In every case, incorporating the full gamut of business requirements entails in too much of configuration and complexity in the UI. At this point, there are only two options left for the user -
1. get trained in the software which itself is time consuming and a challenge
2. ask the vendor company to create the app, which kind of defeats the whole purpose
A few other points -
1. People to whom no-code apps are targeted tend to be in the management rather than the actual users of the system. Management is usually aware of the bigger picture or the more complete workflow.
2. However, managements requirements tend to be more around tracking, reporting and monitoring.
3. The last issue being management tends to get caught up too much in the UI rather than the underlying functionality.
Unless no-code services restrict themselves to a very specific niche with clear workflows and fewer options of customizability, the products are bound to be cumbersome, complex and having a very narrow applicability.
I agree that coding is the easy part. But exactly because of that it shouldn't get into the way. I really think that is useful to have tools to generate simple apps without coding. Who wants to create the thousandth CRUD app? It is nice to have a tool capable of create apps from simple logic and reserve programming for when it's needed.
At the end of the day you have to translate requirements into software. Whether that is through a GUI or textual. Textual just happens to be an extremely effective method to do so.
Every application in existence is a CRUD app. Software is just data processing after all, reading and writing bits.
I think it is extremely egotistical to think that your way is the only way to do things. If some people are not good enough with text files, then by all means we should provide tools so they can help create simple apps without traditional programming skills.
I think a lot of these low code environments are trying to capture people when they prototype software using Microsoft Excel. The thing is if your stakeholder can also make the product it will save you a very large amount of money and then you could hire someone to port it to Python.
I feel like this is pretty spot on to my experience with these tools. I've tried lots of these tools, and been in place to have to recommend them to customers looking for workflow and forms tools "so our business analysts can build things". Inevitably, the developers end up having to use the tool and feeling hamstrung by it.
After tinkering with this one, areas I see lacking are 1) no authentication 2) no images and 3) limited automation options. I'm sure it's coming in later releases, but just an example. Even tools like AirTable etc. that do have auth are often lacking. For scenarios where you want users to only see "their" data, managers to see their employees' data, and vps/admins to see all data are common scenarios that are often hard to implement in these tools.
I'm watching this space for a breakaway, but haven't seen one that I feel is better than written code. I admit bias as a dev, but I do wonder if written code is not fundamentally superior in most cases. Even "Visual Studio" ceased being visual drag-and-drop for most people ages ago. Sure, you _can_ still drag-and-drop windows forms apps, but most devs will write XAML, or in web space, use a CSS framework and markup instead of a drag-and-drop designer.
For scenarios where you want users to only see "their" data, managers to see their employees' data, and vps/admins to see all data are common scenarios that are often hard to implement in these tools.
This is exactly a major problem I'm solving with https://www.cloudternal.com. I would absolutely love to show it to you and get your feedback on it if you have time (my email is in my profile).
Your comment underscores a few misconceptions with corporate software.
1. Writing and process flow as you describe are incredibly important. But, many developers can’t write. Writing is a fundamental skill that takes practice to develop and many developers do not independently practice that skill, despite its importance.
2. The web is a multi-faceted discipline. This is the hardest part to being a web developer. Learning to write the code is comparatively trivial. This is also the greatest cause for frustration and failure for people and automagical software alike.
3. Precision of requirements is important but not as important as many junior developers would suggest. The discrepancy largely arises because many developers find writing to that detail challenging themselves and are frustrated when feature delivery fails to match stakeholder expectations. QA and PMs seem to regularly nail this issue without challenge indicating its not the requirements that are ultimately at fault when things move out of alignment.
I agree. I am a NoCode fan. I run a small operations of a few million dollars and to run it in Systemic way I built a lot of systems with NoCode as i didn’t have the luxury of putting engineers on the job. While I am an engineer myself, my day job was to run the ship and which meant I had little time available to make systems. 1st google spreadsheet is where I started and quickly made apps for recording attendance and crm and other stuff. Soon I hit a wall and had to have engineers deployed. However since last year I started using a NoCode tool to build all internal apps and today I and my HR manager have put up a fully functional system right from attendance, pms, timesheets, project management, crm , sales , purchase and everything you can imagine as a fully usable web and mobile app.
I must say if the tool has a right type of user identified then nothing can beat noCode.
what tools do you use to set all that up? I'm bootstrapping my own startup and most of my brain is occupied for a few critical areas and would love to be able to better ration my "coding mental energy"
The main advantage of "coding without code" that I could see is not dealing with the server and software configuration issues that come up when you code. This can range anywhere from:
- Updating the server the software's hosted on
- Dealing with system errors installing software
- Setting up software on your company's webserver (and dealing with firewalls)
- Installing necessary plugins which may require installing new software that's not compatible with your version of Linux, etc.
- The fact that a lot of web software is designed for a Linux environment and can be completely foreign for someone with a Windows background
- Updating the software you're coding on
Although you shed some of this type of maintenance overhead, you are still taking on the burden of maintaining business logic.
The difference is that now, you lack the vast and mature test automation ecosystem to help manage that cost, and more importantly, the friction of shipping changes is completely gone.
That is exactly what some of the low-code tools aim to address: by having a visual, highly productive tool, you enable better collaboration with business stakeholders.
Requirements gathering becomes an interactive process where you sit together with a business stakeholder to model your application together: by doing it in a visual manner, the stakeholder can understand what you are doing, and you can process suggestions and feedback in seconds, so that the stakeholder can immediately validate the results of a change.
Doesn't work for all requirements, but in many cases you get better software because you understand the requirements better.
This is all great until you get to the stakeholder who prototypes something in Excel (or Honeycode, I guess) and since it only "took them a few days to do this" can't understanding why scaling it up takes six months or a year and won't listen to you when you try to explain that they under-spec'd the system by an order of magnitude.
(This happened a lot when Visual Basic came out - management types would spend a weekend playing with the visual UI editor and then give the developer a week to fill in the complicated business logic behind it.)
(Developer here who has t-shirts older than a some of the people posting)
> unless you've gone through the process of writing code it's impossible to understand just how pedantic and explicit you need to be when building software
Preach! This was something I did not understand when I was only doing non technical product stuff. Now that I build I look back on my interactions with developers differently. I feel their pain so to speak.
I don’t know if builder tools like this thing perhaps create bumpers around the many pitfalls associated with turning analog into digital, but I’d presume eventually they’ll get good enough to act like the automated customer service you get from amazon support chats.
This comment spawned a whole thread that completely fails to acknowledge that there are successful no-code and low code platforms. In fact, Honeycode isn't novel, it's just Amazon's response to Microsoft PowerApps.
Surely, building apps with such accelerators is limited. You're trading customization power for speed to market, and you get a lower barrier to entry which enables business focused people to build stuff they need.
Those apps aren't for everyone and I don't think any enterprise will be able to live with just these platforms, but enabling users to live without IT has a lot of value.
well, I think that's understating the value of a no-code tool like this. By having the right abstractions, apps are easily changeable (in a GUI), which means anyone in the business can make changes to the application.
However, the key here is right abstractions, sometimes seemingly tiny changes are impossible in these no-code solutions due to the abstractions that were chosen.
So no-code tools are actually extremely rigid in comparison to programming languages, but they still have a place and I believe it's still a growing industry.
Yes, precisely this. It seems abstracting applications at that high level will inevitably bake in the business process which is very different for each business unless the application isn't interesting or complex enough. I'm sure within a specific domain, a tool like this can be made (it's usually too costly), but at an abstract level to build any application is missing the real challenge that enterprise software has.
I think “no code” systems like these are mostly of value for people that want to produce some demo / prototype apps that they can then use to pitch around and then get resources for programmers to flesh out better. If said person cannot come up with such an app without involving a programmer, I’m afraid that the person is not knowledgeable enough in the target domain’s technical details to be giving guidance to a programmer.
No-code actually pushed me to learn how to code. I started building an app using Bubble.is and although it worked, it wasn't polished. Learning to build an app on Bubble gave me the confidence that I could actually learn to code. No code is a great segue for early tinkerers into Python or JS.
> the thing that "coding without code" fundamentally misses is that learning to actually write Python or Java or whatever is not the hard part
It does make you cloud/product/service independent. From Amazon's (or Mendix', or what every code-without-code product/service) perspective you are not vendor-locked-in enough.
Actually, I think this has the potential to increase empathy between pure-business folks and coders. After having a crack and encountering the inevitable bumps in the road, more people will realize writing software isn't just about knowing some funny syntax.
I mean, writing code that is good enough to easily work with is actually pretty hard. I've yet to come into an organization where I am like "damn, that is some pretty good legacy code yall have there." I can't even look at my old code and say that, certainly not my earlier work. Mind you, I'm not even saying great code. Nothing about design patterns, unit tests etc... just good enough to not be complete fucking spaghetti with 3,000 line classes and 500 line long methods that take you down the rabbit hole.
TL;DR I had a tough day on legacy system because learning to write code is easy and learning to write good code is hard. I actually saw this today "SELECT %s FROM %s WHERE %s JOIN %s";
Looks like a competitor to Retool, interesting. The focus on data permissions, mobile support, and push notifications is really interesting because none of those features are ones that Retool focuses on, I believe - those features being front and center makes me think Amazon has looked at the competition and wants to focus on what they offer that others don't, rather than just trying to be yet-another-tool in the space.
On the other hand, I absolutely loathe every single UI that has ever come out of AWS, and there is absolutely no chance I give the editor they've built here a shot without hearing lots of positive reactions first.
edit: actually going to pull back slightly on this comparison, since apparently Honeycomb is a little closer to something like Access, where there is a database _in_ the app, whereas Retool is built around connecting to an external data source (e.g. a SQL database). This surprised me because I assumed the entire reason you'd want an AWS version of this kind of tool is to integrate with the broader AWS ecosystem, like frictionless hookup to a DynamoDB or whatever. It may have this but just not spotlight it on the marketing pages?
>On the other hand, I absolutely loathe every single UI that has ever come out of AWS, and there is absolutely no chance I give the editor they've built here a shot without hearing lots of positive reactions first.
I agree so much with this. I hate the AWS console UI so, so much and It blows my mind that such a large company can't seem to even get on the same page about what color scheme or menu bar position they want to use.
But actually, I'm messing around with Honeycode right now and although I haven't gotten a chance to really dig deep and test the long-term usability of it, I have to say that so far it is gorgeous and intuitive. If the UI team that worked on this just completely took over the AWS console, I wouldn't complain.
Can someone smarter than me explain why the AWS UI is so off-putting? I also find myself just put off by AWS UIs.
I can't even figure out why I hate it so much. Looking at the screenshots though immediately filled me with the sense that this thing would just be awful to use. When I go back to the screenshots to try to find objective things I dislike about the UI, I can't really find anything. It seems to do the stuff a UI needs to do.
Maybe it's just a negative association with the look & feel of AWS UI, because most of the time when I'm interacting with AWS I'm trying to get a service I haven't used before up and running. Going back and forth between dense documentation and the UI, clicking and failing, and staring at a spinner spin for far too long.
Perhaps all those hours spent fighting with other pages that look so similar to this one has given me a subconscious dislike for all AWS UIs.
I seem to be the only person who likes the AWS UI. So here's my defense of it.
AWS is like the hardware store. Who thinks Home Depot is elegant? It's not. Who think their organization scheme is a thing of beauty? It's clunky and just functional.
But the idea is, when you go to Home Depot, you're there to get work done. The interior communicates that. The real work comes after you leave - Home Depot understands it's just a facilitator.
AWS did that.
I personally give credit to AWS for looking at Google, and learning. They could've had some high-handed PM come in and roar ITS TIME TO HAVE A UNIFIED DESIGN SCHEME and then forced everyone to deal with UI updates nonstop, you know the game of 'where did it go now,' 'oh, they moved it here.'
AWS went in the opposite direction. At the risk of ugliness, they give you the most bare bones UI, basically 'nudging' you as little as possible - a clean mapping of fields, to pages, to results. We know the downside: it can be unpleasant. But the upside is, it rarely changes, its consistent, and (aesthetic concerns aside) it gets the job done.
It seems a little weird to commend AWS for their design sense, but when you phrase it as their design goals, I vastly prefer them to Google or any other 'opinionated' service.
You're not alone, and thanks for putting into words what had been the back of my mind.
I could not care less about the aesthetics of their dashboard, when I'm on it I'm there to get something done and I never seem to have an issue with that.
This is such a strange comment to me. The issue with the AWS UI isn't that it's "ugly", the issue IMO is that it is the exact opposite of the things you claim it is.
> the most bare bones UI
The AWS UI is one of the most cluttered, complex, complete-opposite of "bare bones" of almost any web app I can think of, except for maybe Salesforce.
>basically 'nudging' you as little as possible - a clean mapping of fields, to pages, to results.
My largest gripe with AWS is that it does not have a clean mapping of fields/pages/results. The flow of getting to "results" in one AWS service is completely different from the flow of getting to "results" in another. The launch wizard for ECS, for example, doesn't even follow the same paradigm that the launch wizard for EC2 follows. One of them has a clear vertical layout with successive config pages, while the other has a mixed vertical/horizontal layout with sub-pages.
When doing something as basic as launching an EC2 instance, the AMI selection page has "Select" buttons next to each AMI on the right side of the page, and clicking one takes you directly to the next page. And then on that very next page, the instance type selection, the format has changed. Now the way you select something is by clicking a radio button (which is on the complete opposite left side of the page!) and then clicking "Next" at the bottom of the page. Why do these two pages require completely different models of interaction when they are essentially accomplishing the same thing?
Even within the VPC service for example, some pages have clusters of information that are right-aligned on the page, while others put the same information at the bottom of the page. Some pages have the "Create new resource" button on the top left, while others have them on the right side. I could keep going... It's the total opposite of "clear mapping of results" to me, and certainly isn't anything close to "consistent".
I don't think AWS "nudges you as little as possible", I think AWS nudges you a lot, but nudges you in completely different directions for every single service, causing you to feel bounced around like you're in a mosh pit when you're having to switch between EC2, CloudTrail, S3, etc.
Even in Home Depot they at least have uniformity in how they arrange their aisles. The nail aisle has little buckets where nails are arranged by a specific ordering system, typically by type of nail and size. If you go an aisle over to plumbing, the pipe joints are all arranged in similar little containers, also with a sensible ordering system typically by type of pipe and size. If you go to the paint aisle, the displays are different but you can still expect them to be arranged in a sensible ordering system, such as by type of paint and color.
If they went the AWS way, the aisle of nails would just be 2-3 large tubs with a bunch of individual nails thrown in, while the plumbing aisle would have things organized in small tubs alphabetically by the name of the manufacturer, while the paint aisle would be condensed like a newspaper with the pages in order of Bob's favorite colors. It would be chaos.
Sorry for the rant. I respect that you apparently like the UI, but it's weird to me that we have such opposite experiences. You say "Home Depot understands it's just a faclitator" and that AWS is too, and I totally agree. But my opinion is that AWS completely fails at effectively facilitating.
A bit of backround: a service typically builds their API first, and then builds the console as a front-end to that API. For most services, everything you can do in the console, you can do via an API call. (I assume Honeycomb is an exception to this.)
That API-first doctrine is at the heart of the underlying problems, which are:
1. Machine-friendly data models.
2. Distributed-friendly data models.
3. Deliberately independent and orthogonal services.
4. A vast range of customer needs over a console that doesn't itself make money.
AWS really does put effort into making their console useful for getting work done. You'll find some workflows that are pretty usable.
But when you get outside a handful of extremely common workflows that were technically convenient for a specific team to implement, those problems become dominant and the console becomes painful if not f*ing useless.
That's why (I suspect) you hate it.
> ... and staring at a spinner spin for far too long.
Oh yeah, fundamental cloud problem #5: "A few minutes" is absolutely forever when you're troubleshooting.
You probably didn't hate it the first or second time you opened it up. Only after recognizing that many operations are extremely sluggish did you start to build an aversion.
I think the same this can be said about JIRA and many other sluggish, enterprise-y tools. The UI design is typically more-or-less OK, it's the experience of clicking on things and having no idea when it will be done, why it's taking so long, or what a faster alternative is that makes you feel trapped.
The UI might not have major aesthetic problems but they could probably be more consistent between services.
I think you might have hit the main issue on the head though, unless you use a service regularly it's difficult to do much without the hefty manuals and while the services may be complex they could make the common or "beginner" paths more obvious.
Having sane defaults where possible and splitting basic and advanced settings could make it more accessible while allowing users to get familiar with the tools. Ideally a good UX should cater to a variety of proficienies and help users learn.
> If the UI team that worked on this just completely took over the AWS console, I wouldn't complain.
This is the fundamental misunderstanding. There is a centralized AWS console team/organization. They are responsible for the UI libraries, guidelines, common elements, mezzanine, etc, across all of AWS.
They dont write the actual "service pane" UX that you interact with when you start an EC2 instance or upload an S3 object. That surface area is so large, varied, and changes at a frantic velocity that there's no way a single team or group could ever keep up. Even a single "service" like EC2 or Systems Manager actually has multiple front end teams responsible for different portions of the UX or functionality.
You're right, and I did think of that after I clicked "reply". What I meant was that a company with so much resources doesn't seem to have that capability. Even with such a large size, I would imagine Amazon of all companies would have the resources to say "this is the design, now get on board" and make it happen.
This goes for other aspects of AWS as well, such as consistency in the way services report to CloudTrail or are referenced in CloudFormation. Overall there just seems to be little coordination amongst AWS teams, and that's always surprised me.
Teams at AWS are almost like individual companies of 5 - 15 people. When integrating with each other they do it in almost the same way external apps would. The frontend of each app is decided by each team using a shared library for UI styling and some guidelines.
This helps with iteration speed and not getting bogged down in middle management approval hell, but it does lead to inconsistency problems.
I have read this is the intended trade-off. They want each AWS service to release new features as quickly as possible. If they were required to coordinate with other teams on UI decisions, that would slow them down.
My first glance reads it to be more like airtable or even salesforce at some level, which to your point are the modern iterations of access / filemaker. Drag and drop all-in-one database and application designer that by virtue of being online and multi-user make them way more useful.
Yes my first thought was that this was like Airtable. One of these days one of these no-code solutions is going to actually stick, and I will stop getting paid to basically glue data from different systems together while browsing HN.
It's a fairly busy territory as it is, with at least 20 major enterprise players.
Microsoft PowerApps with PowerAutomate (formerly Flow, their Zapier/IFTTT) have a huge advantage of being bundled right into other licenses. SalesForce and ServiceNow have similar advantages. Quick Base[1] has to be considered the incumbent. Zoho, Oracle. And then the more independent Appian, Betty Blocks, Mendix, OutSystems.
This tends to be one space where consolidation and acquisitions aren't as popular, and the big players have built their own home grown products on top of their stacks. (counterpoint, Kony got snatched up by a fintech software services company, Temenos. Apple acquired Workflow which isnt quite the same thing but a tangent space.) In a lot of cases, its going to make way more sense to go with the Vendor that already provides other parts of your infrastructure. If you're an Oracle company, Oracle Apex is going to be simpler, which is the point of all these offerings. It makes a ton of sense for AWS to provide this naively on top of their already mature offerings.
It's also not a space I'd want to enter as an independent startup, from scratch, unless you are sure you can actually offer something better and different. Or, instead of a generic offering, your product is tailored to the specific processes and workflows of certain industries. At this point if you want to join this crowd, it would be a safer bet to hitch your ride to a specific tech company lacking this offering (if there is one left) and become so good that they want to acquire you. Or build a specific subfeature in this space, so one of them gobble you up and tack you onto their product (see 3rd link.) I would guess there is still room for some ERPs to be interested in tacking app builders on, like Infor.
[1] Somewhat shocked to not see Quick Base mentioned even once in this thread. It's a billion dollar company thats been offering this nonstop for 20 years, and is still relevant.
I agree. In our case we're focusing on gathering and sharing information securely (end-to-end encrypted) i.e. Typeform for PII[0] with information verification built-in. There are lots of use-cases for a tool that enables non-coders to incorporate that information collection into their business process (we believe).
Hi there! Founder of Retool (https://retool.com) here (and long-time HN reader). Agreed that Honeycode is adjacent to us. I think an interesting way of viewing the space [1] is who the product is for. There are lots of drag and drop app-builders (e.g. mendix, outsystems, bubble, msft powerapps, amazon honeycode, etc.), but they're all built for non-technical people. Their goal is to make programming more accessible to all. (Which I think is a very noble and very interesting goal!)
Our bet, however, is that code is here to stay, since code is actually a pretty efficient way of getting a computer to do something [2]. With that said, though, building specific types of apps (in our case, internal front-end apps today) is surprisingly difficult (have you tried recently!? you have to use react, redux, install 10+ npm modules, etc... just to make a front-end that has a table + POSTs back to your internal API!).
And so that's why we're building Retool for engineers, which has resulted in a few interesting decisions:
* we are not a system of record, since engineers don't like to move data around. We'll connect to your data, no matter where it is (e.g. postgres, a custom API, salesforce, etc.).
* we rely on the user knowing how to write code. I think this is interesting because low-code is good for getting to 50%, 60%, etc. But as you try to get closer and closer to 100%, it becomes harder and harder, since full customizability within a GUI (without code) is just hard (cf 2.). Retool lets you get to 60 - 70% of what you want very quickly, but then relies on you finishing the last ~30% with code, if you really want to. (We provide APIs, let you import custom React components, let you write JS anywhere [3] within {{ }}.
(If anybody is interested in working on this, please email me at david AT retool DOT com. I think there's really a small chance we can really change how business apps are built.)
1. Funnily enough, when we started Retool, there was no low-code / no-code space. If you look at our original Show HN (https://news.ycombinator.com/item?id=17725966), you'll see that nobody mentions "no code", "low code", or anything siilar. It's certainly been fun to watch a "trend" pick up around us, haha.
2. For example, imagine a switch statement. Very simple and concise in most languages, but incredibly hard to implement in a GUI. (A graph with nodes and edges, perhaps?)
3. We secure it by running all JS in a sandboxed iframe.
I guess RAD tools (now no-code) will never fade away from the market.
I bet you're getting a lot of traction on corporations that need to upgrade/replace internal tools.
I know, internal tools will always suck because:
1) your market changes faster than you can change your apps, so you're always lagging behind.
2) And technology moves faster than you can keep them to date. That's the reason we still have IE as corporate browser in most enterprises.
Also, 3) nowadays it's very hard to do both good frontend AND backend coding. Technologies diverged a lot since, say, Rails 2.0 (which is just 8 years away from now). And the barrier to compete is higher every day.
I'm curious if you see 3rd party vendors being useful in this space. e.g. one person consultancy that can use Retool to quickly build out internal apps for other orgs that aren't able to get any internal dev resources
I see this line of thought floated a lot. Go build a fully dynamic app used by internal teams with just those three tools and tell me how it goes after you've been maintaining and building on it for a while.
Those are good building blocks but they're simply not sufficient if you are building a 'Web App' and not a 'Website'.
Also I'll cut off the inevitable, "The web was not built for this and it shouldn't become a place for apps." The world disagrees, I disagree and most people developing on the web disagree.
And I'll raise that we should be moving more towards the web being the best universal distribution platform for software.
> We're talking about internal tooling for businesses here, this isn't necessary at all.
Why treat internal 'customers' any differently than forward facing ones? Building great internal tools can dramatically improve your teams' workflows and solve meaningful business problems.
As far as I can tell, this is being pitched to teams, not really general purpose applications (as I imagine a highly scalable DB being used for). The pricing is quite high on a per user basis and the 'tables' max out at 100k rows, so not useful for any larger scale data aggregation.
Agreed, a seemingly missing feature is how can lambdas or other AWS ecosystem components interact with this data? I could imagine systems where it's nice for "no-code" and "code" to interact cleanly.
I think pretty much all the 'no code' apps that are coming out have taken the wrong approach to it. No matter what, they are still 'designed' by programmers with a programming mentality. This will lead to a sort of failure as people will feel limited when using it, and a 'non programmer' mentality looks at this and goes wtf?
For example:
> =Filter(Tasks,"Tasks[Done]<>% ORDER BY Tasks[Due]","Yes")
I can understand this, 80% of folks here also, but do your mother or father? Or the small business owner down the street? Why is the word `Tasks` in 3 places? What is the "Yes", and so on and on
Yeah, man, this looks like a beefed-up version of Excel macros
Anyone who can write working spreadsheet macros could probably just learn to actually program. Maybe they aren't going to be making the next RTX Voice or proving P=NP, but I'll bet they could crank out some CRUD
Deploying the CRUD securely is a problem, though. Things like this and AirTable are entirely managed by their developers and your IT department, and Excel sheets can just be dropped into an email. If I write a cool python script, how is the rest of my team supposed to use it if none of us are developers and haven’t done it before, and with IT probably trying to stop me?
Also to point out, since mentioning the security aspect, any file/attachment/etc uploaded to AirTable are 100% open and unsecured as long as you can obtain the URL from any AirTable spreadsheet. They don't have a concept of authentication in regards to any files you've uploaded, regardless of your plan.
I did a lot of customer interviews. And I mean a lot.
People that are good at using Excel (as in, not just create a table with data, but know how to use it, do macros, pivots, etc), if the need arrives they just move up the chain to Access/Filemaker. I would say Excel is their gateway drug to coding. Maybe now they will move to Honeycode perhaps (if the UI is ok)
The ones that can't use Excel past putting =A1+A2*0.2 can't use most of the no code tools. But they can use a more visual approach to programming. This is the market I believe will/is exploding as more and more, pretty much everything requires a computer/app, but the customisation for each specific case isn't there. They require a more Lego like approach to 'software' development. For me, that is the NO-CODE definition.
With all the customer interviews you've done, what roles and what industries are the ones you believe to have a larger number of these users who are good at Excel, who are ready to move up the chain to Access/Filemaker?
Call me crazy, but with all the high-level language features in most of the commonly used languages of today, combined with the depth of rich IDE tooling for those languages, we already exist in a no-code world.
Yes and no. Maybe you have better examples of programming languages, but even Ruby/Rails, Python, etc have concepts that make sense for programmers that non programmers don't grasp. Think of it this way, if you give a good designer the Rails Book (or another one), he may be able to do something after a few weeks that may match (but very crudely) the app he thought off.
Now give the same designer Sketch/Figma, but allow him to sprinkle some logic in ready made blocks (if/elses, loops, save object, etc) and he will get much closer to what he wanted.
Is the second approach better? Well most programmers will scream at the database model, etc. For the designer, he did in 2-3 days what would take him weeks and get away with something better.
I think a lot of programmers look at their experience and think 'no-code' will never work, but (where my experience comes) 20+ years of doing software development as a consultant, what I found is 80-90% of most software share most of their functionality, and the remaining percent are in many ways doable with just a bit of 'scripting'
There is a very large target audience which is technical enough to write Excel formulas but not enough to build an app. Your mother or father will never need to use this tool as it is, but those people will.
Wait, who are these people? WYSIWYG App builders have existed for decades and Excel still dominates. Maybe you don't agree, but the main reason for this in my opinion is because these app builders are way too complicated and learning them is largely pointless since their use cases are generally super trivial. Why build an app if Excel+Email works?
Further, if these things do start taking off I don't think the people using them will be non technical people, it will just be technical people shifting their job description.
It is like an all in one hammer, the craftsman throws it in the garbage, and the non craftsman has no idea what to do with it.
These app builders have existed for decades, but its the preloaded integrations that make this generation different. Instant connections to a multitude of cloud databases. Type in your credentials, visualize your data. And these integrations might not just be a database api, but come preloaded with schema to contextualize your database.
It's not that they are difficult or something but usually the decision makers,who could make Excel,as a local database,backup system and CRM platform on Annie's PC go,have no concept of what's better or worse or that sending hundreds of Excel files back and forth is not a great idea. There are people out there running thousands people divisions and having no clue that they could probably get rid of 20% of them just if they would have some centralised system.
Why build an app if Excel+Email works?
Of course it does.There are people on YouTube making houses with swimming pools by carving soil with some primitive tools but does that mean it's the best way to go?
Well, having seen enough people who will never ever in their lives be able to understand this:
=Filter(Tasks,"Tasks[Done]<>% ORDER BY Tasks[Due]","Yes"
And I'm 100% sure that no company would let them anywhere near that kind of stuff,even if it's vanilla drag and drop. Those people are good at some jobs and task but definitely not at this. Anything designed for purely non technical people usually is just a bit crappy: I taught myself programming so I won't need to deal with Salesforce Flow...
I like what you're saying. Would just add that if my mother and father are the audience, I fear your solution would be unfairly docked a couple stars just for existing online and in software form. They would much prefer that any app exist as the result of a 10-minute phone call. ;-)
There are much powerful && easier to use no-code/low-code products on the market but sooner or later, you will need to code and work with databases. Even Bubble becomes complex once you move beyond the most basic use cases.
IMO, that example is absolutely not "no code". In fact, I would think it would be very hard to understand by non-coders. If you can train someone to understand that, you could train them to code.
The only saving grace it has is that most of the interface is "no code" so that you can focus your training on smaller pieces... But that's just "low code" at that point, which isn't nearly as marketable.
A while back Microsoft announced Microsoft Lists, which is a similar tool. Of course there are also existing tools like Airtable, Bubble, Mendix etc. All these tools are great, but they have some downsides in my opinion.
- If the product ever gets discontinued you might lose all your work.
- All these tools have limits regarding the amount of rows you can store.
- If your business depends on such a product and the pricing model changes, it might bankrupt you.
- You can't create or download real plugin that integrate well if you are missing features.
- In most cases you can't host it at your own servers.
- You might end up in a vendor lock-in.
These are some of the reasons why I started Baserow. It is an open source alternative to Airtable and in the far future also for tools like Bubble. While it is still in an early phase there is a test version at https://baserow.io that everyone can try. In the coming weeks you can expect the open source release. Right now, I am finishing up the documentation, examples, plugin boilerplate and some final small changes. After that you can self host it without any limits, vendor lock-in or price changes.
The open source release will probably happen within 3 weeks from now. It is an early test version that is running on baserow.io, but this is for trying it out only. I still need to write documentation, an openapi spec, a plugin boilerplate and some other small things. When that is finished I will make the code available publicly.
Funny tangent: I spent my internship (16 months between 3rd and 4th years) building Web 2.0 apps that were essentially implementing flows people were using on top of Word/Excel+Email. It was good work and people were happy to have a nice dedicated web app instead of their clunky flows.
After about a year I noticed I was basically doing the same thing over and over again, so I decided to make an app that makes web apps! I could build any app in my app! Awesome! I spent 4th year building this awesome tool out - there was a document editor to create your forms, there was a Visio-like flow editor that could make decisions, take actions (email to that person, fill in that field, send to branch 2 if that checkbox was checked etc). After a few months I eagerly applied to YC (for summer 2007) and... nothing. Turns out I couldn't actually describe wtf I was doing and pg would rather fund Heroku. Good call!
Anyway, there were other similar companies back then (Coghead) that went nowhere, but this concept keep on popping up and AirTable seems to have caught on. I guess someone at Amazon got tired of writing the same apps over and over again.
As an aside: I've been reading the AWS blog posts from Jeff Barr, but ignoring the Amazon Polly audio conversions. I actually listened to it today, and not only is it not terrible, but there's a moment (around 1:05 in or so) where you can actually hear an inhalation! I know @jeffbarr is sometimes in these threads: is that a standard feature of AWS Polly, or is there some preprocessing that is generating SSML to control cadence, and if so how do we get our hands on THAT?
Breathing is a feature that you can turn on in Amazon Polly since 2018. There are automated, manual, and mixed modes depending on how much you want to manually control the breaths. More info here: https://aws.amazon.com/about-aws/whats-new/2018/03/amazon-po...
There's a personal taste element: I agree with you that certain WaveNet voices sound better (I've actually used them for video narration with some success). The breathing caught me off guard: it took me a minute to identify THAT as the element that was there but I implicitly wasn't expecting to hear.
The breathing + pausing at commas/full stops and general cadence was frankly superior to what I've seen with Google Cloud Voice, which is why I was curious if preprocessing was done. I've generally had to do multiple manual passes with Google Cloud Voice to get audio output that didn't sound robotic.
The comments here strengthen exactly what I was thinking - this is yet another flavor of low-code app development. I see similarities to Salesforce, SharePoint, Lotus Notes, Airtable, and all the other startups on this path that don't seem to realize that they are re-inventing modern versions of products that have been around since the 80s.
I spent years in my early career doing Lotus Notes Dev, then shutting down all those apps to go to Sharepoint, then shutting all those down to go to Salesforce. I walked away from that churn about a decade ago to just do SaaS, so I can't truly speak to which of the newcomers has the most promise. But I have yet to see someone take on this market with full knowledge of what came before. I see potential for someone to really learn the in and outs of all such products over the last 30+ years, talk to the folks who have re-done their LOB apps in multiple products over that time, figure out what worked and build a true "best-of-breed" solution.
When someone does do that, I'm all in. Until then... the legacy apps I mentioned above are past their time, so pick your favorite flavor from all the new ones.
Yahoo! Pipes tried this more than a decade ago, it's interesting to see that the dream of "apps my mom could build" never dies.
Except most people want to be consumers of applications, not creators. And those who really want to be creators they learn how to code. So, like with Pipes, I am not really sure who is the target audience here.
Microsoft Popfly[1] was another one from back in the days.
"apps my mom could build" kind of describes Excel workbooks. People effectively use excel to build (highly constrained) GUIs for processing data using custom logic that they specify themselves. And excel's popularity speaks for itself, it's completely pervasive. So that's the answer; the audience isn't programmers, it's the officeworkers all over the world currently using Excel to automate office tasks and want a better delivery mechanism than a shared Excel file on the office LAN. That's such a big pie that even capturing a small slice of it might be a reasonably profitable endeavor.
You are spot on. I know a ton of people who fit your description. I wish this were higher up the comment stack. So many people are missing this simple viewpoint.
I remember in 2002 when .NET came out they had a tool that turned UML into method stubs with pseudo-code, and I was sure that my career only had a few years left before it was fully automated away.
It looks like an Airtable replica to me. I might be wrong. But anyways, AWS getting into no-code (less-code) space is definitely going to impact a lot of small time players. AWS can complete the loop of development to Custom Deployment and It also has bunch of other things in its offerings that anyone would be happy to jump in. I'm just worried about how small-time No-Code players would survive going forward!
I'm exploring no-code solutions for some small business tasks. In my experience, if I can find a non-enterprise company to fill my needs, I will be way better off. My past experience with Amazon tools is that they happily stand in the enterprise solutions space, with an unfortunate amount of the baggage that brings along.
I focused a bit on the history of computing when i was getting my CS degree and one of the things I've found super interesting is that for at least forty years (perhaps longer!) we've been at least academically interested in writing code "without writing code". It never really works, however for a technical person it can be a great way to do, like, a sketch.
im genuinely asking myself if "this time is different".
The merging of Cloud + Software consumerism of 15 (ish) years of mobile + software eats world can make the Bubbles, Airtable and other no/low code tools the next long tail revolution of software ?
What is different from the front page + Dreamweaver + flash days ?
My hint : cloud computing and the hosting of database AND logic in bigcorp maintained garden
I'm not sure what your point is. When you say "bubbles" and "software eats the world" I think you are saying that these tools were supposed to replace programming, but so far they haven't.
In fact I think that people who make that claim are wrong. Low code development tools have become hysterically successful, especially in recent years. WordPress (400+ million websites) has 50000+ plugins that can do almost anything. Look at Salesforce (17 billion revenue) and PeopleSoft. Airtable (1.1 billion valuation). Shopify is approaching 1 million sites. Wix has $600 million in revenue. There are a lot of other massively successful products that fit into the loose association you gave.
Its weird to me that people in here keep saying this looks like a competitor to [a single specific recent product X] when in fact this type of system has been an entire very popular product category for decades, and there are literally thousands of systems like it. Of course not all of those thousands of systems have become extremely popular or have the same scope or are contemporary.
For example: Access, Salesforce, WordPress, Tableau, 10000 other ones that never became really popular including the simple one I made ten years ago for a client.
Co-Founder of https://www.cloudternal.com. I'm really surprised they have a limit of 100k records on their tables. They will have the same issue that Airtable has, it's just not suited for enterprise.
We believe there is still a gap in the "database app for non-technical users" space, so we created one that can handle millions of records, provides granular permissions down to the cell level and targets those creative (yet non-developer) users who end up pushing Excel beyond its usefulness.
Hey there, I set that up. The request early access link is a Google Form so it was an issue somewhere between you and Google. It works for me now, but if it still doesn't work for you, please email Carey personally (email is in his HN profile).
Ok honestly, my first thought was "here we go again", BUT when you look at the @jeffbar provided, you can see, that yes, it is "visual" programming. It does however require a certain logical fluency. So I was wrong:
It is _not_ the sales/ceo dream of no longer having pesky engineers.
It's a proper gateway drug into programming.
The most common fallacy across almost 40 years of visual programming attempts is that one can somehow escape the essential complexity of a problem domain. One must have "a certain logical fluency" to design essentially any process, regardless of the technology used.
I'm pretty sure the zillions of Excel users proves it's not logic that's the problem It's all the scaffolding around it that is the real barrier of entry to most development systems.
Right, even extreme Excel macros require logic, and is also a programming gateway. The nice thing about Excel (or the article's example of Visicalc) is that one doesn't need to jump into the deep end of logic problem solving, at least at first.
This looks very Tableau-esque. Another tool that takes a similar amount of work to learn compared to just learning programming in the first place, but with more vendor lock-in.
Maybe it also serves as a ramp up to learning programming, but along that ramp you can deliver economic value to your audience, rather than completing CS theory exercises. That's often one of the selling points of this kind of product.
I don't see Microsoft PowerApps mentioned in the comments. (https://powerapps.microsoft.com/en-us/) It's one of the most significant recent entrants into the "make an app" space. It looks like Powerpoint and its coding is simple, with formulas like Excel. They sell licenses mainly to companies (creating internal app stores).
Not sure if this includes Power Automate but I find it really handy for the work I do. If you're not already familiar with how an API works, being able to point and click on an icon to setup automation is great.
While I’m always skeptical of no code systems, this is the first one that seems to bring to the web what Visual Basic And Access did for Windows — VBscript, GUI driven layouts and connectors, and eventually the pipeline of programmers who went from VB to VC++ and Java.
Amazon also has the Microsoft—esque brand to really drive this into the Zeitgeist. IMO this might be the most game changing product they have launched recently given how much of a business impact it can have if distributed well. But therein also lies its biggest challenge - Amazon hasn’t historically been good at offering their services to the small businesses and consultants that could leverage this and build for the long tail. I wonder if they have a strategy for that.
From the looks of it, I’d say Amazon applied the same level of UX thinking into this as they applied to the AWS admin panel—which is to say, not enough.
I think using this in the real world will be about as easy as trying to buy the right phone charger on Amazon.com. People consistently underestimate how long it takes to learn complicated interfaces. At which point you might as well just learn python.
Take any advanced 3D modeling software for example. They are visual interfaces, not command line tools, but they might as well be considering the learning curve for the average user.
Having visual buttons doesn’t necessarily mean the process of building a 3D model (or a piece of software) is suddenly easy.
Google acquired AppSheet earlier this year. AppSheet has been around for longer than Glide and it has more clients and features. They already acquired the leader in building apps from spreadsheets.
I believe the answer is yes: Excel. Even without using macros, it's basically dataflow programming and a built in user interface structure.
People solve problems and build useful tools using Excel, even those who have no realistic expectation of ever learning to write code. In fact it may be the most widespread programming tool.
Are there things it can't do, and problems with scalability and collaborative development? Sure. But BASIC had those problems and nobody says it isn't programming.
I've seen master programmers use Excel, when they wanted to do something with mixed-type tabular data and graphs, that they could share for others to use.
For a lot of people, hacking a spreadsheet together is easier than trying to communicate their needs to a programmer.
It gets you pretty far. When I worked at a bank, most of the pricing was done in Excel. What they had was infrastructure on top of Excel, like standard calculations and network connectivity, to support this. (I ended up writing a monitoring system for this, which proved very interesting. Months were spent going back and forth with the networking vendor about how slow their thing was, but I added some simple time in -> time out monitoring and we found that the cause was actually the spreadsheet. That was a politically unpopular finding, but data is data.)
Anyway, this is still "programming", of course. You have inputs, you transform them, and you get outputs. What Excel gives is the ability to see all the intermediate calculations update as you stitch things together, which is very different from the software engineer approach (where we think of all the inputs, and write tests to make sure a particular sub-module works, and then treat that as working forever). The software engineering approach lets us build very large systems reliably, but the spreadsheet approach lets you build simple things very quickly.
Ladder Logic is still used heavily in modern industrial automation systems. This isn't to ease development, but to aid in the supportability by folks who don't have a background in software and are used to reading electrical prints.
I'm very eager to see the Office 365 answer to this.
Microsoft is the one that needs to come up with a defensive play here, because this is an area where Excel is used in many businesses both small and large. I'm guessing Microsoft could do a better job than AWS integrating this with Excel and the Office 365 or MS Teams kind of UI to make it feel at home to their users.
On the other hand, AWS is ahead now and likely to start integrating this with the rest of their services if it takes off.
Either way, I think this can be an interesting development for a lot of half baked Excel processes that are everywhere in a typical company.
The "Power Family" or Power Platform (PowerApps, PowerAutomate, PowerBI, Power Virtual Agents) are inarguable the most mature bundle of WYSIWYG, visual data flows, and data graphing on the market. It's not just about the app building itself, but all the ways to get data in and out of it, and what else you can do with the data once youve gathered it. Salesforce is probably the other company in the same league.
Microsoft clearly has a branding / marketing problem, where people have ignored them for too long, and or are just reconsidering products Microsoft has had on the market for 10 year (another thread where people said Office on the web has caught up to gdocs, whereas id say theyve been ahead of it for at least 4 years.)
Mirosoft Lists (their Airtable) is a new interface over SharePoint lists. SharePoint lists are one of the data sources for the Power Platform, but so is Dynamics CRM, ERP etc.
> another thread where people said Office on the web has caught up to gdocs, whereas id say theyve been ahead of it for at least 4 years.
This issue is that gdocs and co are free while even for just web word you need a subscription. so the only ppl who use it are ppl willing to pay, the freeloaders only see it when their company decides to switch back to MS apps after being in googleville for a few years.
>>because this is an area where Excel is used in many businesses both small and large
Those people are not going to be giving up Excel for this. I have tried for years to get people to use other better tools than excel, it is a non-starter
Power Excel Users will not stop using Excel for either PowerApps or this AWS Product
Microsoft can do a much better job than Amazon if they created a competing product. They might take the quicker route and buy AirTable maybe?
I can foresee Microsoft and other bigger players entering the no code market seriously in the near future (though one can say Microsoft already has power apps etc).
Didn't Microsoft just release their Airtable competitor? Lists? Did everyone already forget about that? Seems pretty comparable to this Amazon offering other then the mobile UI WYSIWYG builder.
They don't push it as an "app builder" though, more of a web based access that is heavily tied to office/teams.
Ability to write code - is the main way to deal with application complexity.
If Amazon Honeycode does not have that critical feature (ability to write code) - then Amazon Honeycode is useless for creating any complex applications.
Too bad this is just another low-code CRUD offering for SMB/Enterprise. This would have been so much more interesting if it allowed me to build an app for mobile and web with a custom domain, database modeling and storage, integration-eque triggers/automations, all while keeping the underlying platform invisible to the user. Instead, I have to create a team on AWS and then invite members who then have to install the Honeycode player on their phones just to use my app.
Using data tables to publish websites and apps is an interesting concept and having an in-house tool to produce most commonly requested ones makes total sense. Look at their templates: Inventory management, Team Tracking, Surveys, Reporting...etc. It makes sense.
One hard problem here though, by the looks of it, the tool is a database designed by engineers in response to a lengthy requirements document. It has no regard for user experience, and is one of those things you can use, only if you go through a 3 week training course.
This, imo, is where AWS could borrow from startup playbook, and instead of launching a spaceship, start instead with a paper airplane. Imagine if all you could do was to publish an inventory-management tool, that in one-click integrated with Amazon Pay and let the customers buy your products on a website?
Maybe Amazon is waiting for someone else to build this on top of their tools, and then make it available, but that poses a question why. Why would someone build on top of Honeycode, only to have Amazon eventually make it their own?
Interesting concept, but it's got a long ways to go before anyone needs to be scared of what Amazon can do with this thing.
p.s. One thing I can't figure out is if Honeycode can function as an API. If I am already using AWS for my other infra, keeping my data inside their "Excel" and then auto process and export it to somewhere using drag-and-drop automation, that makes perfect sense.
In fact, the whole "no code" Dreamweaver analogy isn't all that fitting. If they just said "Excel spreadsheet on steroids that integrates with other AWS product," would make more sense, to me at least.
I feel like many of these no-code tools are taking an all or nothing approach that will ultimately ossify into a very specific form.
However, if something like Honeycode also had a robust programming/design API, you allow for tons of flexibility.
We could build a lot of it without code, and we could build a lot of it with code, and even better, we could code more things that can be built without code on an app by app basis.
I'm always wary of these kinds of ideas, but honestly this looks pretty cool! I feel like the Press Release[1] actually quantifies why companies would want to use really well.
What we need in this space is basically a UI where you build out what the presentation of the data looks like, what the permissions will be, and then an app gets generated for you automatically. You see the generated product and can then iterate but instead of with devs with tireless coding automatons
As a developer of an open source low code tool https://github.com/zubairq/pilot I think it is great that Amazon has entered this space. It really validates it for the mass market!
These kinds of systems are all well and good if you have a person in your business with an analytical mind enough to pick it up and all your needs will fit the limits of the framework.
If your business domain has a feature that doesn't fit then you have a difficult conversation with business people who won't change their process to fit the platform and won't pay to rebuild in a platform that does fit.
If you do manage to customise Honeycomb then you're down a path of not really fitting into their model or having to upgrade on their product roadmap, not yours. I've seen SAP and Sharepoint "installations" that have been customised beyond all recognition.
Where this will fit nicely is for those internal apps where people are just using Excel or Access-like systems.
Are there any tools where you can design something in the UI, and then export it as actual React or JavaScript code, that you can then take and upload somewhere else?
Using low-code as a developer to iterate faster, and bang out lots of mini code apps quickly, is an interesting idea.
The idea of code generation is not new - but it seems like the new crop of software developers are learning the same concepts and lessons all over again. Hey - state machines are so hot right now.
Back in the day there was this cool concept of creating a bunch of UML diagrams for your business logic and them BOOM - press a button and here is your C++ code. But then architecture astronomy hits the asphalt and you realize that most of the hard work is still ahead. So things like IBM Rational Rose were only sold to suckers.
Below are a few other AWS services that I'd consider "SaaS style". Lightsail is the only one that has a similar SaaS style pricing: https://aws.amazon.com/lightsail/pricing/
I think Connect qualify as well: while you can create powerful flows integrating it with Lambda, basic flows are super easy to setup through the UI, just clicking around.
This is a great way to prototype some simpler, mostly CRUD-like applications.
Definitely not future-proof as new business rules may be hard to add after a while, but by then the PoC has shown its value and ROI, and writing a real app might become a no-brainer anyway.
Things are broken when a well resourced large company can just steal someone else's innovative idea (Airtable or others) and try to muscle them out using capital or a captive customer base. We need new anti trust laws.
This is not related to main content of the post. But when I visit the page on a laptop, a sizeable portion is taken by the header- two or three layers in a div (lb-clearfix m-nav-double-row)- one of which is logo and create account ( blank space between logo and button), then the menu bar (blank space on the right below create account button), then the blog menu and search. In the main section body, a large portion on the right is white space. I have not done UI UX for a few years. Is this a good design? Are there reasons behind it? (views on mobile, etc)
So far I have yet to see a real practical use for no code, they all seem great in the demo's and get alot of hype but at the end of the day they take far more resources to maintain than a normal app and you end up having to have a programmer maintain after the end user quickly exceeds their ability to develop anything in a no code enviroment.
They either get Flustered and end up back in Excel, or the "app" gets handed off to IT / Development who get frustrated and start a project to rewrite in a actual programming environment
This works only for the development of simple applications. If these no-code/low-code platforms want to be considered for serious development, they need to decouple front-end and back-end tiers. A developer can build front-end in one no-code application (e.g Webflow), or Angular/React for slick single-page applications; and the backend in another backend APIs specific no-code application. It will also enable the backend code to be called from native iOS and Android apps.
Is Honeycode for everyone? Nope. Is it for some people? Sure. I’ve read through countless comments extolling the virtues of hiring python, java, or (insert your favorite language) developer. Let’s not lose sight of the customer. Some problems don’t need a perfect solutions. Some problems need a solution that is more concurrent than excel. Some problems just need a quick solution for now. You would be surprised to learn how many small business run in these imperfect solutions.
My guess is they are doing that because one of AWSs biggest competitors will be Azure. The Enterprise will be riding on Azure+Power Apps with data sourced from Dynamics et. al.
These types of tools seem excellent for prototyping, but always fall short in addressing the real world issues of increasing scope and maintainability. No code web development (Wordpress, and Squarespace) has largely thrived due to blogs and largely static content, but I fail to see a similar use case in mobile app development. Maybe it's a lack of imagination, but how valuable is a tool like this outside of todo lists, blogs, and other minor use cases?
If you want a new perspective to the entire nocode space, remove the line "building apps" from any conversation or line of thought.
A spreadsheet to track a project need not be an app, the ability to temporarily give access to internal data to a non developer team (which become CSVs in email) is not an App.
It is this need of building a full solution which actually takes us away from the need of the users to the need to justify a resource for the thing.
Give me an intuitive, drag and drop enviroment where I can plan out my AWS deployments and tie resources together, and then write the cloudformation for me. Then I'll be happy.
Also, this thing requires a different login even though I'm logged in to an AWS account with corporate SSO. Like quicksight and other tools do, and it's just as infuriating. Just let me start using and bill for usage.
So, this is like Neonto Native Studio[1] but with less focus on looks and UI, and more on business worflows? I can see how this would be useful for many businesses with rag-tag processes, being able to combine on a easy-to-watch app that everyone has on their phone would be nice.
When looking at the website, I do think this could be a very decent product that could fulfil a business need.
From what I've seen many businesses use Excel sheets as a sort of apps. And this seems to be a mobile-compatible version of that idea. Of course it'll be very limited, but for a certain niche of business apps it could be very useful as a replacement for Excel.
It's weird that Amazon releases this low-code tool and yet they can't offer basic managed CMS/Wordpress to millions of businesses out there. Their pricing could start at 20 USD per month and they could conquer the premium (wordpress) hosting market dominated by WP Engine, Kinsta, Media Temple, etc.
This looks like several Microsoft products stacked together, Sharepoint, Forms, Flow, Power Apps. I already do this with Microsoft and most of the time I don't have all of the tools I need or I want to scream at the screen "just show me the code!".
There is Podio (https://podio.com/) in this space which I think is really cool - or it was when I tried many years ago. Always wonder why it is not more popular.
In my experience, when people build apps without having to write code, the first iteration is awesome.
Get something working and shows great promise.
But as complexity grows, the app ends up being a badly designed excel screen on the web.
I didn’t see much in the way of docs from the micro site at least. I’m wondering if there is IAM integration or the ability to call Lambdas. Those would be Airtable-killer features from where I sit.
I think the problem is, it's easy enough to glue to Airtable (lovely API), and the other problem is I'm not sure how you'd generalise the power of Lambdas to a consumer, for whatever this Honeycode thing is.
It seems like a start, but unless they're supporting a community plugin ecosystem you'll be at the mercy of what their team decides is worth integrating. Maybe it doesn't matter.
i was hoping for something at least semi-interesting. not so much. airtable, with a google aesthetic. eh.
i feel like Anvil is on the right, almost perfect, track -- except for their choice of Python over Javascript. They chose self.Python over javascript. ok. life is full of decisions. in their defense, callbackjavascript is...not so promising.
bubble went with..something. right idea. not the best execution. still, a step in the right direction.
saw a couple other tools out there that are trying to cross the chasm, but nothing as good as VB yet.
Interesting ... there's a big push towards this "no code, low code" solutions lately in the industry, I wonder if this is just to sell more cloud services?
Taking the thunder from the coupon code site Honey. Won't be searching for Amazon honey or code and finding real honey. It like doing this with product names.
Not surprising to see Amazon get in the game with a #nocode tool. I will be interested to compare this with Webase [1] where we've focused first on custom views and the data model but have yet to support custom notifications (coming soon though!).
Although the world still needs lots of developers I do believe there is a BIG opportunity in the #nocode space.
Correct, especially when you add Power Automate and Power Apps - MS have been quietly pulling ahead in this space.
They also have one huge advantage that no-one else besides maybe Google have - integration with Office 365: your corporate directory, email, filestore...
Which means they don't even need to be the best at this kind of product. Good enough, plus the integration, is a game changer.
The one thing Microsoft really needs still is in house, industry specific layers to drop on top of dynamics, such as https://www.mtwocloud.com/ instead of depending on these third parties. Microsofts own sales teams don't know these products exist, and they have poor visibility. Enough companies won't even touch Dynamics, preferring something more industry specific.
Look at all the other things they cover in the SalesForce, Adobe, Oracle realm that automatically integrate right into the Power Platform.
https://dynamics.microsoft.com/en-us/
Microsoft does have industry accelerators that sit on the Common Data Model & Dynamics, so ISV's (and presumably in-house devs) can write industry-specific solutions that might hopefully play nicely together:
Sharepoint in real life seems to be a very complex product with few people actually knowing it. Out of a company of 10,000 people we probably have 5 guys actually knows anything about sharepoint, Why is it so obscure?
Because its so hard to use that nobody can really explain it. Is it a share drive in the cloud? Not really, but it can kind of do that. Is it an application platform like Salesforce? Kind of. Is it a project management system? It sure can be.
On top of the confusion, often times the only time a end user sees the word "SharePoint" is when their Office document got lost because OneDrive pooped out and it's SharePoint underneath, so then it starts whining. The only time I've seen SharePoint work well at all is at a company that kept teams of SharePoint developers on staff, and even then we still begged for a share drive somewhere (have you ever tried to store keepass vaults in SharePoint? it's a magical experience).
1. Amazon isn't especially known for high quality software. I picture lots of weird corner cases that won't be tested or fixed in their frantic pursuit of new features (which is what's rewarded, like Google if not more so).
2. Sky high Amazon attrition - especially in engineering!* - means that it's always newbies who'll be working on it, under high pressure.
I have trouble imagining a non-trivial corporate app with any kind of lifespan living on this thing.
*I live in Seattle so any Bezbots can save themselves the denial of harsh reality.
This is like a movie you know 2 minutes in, is going to be a complete disaster, give it another 5 minutes and finally turn it off. You stumble upon it's imbd page some time later to discover it has a 3/10 rating and nobody went to see it.
I don't see a single innovative idea in this product and I see plenty that's worse than the experience I had in Dreamweaver in year 2000.
This looks similar to Airtable, except Airtable UI seems nicer. Airtable is a Billion dollar company, tons of people are happily using it.
I am no fan of Amazon, but I do not think it is as bad as you describe. Even if it is half as good as Airtable, this will take off, simply because of Amazon's weight behind it.
I agree, the users of Airtable love the UI. But it's mostly individuals and small companies. Airtable isn't practical for enterprises with its 50k row limit and extremely limited permissions.
With Honeycode being an Amazon tool, I would expect their targets are more enterprise. But even this tool is limited to 100k rows, so until that changes, this can't really be used at scale either.
There's still a gap in modern database apps combining scale, granular permissions and something made for non-technical users.
It's about as useful as amazon web services are, for 90% of the companies that are going to get rid of their infrastructure and become completely dependent on amazon for their business to continue functioning.
These little creepy 'useful' products are just vendor lock-in, the same way those creepy Internet Explorer-only features were 'useful', and forced the whole goddamn web development industry to complicate their tooling and made testing and providing the same experience across browsers a goddamn nightmare for decades (is it still ongoing? I thankfully escaped hell that is modern web development).
I'll probably be on my deathbed by the time these old idiot governments comprehend what these creepy IT companies have been up to since their inception.
I work with business stakeholders creating internal line of business apps a lot, and most of the time the requirements that they are able to articulate are some variation of vague, ill-specified, and flat out wrong. And it's not their fault at all, it's just that unless you've gone through the process of writing code it's impossible to understand just how pedantic and explicit you need to be when building software versus, say, giving your human colleagues instructions.
And by the time you've got enough experience to be able to do that, tools like this just get in the way compared to writing some Python or SQL or C# or what have you.