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?
> production ready
> low code
Choose one
Zappier, airtable, retool(or open source alternatives) seem ok if you need something quick.
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.
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.
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 haven't tried any of the others mentioned, though, so I have zero context.
- 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.
We had to give it a past in the end due to no i18n or equivalent support.
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.
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.
Hoping for: - Better pricing for public apps. - Better ability to easily customize the frontend design without touching CSS/HTML/JS.
The cost is in requirements and dependencies. The tools and implementation is the cheap part.
Our project did it in about 2-3 years, rewriting hundreds of tests in the process, yay :)
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.
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.
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.
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...
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.
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 had already been at it, chunking up useful blocks.
[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.
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
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.
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.
Firstly, I appreciate your open-mindedness towards low-code platforms like Powerapps and your team's positive experiences with it. That's a good start as low-code platforms can indeed offer agility and efficiency.
Regarding your concerns with Outsystems, it's not uncommon to have reservations about new tools. You mentioned feeling a bit skeptical and having to compensate for its shortcomings. It's essential to have a platform that seamlessly integrates with your existing workflows.
At DronaHQ, we aim to provide a low-code solution that aligns with the needs of enterprise-level development teams. One aspect that sets us apart is our customization capabilities. You can enhance your applications further by leveraging JavaScript to fine-tune your exact requirements. This means you have full control over the look, feel, and functionality of your applications.
Additionally, DronaHQ integrates AI capabilities that can dramatically improve your development process. Our platform allows you to harness AI for querying databases right within the platform. This not only makes database interactions faster but also enables more intelligent and efficient data handling.
And we offer a wide range of features and integrations to simplify your development efforts. I encourage you to explore DronaHQ further
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.
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.