You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of #4109, we're going to be using the BinderHub UI for ephemeral hubs.
The UI is currently janky, hard to modify and a bit unloved. When I first wrote it in like, 2017, the first line of frontend code written said:
/* If this file gets over 200 lines of code long (not counting docs / comments), start using a framework
That line is still there, while the line count is of course far over 200.
This has serious consequences for users.
The frontend is hard to work on for most modern frontend devs, making any features that touch the frontend hard to implement. The frontend is also hard to work on for the people who already know how the frontend works as well, so it's not necessarily a 'trade-off' here.
There's a lot of 'refresh the page, maybe the error will go away?' style text in the UI, because good error handling (and reconnects) aren't present. And they aren't present because the frontend is hard to touch.
It should share code with jupyterhub-fancy-profiles to the extent possible. It already does for the binderhub API client, but should for other aspects too.
Any UX improvements we may want to make are basically currently impossible.
Proposal
There's good apetite for a frontend rewrite (based on jupyterhub/binderhub#774), and is what I'd have done in 2019 if not for circumstances unrelated to Jupyter / code that prevented me from doing so. Now, I propose we just go forward with this, and complete the rewrite into something modern.
This has to be done with a good eye on not tying up too many of 2i2c's engineering resources, which should be primarily focused on the infrastructural issues outlined as various components of #4109. To that end, I've gotten some review capacity from @batpad (as well as enthusiasm from other, non-2i2c BinderHub maintainers) to help shepherd this through.
This is a bit of a slow burn, consistent work thing that will probably take a month or so to complete, and should not block any other binderhub work
Updates and actions
No response
The content you are editing has changed. Please copy your edits and refresh the page.
Context
As part of #4109, we're going to be using the BinderHub UI for ephemeral hubs.
The UI is currently janky, hard to modify and a bit unloved. When I first wrote it in like, 2017, the first line of frontend code written said:
That line is still there, while the line count is of course far over 200.
This has serious consequences for users.
Proposal
There's good apetite for a frontend rewrite (based on jupyterhub/binderhub#774), and is what I'd have done in 2019 if not for circumstances unrelated to Jupyter / code that prevented me from doing so. Now, I propose we just go forward with this, and complete the rewrite into something modern.
This has to be done with a good eye on not tying up too many of 2i2c's engineering resources, which should be primarily focused on the infrastructural issues outlined as various components of #4109. To that end, I've gotten some review capacity from @batpad (as well as enthusiasm from other, non-2i2c BinderHub maintainers) to help shepherd this through.
This is a bit of a slow burn, consistent work thing that will probably take a month or so to complete, and should not block any other binderhub work
Updates and actions
No response
Tasks
The text was updated successfully, but these errors were encountered: