Sort all front-end clients list to remain client framework agnostic

[FossPrime]

Minor, I know. But hear me out.

We are implying that we support or prefer angular over Vue in some way by not having an alphabetical list, or one that's not even sorted by github stars... Vue has 203k + 36k stars, over angular's 87k, which is technically lower than Node.js, but that's not a front-end framework (Unless you count webcontainers).

We can cutout Lit, Svelte and Astro as they did not exist when Feathers was released, and having 4 would violate the literary convention known as "rule of three's".

This PR also adds Angular and Vue where it's missing from a list mentioning other compatible Feathers clients.

[mkadirtan]

Why use / instead of , though?

[FossPrime]

Why use / instead of , though?

These two have similar meaning:

• For Angular/React/Vue clients.
• For Angular, React, Vue or other clients.

The less traditional grammar encourages that the enumeration be more loosely interpreted, than a binding comma separated list. By no means do we discourage TS clients exports use with Svelte, Nuxt, Observers and Vite clients… but we have to draw the line somewhere. And, TS supporting frontend clients is needlessly generic and take too long to process when reading.

The biggest benefit is probably how easy it is to go back and change it. It's more semantic and easier to spot and remember than a plain English comma separated sentence that could easily get misremembered. As long as we're consistent, that's all that matters.

I'm also open to using the Web Component frameworks terminology, bit again, it makes the docs much harder to read. Kind of like renaming JavaScript to ECMAScript, or calling Linux, GNU/Linux, which means GNU plus Linux.

[mkadirtan]

Why use / instead of , though?

These two have similar meaning:

• For Angular/React/Vue clients.
• For Angular, React, Vue or other clients.

The less traditional grammar encourages that the enumeration be more loosely interpreted, than a binding comma separated list. By no means do we discourage TS clients exports use with Svelte, Nuxt, Observers and Vite clients… but we have to draw the line somewhere. And, TS supporting frontend clients is needlessly generic and take too long to process when reading.

The biggest benefit is probably how easy it is to go back and change it. It's more semantic and easier to spot and remember than a plain English comma separated sentence that could easily get misremembered. As long as we're consistent, that's all that matters.

I'm also open to using the Web Component frameworks terminology, bit again, it makes the docs much harder to read. Kind of like renaming JavaScript to ECMAScript, or calling Linux, GNU/Linux, which means GNU plus Linux.

Thanks for the explanation. It makes sense, and I agree with you.