Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 3 commits into
base: dove
Choose a base branch
from

Conversation

FossPrime
Copy link
Member

@FossPrime FossPrime commented Mar 25, 2023

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.

I would love to mention Vanilla TS, Vite, Node.js, Deno and Bun... but that would be repetitive and overly wordy. 

eg: https://vite.new/vanilla-ts
@FossPrime FossPrime changed the title Sort front end clients list by popularity Sort front end clients list by popularity or alphabetically Mar 25, 2023
@FossPrime FossPrime changed the title Sort front end clients list by popularity or alphabetically Sort front end clients list to remain client framework agnostic Mar 25, 2023
@FossPrime FossPrime changed the title Sort front end clients list to remain client framework agnostic Sort all front-end clients list to remain client framework agnostic Mar 25, 2023
@FossPrime FossPrime marked this pull request as ready for review March 25, 2023 21:30
@mkadirtan
Copy link
Contributor

Why use / instead of , though?

@FossPrime
Copy link
Member Author

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants