No, you're looking at a Getting Started Page targeted at web developers, hence they use the tools they are familiar with. These tools take care of auth/data format and other glue code so you can get started easily... But because Solid is based on open standards, you could write a desktop app that makes HTTP requests using your language's clients without issues, but you'll have to write some boilerplate code yourself until there's frameworks in your language that handle that for you.
I believe working with Solid is mostly about working with HTTP and RDF... so, if you're into the JVM, try Apache Jena[0].
Working with RDF is computationally intensive. And writing UIs that fit to various ontologies is not solved. So everyone inevitably ends up writing applications to fit a particular ontology.
Excluding theoretical quibbles, what changes? In practice, the particular ontology that your application supports is the standard.
The evaluation of SPARQL patterns is PSPACE-complete.
Which means that for trying to approach the problem of writing UIs (working on a realistic hardware) that adapt to different ontologies you need to restrict the set of possible solutions...
That is, to limit the number and place constraints on the ontologies you accept.
The ActivityPub ecosystem is a glaring example of this.
ActivityPub defines a set of baseline requirements (and a basic ontology) that all implementations need to support.
Once you meet the baseline, you can use linked data tools to extend the standard. Applications that understand your extension will also interact with it in the UI, those that don't understand your extension usually just ignore it.
But you need to specify base requirements (set the baseline for an extensible standard)! You can't just throw totally random ontologies at devs, it won't work. I think this is the error Solid makes.
