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 guess it depends on what you're writing for.

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.

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

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.

Indeed. The hardest part of my job isn't writing code. It's in understanding the problems and working out how to solve them.

~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?

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.

I agree with this.

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.

The "curse of knowledge" works both ways.

I totally agree.

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.

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.

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.

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

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.

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

Sounds like we have a similar career track.

My joke is that the only place a stakeholder should hold a stake I'd through the heart (on the bad days).

Some stakeholders are brilliant they explain what they want in sufficient detail and get out the way.

The worst are the ones who try to tell you how the software works internally.

You don't hire a builder and then interfere with every brick course laid down, at least if you want the wall finishing on time.

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

As a technologist I'm surprised that you need this processed explained to you.

It's progressive improvement. It's trial and error, without this process we'd never ever make progress.

This perfectly articulates my experience. If everything was as simple as the resulting python code they'd never need me.

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";

this is such a beautiful comment. So very true

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

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.

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

this also has led us to embracing git syncing (serializing retool apps as yaml files and syncing them to git repos: https://docs.retool.com/docs/git-syncing ), being on-prem by default (https://docs.retool.com/docs/setup-instructions), etc.

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

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 find it most similar to bubble.io, which includes databases but also allows linking to external data sources like Airtable.

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

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.

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 requirements-writing assistant would be killer. Maybe something that uses natural language and writes a spec in a formal language under the hood.

Wow, that looks great. An COSS alternative is exactly what this space needs. I wish you great success.

Thanks for listening to Polly! That's Polly's Matthew voice, there's not special preprocessing, and you can make your own text sound like 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...

It still sounds very robotic to me. I think Google's WaveNet sounds much more natural: https://cloud.google.com/text-to-speech#section-2

This should be the real post link IMHO

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

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.

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.

Agreed. At least, I don't see anything (other than visual complexity in their UI/UX) that sets them above Airtable.

Good try though.

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 agree, I tried to upload a 1 Megabyte sized CSV and was promptly shut down (on the trial tier). In 2020, a floppy disk worth of data is too much?

Looks awesome

FYI: When you try to request early access, I get an SSL error.

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.

So, it's more than retool?

Visual Basic?

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.

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.

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.

Founder of Glide here! Thank you for the vote of confidence :)

We’re quite excited to see the no-code space heat up with Amazon joining the fray.

And turn it off 3 months later? :-)

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.

> Has programming 'without writing code' ever panned out for anyone?

Yes, for everyone, many times. You just have to carefully define what "programming" is.

Even when there's initially no "programming", soon things like "macros" will be added.

Ladder logic used to be fairly big in PLCs a while ago, but PLCs were rather simple.

frontpage98 was the one to kickstart my web experience.

They are good to start somewhere from, but they'll never be a replacement.

I think you are right. You show some of my coworkers GUI built with Qt and they will eww all over it.

edit: But this.. it is polished.

It's called Power Apps https://powerapps.microsoft.com/en-us/

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

Power Apps is Microsoft's version of this. It is actually quite popular.

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.

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.

I am trying, https://www.gatsbyjs.org/

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/

- Lightsail (ie. self-hosted wordpress)

- Cloud9 (IDE in the cloud)

- Workspaces (remote windows/linux desktops)

- Workdocs (cloud documents)

- Workmail (email)

- Chime (audio / video calling)

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.

https://aws.amazon.com/connect/

No, there is the Amazon Connect cloud contact center https://aws.amazon.com/connect/

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.

Yeah, imagine an "app store" for Lambdas that work with this, or just a trend of SaaS companies making their APIs "Honeycode-compatible".

Came here to write exactly this, but thought I'd do a quick Ctrl+F first =)

Looks like it. My first thought was Filemaker Pro or the old Claris Works/AppleWorks Database program.

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.

> SharePoint

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?

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.

It doesn't have to be innovative, it needs to be useful. Having this inside the aws ecosystem, is going to be very useful for a lot of people.