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?
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 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.
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
>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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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/
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.
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'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.
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.
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
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.
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.
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 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
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. ;-)
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
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.
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'
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?
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.
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.
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...
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.
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).
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.
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.
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
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.
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.
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.
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.
330 comments
[ 3.3 ms ] story [ 383 ms ] threadOn 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?
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.
https://www.gartner.com/en/documents/3956079/magic-quadrant-...
https://imgur.com/kD5hQ46
https://flow.microsoft.com/en-us/blog/microsoft-acquires-sof...
[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.
[0] Personally identifying information
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.
Or just use HTML, CSS, and JavaScript?
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.
I disagree with the person you're responding to, PHP and HTML should be more than enough for such things.
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.
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 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.
Isn't it the other way around? Being a large company makes coordinating on an uniform look and feel much harder, not easier.
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.
This helps with iteration speed and not getting bogged down in middle management approval hell, but it does lead to inconsistency problems.
Apple can do it because all of their legacy architecture and organisational structure was put in place before the internet
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.
> staring at a spinner spin for far too long.
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.
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.
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.
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.
Oh, and then you find that search only supports either exact matches, or (for some reason) suffix matches.
> 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.
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.
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.
Oh, I love, hate, detest, adore, or any number of other negative and positive adjectives the AWS console UI, all depending on what page I visit.
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.
[1] https://press.aboutamazon.com/news-releases/news-release-det...
https://aws.amazon.com/connect/
- 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 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.
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.
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.
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.
Good try though.
Maybe more like Filemaker Pro, circa 1990.
edit: But this.. it is polished.
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.
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).
They don't push it as an "app builder" though, more of a web based access that is heavily tied to office/teams.
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.
https://powerplatform.microsoft.com/
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.
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
Of course with AWS resources this can change with time. They did hype this some months back, I was expecting something a bit more impressive OOTB.
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.
We’re quite excited to see the no-code space heat up with Amazon joining the fray.
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
You mean they prefer to call someone for 10 minutes and pay them to build the app? Or a recommendation to use an existing app?
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
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.
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'
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.
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?
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...
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.
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/
https://docs.microsoft.com/en-us/common-data-model/industry-...
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?
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).
https://hn.algolia.com/?q=without+writing+code is an interesting search
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
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.
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
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.
frontpage98 was the one to kickstart my web experience.
They are good to start somewhere from, but they'll never be a replacement.
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.
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.
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.