The Future of gon
<!--IssueSummary start-->
<details>
<summary>
Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards.
</summary>
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=22657)
</details>
<!--IssueSummary end-->
An issue to discuss what do we actually want to do with `gon`. I often see it mentioned (in MRs or Slack) that we are getting rid of gon (or reducing usage). But couldn't find an issue.
All our current serialization methods are arguably worse than gon (see https://gitlab.com/gitlab-org/gitlab-ce/issues/37441 for discussion on that)
- Harder to use
- Require elaborate stringify/parse hoop-jumping (or convertPermissionToBoolean!)
We should _definitely_ use API for the majority of data fetching. But we still need initial data.
- for initial render we need to send some data. `endpointUrl` is a common example
- Some data is legitimately global, so doesn't make sense to send a URL and fetch that all the time (e.g. `currentUser`, `apiVersion`)
issue