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.
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.