Ask HN: What low code platforms are worth using?
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?
94 comments
[ 2.8 ms ] story [ 273 ms ] thread> production ready
> low code
Choose one
(We really are at the point where some solutions offer choose two)
But, add “robust sophisticated data access controls” to that list and its still “choose two”)
Perhaps Airtable for an aaS approach that can be exposed to external visitors as a website, but the concept is sound.
Zappier, airtable, retool(or open source alternatives) seem ok if you need something quick.
Airtable / Retool - Budibase
https://allcancode.com/platform
I haven't tried any of the others mentioned, though, so I have zero context.
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.
https://lowdefy.com
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.
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)
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
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.
I think code is a great thing, just that the "everything looks like a nail" argument goes both ways
Low code is just a GUI on top of some library. I'd rather just write the code and call the library functions directly than mess around with boxes that do nothing other than limit my options.
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.
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.
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.
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.
That being said, it got us up and running quickly at a time where we didn't have much time to spend on that stuff. I think it's a reasonable progression to start out with something like a no code tool and switch to code when you've got the time/people.
It's a fine tool for the business if you want to avoid shadow IT, I suppose, but you have to be aware that sooner or later you will need to integrate it with .NET because of feature creep and by that point you end up maintaning PowersApps, .NET and a lot of duct tape in between.
We had to give it a past in the end due to no i18n or equivalent support.
- I wasn’t around for the decision between outsystems and mendix, but apparently the choice largely came down to the support provided by the Mendix team in getting a fledgling dev team up and running in a company which at the time only outsourced dev work
- following on from that, the Mendix guys were all great to work with. A genuine positive. I heard that the impression of outsystems was much colder
- it’s a really mature product that’s always growing. Backed by Siemens for a few years now.
- like all low code it has its limits but it’s built in Java and there is the option to add Java code where needed for performance or for some other reason. There are APIs for hooking into the platform at multiple levels so it’s extensible.
- in my current job I build in azure/logic apps/function apps. Personally I would either do function apps or full low code like Mendix (costs aside). I try to avoid the middle ground or power automate/power apps/ logic apps - you basically get the worst of all worlds, and are only really intended to link services together or orchestrate amongst services.
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.
Our project did it in about 2-3 years, rewriting hundreds of tests in the process, yay :)
The cost is in requirements and dependencies. The tools and implementation is the cheap part.
Not always true. This is a bit of a myth I myself sometimes fall for. Tools and implementation require a lot of very skilled workers to become cheap, because they must know all the traps that any language or framework implicitly or explicitly adds.
For example, I have been learning SwiftUI lately as it is sold as the new cool shiny stuff, and coming from a backend background it was nice at first, until I started fighting with xcode, "this thing is not possible yet in swiftui, so you must wrap an ns controller", etc. Now that I know these issues I am not anymore the clueless guy but I would still consider myself pretty junior in this field/technology: are you happy to have someone with 0 experience do this kind of work? Then yes, it's cheap in terms of salary and expensive in terms of time/quality of your product. The guy learns and eventually leaves to make more money.
Ps: overall I agree that requirements and dependencies are costly too. I wouldn't underestimate the costs of language/tools/technology though.
The word you’re looking for is “experienced”. You’re echoing all the concerns everyone that’s dealt with it shouts from the roof tops, but you’re saying the same thing they did before getting that experience, “this time is different”. See you on the other side.
The problem is that I don’t control the entire IT org and my group has to deal with issues like presentation logic bubbling up into our APIs from underpowered and overhyped low-code platforms.
I guess the difference between you and me is that I’m open-minded about the possibility that some of these tools might potentially, someday, be better than what we’ve seen until now.
Hoping for: - Better pricing for public apps. - Better ability to easily customize the frontend design without touching CSS/HTML/JS.
We're revamping some things around Public Apps to make them better/more accessible/more easily shareable for unauthenticated use cases, where you don't pay for end users.
For use cases where you are authenticating external users (using Retool Embed or Retool Portals), we offer custom pricing because use cases vary quite a bit. Sometimes the number of users doesn't even make sense as the billable metric.
Happy to chat more to see what'd work for you - feel free to reach out at antony [at] retool [dot] com!