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.
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.
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.
https://lowdefy.com
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.
In my experience Anvil is the fastest way to develop a web apps. It is a framework that lets you do everything including Frontend, Backend and Database using just Python. I started using it when I was a total newbiew to programming and I am still using it.
You can check it out at https://anvil.works
It has a drag and drop designer so you can just drag a component, attach a python function to it and you are done! Even communicating with backend is as simple as calling a python function and passing data as parameters to it.
If you want, you can also implement HTML, CSS or Javascript in it. In fact, Anvil allows you to "steal" javascript apis for browser and implement them in python. You can integrate any javascript library like that.
This means you won't ever have to worry about being stuck.
Zappier, airtable, retool(or open source alternatives) seem ok if you need something quick.
Airtable / Retool - Budibase
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!
If you are clever enough, your current ecosystem can be bent into a "low" code arrangement.
We pushed most of our logic into SQL queries over time. Domain experts write "code" these days. This was only possible after years of refining our schema relative to our customers and problems. Learning what should be configurable and what should not. To do this effectively usually requires that you already wrote a lot of code.
SQL databases are a superpower. I feel like they are your ultimate low code platform. Especially SQLite, which can run literally anywhere. In this arrangement, the query planner and virtual machine are your programming staff. The quality of this low code ecosystem is entirely defined by the imagination of the person responsible for designing the schema.
If you find yourself having a really hard time writing a query that seems somewhat ordinary for your problem domain, it might be an indication of a skill issue with your DBAs or schema author. This is where low code typically goes off the rails. Your in-house employees are also now customers and you have to accommodate their requirements in addition to the ones that these abstractions are ultimately trying to address for your outside customers.
Also how “SQL databases are a superpower”?
I suppose one still needs a non trivial dev infrastructure and dev skills to make the SQL a superpower:-|
Exactly.
My intended takeaway from this is that there is no free lunch unless your business is super simple.
We've taken this approach because we believe that building in a GUI only, is just not productive and restricts developers. Also, many low-code frameworks do not have first class support for Git work flow, and code review becomes worthless or impossible.
Lowdefy makes code review easy, so you can write low-code web apps like you write code, but with the abstraction benefits of a low-code framework.
We've been using Lowdefy for the past 4 years to build enterprise applications for customers, anything from large multi-company CRMs to call centre solutions, various ticketing and customer support portals, even an MRP in the food production space, and so many dashboard reports. What I like most about working with Lowdefy, is that it abstracts the business logic from the tech and makes maintaining a large number of apps easy.
Check out our website and repo, and let me know if you'd like a demo of what can be built with Lowdefy.
https://lowdefy.com
https://github.com/lowdefy/lowdefy
https://allcancode.com/platform
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.
- 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.
They also have nice repository integration and subdomain support now
Pricing is also super reasonable for anything other than eg high high volume analytics use cases.
If the environment is under tighter control, say, an internal intranet app, or tye LC runtime provides high quality widgets and plumbing that handle scale, protections, etc, then LC can be awesome.
The nearest analogy I can think of is using Squarespace vs rolling a website. Squarespace is great, and has all kinds of widgets, and is fab, until it suddenyl isnt and you need to add custom code, whereupon it all grinds to a halt. Rolling by hand is insane, slow, crazy, until you realize that its the only way to get what you want on your terms. Horses for courses.
> 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”)
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.
Our project did it in about 2-3 years, rewriting hundreds of tests in the process, yay :)
Why[1] is that? Whelp, what the nocode tools do - in my completely non-credible opinion - a real good job of is exposing the base abstractions used by developers. But - and whew, am I gonna piss off some people here - good base abstractions need domain knowledge. So when you combine "no industry knowledge" with "no coding knowledge" into a Superteam making Enterprise Software, you got a magic formula for making tools with negative value.
Since I come from the interface between technical representation and domain knowledge, I think something that really speaks to this is the utter insistence on having documents that automatically populate from BIS (business information systems). XML was the NoCode of this application, and it never worked. The reason it never worked, is because neither the domain knowledge (CAD or PDM or LSA or WI, consumables/fasteners location, flight ops mission plan AND emergency engine procedures[2] AND most of preflight, et cetera et cetera) OR the schema ("BREX allows you to do whatever you want with the schema! Go nuts!") have enough information to formulate natural language descriptions, procedures, checklists, and the like. Either the Powers-That-Be thought the domain stuff would sort itself out[3], OR they're making the assumption that documents don't need natural language. Either is super duper dumb, but the basic notion is so seductive that we keep on chasing it, for decades and decades. I see a shadow of this in the general nocode platforms. Maybe, possibly, AI has the answer here in the form of "instant domain knowledge", but boy, would I never use that for anything safety critical without SOMEONE who knows what they're doing. Overfitting is a thing.
[0] I've seen Zapier do crazy cool things, but teams with domain knowhow (and programming knowledge) had already been at it, chunking up useful blocks for the "users" making actual apps.
[1] In my experience, is the probably-unnecessary adder.
[2] "What do you mean, 'our engine doesn't catch on fire'?"
[3] Which, right there, would be a good software application. "Will the FAA let me fly with the business system informations I have?". Instead of hashing it out in your pilot checklists three weeks before cert, because natural language is the crappiest place for that analysis.
It's primarily headless CMS but you can push it beyond that into any CRUD app.
You get:
- PostgreSQL db with quite sensible schema, indexes, keys etc
- You build your models and relations in UI but they get checked out as yaml files into git
- Admin UI
- standard REST and GraphQL endpoints out of the box
- OAuth connectors
- Easy overrides / customization with typescript through multiple layers (controllers, services, orm)
- Fully opensource
- Easy deployment
- Community plugins
If you want to eject, you have good db layout so you can move functionality to another system if you outgrow it. No vendor lockin.
So you can build within existing apps and use your own arbitrarily complex React components. This is what makes it suitable for complex production projects, because (as many others note) you'll invariably hit ceilings with typical low-code tools.
It focuses on both websites and applications, so it can be wielded as either a Webflow or Retool alternative.
My company built an amazing No-Code platform www.onedb.online that can build business apps such as ERP & CRM at least 15 times faster than traditional code and at least 99% of what you need without code and you can easily plug-in code components (SQL, Javascript, CSS) when required.
Also FYI I gave up waiting for this to load at 30 seconds. - 4s: first spinner - 15s: second spinner - 30s: some kind of top bar - 35s: nothing seemed to be happening. Tried in Chrome, Chrome Incog, Edge
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.
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.
It uses the concept of Flow-based programming. Also its so underacknolged but this tool is very flexible. I have used as an Event Bus all the 3rd-Party Integrations.
We had to give it a past in the end due to no i18n or equivalent support.
The sweet spot would be: - Easily build primitives using code - Compose those primitives using no-code
The reality is that you shouldn't be turned away from these tools simply because of the negative developer perspective they tend to have, but you should consider the practicality of your situation. What matters is that you are aware that these platforms have limitations, and that you solve the inherent business problem you are seeking to solve immediately. Additionally, always have a plan to eventually migrate out if the platform if the situation warrants it.
What I find paradoxical is that we SW engineers tend to neg on low-code tools, yet proclaim that code is simply a means to a business problem. We enjoy coding new projects, and hate integrating or migrating off shityly built applications.
The practical reality is that whether it's code you wrote or a no-code platform, getting your tool to work in the 99th percentile is always going to be the hardest part of the problem. In this case, using a no-code platform whose inner workings are obscured away from your is just as challenging as working with an arcane internal application whose original developers left the company a long time ago.
Disclaimer - I'm building Leaptable - a Low-code database powered by AI Agents. It's still not ready for prime-time and would love your feedback. https://github.com/peterwnjenga/leaptable
Both of these points are in the site guidelines (https://news.ycombinator.com/newsguidelines.html), so if you'd please review them and stick to the rules when posting here, we'd appreciate it.