CoCalc deteriorates formatting for tab widget

[jt0dd]

Using the tab widget from ipywidgets:

https://ipywidgets.readthedocs.io/en/stable/examples/Widget%20List.html#Tabs

with the following code:

from ipywidgets import widgets

tab_contents = ['P0', 'P1', 'P2', 'P3', 'P4']
children = [widgets.Text(description=name) for name in tab_contents]
tab = widgets.Tab()
tab.children = children
for i in range(len(children)):
    tab.set_title(i, 'hi')
tab

We should get a nice clean UI result, like...

Standard Jupyter Lab, looks good 10/10:

Standard Jupyter Notebook, looks good 10/10:

Google Colab sort of messes up the coloring in dark mode, but otherwise good 8/10:

Then CoCalc really just sloppy, no padding, very different from the expected result, 2/10:

[williamstein]

CoCalc uses the standard default Antd Tab component for tabs: https://ant.design/components/tabs/

I'm sorry that you don't like it. If you want to suggest a change to how it is styled in CoCalc, we would consider that. The link above has links to code sandboxes, etc., where one can play with the styling. However, this requires some familiarity with react.js.

Overall, the UI in CoCalc is (or will soon be) entirely built on top of Antd, so for consistency it makes much more sense to use their Tab component than the one that might be in Lumino or somewhere else.

[jt0dd]

I'm sorry you don't see value in the same code producing consistent output across varying platforms (i.e. CoCalc vs Jupyter / Colab).

[williamstein]

I'm sorry you don't see value in the same code producing consistent output across varying platforms (i.e. CoCalc vs Jupyter / Colab).

I see a lot of value in consistency. I think the issue is just that I want to consider consistency along more dimensions that you seem to want to:

• consistency across different clients implementing ipywidgets
• consistency within a given client with other UI elements

I'm not going to change from Antd tabs to something else. However, as I mentioned above, it's certainly possible to change the style of Antd tabs somewhat, and I'm open to that.

[jt0dd]

I suspect most of your customers won't care as much about UI, so most of what I'm saying might not affect you. Just one customer giving a bit of feedback about our pain-point with this front end inconsistency, in the off-chance you have other customers with the same frustration.

I appreciate what you're saying, but at the end of the day I'm just one customer and you develop / run the service. I don't have time to research why it would be necessary for you to have re-engineered the front-end of Jupyter to such an extent, when it's pretty good the way it is. Perhaps that was necessary. But seeing as the Jupyter project has now added support for collaborative editing natively, I don't see it as having been necessary.

In my eyes, you're a managed service with a value proposition of making it painless to host Jupyter as a cloud service at a reasonable price and let multiple users authenticate to it. That's a good value proposition. But it's clearly possible to achieve that with Jupyter's native front end, since the feature now exists (I recognize that perhaps it didn't when you started, but Jupyter is open source and you could have forked it).

What I hope you take from this is that regardless of your reasons, any inconsistency you add to the Jupyter environment is a potential pain-point for the end-user. If I develop a UI in CoCalc, and the front end is not consistent with native Jupyter, that's an immediate pain point for me in terms of assuring the desired UX experience (since we need our Notebooks to be shareable outside of CoCalc).

For us, it was easier to move away from CoCalc and just use the standard GitHub collaboration workflow. Slightly less seamless, but we avoid the inconsistent Jupyter front-end.

[mforbes]

@jt0dd The advantage CoCalc has over any other tool is real-time collaboration (i.e. I can see the exact same code my students are running, as they are running it, debug in real time etc.), and this needed a new frontend. This is a game changer, and only currently available because of the customzed front end. CoLab used to do something sort of like this, but stopped.

Jupyter Lab may be moving in this direction, but CoCalc has been doing it for years. (@williamstein Do you have any discussion online about how CoCalc will relate-to/interact with this new feature? I am curious.)

If you don't care about such real-time collaboration, you can just use CoCalc with the standard Jupyter UX by using Classical Jupyter, but once you get used to the possibilities afforded by real-time collaboration, you don't want to go back.

[jt0dd]

@mforbes

The advantage CoCalc has over any other tool is real-time collaboration (i.e. I can see the exact same code my students are running, as they are running it, debug in real time etc.), and this needed a new frontend.

My argument here is that since Jupyter lab has now built this feature in natively while remaining consistent visually, it must not have really needed a new front end. My argument is sort of that perhaps it would have been better to expand the existing jupyter front end rather than adopt a new tech platform for it.

But that tech investment is done, and the cost was front end visual consistency. Yes, real-time collaboration is awesome, we loved it, but for us the added UX pain point didn't outweigh the reduced collaboration pain-point.

[jt0dd]

How is this new client working? Are they doing P2P with basically a middle-man server hosted by Jupyter tracking authentication based on anyone knowing the link? P2P always needs some middle man to facilitate the connection. Can't imagine Jupyter would be moving to a paid service, so I wonder how they're funding that middle-man server.

@mforbes what I'm sort of wondering is if CoCalc could just swap to Jupyter's new native real-time colab feature and modify the authentication mechanism to use CoCalc's existing authentication.

[mforbes]

@jt0dd I have not used it yet (CoCalc works well enough, and we are productive with it) so have no idea how it works. I am pretty sure that the CoCalc team is keeping up to date with the advances at Jupyter, but know that realtime synchronization is a very difficult problem. (Google tried, then abandon for example.)

While I would like to be able to use the common interface with Jupyter if it works well, I would not like to see CoCalc's effort fragmented while trying to support different technologies. CoCalc's current approach is obviously very flexible: have you tried out their new collaborative whiteboard? This came together in a few months, and while it still needs UX improvements, it is already very functional. (Saved me when OneNote crapped out on me while giving a live lecture via Zoom for example.)

[williamstein]

Here are answers to some questions that come up in the comments above:

mforbes:

I am pretty sure that the CoCalc team is keeping up to date with the advances at Jupyter, but know that realtime synchronization is a very difficult problem. (Google tried, then abandon for example.)

Indeed, I go to hours of meetings about this with Jupyter devs regularly, and provide as much support as I can. For example, there was a recent issue jupyterlab/jupyterlab#12154 "CRITICAL - data loss and notebook corruption on a hosted Lab instance", which the Jupyter RTC devs strangely didn't seem to be aware of, so I pointed it out to them at a meeting and we discussed it. They have highly prioritized the necessary work to properly actually implement RTC, and are getting there. For example, today in the JupyterLab meeting, David reported on new work to have the backend server process properly participate in RTC, rather than RTC being entirely between the frontend browser clients; this is a key step to avoid data loss and other problems that make the current experimental version not really usable. Solving that problem required creating a new library, which is a Python wrapper around a new Rust implementation of yjs, and that's all necessary since the backend Jupyter server is written in Python instead of Javascript. (In CoCalc, the backend server is written in Javascript, so only one implementation of RTC is required.)

The entire algorithmic approach and data structures used in JupyterLab's RTC implementation are completely different than what's used in CoCalc. There are significant pro's and con's to each approach.

I've heard a little about what happened with various Google projects and RTC -- there was both colab and kaggle notebooks (also owned by google) that had RTC, and both don't now, for different reasons...

jtodd

... it must not have really needed a new front end.

One detail is that I started CoCalc 4 years before JupyterLab:

• https://github.com/sagemathinc/cocalc/graphs/contributors
• https://github.com/jupyterlab/jupyterlab/graphs/contributors

Before that, I wrote the Sage Notebook in 2007, which was REALLY difficult at the time, to put it mildly (nobody had done anything like that, async javascript was totally new, and web dev sucked; also UW students like Tom Boothby and Alex Clemesha, etc. helped a lot with this.) I remember when Jupyter came out in 2011, and people kept telling me: "heh they cloned your software", since Jupyter notebook looked and felt almost exactly like the Sage notebook. I was glad, since working on the Sage notebook was a pain in the butt. If they would have said: "in 10 years, somebody will tell you to stop working on notebooks because your UI is too different than Jupyter" I would have been amused :-).

mforbes:

The advantage CoCalc has over any other tool is real-time collaboration

There are other advantages, as listed in our Help menu:

(NOTE: some of these are now available in JupyterLab, in some cases because I pushed for them to be there, e.g., large output limiting, and I hope at some point all of them are!)

Another remark is that there are a lot of different Jupyter clients at this point:

• VS Code
• DeepNote
• nteract
• colab

@mforbes what I'm sort of wondering is if CoCalc could just swap to Jupyter's new native real-time colab feature and modify the authentication mechanism to use CoCalc's existing authentication.

That's what #5905 is about. Regarding identity/auth, I have suggested in multiple meetings that it would be nice to be able to pass on the cocalc user to JupyterLab's RTC for the cursor name, etc., but realistically, I'll probably have to contribute that as a PR to JupyterLab myself. In any case, we do eventually plan to support JupyterLab + RTC in CoCalc, and that PR was from 1 day ago.

[jt0dd]

@williamstein

Before that, I wrote the Sage Notebook in 2007, which was REALLY difficult at the time, to put it mildly (nobody had done anything like that, async javascript was totally new, and web dev sucked; also UW students like Tom Boothby and Alex Clemesha, etc. helped a lot with this.) I remember when Jupyter came out in 2011, and people kept telling me: "heh they cloned your software", since Jupyter notebook looked and felt almost exactly like the Sage notebook. I was glad, since working on the Sage notebook was a pain in the butt. If they would have said: "in 10 years, somebody will tell you to stop working on notebooks because your UI is too different than Jupyter" I would have been amused :-).

Thanks for the background, that's such a bizarre scenario to me, I had no idea. I assumed (I think reasonably) that CoCalc was a startup with a value proposition of real-time Jupyter, not that the developer was doing jupyter-esque notebooks before Jupyter. I apologize for my misguided comments. Nonetheless, the reality is Jupyter did become the most popular tool for the job, and I don't know if I would be able to get buy-in on the tech from my superiors if it hadn't been so popular.

So here's how I see it, metaphorically: You invented the web browser with special features, some lesser known hobbyist tool then big ole Google came along and made Chrome, and Mozilla made Firefox, those became the widely used tool in the space, and people are now annoyed that your browser renders their web pages wrong.

But look at how unpopular IE got because of inconsistency with the other clients (Chrome / Firefox mainly). Developers complained it basically out of existence, and things just worked more seamlessly on Chrome / Firefox because it was easier to develop for those clients. I suspect you don't exactly hold great interest in winning some competition, you probably did very well for yourself already. This sounds like more of a passion project that also pays the bills, which I applaud, and look forward to being a customer again in the future.

In any case, we do eventually plan to support JupyterLab + RTC in CoCalc

If that by any chance supports the standard front end, I'll be a customer again on day 1.

[jt0dd]

Another remark is that there are a lot of different Jupyter clients at this point:

VS Code
DeepNote
nteract
colab

And PyCharm. Although they not only deviate from the native UI, they break features. I have a ticket open with them now.

But I'm fairly certain Colab is the most popular one out there and it sticks to the native front end. I'm not sure about the others, never heard of them.

[williamstein]

Nonetheless, the reality is Jupyter did become the most popular tool for the job

The reason for that is the Fernando Perez (who started IPython and Jupyter) spent basically a year writing a massive grant proposal to the Moore-Sloane foundation, and they funded it at 5 million dollars, and subsequently they did a good job spending that money. I spent that same year writing very fast code for computing Hilbert modular forms...

https://github.com/williamstein/psage/graphs/contributors

I'm happy that Fernando put so much work into that grant, and that Moore-Sloane funded it. If not for that, maybe many people using Jupyter now would be using mathematica or matlab.

That said, I'm not going to stop pushing the boundaries of web application compute technologies, and I think the best is yet to come (in all the projects).

And Pycharm.

Thanks for adding that to the list. And I'm sure there are many others that I forgot...

Colab [...] sticks to the native front end

To clarify, Colab has its own closed source frontend implementation of a Jupyter client, which has essentially zero overlap with the codebase of JupyterLab or Jupyter classic. However, for ipywidgets I think colab 100% does use the same code that comes from ipywidgets upstream (so lumino widgets). There are good reasons for Colab (actually, Pete Blois) to reimplement the notebook from scratch (except widgets), and they involve unique security constraints from Google, among other things.

[jt0dd]

@williamstein Well you lost a customer but gained a fan.

[williamstein]

I greatly prefer customers :-)