[Closi]

The interface between Microsoft PowerApps and Microsoft Dynamics for example seems to make sense to me - that these low-code solutions can be used to augment an existing (cloud-based) ERP with new forms/capability that wouldn't otherwise be practical.

It seems to be a case of 'right-tool-right-job' rather than a blanket rule that no-code is good/bad.

I actually think no-code is incredibly powerful when applied by the right person to the correct problem, and will run circles around a custom-developed app in terms of cost, time and flexibility. If you apply it to the wrong problem then of course you aren't going to get the same outcome, like with any technology. I think the mistake people often make is thinking that no-code aims to eliminate all-code, but like any development tool it just fits a certain niche well.

[patentatt]

I use no-code and low-code tools daily to spin up simple things that are long-term maintainable. I can write real code, but the speed of cranking out these low/no-code sites is unmatchable. Is it frustrating at times? Sure. But like you say, when it’s the right tool for the right job it can be a good idea. We don’t have any truly ‘non-technical’ folks touch any of it though, at worst it’s someone who is basically a self-taught programmer who has a good conceptual understanding of things but may not be able to wrangle the syntax of a traditional programming environment.

[hypermachine]

I personally believe that Microsoft has lost their way when it comes to low code (which is why we are trying to build a replacement). PowerApps is a lot less powerful than the traditional VBA/Excel/Access combo.

However they did manage to add RPA to PowerApps, which is a plus.

[Closi]

Eh, VBA & Excel serve a fundamentally different use-case for Microsoft. Building lots of hacky applications using spreadsheets was never the intention, and does not result in good applications.

Access... I agree and miss it, but I can see why they wanted to replace it. You couldn't build scalable applications with it because of database locking, and to do the sort of stuff you can do in PowerApps you had to resort to VBA which was beyond the capability of most users (and a language they were trying to escape from anyway!). Lots of the things being built in Access could also be built in Sharepoint Lists, which was also simpler for many users and 'cloud/mobile native'. The more complicated things being built in access... I believe Microsoft probably looked at a lot of them and thought that they would be better in SQL Server & C# / Visual Studio. Plus from a commercial perspective it's way easier to sell PowerApps, you just show managers that you can put things on their phone.

[hypermachine]

Their biggest mistake was not scaling the VBA/Excel/Access stack beyond desktop and updating it. Where is the WinUI integration for VBA? The product and language was fine but it has been abandoned by Microsoft. It is easy to learn and use but they never tried to make it a cross platform technology.

[Closi]

I don’t think that’s a mistake - VBA in the browser sounds like an awful technology that I want nothing to do with!

Also most VBA code already written is inherently locked into the windows API and COM framework so isn’t multi-platform by design. Code written in VBA on Excel for Windows often doesn’t port across to Mac without errors because there is little abstraction from the host OS. That’s why the replacement technology is a cross-platform JavaScript API for Excel (that will eventually allow fully cross platform macros).

It does have WinUI integration via winforms, but again porting winforms to mobile and web would be a huge technical challenge and be very ugly (or break compatibility).

[PaulWaldman]

VBA in the browser? This sounds like old school ASP using vb script!

[hypermachine]

Join our mailing list :) Give us a try when we launch, you might be pleasantly surprised.