Currently, we have one JS file + 1 HTML file (rendered with Jinja2) that does all the frontend work. This includes:

1. Client for the BinderHub API
2. Main page (when people see mybinder.org)
3. Loading page (when people go to a mybinder.org/v2/gh/user/repo launch URL)

(2) and (3) are particularly intertwined - they're restyled versions of the same page (HTML + JS).

In the future, I'd like us to improve on the following aspects:

1. JS Tests (we have none)
2. Export a BinderHub client API library that others can re-implement. Right now, everyone does their own implementation, and particularly run into problems against eventsource retries.
3. Implement both v2 (current) and newer API (whenever API refactor process #358 lands)
4. Split the main & loading pages
5. Make main page a lot more dynamic - ideally showcasing useful / featured repos & other forms of discovery
6. Better (privacy conscious) frontend instrumentation to see how people use the main page & how we can improve it.

Doing a refactor of the current JS in some form or way while it's still smallish (~400 lines) seems like a good idea to me!

Factors

Some factors to consider:

1. How much is it used inside the Jupyter community? We want to make it as easy as possible for other Jupyter contributors to work on this.
2. Does it help bring new people with different skillsets into the project? We should balance this against (1) - we wanna diversify who comes in and contributes to the project, and specific tech might help / hinder that.
3. How much is it used in the frontend dev world? We wanna use an approach that's likely to be well debugged & with a lot of resources out there on how to use it.
4. Is it appropriately scoped for our size? We shouldn't overcomplicate our lives by choosing tools meant for 100k lines projects while ours is much smaller.
5. Does it make working on the frontend a happy & joyful thing for many people in the long run? Often projects end up with convoluted untested frontend code that is hard to touch since it might break.

Options

Here are some options

Option 1: React + TypeScript

We can switch to using TypeScript as a language & use React for frontend components + tests.

Option 2: React + JS

Similar to above, but with just plain JS (JSX) instead of TypeScript.

Option 3: Next.js

Recommended by @betatim: https://nextjs.org/docs

Option 4: No React

We'll refactor and move away from monolithic single JS file, but keep using our current setup of pure DOM manipulation rather than use a library.

There are probably more options than this, but this should be a starting point to discuss!