Microsoft Power Fx – A low-code general purpose programming language
github.com
github.com
Excel is one of the world's most popular programming environments, because it has such a low barrier to entry, but it's limited: the input is always a grid of numbers, and the output is always a grid of numbers, which limits how useful it can be to people outside number-crunching professions.
Visual Basic (especially the original, pre-.NET incarnation) let you create Real Windows Apps with all the inputs and outputs that entails (images, copy/paste, files, sliders, textboxes, databases) and let you use a fairly simple and forgiving language to wire them together... but the barrier-to-entry was still a lot higher than Excel, even if it was lower than C++, or even Visual Basic.NET.
This PowerApps thing seems like an elegant middle-ground between the two - rich inputs and outputs (images, sliders, text-boxes, databases), with a simple, predictable language to wire them together. The inputs and outputs aren't quite as rich as Visual Basic, but the shift from native apps to web apps has changed people's expectations since the days of VB6, so that's probably an advantage.
In practice, it absolutely makes a difference.
Students, our future developers and power users, should not be locked up in their perspective, but be set free to choose the best for their future endeavors.
There a lot of kludges, especially around teletypes/terminals, yes. But the common interchange format being ~ASCII~ UTF-8 makes learning the ins and outs way more pleasant than if everything gets connected by COM, .dll APIs, inscrutable .inf files or whatever Microsoft thinks up at a given decade (you can notice I've stayed away for a while)...
Now Excel stands aside as as environment where learning _was_ pleasant, everything had an inspectable representation and a shared interface! Despite arrays bounds and reuse-by-copy-paste being messy, spreadsheets remain a sweet spot of bringing power to "low-code" users. I didn't look into this specific project enough to say where falls on lock-in-vs-interoperability scale, but IMHO the world needs more "spreadsheet plus" experimentation so I wish them the best...
This thing seems like more or less the same, except slightly different.
Low (or even negative) value for the users but probably high value for the managers and programmers who hope to get a promotion out of this thing.
Microsoft should just stick to Power Query and make it a real standard instead.
You need a costly instance as soon as you go more advanced.
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.
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.
> 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.
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.
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.
Maybe you should have digged a little further. To lazy load related entities you would have to declare the navigational properties virtual.
https://docs.microsoft.com/en-us/ef/ef6/fundamentals/proxies
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>
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).
So why would the state of the product as it was 10 years ago matter in your decision to switch back today?
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?
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.
If you're trying to lazy load after that, you will get significant performance issues.
Otherwise, I've created an erp+e-commerce on EF and didn't encounter much issues.
One time, i had an performance issue case and detailed the issue on the nuget repo. Next release had a workaround.
You kind of just described Linux, Unix, modern Web dev, iOS dev, Android dev etc.
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
Add Android on this category too. They also do videos to be even more infuriating!
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?
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².
¹https://insights.stackoverflow.com/survey/2020#technology-mo... ²https://insights.stackoverflow.com/survey/2020#technology-mo...
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.
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.
There is seldom any product from them that feels consistent and cohesive in its design and in the ways in which you can interact with it.
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 just use SQL these days. Way better. More boilerplate, but that's not a bad thing.
Pretty much this. Use MS Power platform exclusively for reading/writing from MS things and you should be OK. Venture beyond that and it's painful.
A lot of stuff seems to have grown out of (or is just layered upon) Sharepoint and Dynamics, so there is a lot of synergy there.
Through Edge browser. Corporations think "it's secure" to lock stuff to work in one browser and MS is more than happy to deliver this.
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.
- 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...
Maybe just a few of the "over a dozen" to give the rest of us a sense of the sort of apps that can be successfully created in this environment.
Was there anything that was less-than-perfect particular from the perspective of the end-user?
Has your company decide to use powerapps for all CRUD requirements going forward? This seems logical based on your assessment.
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.
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.
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!
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.
It sounds like your app was not so simple.
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.
Or go directly into this module: https://docs.microsoft.com/en-us/learn/paths/integrate-power...
> Microsoft Power Fx is the low-code language that will be used across the Microsoft Power Platform.
The emphasized part above is all you need to know to understand that Microsoft Power Fx is NOT a low-code general purpose programming language, as is mistakenly stated in the README document. It might be general purpose in the Power Apps context, but it's a moot point from the larger perspective. Generally, Microsoft Power Platform and, thus, its subset Power Apps, present a much stronger lock-in risk than Azure and some other products and services.
> We are in the process of extracting the language from that product so that we can use it in more Microsoft Power Platform products and make it available here for you to use. That's going to take some time and we will report on our progress here and on the Power Apps blog.
I think more interesting than "low code" is the stated goal of enabling "the full spectrum of development from 'no code' to 'pro code' with no cliffs in between."
"Pro code" means you can edit the source with Visual Studio and use source control.
This provides a path to convert a rapid prototype into a real app.
Got an example?
I mean, yeah, great ideal, but that doesn’t appear (to my superficial look at it so far?) appear to be anything other than an ideal.
I can also aspire to build a platform which enables everyone to prototype and then also run it in production with no performance issues, where “pro developers” can just pickup where “casual developers” left off on the prototype.
...but I’m not really interested until someone actually does it, rather than just talking about it.
The power platform is a lot of PowerPoint and sales talk so far from what I’ve seen, but with what seems of actual implementation always rolling back to Q2 next year when you ask for the details...
I mean maybe you got further than me down the rabbit hole than [1], but yeah... I can modify some of the display javascript as long as I use the API and do not interact with the DOM is 100% not a killer feature.
[1] https://docs.microsoft.com/en-au/powerapps/developer/model-d...
This one seems to be going in an open source direction, and building upon web standards. This gives it a much better chance of success.
Obviously it requires investment, and there is no certainty of success.
But even just a carbon copy of an existing project like Access 365, but an open source version that targets the web would be very useful. Especially if it could be extended with .NET and put into version control. Although there are competitors in that space.
Reimagining the entire Rapid Application Development model is riskier for sure.
- https://doc-snapshots.qt.io/qt6-dev/qproperty.html
- https://github.com/Logicalshift/flo_binding
- https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui....
- https://raphlinus.github.io/rust/druid/2020/09/25/principled...
Does anyone know how properties/FRP/Power-Fx compare to FRP frameworks, or ReactiveX, or MobX, or Svelte (JS)?
By comparison, with React or ReactiveX, you can do very similar things, but by default, complications creep in because of how the language works. In JavaScript, for instance, you have to worry about binding "this" for example: https://reactjs.org/docs/faq-functions.html In ReactiveX, you have to think about how you're going to structure your code, and maybe even occasionally draw flow graphs.
I would also compare this to SwiftUI or Flutter, but more from the app layout perspective, where both platforms are much more mature than when they started. Here's an example comparing React and SwiftUI: https://blog.maximeheckel.com/posts/swiftui-as-react-develop... One could imagine a meta-article that compares Power-Fx to SwiftUI to Flutter, etc. Actually ... I went hunting for how state works in Flutter, and it's remarkably complicated, showing perhaps that languages which are free to evolve can maybe iterate to better solutions faster: https://flutter.dev/docs/get-started/flutter-for/react-nativ...
To that end, I'd look forward to seeing more projects and languages adopt the "automatic code upgrade" approaches widely seen in Xcode, React/JS codemods, and here, in Power-Fx. The idea that somebody has mapped a conversion from "the old way of doing things" to "the new way" is really convenient when the language can support it.
I'd be interested to see if Power-Fx might expand to automated test cases -- wait, apparently that's a thing for Power Apps: https://powerapps.microsoft.com/en-us/blog/introducing-test-... It maybe needs a bit more usability improvement. It would be amazing if it behaved like Redux such that you could scroll through your test playback and maybe even view or add assertions at different steps or if it supported automatic "snapshots" of visual appearance or view state, perhaps like Jest. Theoretically, you could run a test step twice (or more, such as when fuzzing) and if its output changes, mark that section visibly as dynamic or "to be ignored/fixed later" (kind of how Bazel can warn on non-deterministic build steps). If a function loads remote data, maybe it could also be a suggested snapshot for the test, and once you've a snapshot of loaded data, you could experiment with automatic fuzzing. There's a lot of potential in testing functional UI that could improve apps and even inspire tools for other, more traditional languages and frameworks...
Thinking about testing tools, I suddenly had other ideas: What if you gave Power-Fx an input, an output, and then had it suggest what combinations of functions might produce that result? I'd imagine it would be more of a learning tool, but it could be interesting. Similarly, for education or understanding complicated functions, maybe there's a "debugger" mode where you could hover over any part of the function and it would tell you the value of that part of the function, given the view's current state/input, kind of like how Excel highlights cells that store data? Or to automatically convert a function into an English text representation that might be 5-10 sentences but would use existing data/context to explain itself? That way you could follow the flow of the function the way some regular expressions tools help you understand what's going on in a complicated regex expression/function, for example.
- You brought up "OnSelect" and binding "this" in JS, but they don't seem related to picking one way to propagate state through a GUI (either "push", "pull" (signals and slots), pseudo-immediate-mode and state diffing (React), FRP, property binding, ReactiveX, or something else).
- https://blog.maximeheckel.com/posts/swiftui-as-react-develop... does discuss state, but you brought it up in the context of app layout. App layout is another area with multiple choices, but it's more linked to visual design, and less to functional correctness (which is vulnerable to state-propagation bugs which I was talking about).
- Automated code updates, and test generation, are not related either.
It may be unfair, but as an academic, when I read "not Javascript" I thought, "oh yeah, seems cool, surely anything is better than Javascript" and then it hit me that they were gonna base it on EXCEL. The nightmare platform to end all nightmares. The software that's responsible for austerity [1] and for people dying of Covid [2].
OK, I'm sure this is unfair. Maybe Excel's underlying design is a great computing platform? Comments from domain experts?
[1] https://www.washingtonpost.com/news/wonk/wp/2013/04/16/is-th...
[2] https://warwick.ac.uk/fac/soc/economics/research/centres/cag...
>The study’s most conservative estimates suggest that the failure to contact trace is associated with more than 125,000 additional infections and more than 1500 deaths.
IT people hate Excel because normal people can get work done, much like HyperCard and Flash before it. Perhaps someone will write a more IT friendly Excel without losing the users.
Excel's limits https://support.microsoft.com/en-us/office/excel-specificati...
A consultant should know his tools, that's what you pay him for.
This is arguably more a business problem, but there's real issues when people coming/going and then having to get familiar with dozens-hundreds of spreadsheets. Maybe if they're good at Excel, they just pick it up easily, I dunno, but I've rarely seen stuff like confluence documentation and edit history and other supporting docs for spreadsheets that are critical to the company. It kinda feels like they rely more on tribal knowledge than devs.
Nothing about our languages or tools constrains devs to necessarily do this too, we've just got a culture of doing that stuff because we know how awful life is without it. Maybe it's different for spreadsheet people though. I could just keep the business code on a single hard drive and deploy by copy-pasting over a network share or through email, but you'd rightly call me mad.
Now, if programmers are unable to understand the logic behind Excel models to "productionize it", then we have a problem with the education of programmers.
https://www.microsoft.com/en-us/research/blog/lambda-the-ult...
> By Calc Intelligence, we mean the research goal of bringing intelligence to end-user programming. The spreadsheet of the future is a trustworthy collaborator and teacher.
> In December 2020, we announced LAMBDA, which allows users to define new functions written in Excel’s own formula language, directly addressing our second challenge. These newly defined functions can call other LAMBDA-defined functions, to arbitrary depth, even recursively. With LAMBDA, Excel has become Turing-complete. You can now, in principle, write any computation in the Excel formula language.
And then they go and re-enact Tony Hoare's billion dollar mistake, for no good reason that I can see:
> Some language such as JavaScript uses the concept of an "undefined" value for uninitialized variables or missing property. For simplicity's purpose, we have avoided this concept, treating instances that would be undefined elsewhere as either an error or a blank value. For example, all uninitialized variables start with a blank value. All data types can take on the value of blank.
This is the same spurious "simplicity" seen in Go, and I don't understand the appeal - especially coming from a team that clearly "gets it" when it comes to the importance of expressive types.
As for Power Fx, in one particularly fun PowerAutomate flow I crafted for them, I wrote the following one liner to display a "percent complete" value for a given employee with regards to trainings they'd taken vs. trainings they were expected to have taken for OSHA compliance purposes. Parsing it is left as an exercise for the reader:
formatNumber(add(mul(float(div(sub( length(variables('TrainingsConducted')) , sub(length(split(variables('IncompleteTrainings'),';')),1)),float(length(variables('TrainingsConducted'))))),float(100)),float(0.5)),'##')
Low code, indeed.
Overall, I rate the POWERStack 8/10. It's not perfect, but it's fairly robust, not too difficult to reason about, and there are more than enough enterprise clients married to Microsoft to keep me in business for the foreseeable future. My only requests are to let me code Power Apps and Power Automate Flows fully in code-behind. I get that they're low-code tools by design, but in practice, they make things more difficult than they need to be for those of us who are quite happy to live in code, and I'd like to be able to build tools for automating the process for updating/adding functionalities to existing powerapps for those stakeholders that are on the absolutely-not-a-single-line-of-code-ever end of the development skill tree. Otherwise my business (in the Microsoft space) will remain bottlenecked by my time, and I'll have to dig elsewhere for my "set it and forget it" income stream.
If you need help building things with these tools/in this environment, feel free to reach out.
At some point, when Sciter (https://sciter.com) was young it was named HTMLayout - pure HTML/CSS engine without script. At some point I've decided to add a bit of scriptability/formulas directly into CSS so you might say (in CSS) for example this:
button#show {
click!: $(someotherelement):visited = true;
}
So CSSS! (css script) was born: https://sciter.com/docs/core/csss!.htm - it was even more powerful than Microsoft Power Fx - you can even define functions in it and operate with all data types of CSS.
The excitement ended when I've got a bug report with HTML/CSS document where one of focus!: ... handlers in that CSSS! spanned more than a page of printed and ugly text. So I've said to myself: it is time for scripting - anything, even JS, but with regular code flows and organization.
I worry that a year or two down the road there will be production Power Fx applications hitting all sorts of problems that would have been prevented if there was a proper numeric type from the beginning. Computers are fast now, the average application can handle burning a few extra cycles on addition operations when updating a textfield if the alternative is a customer's account balance getting miscomputed.
> The binary representation of a Decimal value consists of a 1-bit sign, a 96-bit integer number, and a scaling factor used to divide the 96-bit integer and specify what portion of it is a decimal fraction. The scaling factor is implicitly the number 10, raised to an exponent ranging from 0 to 28
Also why isn't python or a subset of js used for low code app building ? Why does it always need to be a new language ? Genuinely curious
Here's one that touches on your question: https://powerapps.microsoft.com/en-us/blog/what-is-microsoft...
Most people who have been programming a while disregard what a huge barrier to entry syntax is. Python's bizarre white-space sensitive syntax is especially bad for this kind of embedding. Another huge barrier to entry is the need for explicit iteration - the much more beginner-friendly option is to express operations in terms of their effects on the "selected" element in a list, or on the whole list, relying on the programming environment to actually handle the iteration.
Overall, I think the approach taken here, of offering a beginner-friendly programming language AND environment, which exposes the resulting code as a data structure and not an opaque script, has some of the best chances of taking a PoC built by a domain expert and actually turning it into production software. Even better, it greatly expands what a user can do without ever reaching for a programmer to do it for them.
Embarcadero Delphi has become irrelevant, SAP is not accessible to most consumers. The newer generation of platforms like Retool and Bubble are all designed with software engineers first in mind when it comes to extensability and customisation; they are very inaccessible to layman if you stray from the well-beaten path. They all force you to choose between a false dichotomy of either pure GUI and no code, or an obtuse API that requires a CS degree and five years of fullstack software engineering experience to understand.
In VB6/VBA, calling Windows DLL via COM was trivial. The entire power of the operating system was at your disposal in a few simple readable lines. I want to make a similar system for the modern web and APIs. iOS's Shortcuts may look pretty but they are a step backwards from the HyperCard days.
[0] The litmus test I use is this: Can I teach somebody from a non-STEM background how to code and more importantly get them to integrate it in their own workflow in an afternoon? With VBA/VB6, yes. Everything is a click away. They had hot reloading in 1995. It took JavaScript 20 years to reinvent the wheel. Good luck explaining even how the packaging dependency system works with Python.
In fact what I have learned doing a couple of consulting projects for a life sciences companies, is how many of Excel VBA powerusers eventually get IT to give them VB.NET and carry on from there.
They don't think twice about adding the DLL/COM libraries required to access the laboratory data readers for accessing cell data values.
VBA's biggest weakness is that its open source community and ecosystem is non-existent, so you always end up remaking the wheel. It's just easier making either python or javascript the default franca lingua.
It looks like Microsoft is a few steps closer to that kind of thing with Power Automate.
I also have a flow that brings the Planner tasks back into SQL so that I can dyanically create links to the Planner tasks list in the SQL database frontend.
Power Apps are irrelevant to you unless you're heavily integrated with O365. And if you are, chances are that you're in a large organization. And if that's true, you hire a certified MS partner to handle maintenance, you don't leave it to non-technical staff.
At best, like MS Excel, staff can use the tool to prototype something, and then let the consultants figure out how to create a working solution that works across the whole org.
A Customer (who frequently creates macro-laden Excel contraptions and byzantine nests of "linked" workbooks) was trying to automate some workflow between a third-party application and Excel.
The third-party application is a bit of a "platform" (a "let's re-invent Microsoft Access" data roach motel type application) and uses lots of owner-drawn controls masquerading as common controls (with no keyboard shortcuts). He was struggling to get the UI automation functionality to do what he wanted.
Having spent a "former life" writing VBScript automation code using "SendKeys", etc (and using various other macro automation tools) I explained that he was descending into the hell that is other people's Windows UI behavior, and that it often ends in frustration.
I expect that this platform will end up, like so many before it, being used to create inscrutable edifice in many companies. That edifice will be abandoned when the knowledgeable party leaves a company and nobody new wants (or knows how) to figure out how the junk works, or will become wildly mission-critical and have massive amounts of money poured into it to keep it working, lest civilization collapse (e.g. "The Machine Stops").
The only one that I have used that seemed any good was Labview, and even that is not really 'low code', just 'different code'.
I believe in the power of good reactive programming as Excel is amazing, and this Power-FX is looking really cool. I'd be concerned about how it fits within the larger engineering world versus the Microsoft universe, but I built a programming language that is reactive from the get-go.
And yes, it's in the context of board games, but I hope it can become more general in the future. Reactive just makes things so... easy: http://www.adama-lang.org/docs/reference-reactive-formulas
yaml + Power-FX
I've seen multiple platforms do this the other way around and before as a result the GUI is in full control of the app schema and you end up with machine generated config which is hard to debug, reuse, review and edit.
While designing the app schema for Lowdefy [1], we are only implementing the app schema by coding it by hand - all the time (at least until all best good practices are established). This ensures that we always implement predictable defaults and that we make sure that developers only write the minimum config to be able to create an app. No unexplainable / magic paramaters in any the schema.
We also implemented a MongoDB like query model in the YAML (Lowdefy operators), and we are often surprised by the level of complex logic that developers construct with ease.
Source: am both
Occasionally I'll have flashbacks to a younger me doing a similar thing in Access with VBA 15 years ago. [herewegoagain.meme]
At best, these things usually end up as decent programming languages for professionals that end-users avoid like the plague. At worst, they end up as giant dumpster fire where people are lured into a doom of unmanageable code, as it seems easy enough to build sloppily until it's overwhelming and unintelligible. The other features (declarative, functional, stro gly typed) give me some hope it's not a total disaster, but...
[0] https://github.com/microsoft/Power-Fx/blob/main/docs/overvie...
Are there any services I can use as a drag and drop front end builder and connect data population to my backend? checked out wix and webflow, they both seem to require storing data on their side and most of tutorials are showing how to populate that datastore with airtable or zapier, which is not an option for me.
First, Worth noting you can export Webflow as code and rehost it wherever you like if that’s helpful. BusyWorkHQ hasn’t launched yet I don’t believe, but it’s a backend builder for Webflow and may help you solve your problem by letting you connect a database/api thru to Webflow. @PatrickStolc on Twitter is building it
Have a look at Adalo - They have the ability to replace their backend with an external database (it’s a little bit tucked away but it’s there). The downside is that the front end parts aren’t as freeform as Webflow. They’re more focused on mobile but support web apps too
You may also be interested in React Studio, Wappler or UIBakery
> you can export Webflow as code and rehost it wherever you like if that’s helpful.
this sounds good starting point for me, I am guessing in this case I need to render HTML on server side or add some additional code to exported source code to be able to render data front end on browser side.
Other options also seem interesting, thank you!
As an alternative (and possibly easier imo), you could add custom JS code on Webflow (it has an embed function) to hook onto its dynamic list functionality and add your own data inside.
In other words, create a list on Webflow with one item in it designed the way you want the final data to look. Then use JS code to override the data on that page with your own data source and to duplicate the list item as many times as you need for your data source
This may be a useful reference: https://cmsdocs.webflow.io/
Finally, I’ve not looked at this much but it may help: https://www.nocode.tech/lessons/building-user-authentication...
Edit: not really usable for anything customer centric, which on a re-read of your comment seems to be what you're going for.
those people seems to be unparalleled when it comes to programming languages, I'm not sure about compilers and runtime because JVM/GraalVM are impressive as hell, but I think Roslyn stands
Low-code is application specific configuration, with some control flow primitives