Ask HN: What low code platforms are worth using?
94 comments
No code has its role, there are many simple things it can make easier. For most non trivial systems, no code will get you 80%-90% to a solution and the last 20% of your solution will be extremely difficult, complex, or impossible to deliver in any maintainable way.
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.
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.
Having worked with several low-code/no-code systems in the past, I've had similar experiences. They work really well if you stay within their area of strength, but once you go outside of what it was designed for, it becomes an ugly, unmaintainable mess.
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.
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.
Not at all a sales person, but...
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
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
Any no/low code problem trivial enough to be hacked together by a non-programmer can be completely replaced with code in extremely short order by someone who knows what they're doing. The nightmare scenario, where that principle breaks down, happens when you hire people specifically to work on your low/no-code codebase.
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.
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.
Yeah code is not a bad thing. It constrains us and make the hard things about designing and building non trivial systems up front.
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.
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.
> Yeah code is not a bad thing
I think code is a great thing, just that the "everything looks like a nail" argument goes both ways
I think code is a great thing, just that the "everything looks like a nail" argument goes both ways
This whole hammer metaphor gets too stretched in the context of software. Code is not a single thing, it's a whole approach to programming computers. It's hard won territory, seeing people had to use machine code and op code tables to program for a good chunk of history. And the allergy some people feel about it is unjustified in my opinion. The strengths of coding tooling are well worth the investment and trying to avoid code as if it ware a deterrent to "getting things done" is failing to understand what is hard about programming. Not learning how to code (and properly, with version control, code reviews etc which are surprisingly shunned by some professional programmers). The hard things about programming non trivial computer systems are made easier by the scaffolding of programming languages. Not harder.
Low code is great if you don't know programming. For more complex systems you want developers who understand the system deeper than "box connects to other box makes things go brr", and if you have developers who know what they're doing they'll make a better system faster with actual code.
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.
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 "no-code sales person," I actually agree. It's why we started on https://plasmic.app, to bridge the gap between low-code and code—we think there can exist low-code tools that integrate deeply with existing code and codebases, to allow scaling in complexity.
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.
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.
> 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.
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.
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.
I am sincerely wondering if this must be the case or is it a shortcoming of the existent solutions, but something that can be overcome. (Disclaimer: I am a programmer who never seriously used any low code product apart from a spreadsheet. Unless you count Emacs as a low code platform, which would not be wrong, I guess.)
I think it's intrinsic to the problem. That 20% long tail of the customer's problem is not just different for every company, it takes a decent programmer to recognize where that border line is.
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.
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.
Emacs were pretty productive but sometimes overcomplicated imo. Remember TRAMP mode?
in my experience this makes sense. really true, hands down.
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.
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 anything complex, for example a SaaS platform, your best bet is to build from scratch with code. The flexibility, ownership and technical viability are essential in these scenarios.
For simple CRUD apps, internal tools, reports, spreadsheet replacement - low-code platforms - particularly OSS options (Budibase, Appsmith, and others)
For simple CRUD apps, internal tools, reports, spreadsheet replacement - low-code platforms - particularly OSS options (Budibase, Appsmith, and others)
I spent around a decade in enterprise digitalisation, and now work with organisations transitioning from startup to enterprise along on their journey, and I’ve never seen a good low-code platform. PowerApps are fine though, it’s certainly a lot better than what came before it, but you’re very likely going to end up with terrible flows that lack documentation, testability, maintainability and are far too dependent on certain employees who will easily find better pastures as their low-code platform skills grow.
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.
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.
Low/no code have long learning curve because they provide too many configurable tools and have big limitations because they don't provide enough configurable tools.
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...
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 at risk of sounding facetious, but Excel.
I don't need a spreadsheet that much, but I've been finding MS Office 365 version of Excel to be obnoxious to use. They've changed a lot since I used it 5 or 10 years ago. I don't need it enough to learn it, so I've just been using Google Sheets as needed.
In the browser the google office suite absolutely beats microsoft’s, even after years of benign neglect by google. Comparing the desktop microsoft apps vs the google web apps I would say the microsoft stuff is more fully featured, but slow and more confusing to use.
Honestly? you might be right.
Perhaps Airtable for an aaS approach that can be exposed to external visitors as a website, but the concept is sound.
Perhaps Airtable for an aaS approach that can be exposed to external visitors as a website, but the concept is sound.
I think Airtable would make a reasonable admin backend for a custom site/application, as the admin backend is usually the bit of the system that gets the least UX love, and it's close enough to a spreadsheet that it shouldn't be too hard for people to pick up.
How do you feel about Airtable's recent pricing changes?
This, but I also have a wishlist of features I wish Excel had in order to achieve parity with Airtable/Notion – arbitrarily-sized lists of data in a cell, for one (as opposed to arrays splatted throughout multipel cells.)
No, you're actually right.
These low code platforms are like blueprints in game dev engines. They are cool for the first 2-3 iterations and a nightmare after.
One huge problem is that with code the usual way of ensuring maintainability is to revisit old code and rewrite parts of it as needed, in order to be able to maintain it properly.
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.
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.
And with none of the intelligent tooling which IDEs and version control software have developed to make that process easier / less error prone.
Git commits of node coordinates and minified JavaScript is not my idea of a good time.
Git commits of node coordinates and minified JavaScript is not my idea of a good time.
I agree. Check out what we’ve done with Lowdefy. Web app config that is Git friendly.
https://lowdefy.com
https://lowdefy.com
I used to work for a small software consultancy firm, and we used to configure some integrations between systems with public APIs using Zapier.
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.
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'm a long way off from being a professional programmer, but part of my current job is to develop and maintain low code solutions. The company I work for is all in on MS (sharepoint, O365, Azure, etc) so powerapps is a no- brainer for us. I've had to make do with a couple of ugly workarounds, but for the most part the whole "power" platform makes things pretty seamless and easy.
I haven't tried any of the others mentioned, though, so I have zero context.
I haven't tried any of the others mentioned, though, so I have zero context.
This matches my experience as well - in an enterprise environment when you already code .NET and people already use Powerapps, etc... why go looking for a new platform to integrate? Just keep using the platform you are already invested into.
I'm a developer, but had some experience with Bubble because my former client was using it. I would say that it's good "full-stack" web dev platform that allows you to get further than you would think with a low-code tool. But in the end, you trade-off speed in the first few weeks against complexity and bad maintainability later down the road.
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.
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.
The problem with low-code platform is that you are always restricted and can't go beyond what they offer. And someday, you will run across a problem that you can never solve with that platform. But there is a better way to do it.
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.
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.
I've used https://val.town as plumbing between webhooks where I needed to restructure a JSON payload, but only wanted to write the business logic. It's great for Zapier/IFTTT-like tasks but where you still want to write code for the business logic, you just don't want to scaffold up the rest of the pieces.
For prototype/internal use or customer facing products?
Zappier, airtable, retool(or open source alternatives) seem ok if you need something quick.
Zappier, airtable, retool(or open source alternatives) seem ok if you need something quick.
Retool for sure, they are pumping out features really quickly too. The model makes a lot of sense from a developer's point of view. Now that they are also going into public apps I would really consider them seriously.
Hoping for: - Better pricing for public apps. - Better ability to easily customize the frontend design without touching CSS/HTML/JS.
Hoping for: - Better pricing for public apps. - Better ability to easily customize the frontend design without touching CSS/HTML/JS.
<3 Love to hear it! (PM at Retool)
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!
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!
> My group writes .NET code
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.
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.
Would you mind elaborating on “pushing logic into SQL queries”?
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:-|
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:-|
I'm not them but I'll translate for you. They had a shitty app that did dumb stuff that SQL can do for them. Someone finally figured out how SQL works and wrote some proper queries and now they think they're geniuses.
> 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.
Exactly.
My intended takeaway from this is that there is no free lunch unless your business is super simple.
We've developed a low-code solution for building web apps: Lowdefy - A config web stack for business apps.
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
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
There is a hybrid alternative that combines no-code with low-code and pro-code. It is a platform that generates code for React, React Native, and Next.js. And it is free to use :-)
https://allcancode.com/platform
https://allcancode.com/platform
GitHub Copilot obviates the need for these platforms, in my humble opinion. You don't need "low-code", you want "low-effort coding". You want something quick and dirty that does 80% of the work.
We used Webflow for our company's landing page for a while but for our uses it was more "slow code" than "no code". To get the layouts we wanted you still had to understand the quirks and intricacies of flex/grid so it was just a clunkier interface than writing code.
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.
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.
.net dev here. I started my career using Mendix. It’s very much aimed at enterprise (see pricing) and in direct competition with Outsystems. I haven’t used it for about two years now so might be out of date. Some unordered thoughts:
- 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 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.
Pipedream is very good for a sort of medium-code Zapier like. Great for point and click hooking up web services but also being able to eject out into JS/Python/Docker with all the authentication done, debug/replay steps and production traffic errors, and generally nice magic support for npm dependency inclusion.
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.
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.
The problem isnt the means of production, its the robustness of the outcome in the real world (aka hostile environment). If your LC environment includes components and runtimes that will survive, then you might be ok. For example, ita one thing to have an LC app that takes in, say, an mailing address, but quite another to expect that widget to handle users typing in addresses half baked, or across multiple countries, or while wearing gloves, or if you have not 100 users but 100,000, or any other of the bazillion things that happen in the real world.
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.
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.
> non trivial
> production ready
> low code
Choose one
> production ready
> low code
Choose one
> I know most “normal” developers have a reputation for being hostile to low-code platforms
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 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.
I have around 20 years of experience doing work with third generation languages. So I’d classify myself as both “normal” and “experienced”. The closest thing my group does with “low code” is the odd Azure Logic app for alerting, and we don’t have any plans to change that. I’ve been around long enough to see things like Lighswitch die on the vine.
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.
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.
Easy question - use platforms from which you will be able to migrate in the future with the least amount of money and time wasted. Pick one where time to ditch the low code infra would be less than two years and using not more than half of your dev team staff.
Our project did it in about 2-3 years, rewriting hundreds of tests in the process, yay :)
Our project did it in about 2-3 years, rewriting hundreds of tests in the process, yay :)
Anything specialized for your industry, then a nocode platform can work real well. General purpose nocode, without either domain knowledge or software knowledge? Hnnnnnhg[0].
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.
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.
I am surprised I don't see Strapi mentioned here.
https://docs.strapi.io/
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.
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.
Agreed. When building projects or POC I always default to Strapi and Remix. Because it allows me to build things fast.
https://plasmic.app is a soon-open-source visual builder that (uniquely) integrates with codebases. (I work on this!)
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.
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.
[deleted]
I disagree - Would you build a AAA Game without using a Games Engine or a Financial Forecast in code instead of Excel? that would be crazy.
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.
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.
Personally I would avoid the 'amazing' rhetoric and let the customers decide that. (Not having a go, just suspect that it's detrimental).
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
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
I was about to reply same before solving 99% of world problem. Please look into why your site is taking this much time to load...
There more I work the less I care about no-code or development languages.
The cost is in requirements and dependencies. The tools and implementation is the cheap part.
The cost is in requirements and dependencies. The tools and implementation is the cheap part.
> 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.
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.
I think that assuming that technology is secondary is a trap that skilled developers encounter when moving into management-they assume that development is as easy for others as it is for them. When I moved into technical management, I was fortunate enough to work with high performing teams for a while, so when I encountered a poor performing team (the team lead didn’t know basic good practices, and bug counts rocketed up because of an inexperienced dev team) it was a nasty shock.
We tested PowerApps at work. It looks fine at a first glance but comes off as really rough around the edges.
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'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.
Apache NIFI (https://nifi.apache.org/).
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.
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.
With Outsystems, I heard from anecdotal experience that developers end up pushing business logic into SQL queries.
i’ve worked with retool at my past 2 startups and it has been very useful as far as allowing engineers to build out quick internal tools so that things like service requests that occur quite often can be handled manually by the customer service teams.
Yeah. For complex CMS driven websites I’d always choose Webflow. But to have it all nice and combined in one tool handling non-trivial complex software projects I really don’t know of a single platform out there for that…
Having done some research on this for internal use in the past I would recommend AppSmith as the best of the bunch given it's mostly open source.
We had to give it a past in the end due to no i18n or equivalent support.
We had to give it a past in the end due to no i18n or equivalent support.
I would not take any recommendations here, as the tool to use "depends". I would try a bunch of the tools and stick with the one that you like the best, but you need to invest the time yourself!
Don't have a strong opinion about the platform but I have heard decent things about Mendix..
Surprised no one has said Framer yet
I love their ai generated components and full landing pages great for prototype or proof of concept or validation .
(founder here) Webiny is an option I would recommend checking out. It's open-source, so unlike Webflow, you can actually creation your own low-code components. Webiny has a Page Builder, Form Builder, File Manager and a Headless CMS. All products can be configured and use as a low-code solutions.
SQL as the database, Budibase for app building!
Xano.com is great for this. Go check it out.
Also, why is this thread been removed from the home / front HN page?
IIRC the HN algorithm downranks stories where number of comments exceeds the number of upvotes. As of me writing this, there are 50 comments and 35 upvotes.
Interesting. All in like 1h. Also might be less relevant for AskHN, since the idea is to comment / discuss the topic. Surprised that there is not a more effective solution to this.
Aaikansh22(1)
Here's the short answer
- Retool
- Anvil
- Bubble
- Airtable
- Webflow
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
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
Please don't use multiple accounts to upvote things (that's very much against HN's rules and will get you banned here), and please don't use HN primarily for promotion (it will eventually get your thing added to a spam filter).
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.
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.
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?