The argument seems to take the leap from 'Ring is the wrong abstraction for what I want to do' (fair enough) and concludes 'Ring is inadequate, and therefore Clojure has a viability problem.'
Ring is explicitly designed to be web-server agnostic and therefore intentionally does not expose the full Jetty/Jakarta surface. Many using ring aren't using Jetty!
If your app requirements are specifically EE/Jetty-centric, then bypassing Ring may be entirely reasonable, but I don't see how that becomes an argument against Ring's design, much less against Clojure’s viability for enterprise applications...when enterprise means "serious business" not "Jakarta EE".
There are a few actual issues with Ring's design (that are in the issue tracker) I can think of when it comes to it's ability to express valid HTTP semantics. But "it doesn't OIDC" isn't one of them (that's sort of a category error?)
All that said... The charitable reading of "Clojure has a larger problem for its future [...] in which we can produce enterprise-grade web applications" is one where the "we" is limited to Derek's company/team, which yea, sounds like they need more Jetty/Java EE than Ring provides. But if the "we" is the Clojure community as a whole, then I would dissent.
Comments
(as discussed in clojurian slack):
The argument seems to take the leap from 'Ring is the wrong abstraction for what I want to do' (fair enough) and concludes 'Ring is inadequate, and therefore Clojure has a viability problem.'
Ring is explicitly designed to be web-server agnostic and therefore intentionally does not expose the full Jetty/Jakarta surface. Many using ring aren't using Jetty!
If your app requirements are specifically EE/Jetty-centric, then bypassing Ring may be entirely reasonable, but I don't see how that becomes an argument against Ring's design, much less against Clojure’s viability for enterprise applications...when enterprise means "serious business" not "Jakarta EE".
There are a few actual issues with Ring's design (that are in the issue tracker) I can think of when it comes to it's ability to express valid HTTP semantics. But "it doesn't OIDC" isn't one of them (that's sort of a category error?)
All that said... The charitable reading of "Clojure has a larger problem for its future [...] in which we can produce enterprise-grade web applications" is one where the "we" is limited to Derek's company/team, which yea, sounds like they need more Jetty/Java EE than Ring provides. But if the "we" is the Clojure community as a whole, then I would dissent.