how much of it is because the VC funding dried up and went to LLMs instead
RIP Low-Code 2014-2025
41–50 of 160 posts
Re: RIP Low-Code 2014-2025
#42Dumb question: whats the difference between "low-code" and "libraries+frameworks"? Usually the point of a library or framework is to reduce the amount of code you need to write. Giving you more functionality at the cost of some flexibility. Even in the world of LLMs, this has value. When it adopts a framework or library, the agent can produce the same functionality with fewer output tokens. But maybe the author means…
> Dumb question: whats the difference between "low-code" and "libraries+frameworks"?
There's not much technical difference.
The way those names are used, "low-code" is focused on inexperienced developers and prefers features like graphical code generators and ignoring errors. On the other hand, "frameworks" are focused on technical users and prefer features like api documentation and strict languages.
But again, there's nothing on the definition of those names that requires that focus. They are technically the same thing.
Re: RIP Low-Code 2014-2025
#43>the cost of shipping code now approaches zero. Is this a commonly held assumption?
The people saying that never specify what code is being deployed.
I can get assembly from /dev/urandom for cents on the TB.
Re: RIP Low-Code 2014-2025
#44"While it’s possible low-code platforms will survive by providing non-technical users with the kind of magical experience that’s already possible for developers with AI coding tools today" - that magical experience is available to non-technical users today already. The last barrier is deployment / security / networking / maintenance, but I'm assuming here are a lot of startups working on that.
In a way, low-code has been the worst of both worlds: complex, locked-in, not scalable, expensive, with small ecosystems of support for self-learning.
(Context: worked at appsheet which got acquired by Google in 2020)
Re: RIP Low-Code 2014-2025
#45I was going through my low-code bookmarks and I found this jewel from November 2021 (1 year BC-GPT = Before ChatGPT):
Low-Code and the Democratization of Programming: Rethinking Where Programming Is Headed
https://www.oreilly.com/radar/low-code-and-the-democratizati...
Re: RIP Low-Code 2014-2025
#46I think this view is really short-sighted. Low-code tools date back to the '80s, and the more likely outcome here is that low-code and agentic tools simply merge. There's a lot of value in having direct manipulation and visual introspection of UIs, data, and logic. Those things allow less technical people to understand what the agents are creating, and ask for help with more specific areas. The difficulty in the past…
This makes the most sense to me too. My feeling is so-called AI is going to deliver on a lot of the things we're used to having shoddy versions of -- good natural language interfaces, good WYSIWYG type tools, all of this could turn the wix/squarespace/wordpress/etc landscape into something pretty good, rather than just OK.
In my most hopeful of futures, we've figured out how to do lightweight inference, and if the models don't run locally at least they aren't harming the planet, and all this AI tooling hydrates all the automation projects of the last 40 years so that my favorite tiny local music label can have a super custom online shop that works exactly the way they need without having to sacrifice significant income to do it.
Re: RIP Low-Code 2014-2025
#47I think this view is really short-sighted. Low-code tools date back to the '80s, and the more likely outcome here is that low-code and agentic tools simply merge. There's a lot of value in having direct manipulation and visual introspection of UIs, data, and logic. Those things allow less technical people to understand what the agents are creating, and ask for help with more specific areas. The difficulty in the past…
Mendix is nothing more than MS Access for the Web.
Ok funny anecdote: I once did a special assignment for the CEO of Mendix to build a convertor for MS Access apps to Mendix. So, yes, I can confirm that this is roughly true ;)
I wrote a short post about it on my blog: https://blog.waleson.com/2022/10/access2mendix.html
Re: RIP Low-Code 2014-2025
#48> "For us, abandoning low-code to reclaim ownership of our internal tooling was a simple build vs buy decision with meaningful cost savings and velocity gains. It also feels like a massive upgrade in developer experience and end-user quality of life. It’s been about 6 months since we made this switch, and so far we haven’t looked back."
Fascinating but not surprising given some of the AI-for-software development changes of late.
Re: RIP Low-Code 2014-2025
#49SAP the lowest on both axis... had to crack up at that
Re: RIP Low-Code 2014-2025
#50Interesting article -- my take on low-code has always been less about how much initial development time the application takes to code, and more about how it can ease the long term maintenance of an application. With AI tooling it is going to be easy for companies to spin up hundreds of internal applications, but how are they accounting for the maintenance and support of those applications? Think about the low-code pl…
Auth is a pretty classic case where it’s not hard to make your own account create/login form but it’s really hard to make a good one that does all the “right things”.
Authentication and authorization are important requirements for internal tools. Low-code platforms support authn/authz for app access. Building internal tools with code is much easier now with GenAI, but ensuring proper RBAC access controls remains a challenge.
I have been building https://github.com/openrundev/openrun to try and solve internal tooling deployment challenges. OpenRun provides a declarative deployment platform which supports RBAC access controls and auditing. OpenRun integrates with OIDC and SAML, giving your code based apps authn/authz features like low-code platforms.