Actually I think the lesser known parts of office 365 'PowerApps' have various features for point and clicking your way to a cloud database, forms and reports, and even ETL from your existing data sources.
However, people don't think of these options like they think of access. For MS and Office 365, they could put more effort into marketing the features. Maybe they don't want to. For Salesforce, I guess they could try to get their product into non-computer people IT class syllabuses?
Like ... crazy push. They're running free App in a Day workshops in hundreds of cities, and the "Power Platform" (Power BI, PowerApps, and Flow) is their key foot in the door sale in FY20.
Low code/no code is always a Modern Workplace linchpin.
Something like WinForms with SQLite that didn't use Entity Framework would be far better. But really all we want is to get back to VB6 on top of Access. Maybe a few less footguns...
The big problem is that there is much more of a learning curve. The first useful software I wrote used VB6 and winforms. Getting started was easy and intuitive, with a gentle learning curve. With virtually no experience, I was making neat things in hours. Within days I was making full applications. That says something about the power of that platform.
To be truly effective with modern web development took me a year or so. That was after years of professional experience.
At this point I can build web applications faster than I can build desktop software, but it took a huge time investment to reach this point, and I had to build multiple tools to make it possible.
I agree that there's a niche that needs filling. I want all the benefits of modern web development, and I want a learning curve like VB6 with Access.
True! I wonder whether making JS event handler in little textarea boxes would actually help. Select “Even handler for field ‘Name’ on ‘click’”, then program your event. Obviously the end result is a js file, but they user is guided...^W prevented from doing something else than modifying output before submission.
YAGNI. Why not just go with a process that you can't scale to that hypothetical use case, and once that process reaches maturity (stops being adjusted every week) and grows to the point scaling becomes a real consideration, and not just theoretical one - only then hire resources to migrate it to a new system that's scalable?
I'd probably do a web app myself, but that's just me. I know a lot of people that cut their programming teeth on Access apps, including distributed ones.
People often develop smallish CRUD apps in MS-Access in two weeks or less. It's up and going without fuss and muss and without fiddling with servers, containers, DBA's, etc.
You have to admire its nimbleness.
Yes, the database "crashes" fairly often, but it's easy to make frequent round-robin-style file-based backups using Windows Scheduler and DOS scripts.
Most databases cannot be properly backed up with file-based techniques because of syncing of internal pointers. But MS-Access's separate "lock-file" based technique somehow facilitates file-based backups.
Such MS-Access apps are far from perfect, but if you factor in everything, they seem to be a net benefit.
I'd probably do a web app myself
If follow-on maintainers don't know the web framework used, it can be hard to maintain. Web apps are rarely nimble to do without an involved framework on which the developer is familiar with. MS-Access avoids that problem with ubiquity and a light drag-and-drop learning curve. (It did get harder to learn when they went from coordinate-based to an HTML-esque flow engine around 2006.)
Let's face it, desktop GUI IDE's are usually much easier to learn than web stuff. You don't have to deal with the web's lack of state, and CSS/DOM/JS headaches/bugs/inconsistencies.
When I first learned MS-Access, I barely had to read the manual. I could discover most functionality by clicking around. With Base, I had to constantly dig in the manual and still couldn't get it to do many ordinary CRUD idioms.
I spent a couple decades as a power user of the MS Office suite and find that I can generally make Calc do what I need as a spreadsheet and even Writer as a word processor. However, pretty much every time I've tried to develop a solution in Base it turns into a fight and I end up throwing up my hands and going with a different database solution. Calc doesn't even work all that well with it... and it's one of the few applications that works with it at all.
Running on? Wait, you mean I have to get IT to set up a server for me? Who's responsible for maintaining that? Backups? They're going to do that for something used by only 10 people that saves us maybe 20-30 hours a week? How much are they going to charge my department for this?
I wonder whether today’s equivalent could be made on Raspberry Pi. It requires a few tricks, but there is so much demand from managers who could afford paying 50€ out of pocket.
Of course, having a rogue box plugged to the internal network with a Wifi and Bluetooth chip on board is not IT-approved. Can it be bypassed?
The largest drawback is that it comes with an Oracle database bundled, so many of the savings in development time are wasted dealing with it.
Libre office has "base" but its just a front end. My boss uses access, she like the query builder. I've got my mysql instance and some front end tools that do the same, but I'm a developer.
Filemaker is another of these applications, but not open source. The thing these stand alone apps have is direct printer access for printing forms and labels. It makes it hard to get off.
(Our get off filemaker solution is to download the data from our website and use a stand alone print app to print the labels. One extra step, but its not completely ideal.)
Note that any number of cloud startups don’t count as an alternative to access. When these things start it’s as an excel sheet with data that no one will go through the enterprise hassle to get cleared for anywhere but their own hard drive. This needs to sit above excel but still local. You need the entire business case and business value while it’s still in a local directory.