[Serializer] Remove unhelpful exposed "serializer alternative"
Removed mention of JMS serializer as an alternative to Symfony Serializer.
It was pushed at the bottom of page in https://github.com/symfony/symfony-docs/pull/7043
Reintroduced in https://github.com/symfony/symfony-docs/pull/17783 during the big merge of the serializer docs (i guess because new structure had no more a natural good place in the end of the page)
To me, it does not feel necessary, and I'm betting create more confusion in readers mind that really helps anyone..
But my main point will be "why is this not done on other packages doc pages?" ... if we need to promote alternative, I can think of a few other Symfony packages where that kind of mention could be legit...
Well just a minor thing passing by :)
So I suggest we simply remove this mention.
I actually intentionally placed the note at the top when rewriting the serializer documentation. See https://github.com/symfony/symfony-docs/pull/17783#discussion_r1811406869 for a bit of the reasoning. I think this still holds true.
Can you elaborate a bit on what confusion you think this will cause readers? Maybe we can reword it slightly?
@wouterj I indeed missed that discussion, thanks for the link! 😃
I am still not entirely convinced, and will share my reasoning.
But this is all but an important topic, so I will not mind if you skip it :)
If someone is reading the Serializer page on symfony.com there are two cases: either symfony/serializer is already in their composer.json or it is not :)
If it is already installed, readers usually come for usage docs (and in Google the link is titled How to Use the Serializer). They will probably ignore the block but, if not, the "popular" wording feels unusual for Symfony docs, which makes it stand out and can then confuse.
If not, the reader's goal is probably either to discover the component or to install it because a CTO or tool requires it. In both situations, pointing to another library at the end of the install steps adds little context and mostly risks creating doubts or mistakes.
Finally, one could ask why this library (other serializers may be more "popular" today) and why only this one (components like HttpClient, Filesystem, or Uid do not suggest alternatives in their docs).
Well... just me overthinking details again 😇