Dumb 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, "We can no longer lock in customers on proprietary platforms". In which case, too bad!

Agreed. Libraries and frameworks definitely adhere to a 'low-code' philosophy.

Your last idea makes sense as well to some extent. I think for sure, once you abstract away from the technical implementation details and use platforms which allow you to focus only on business logic, it becomes easier to move between different platforms which support similar underlying functionality. That said, some functionality may be challenging for different providers to replicate correctly... But some of the core constructs like authentication mechanisms, access controls, etc... Might be mostly interchangeable; we may end up with a few competing architectural patterns and different platforms will fit under one of the architectural patterns; which will be optimized for slightly different use cases.

> 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.

React, Next, Laravel, Rails.. In fact, all higher-level programming languages from C on up are low-code solutions.