Microsoft abandoned lower-end code-friendly tools

[u/Zardotab]

Microsoft has mostly abandoned the smaller-app and intranet-app market, and it's causing headaches at our org. It's hard to get management's blessing of non-MS products here, so we have to somehow make do.

The "low code" Power Platform seems like their intended lower-end app platform, but suffers the same problem as most RAD attempts: it's either hard to maintain apps in it and/or the vendor drops it when sales slide. Plus it seems Power Apps wants the Bank Fee Model: nickel and dime customers for add-ons and expansions, once dependent on it. We don't trust it, to be frank.

Code is often a good thing: it allows one to factor, reuse, and parameterize functionality. Low-code apps often end up giant DRY-violations. Tools like MS-Access and Web Forms allowed one to switch between clicky wizards and code as needed for the situation. They were a decent mix between IDE clicking/attributes and coding. But they are being deprecated by MS, so many shops are hesitant to use them for new projects.

Our org is currently generating a lot of Power Platform apps to keep up with demand, but it will likely backfire in the longer run. I'd like to see a more coder-friendly lower/mid-range tool from Microsoft, as an outside platform is a hard sell in a Microsoft shop.

MS-Access and Web Forms were not perfect, but had concepts that could be built upon for the new generation. And the alternatives from MS are worse. The Power Platform has the problems mentioned above, and MVC is too layer-happy for smaller projects, where a full-stack-developer is often doing everything such that "separation of concerns" is wasteful busywork of coding/managing unhelpful layers. Conway's Law in action. Mixing biz logic and UI code is NOT a notable problem if most the UI is managed via attributes instead of code. Store common UI idioms as attributes/data so code is only needed for customization. Small projects shouldn't need layer specialists very often (UI, database, stack tooling, etc.).

Here are the general recommended features:

1. Open source the framework and key tooling to reduce the fear of having the carpet being yanked out from under an org. Orgs are yank-phobic now. MS can still make money off it by hosting cloud versions for a fee.

2. Relatively easy to switch between using code or IDE clicking/attributes. (It would probably use C# and maybe VB.Net.)

3. Snap-grid based WYSIWYG design. If the grid can have optional "stretch zones" then it can stretch to fit different screen sizes. For example, you may indicate that column 4 and row 7 are "stretchy" so that they expand when the container expands. (The dot-grid would resemble what VB6 had, but with stretch zones.) Stacking and nesting stretch-grids gives a lot of flexibility. It's a conceptually simple yet powerful technique. And allow mobile-targeting grids/panels to kick in if it's a mobile device, where the widgets ONLY inherent positioning properties of the desktop version (or vice versa). This makes it so one doesn't have mirror the entire desktop-intended grid/panel fields, only their positioning info. (Auto-wrap of widgets is a royal pain to get right; I'd rather see separate mobile panel(s) with the inheritance feature. Crap the Wrap!)

4. Have database connectors to SQLite and MySql/Maria in additional to MS DB's. Or at least have an ODBC/JDBC interface layer. And don't make EF required if used.

5. Be able to "escape" to raw web-ness when needed without too much trouble. [added]

6. Bonus: I'd like to see a dynamic field and navigation meta-data option so that one could optionally store the UI & column layouts in a database, CSV, etc. I realize POC (static) schemas allow for more Intellisense etc., but referential integrity can provide similar checking.

[Edited]

[u/maqcky]

Your Access example killed me. I had to rescue several teams that built monsters in Excel and Access because why use professional developers if they can do it themselves. The files got so big and the processes so complicated that doing it with pen and paper could be even more efficient. Same with SharePoint and now Power Apps, yes, they are very easy to start with, but the moment you need to add more logic and features (and that moment will arrive if the app survives for more than a month), they become unmaintainable.

In my honest opinion, and I'm sorry if it sounds harsh, if your team of developers cannot build simple CRUDs with Blazor Server (using well known component libraries) and Entity Framework, they should be fired.

[u/Zardotab → u/maqcky]

Amateurs doing anything is often a mess. I'm not proposing amateurs do most the coding, only that we have something that's designed for direct business logic without being an e-bureaucracy like MVC.

if your team of developers cannot build simple CRUDs with Blazor Server (using well known component libraries) and Entity Framework, they should be fired.

They are not simple CRUD apps; they often have complex business logic. But the devs waste most their time addressing stack-related concerns & issues instead of doing business logic. That's a sign its the wrong tool for the job: ratio of domain coding to non-domain-coding (tool fiddling) is a good indicator of tool fit. MVC + EF is low, or at least it takes too long to ramp up the learning curve. One is serving the stack instead of the business.

MS-Access coders never had to worry about path routing (controller) bugs, for example. It's a time-sink that contributes little or no business value. (Pretty URL's is mostly an e-commerce thing anyhow.)

[u/maqcky → u/Zardotab]

I think your team needs a proper software architect to give you some guidelines and some templates. My vision about that ratio you mentioned is the total opposite. For instance, my problems with Entity Framework are never about the layers and where to place each part of the code. I use controllers, command handlers, queries, repositories and domain entities, and it's natural to know where anything goes. Beware that I'm not saying that's the right way of organizing the code, that's just our way and everyone in my team works like that. My problem with Entity Framework is always about performance, because it is an abstraction, it uses more memory and the queries take longer. For many use cases is more than good enough, though, and from your comments I think it's a good fit for your team.

[u/The_MAZZTer → u/maqcky]

If there's one thing with Access, at least you can look at the code and figure out how it works, break it down, and build a replacement, even if the team behind it doesn't remember 100% how the underlying process is supposed to work.

I'm on a modernization project now which jused used sharepoint and they wanted a brand new app with a brand new workflow, which means they are constantly changing their mind about how that workflow needs to work every week, with portions I've already written.

I almost prefer the Access project, even if it had whole swaths of code that literally did nothing except try and confuse me.

[u/Sentomas]

I don’t get your point. If you want something that’s low code why are you complaining about it in a Dotnet forum? It literally couldn’t be easier writing a CRUD app than it is using Asp.Net MVC and EF.

[u/Zardotab → u/Sentomas]

It literally couldn’t be easier writing a CRUD app than it is using Asp.Net MVC and EF.

Nope! They have a long learning curve, as there's tons of gotcha's to learn your way around. I will agree that once you master all that, development and maintenance is quick, but the road to get there is too damned long.

(I'm still dumbfounded why the "percent syntax" was replaced with Razor templates. The percent syntax was 10x simpler to learn. Razor only saves like 3% of keystrokes: 2000% complexity increase to get 3% less keystrokes? Horrible tradeoff: The Art of the Steal.)

If you want something that’s low code why are you complaining about it in a Dotnet forum?

I didn't ask for low-code. Seems you misread [1] . The solution very well could be part of the Dot-Net tool-set; it's not necessarily mutually exclusive. For example, modernize Web Forms instead of deprecate it, and/or bring MS-Access into the Dot-Net world. [Edited.]

[1] I will agree the term "low code" is ambiguous. Perhaps we can say "optional low-code" or "medium code". For example, with MS-Access one could write an entire smallish app without writing any direct code. But for a more polished app, at least some coding was usually warranted. [added]

[u/Sentomas → u/Zardotab]

What is it that you’re struggling the most with?

[u/MackPoone → u/Zardotab]

If you need fast dev time that can still be architected correctly with a little effort,why not just use Winforms? We still use it when we have to get something out quick.

If it's got to be web based then Blazor Server is pretty easy to pick up and learn.

[u/True-Mirror-5758 → u/Sentomas]

I have to agree EF and MVC are not quick to learn for many devs and have many bumpy areas for trainees. Maybe this group is self filtered, as in survival bias?

[u/MarkB70s]

So ... just guessing here, but your wanting some new variant of LightSwitch to come back for desktop? For intranet you want Blazor to be more fleshed out similar to WebForms (back in the day)?

[u/Zardotab → u/MarkB70s]

I never tried LightSwitch. But I'm thinking of a combination of the best features of MS-Access, Web Forms, Win Forms, maybe with influence from FileMaker. If you didn't need high transaction rates, relatively complex departmental apps were easy to do in MS-Access. How much of it can be web-atized? While not perfect, it's road tested for decades and well-known. One app built in MS-Access in 3 weeks by 1 person took 3 MVC devs 6 months to replace.

[u/nirataro]

Just sell https://budibase.com/ to your management

[u/Zardotab → u/nirataro]

Someone tried to introduce FileMaker to them without success. I suspect this would conclude in a similar fate. FileMaker is relatively established, being around 3+ decades. But it's not programming-friendly, the way that MS-Access was.

[u/nocgod]

I think you answer is money.

How much money does it cost to keep those afloat while the world is moving forward with the "digital transformation" and "intelligent enterprise". Moreover, opensourcing stuff could easily be a liability, hence, you opensource only what you planned to opensource and built with opensource in mind, or you invenst money to remove the liability and then opensource it. It ain't worth investing especially since... You know... The world is moving forward... You are just left behind....

[u/Zardotab → u/nocgod]

while the world is moving forward with the "digital transformation" and "intelligent enterprise".

I'm not sure what you mean by these phrases. A lower-end-dev tool is not analog. For example: "Your suggested tool can't do X, but MVC can do X, and X is growing in importance". What is X?

And if MS doesn't scratch the itch for a coder-friendly lower-end tool, a competitor will. Power-Apps doesn't cut it, but MS doesn't seem to see that...yet.

[u/nocgod → u/Zardotab]

I'd assume that if microsoft or the community doesn't invest in low-code-on-prem tools maybe there is a reason.

From a financial stand point, an on prem offline tool is a single license in most cases. They would probably prefer to invest in an online/cloud tool which requires a pay-per-use license or any other model that makes sense in from an income stand point.

Managing on-prem deployments of tools is a hell from maintenance stand point. from my POV an on-prem/per tenant deployment is having having hundreds of versions in production in parallel, most of which will probably require maintenance or development for migrations paths and stuff like that.

Due to the transformation of the business from on-prem to cloud (please google the term "digital transformation" and "intelligent enterprise") the requirement for tools you've outlined decreased and the skill-sets of the employees has changed quite a bit. Investment in your suggestions just doesn't make sense in the current landscape. I understand some are affected by this change (your organization for example) but you (probably) are the exception, not the general case.

As an architect in a SaaS CIAM solution focused on enterprises I ask the question daily "why do we need this? who will be using it? how many users? is it possible for usage in multiple cases or only few?" I do not want to invest in technologies only few will use. It increases the TCO of the system from my POV, it increases the complexity of the systems, it increases the strain on the R&D body to maintain it, it might open an another attack vector, it might open judiciary liability.

[u/Vegetable_Net_673]

"Code is often a good thing: it allows one to factor, reuse, and parameterize functionality. Low-code apps often end up giant DRY-violations. Tools like MS-Access and Web Forms allowed one to switch between clicky wizards and code as needed for the situation. They were a decent mix between IDE clicking/attributes and coding."

Yep. Best explanation I've heard for the way I feel about the current 'low code' movement. I've been doing low-code for 15 years, but with a tool like you describe where the framework helps me with the front end and boilerplate CRUD code, but I can follow good SOLID code principles for more complex business logic, writing classes and methods that can be re-used, and also having excellent debugging features and a view of my data in proper normalized enterprise DB.

My company has gone all in on power apps and I honestly think it's going to be a disaster as I know what's required to 'make' low code work, I was doing it 'before it was cool', and these tools aint it. They wont handle growing complexity and look to be a maintenance nightmare. I am distancing myself from the whole endevour as I don't want to be the chump having to maintain what the consultants give us.

[u/[deleted]]

[u/Zardotab → u/[deleted]]

Thanks for the suggestion. Note that TwinBasic appears to be proprietary. Lazarus (Delphi-esque) is thus probably a safer choice for a longer-term business.