Sorry if this isn’t the place to discuss this. I created this issue for visibility of a comment I made in a pull request to add a ORJSONResponse class (similar to the UJSONResponse class). I'm gonna quote it here:

[...] I don't think flavour of the month JSON libraries belong in Starlette core, this applies to UJSONResponse as well. Next up someone wants a SIMDJSONResponse class[1]. Where should the line be drawn?

Another aspect to consider is the maintenance burden of implementing custom response classes like this in core, because that means a contract has been signed. So if orjson becomes unmaintained tomorrow, Starlette would have to go through a deprecation cycle to remove it. Or keep it forever... Bugs in the renderer(s) would likely end up as a Starlette issue as well, instead of in the upstream JSON library.

But enough complaining and on to more constructive feedback. It's evident by this pull request that it's pretty trivial to implement your own custom JSONResponse class, so maybe just a section in the documentation describing how to do it is enough? Then someone can (and probably will) publish a package to PyPI that Starlette later can link to, e.g. starlette-orjson. Maybe even a starlette-contrib repo under the encode org? 🤷‍♂️

Another option is to make the default JSONResponse more pluggable/configurable, similar to how you can configure renderers in Django REST Framework[2]. Personally, I like this approach.

[...]

[1] https://github.com/TkTech/pysimdjson
[2] https://www.django-rest-framework.org/api-guide/settings/#default_parser_classes