I've been thinking through a blog post on this exact topic for APIs. The main challenge has been teasing out what is required for framework-less from the rest of the design principles we used. Here is a rough overview. Feel free to comment or ask more questions.
For us, I think the primary factor to become framework-less has been the pragmatic use of functional programming. No more inheritance, interfaces, overrides, attributes, etc. Just types and functions on those types, and everything is easy to compose together. Here is a humorous video on these "functional design patterns". Functional programming informs the other things I mention below.
I had to write a few small libraries myself where the alternatives already in the ecosystem were frameworky. For example, HTTP request filtering/routing (7 source files), SQL (7 source files), and validation (4 source files). The theme of these libraries are: instead of having to inherit and override preset methods, provide common functions that users can chain together. And allow the user to add their own functions for cases not covered.
I believe another important factor is the pervasive use of messaging. Primarily that our business logic only returns decision events rather than actually performing the IO themselves. Subsequent steps in processing the request can simply map the decision events to whatever IO is appropriate (SQL statements, email, etc), even ones we think of later. Whereas a framework usually does not make it easy to plug in new IO integrations. And IO in business logic just makes that logic hard to test and compose with other code.
This one is a bit easier, because there already exist some "platforms" that tie most everything together into a unified solution. Elm is the most obvious example. The most "frameworky" bit of it is the JS interop using ports. Otherwise, Elm prescribes an application structure (Model/Msg types and View/Update functions - aka MVU) and that's it. Most everything you do after that is your own code to solve your own problem. It uses a virtual DOM library to render HTML, similar to React's. It also provides some other libraries like HTTP, Regex, etc. Even if you ultimately choose another MVU platform, Elm is a great teaching tool. We're using it in production currently, but evaluating other options.
Note that MVU is designed to handle different circumstances from a back-end API. MVU is designed to collect user inputs that may be haphazard or never come at all. Whereas request/response APIs usually expect to execute a use case in a consistent and sequential way. So using MVU for APIs is paying overhead for flexibility that will not be used. However, MVU is a lovely pattern for Process Managers.
I think my mouth was open the entire time I read that just now ...
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.