Why does it have to be, that Python-Classic-Notebook and Jupyter-Lab on Project Jupyter | Try Jupyter takes ages to respond?
Sometimes, like during the last hours and now, neither Classic nor Lab is working. So the best a (new) user can get is a webpage, which takes ages to get ready.
Why?
Hi! Could you tell us how long âagesâ is? E.g. 30s, a minute, several minutes, etc?
Hi. At the moment, I canât measure the time, because neither âClassicâ nor âLabâ is working:
At other occasions, it was âbetween 20 s and 90 sâ⌠approximately. For comparison: Opening a Jupyter-Notebook (I hope, I am using the correct technical term) on Colab needs approximately 5 secondsâŚ
I am using an internet connection download-speeds > 20 Mbit/s, so this is not the problem. And I am surprised, that you ask. Because I think, this performance problem is a persistent problem, isnât it?
For what itâs worth, I just tried, and opened a Jupyter with R notebook in ~14 seconds.
That one screenshot tells you the problem is in that case: too many concurrent users of the backing repo. Granted the solution isnât obvious from the error menu. That page screenshot tells you that it is the MyBinder.org service is providing the resources. If I recall correct most default sites are limited to 100 concurrent users on the system. That general default can be specifically overridden for short times, such as giving demonstrations at JupyterCon sessions, etc., by contact ahead of time MyBinder folks are contacted. I suspect the âTry Jupyterâ demos have much higher limit settings, nonetheless they must have been exceeded at that time.
If you donât specifically care what environment you start out with, you can go to here and launch any MyBinder-backed example. Hopefully, youâll find one that isnât currently used by too many concurrent users. If you do need the content from the Try Jupyter demos there are ways to copy the content over after launch.
You can also develop a repository somewhere and via configuration files configure it to launch with the environment you prefer as well. You may want to start with the How-to-Guides and look at examples people have made. If you overlook the postBuild file my repo here, it is otherwise a fairly simple example that can be set up on Github solely by using the browser-based interface. The requirements.txt file is specifying the packages installed there. You donât even need a full repo to do this because Gists can work as well. This is an example. You can click the launch binder badge there or follow the directions in that README to paste the URL for one you make in the MyBinder.org page. The MyBinder.org page can make the launch binder badges.
If you do make a new repo or gist, or update it, upon first launch, the image backing the container needs to get built before the session can spin up and so expect some delay initially. For simple requirements.txt-based sites the build time is fairly fast these days. You want to keep your requirements small. If you try to install every package on the planet that will make the build take longer. Aside from build time when you start or edit a repo or gist, another time you may see a delay is when the system needs to make a new node because the MyBinder service is experiencing a lot of use. Iâve personally not noticed this very often lately as the management seems quite good now.
For a while, I was seeing Chrome get locked out of launches from some repos if it had a bad launch. This was usually when I was developing an environment or content. Also, I havenât seen it in a while but the best way to test if that has happened to you, is to try another browser on the same machine. Or try the same launch route from a different computer. MyBinder can also be launched from most modern hand-held devices so sometimes you can a tablet or phone that to test where the issue is in launching.
Hopefully, knowing a little of the amazing things going on behind the curtain will give you some more options now.
Comparing a free service provided by an open source community to a mega-corporationâs paid product is not valid. Even if you donât personally pay for Colab now, you may if you want to have better features. Or it may just be discontinued at any point, see examples here. Full disclosure / Disclaimer: Google Cloud is one of the wonderful partners that support the MyBinder.org service.
Hi, thanks for your detailed info.
I think, it is valid to compare, though. Why not compare a self-made rocket with a Whatever-Starship to check, what feature of the self-made rocket can be improved�
The reason for my post was: If the Jupyter-Community has a âTry in your Browserâ button on its homepage: I donât understand, why this is not working easy, fast and nicely.
Nothing elseâŚ
I mean we could possibly serve JupyterLite which does not require a server.
Could MyBinder include JupyterLite as a fallback when no server is available?
Or at least add a link to a JupyterLite deployment in the error messages, like âall our droids are busy, but you can try JupyterLite >here< (link)â
JupyterLite as a webserver error page would definitely stand out 
Problem is it only makes sense to direct people to JupyterLite where the desired repo is similar enough, especially since a lot of users will be directed to a particular notebook/repo by others, and wonât have much knowledge of the Jupyter ecosystem, so may be confused if we suggest JupyterLite as an alternative.
Do you have some repos in mind where providing JupyterLite as an alternative makes sense (and if so, should we recommend trying JupyterLite first ahead of something on mybinder?)
I guess it would make most sense on the jupyter.org/try for kernels which have an in-browser equivalent (so for now basically Python, and expand as new kernels get added).
(which I understand is the biggest frustration in this thread, but could be avoided this way)
If itâs just about trying the JupyterLab and RetroLab interfaces, then JupyterLite should be more than enough. The advantage is that it indeed boots in seconds and is always available.
Another idea similar to what is being discussed here (and scattered across GitHub - jupyterlite/jupyterlite: Wasm powered Jupyter running in the browser đĄ and Twitter) would be to have a BinderLite deployment that would understand the same files as normal Binder (requirements.txt / environment.yml to start with).
Do you have some repos in mind where providing JupyterLite as an alternative makes sense (and if so, should we recommend trying JupyterLite first ahead of something on mybinder?)
The default deployment over at https://jupyterlite.rtfd.io/en/latest/try/lab has a couple of example notebooks and files for:
Which is very similar to the content of JupyterLab Demo: GitHub - jupyterlab/jupyterlab-demo: Demonstrations of JupyterLab
So for these kind of demo repos maybe that would be suitable?
Still lacking interactive C++ in the browser but weâll get there eventually!
Yep: the only way to win the on-demand-container game is to not play, by either:
try.jupyter.org)Since the bad old days of jyve, Iâd always hoped weâd get up to where we could give (millions of) site visitors the 80% jupyter interactive experience with the right application (from a custom voila app to full lab, and various things in between) without needing a hard-to-deploy solution. I think liteâs getting there, in a way thatâs reproducible, extensible, and free.
Longer term (e.g. for ju and r): getting a no-fooling conda channel for wasm-32 would pretty much blow the doors off it, as weâd likely be able to package up any number of well-behaved kernels.
So are there any plans to improve the performance and usability of Project Jupyter | Try Jupyter ?
As mentioned above: running free-compute-as-a-service is an increasingly loss-leading activity these days, and as open source organization, we basically get as good as we are donated and or can engineer ourselves. As long as we have to fire up a cold container, it canât really get much faster⌠and keeping containers warm is kinda out of scope.
As for JupyterLite, which would be (pipes willing) all-but-instantaneous when hosted for free by a big CDN: weâre buttoning up a few things which get us closer to effectively demoing JupyterLab and/or RetroLab (soon to be Notebook 7) without Docker or any reliance other than that static host.
The last few steps, of getting rid of external CDN dependencies, are a bit tricky, but I think necessary if it were to start to supplant the role of try.
Wow I just tried https://jupyterlite.rtfd.io/en/latest/try/lab and am super impressed. If the JupyterLite team believes that the tech is up to the task for serving the most popular links at try.jupyter.org, I would be in favor of directing those links to use JupyterLite rather than mybinder.org (even if it means we need to update some of the content in those repositories, I think it would be well-worth the reduction in usage for Binder)
Just to close this thread: jupyter.org/try now links to JupyterLite which should load instantaneously on fast Internet connection, see the announcement in JupyterLite: Jupyter â¤ď¸ WebAssembly & Python - #4 by bollwyvl and https://twitter.com/choldgraf/status/1499893924197912577
Performance and usability is much better now. 
Thanks for your update.