We recently tried to build a relatively simple PowerApps application - under the assumption it would save time over pumping out a React boilerplate form. Never again.
We wanted it to be able to integrate with our backend which lives outside the MS ecosystem. No problem we thought - that's what custom connectors are for. Except they don't work with any of the automated form generation functionality. So we pretty much have to build the form entirely manually.
Low code becomes high code all of a sudden - except it's worse than just coding and learning a new framework. You can't just input your code anywhere you want, or import your dependencies, etc... You have to hunt around in a zillion different (laggy as all hell) interfaces to find the right location where that code can live. Or maybe it's not code - but a toggle somewhere... OMG... kill me.
Good luck if you are trying to learn the lower level aspects... since all the tutorials, blogs, youtube videos - all assume that your data all lives in Sharepoint or some other MS resource - and that your connector actually works as advertised.
If you can code - and your stack doesn't already entirely consist of the MS ecosystem. Just roll your own.
> You have to hunt around in a zillion different (laggy as all hell) interfaces to find the right location where that code can live. Or maybe it's not code - but a toggle somewhere... OMG... kill me.
> since all the tutorials, blogs, youtube videos - all assume that your data all lives in Sharepoint or some other MS resource
If you have to troubleshoot software advertised and explained by happy smilling people dragging and dropping things, code automagically appearing from snippets, claiming that "it's easy" - RUN AWAY. Your mental health is at stake.
I was not having the best time mental-health-wise anyway about 10 years ago. I was freelancing and writing an application for a doctor's surgery in C#, using some of the cool new toys they'd produced for it. Including Entity Framework. Which came with lazy loading of object properties, cool. Except I kept bumping into cases where the object hadn't lazy-loaded, and data I knew should be there, wasn't. Digging in through myriad stacks of documentation and notes, all of which said that data would be loaded if it was asked for without needing to load it, I finally bump into a small note, obviously written by an actual dev, that cheerfully pointed out something like "to ensure your data is actually loaded into the object, you'll need to call the loadData() method before using it" (I paraphrase from memory).
I lost it. I completed that project, then uninstalled Windows, installed Ubuntu, and started learning Go (I intended to also learn Rails and Python, but fell in love with Go's simplicity and haven't moved on since).
It actually helped with my mental health. Realising that at least part of my problem was that people were professionally lying to me was an insight I needed.
I'm never trusting a Microsoft technology again. It's always nice and slick on the surface, and then a twisting pile of mess underneath.
Note that the EF will not create proxies for types where there is nothing for the proxy to do.
This means that you can also avoid proxies by having types that are sealed and/or
have no virtual properties.</quote>
This is a common rookie mistake, unfortunately.
Entity Framework is an absolutely top-tier ORM (if you like ORMs). Because lazy loading is frowned upon by some purists (and DBAs), EF also support controlled/eager loading where nothing happens (lazily) behind the scene.
You can - for instance - in the query use <code>.Include(x => x.RelatedEntity)</code> to load a related entity eagerly without going back to the database server to load the related entity for each row (the so-called N+1 problem).
Because Linux is open about everything, but particularly about what works and what doesn't.
Working with Microsoft tech felt like being gaslighted by an abusive partner. Their documentation absolutely did not match what their tech actually did.
I'm really happy working in Go on Linux. Why would I want to switch back?
If the thing which would be intuitively obvious to 90% of people in your audience doesn't work, then your framework is wrong, not the people. It shouldn't take a mountain of documentation to clarify a basic feature.
There can be many "basic features" in a large framework that can't be made more intuitive without making the other features less intuitive.
Just because there are some unintuitive edge cases which you can identify in a technology doesn't mean the technology is "wrong". Pick your favourite technology and I am sure you can find many such unintuitive edge cases if you purposefully look for them.
I’ve had similar experiences with Microsoft’s documentation. My memory is fuzzy but one instance I can recall the documentation was clearly what was meant to be in the final product but most definitely was not what shipped. To make matters worse the docs as they were would often result in a configuration that worked on the first sync but subsequently failed or even caused the service to reach a permanent state of limbo where it could never finish starting. This left a lot of people thinking things were broken for other reasons.
They took ages to for them to finally update the pages. In fact it took a well known consultant, one of their mvps, writing not just documentation that worked, but also thorough instructions on how to fix the predicament Microsoft got you in. I wouldn’t be surprised if the team writing the docs were completely lost until they read his blog. The service was just one component but it was ridiculously complex for what it did. Sometimes I wonder if they crammed the service (Forefront Identity Manager) in to save the team working on it since they cancelled the standalone version of it.
Their docs can be good and are certainly improving but it does still feel like disjointed teams doing their own thing sometimes.
My assumption on this site is that most people talk from the perspective of devs. So I assume your experience with Microsoft's documentation is also on the dev side of things. I can't speak to that, I'm a sys admin so I have a different experience. And my job has me approaching technology from the opposite end. From what I have seen, Microsoft's is generally pretty good. Not the best but definitely far from the worst.
I’m afraid not. Those docs would have been used by both sides, especially for non-prod environments but they were definitely operations oriented.
I would agree they’re usually good but when they were bad, they were real bad. And bad seemed to happen a lot more outside of the “big” internal fiefdoms at the time (Desktop, Server, AD, Exchange, etc.).
They did seem to hit a rough patch during the transition but the only thing I’ve seen is gaps here and there due to what I assume is incongruity between teams. Like tools being moved from an installer and therefore the installer docs but corresponding docs for how to get those tools not being created/updated elsewhere.
I've always like C# for its multi-paradigm nature, good runtime, and excellent collections framework. It's basically what Java could/should have been.
Unfortunately the legacy tooling is infuriating to work with. It's been steadily improving for the past few years with the advent of .NET Core but in practice this doesn't mean much. If you work at a ".NET shop" then odds are that the devs that work there have been firing up Visual Studio and creating solution files for the better part of two decades; good luck getting them to use dotnet or Docker Compose, not to mention the long-lived legacy apps floating around that are still built that way and live on IIS in a corporate datacenter someplace.
Yes, C#'s greatest weakness is the tooling. There's no autoformatter, for heavens sake. (There are two in theory, but one is prettier's support for an old version of C# and one just doesn't work). And, yes, solution files and project=assembly are both absurd.
There's autoformatting tools in C# editors (VS, VSCode) and also the dotnet-format command-line tool for non-editing environments. Have you tried these?
The modern .NET tech stack has radically changed so much in the past 4 years that it's not surprising that so many folks are still having flashbacks to the old proprietary days.
Yeah but no. Linux is pretty open and honest about the twisting mess. There are years-long discussions about them. The Xorg/Wayland thing has been surfacing a few times on HN recently.
If you search for a Linux problem, you'll get 50 different people telling you 25 different ways of fixing it, most of which work.
If you search for a Microsoft problem, you'll get 50 pages of corporate bullshit that pretend everything's OK. You have to ignore those and dig further to find some unofficial blogger or random dev post that actually tells you something useful.
Also looking at you, Apple - less bullshit and more honesty in your support pages please
> If you search for a Linux problem, you'll get 50 different people telling you 25 different ways of fixing it, most of which work.
Not in my experience. They may have worked for some version of some distro, but it is almost always not the one I'm trying to fix the problem on.
> If you search for a Microsoft problem, you'll get 50 pages of corporate bullshit that pretend everything's OK. You have to ignore those and dig further to find some unofficial blogger or random dev post that actually tells you something useful.
Unfortunately that is also pretty accurate, and it has been getting worse since Windows 10, resembling more and more the problem with searching for solutions to Linux issues. Does this fix still work for 1901 or did it only work for 1607?
> You kind of just described Linux, Unix, modern Web dev, iOS dev, Android dev etc.
More devs seem to have this opinion of Microsoft technologies though. Their desktop OS is the most dreaded as a platform, and the most dreaded of any OS except for Android (by 4‰, and of course devs already killed Windows Mobile)¹. And even more relevant to the link we’re discussing, another relatively low-barrier-to-entry language they created is the single most-hated programming language there is².
That is interesting. I assume it's because corporate takes over and honest communication is no longer possible when the financial stakes of admitting error become too large. But I could be wrong.
I am pretty sure the reason Stack Overflow was created is to provide help understanding what MS code actually does vs what MS documentation says it does. They just happened to hit on a formula that was useful for other people too.
I remember participating in a Microsoft sponsored meeting when LINQ to SQL just came out. Failed to have an answer on how to reasonably implement paging.
I was always ORMphobic person and especially I afraid EF. This framework lets you think query DB is easy and you don't have to dig into details, but it always turns out you have to know how the DB works plus you have to learn how EF works internally. I am trying to stick with micro-ORMs, like Dapper or something like SQLBuiler. Raw SQL is no good too.
I've experienced similar when working with android's api. Docs say x should work, but it's just not happening. Five hacks later, and you've got a working app that feels choppy. Granted this was back in the 4.4.4 days, so things may have gotten easier since then.
To be honest I can't remember (and I'm definitely not going to look). It was pretty early in the development of EF - I understand that this problem no longer exists and lazy loading works fine now.
Which I would totally have understood and forgiven if they'd been honest about it. But all the documentation was lying, except this one tiny bit buried deep in the tech docs. That wasn't the first time I've encountered this phenomenon in Microsoft tech. It seems there's a mis-communication between the documentation team and the actual dev team, and they end up documenting what should happen instead of what actually happens.
You said yourself that the lazy loading actually did work most of the time except for these problem cases, right?
So doesn't that sound more like it might just be an unintentional bug or maybe you had your environment configured differently from what the docs were expecting?
It really sounds to me like you threw the baby out with the bathwater over a small bug, when bugs of a similar magnitude will likely be present on every other platform too (including documentation bugs)
I've never used EF or developed business apps in .NET, but I have used similar technologies like Hibernate in Java and I think you are basically describing standard caveats with any ORM. Lazy loading is often a non-obvious behavior.
If your documentation says in several places that your system does X, but it doesn't, it does Y, then that's lies.
It might be caused by a bug, and what you're documenting is intended behaviour not actual behaviour. But then you need to say that somewhere - something like "We expect the system to do X but we haven't actually tested it so it might not". Not saying that, and instead saying "the system does X" is lying.
And yeah, I stopped using ORMs too :) They just get in the way.
With this definition, every software which has undocumented bugs (i.e. every software) is lying. That doesn't seem useful to me and I don't see how the problem is solved by moving away from EF either.
No, I think there's a difference between undocumented bugs and professional documentation that very clearly documents behaviour that doesn't actually match what the system does.
As others have said, it's a problem that's particularly apparent with Microsoft - it feels disjointed. Like the documentation team read a different spec than the development team.
No, but I do have a longstanding annoyance with the general form of argument in which technologies are dismissed just because they have some weird edge cases. All substantial technologies have weird edge cases.
I cannot agree with you enough. Our company hired a new manager that had a background "familiarity" with PowerApps. He requested that I (a software developer) create a PowerApp that would be used by the company, essentially a ticketing system. I figured with my ~decade experience in developing complex web applications from the ground up, this would be a piece of cake.
What an abysmal way of developing applications. Everything (containers, widgets, etc.) is basically SVG's and your application looks like your designers couldn't use anything but MS Paint. Creating more complicated interactions with buttons and other UI elements was a pain to develop and making the UI responsive was a nightmare. The generated HTML was insanely ugly and the application was very slow/sluggish feeling. After fighting for a couple weeks, I began to (behind the scenes) build out a quick web application alternative to pitch. Long story short, he LOVED the web app version and that is what we are still using today company wide.
> Everything (containers, widgets, etc.) is basically SVG's
Controversial opinion: vector-based UI widgets are the right way to do web apps. Instead of all the existing framework approaches that ultimately produce HTML, both developers and users would be better served by using HTML for the elements on a screen that correspond to documents, but the web app's "chrome" should use SVG. Most of the complications of frameworks come from a blind spot on the part of developers, who continually select a tool with a high impedance mismatch to their goal (producing an app). This blind spot on the part of developers leaves this area under-explored, and in turn there's under-investment in the specs / on the part of browser makers to eliminate pain points in the way that developers are actually using the platform for their work.
The problem is that SVG doesn't AFAIK support layout constraints - you'd have to essentially recreate flexbox and grid in JS, and God forbid you wanted to make the design responsive!
I agree with you in principle that SVG is a better match to app UIs, but we'd need a good layout story for that to happen. And I'm using SVG for much of my own application interface!
ideally, an SVG layout optimised for web app design would be somewhat more flexible than just grid and flex - such as anchoring an element to 2 other separate parents (or in other words, supporting a directed graph rather than a tree). A pure constraint system would be nice, but is probably not viable if fast rendering is important (which, it is).
I went down that road for awhile. You start running into problems when you research all of the default behavior that the built-in widgets have, and this is even before you get to accessibility issues.
I love the idea of punting on HTML and writing a ground-up SVG UI toolkit, or even a WebGL based on if you're feeling ambitious, but giving up on the built-in browser behavior and all of the automation tooling around interacting with HTML is a non-starter for most use cases.
Interesting, if SVGs make sense, then a new game-engine-like client makes more sense as a general delivery platform. Maybe Dart/Flutter/Fuchsia isn't far off.
- Canvas apps: worth it only for very simple applications that interact with another MS datastore (Sharepoint, CDS/Dataverse) and services. If you mostly need to interact with custom APIs, a simple custom webapp is probably a safer choice.
- Power Automate: stick to very simple flows, take advantage of the connectors but avoid at all cost complex business logic within the flow itself
- Model-driven apps: more interesting in my opinion. They effectively are mini-instances of Dynamics CRM, and you get A LOT of functionality out of the box. You can't tune the UI much, but you get the benefit to build an "interactive database" very quickly, with support for RBAC system, OData REST APIs, Views, Workflows, C# plugins, dashboards. If you need an internal application, used only by a few people (licensing), where you need an interactive data-store without complex requirements on business logic and custom UIs, then I think Model-driven apps can be terribly effective. Now, if only the licensing wasn't so damn complicated...
I'm Power Platform architect, I have been working with Dynamics for more than 10 years. Your post feels more like you were thrown on a project where you didn't know the stack.
I've seen those projects where I'm brought in to fix some internal project gone wrong because they took internal softdev with no knowledge of a platform that exist for more than 15 years.
Meanwhile, I shipped whole systems in half the time you took to "roll your own".
Just try to roll your own ERP/CRM, we saw plenty of time how that goes.
Ok, so, what should a software dev who hasn’t worked with power platform before look at to get up to speed on the proper way to use it with their own api’s?
I have to flip between Chrome and Firefox depending on which bugs in which product I need to avoid :-)
My favourite one is a bug in Flow where you paste a string and the entire UI goes in to an error state (can't even save) so you have to reload and lose any existing changes.
I was curious about PowerApps when it first came out and the past year or two is the first time I’ve ever seen one.
We have a handful of PowerApps at our company and they’re really just forms hosted on Sharepoint sites. Type in some info, select some drop downs and hit enter. I still haven’t experienced PowerApps from the development side, but I’ve been pretty unimpressed with the work I’ve seen from it.
Flipside we rolled out over a dozen powerapps and they work great. Our Engineers can now focus on solving bigger/tougher problems instead of being tasked with making simple crud apps 24/7
I had a very similar experience. Also, the interfaces are hideous and static - even though this was an internal product, the client wasn’t happy. If I’m going to have to customize it so much to make it look decent, we’re back to hi-code.
We wanted it to be able to integrate with our backend which lives outside the MS ecosystem. No problem we thought - that's what custom connectors are for. Except they don't work with any of the automated form generation functionality. So we pretty much have to build the form entirely manually.
Low code becomes high code all of a sudden - except it's worse than just coding and learning a new framework. You can't just input your code anywhere you want, or import your dependencies, etc... You have to hunt around in a zillion different (laggy as all hell) interfaces to find the right location where that code can live. Or maybe it's not code - but a toggle somewhere... OMG... kill me.
Good luck if you are trying to learn the lower level aspects... since all the tutorials, blogs, youtube videos - all assume that your data all lives in Sharepoint or some other MS resource - and that your connector actually works as advertised.
If you can code - and your stack doesn't already entirely consist of the MS ecosystem. Just roll your own.