I work in an enterprise environment that has multiple development teams, one of which uses Powerapps and another that uses Outsystems.
My group writes .NET code, but we have an interest in ensuring that whatever low code platforms are in use elsewhere don’t make our lives harder. I know most “normal” developers have a reputation for being hostile to low-code platforms, but I’m quite open-minded, and some members of my team like Powerapps in principle, and based on past experience.
Outsystems seems to be good for rapid development, but (maybe unjustifiably) I get demoware vibes from it, and find my team having to compensate for its shortcomings.
Has anyone got strong opinions on which low-code platforms, in 2023 are capable of getting out production-ready code for non-trivial projects?
Developers are hostile to these types of solutions specifically because once you go past basic CRUD your no code solutions make everything so much harder and complicated compared to if you had of just used JavaScript in the first place.
I’m fully expecting some no code sales people here to disagree. They always do. Those same sales people will try to blame the programmers for getting in the way of saving money or being stuck in their old ways. Have a good long proper conversation with your programmers that you trust and try to understand their resistance better.
In every project I worked on, the users of the system always wanted it to do things that go beyond what the low-code system was designed for. That always required what was essentially coding, but using some clunky UI for advanced code-like functionality.
In the end, you have a system that would have been much more maintainable if you had just gone with a standard "with-code" solution.
They always sell these things with the idea that non-coders can do most of the work on the system, but that's only true for a very basic system. In my experience, it's coders that end up doing 90% (or more) of the work and it ends up being inferior to a coding-based solution.
I think that a lot of the problems that general wisdom thinks are implicit to no/low code are so prevalent precisely because the barrier to entry is so low.
You get a lot of people who have never programmed anything who can basically put together something that almost works by tweaking tutorials and googling around.
But where they get stuck is lacking the programmer's mentality - of being able to puzzle around restraints (which all programming languages have) and then imagine all the worst case scenarios and test against them.
Down thread, somebody even makes the claim that low code doesn't permit for maintenance but of course this isn't true - again, it's just inexperienced users thinking that once something works once it will work forever.
And the amount of professional developers who would be willing to come in and untangle a low code mess as opposed to suggesting a "real" solution (coincidentally using their favoured stack) probably reinforces the idea that the last 20% is impossible with low code.
It's not about agendas or people being stubborn, it's just about people playing to their strengths and having their perspective coloured by experience
As a rule of thumb, the only kind of job posting that should mention a low/no code solution is one for a software developer hired to migrate your current solution to real code.
It may seem like a good idea to postpone such considerations. And it might even be in some situations. But complexity will still bite you in the ass even if you sweep it under the carpet and tell people not to worry about it (for now).
But if people say you can't replace a railroad consist that necessitates engineers and designs with wheel barrels that anyone can push and you say "you totally can, you just need enough wheel barrels" you're being disingenuous about the realities of the two approaches.
A very nice effect of this is cross-functional collaboration—once it's possible for the team's developers to provide the right components as building blocks, then the non-developers in operations, design, marketing and product functions can compose these into full pages.
And being fully honest, I've not seen basic CRUDs since college homework days. Every CRUD I've seen since has some business rules applied to it, whether these are triggers or some special field constraints.
If a business needs a basic CRUD, it gets away using a spreadsheet.
As a result these solutions work just fine until the point where they trip the user up and start repeatedly punching them in the face. The user will usually try to work around the limitations and that's when it goes really badly wrong. Often the users will blame themselves for not knowing how to progress or for creating a mess.
If your needs are simple enough you might never reach that border. It's suitable for those tasks.
It's made worse by the economic incentives of no code platforms too. They try and trap the user on their platform. So, once you reach the border line the user usually has to dump the entire app and bring in a programmer to code it all up from scratch. That makes bad workarounds that much more tempting from the user's perspective and thus that's how the no code solution dumpster fires are born.
however the answer still boils down to "it depends" since it intersects with different industries, and companies of different maturity stages.
making a landing page for some simple site? no code works.
need a fast crud for operations team? no code works.
creating a web app prototype to validate a simple idea? no code works.
refining a product with existing users in terms of platform compatibility, scalability, performance? time for specialists on front-end and back-end languages.
i think there comes a time when sales are coming in at the door and at that point throwing money at the problem makes sense, to move from no code to handwritten web apps and mobile apps.
i personally prefer appsmith over budibase. zapier and n8n, cool stuff too.
but in complex stuff i still come back to reactjs and nodejs.
For simple CRUD apps, internal tools, reports, spreadsheet replacement - low-code platforms - particularly OSS options (Budibase, Appsmith, and others)
This doesn’t really have anything to do with the low-code tools in my experience. It has far more to do with your organisation, and how it’s put itself into a position where it has in-house software developers but are now using “unprofessionals” to “make do”. Usually because the development teams can’t deliver business value fast enough for whatever reason, but your process people can. The issue is that low-code applications don’t really scale well over time. They can, if you take them stipulated, but if your organisation did take things seriously then you probably wouldn’t be here because you’re worried about the impact they PowerApps will have on your team. So my guess is that they will have an impact and that you’re likely not in much of a position to do that much about it.
So here are your options the way I see it, and I know that’s not exactly what you asked, but instead of trying to look for a good technology to solve your organisational challenges, try looking at your processes instead. Why is your organisation turning to PowerApps? Is it because your SWR teams can’t deliver value fast enough? If so, then can you do anything to change that? Stuff like that.
I wouldn’t be too optimistic about it though. These issues are very well explored in things like Conways law and more recently in Team Topologies, and their solutions is often going to be alter organisational processes and practices which you sort of can’t do from the bottom up. Because if your leadership took digitalisation seriously you wouldn’t really be worried about whether or not the use of PowerApps, RPA, whatever else, will impact your team.
I've started using Anvil 6 years ago and never looked back.
I never liked low code solutions, but I was the only developer in my company, so I didn't protest when the management tried them. We hired consultants, spent tons of money, hit tons of walls and gave up.
Anvil is only code, only Python. It's no javascript, no html, no sql, no server management, etc., but yes code. Only Python, but it leaves the door open if you want to use javascript, sql, git, etc.
Here is a post that summarizes it quickly: https://anvil.works/forum/t/showing-off-anvil-to-others/1864...
Perhaps Airtable for an aaS approach that can be exposed to external visitors as a website, but the concept is sound.
One huge problem with no/low code solutions is that people usually think that this doesn't need to be done for no/low code solutions, only for code solutions. But solutions using nodes in order to build stuff also need to be revisited, refactored and thought of as abstractions.
Git commits of node coordinates and minified JavaScript is not my idea of a good time.
What you're looking from a no-code platform is a way to execute custom code, and Zapier has this little virtual machine step that could be either JavaScript or Python and then you can "meet in the middle" systems, that would otherwise not meet before. They behave pretty much like your typical AWS Lambda function, with an input and an output.
I think n8n and Huginn could be suitable for this, but I don't know for sure as I've not had the need to use them.
A few of the shortcomings I had with Zapier (and our people) in this regard:
- Both systems must have public APIs that could be authenticated using bearer tokens. If the system had oAuth or something that requires a token to be generated dynamically, then the integration could not be performed because Zapier's Python VM only has a few libraries (I relied on Python's requests for this).
- For the above: if you had a way to flatten library code in a single Python script, that would have a worked around it I guess.
- All your code must run under 256 Mb or 10 seconds.
- Our Project Managers believed any integration could be done, but actually very few of them could be done because of the public APIs limitations stated above. Our salespeople thought we were on a mission to disappoint them, but most integrations weren't technically possible given these constraints and we weren't permitted to develop custom installable on-premises code for these.
> I know most “normal” developers have a reputation for being hostile to low-code platforms
There's a reason for that, and it's that no-code is absurdly limited. The moment you need to do something outside of the use cases the no-code platform was designed for, it's the moment you'll outgrow it.
The thing is, you'll outgrow no-code faster than you think. Weeks, if not days.
I haven't tried any of the others mentioned, though, so I have zero context.
I would say Bubble is good if you don't know how to code but still want to build something like a basic CRUD app. If you know how to code, my advice would be to still code it yourself. This advice is probably valid for most no-code tools, because you always trade off against something.