Introducing a toolkit in JupyterLab

[fcollonval]

Problem

This is a companion PR of the JEP Jupyter UI Components to use a toolkit based on web components for building JupyterLab UI

Proposed Solution

A prototype of the toolkit is implemented using the FAST library by Microsoft.

---

@jupyterlab/jupyterlab-council votes

Quorum met with 8/13 of @jupyterlab/jupyterlab-council voting.

The result was Yes.

8 Yes, 0 No, 0 Abstain

[fcollonval]

Discussion a the weekly meeting:

Who does it benefit? Does it make things easier for contributors?

• Developers: faster UI development as CSS is mainly needed for positioning and you get basic behavior for free (like keyboard navigation on tab panels, tree view, accordion panels,...).
• Accessibility maintenance: update behavior and/or styles in a single place to correct everywhere; e.g. changing the hover contrast on buttons.
• Third party authors: faster development, better integration, better accessibility, still picking the framework you prefer (Vue, React, vanilla JS,...).
• Users: More homogeneous look and feel of the UI

Will this be used with ipywidgets? What is the scope of the impact in the Jupyter ecosystem (ie. only JupyterLab or multiple projects)?

It's not a given that it would be used for ipywidgets.

If that toolkit percolates across different projects, the main benefactors will be JupyterLab/Notebook 7+ and JupyterHub.

For ipywidget the first step is likely to make a custom ipywidget library that uses these controls (similar to existing libraries providing material or Vue controls). And them, the question of moving as core replacement may come after experience with that external libraries has been used. As pointed out, one of the challenge of the current widgets are the ability to customize greatly some styling (e.g. the button type).

How big does this make the JupyterLab bundle when added?

(definitely lighter than blueprint)

The minimified version of the library as standalone library is about 360kB.

When web components have been advocated for before, one of the problems has been that the global namespace means that there may be conflicts between packages with the same name. How has that been addressed here.

Tested installing multiple extensions pinning different version of the toolkit, resulting in only a single version of the library being loaded. All elements were created without errors - the styles were not the latest as the version loaded was an older one (final choice resulted of webpack federation resolution).

Is this library open governance or open source?

It is open source; not open governance (not big or old enough to reach that point).

Is it possible to easily switch the underlying library (for now FAST libraries)?

No, they provide 2 parts:

• Helpers for building components - this could probably be replaced almost transparently by a library like Lit
• Design tokens system - I don't know a replacement for that.

---

Concern: is this a library we are confident in depending on. Clarification: it doesn't sound like anyone is against the web components part, it's more important that we find a solution
- We need this change, it's a question if this is the library we want to support this change.
- Is this library open governance or open source?
- Do we want to invest in depending on these libraries and converting JupyterLab to follow it?

[fcollonval]

A nice side-effect of dropping as much react as possible for the web-components is a probable speed-up gain of the UI; see that benchmark.

[fcollonval]

Meeting notes from April 22nd, 2022

Attendees: @afshin @ajbozarth @ellisonbg @fcollonval @gabalafou @jasongrout

Discussion

The questions is not on the technology (it sounds mature and well written) but on the additional dependencies and the multiple paradigms to create code for Jupyter frontends:

• Do we feel confident enough in that library to advocate it to the users? Could we support it in the worst case scenario (i.e. Microsoft pulls the plug and archives the project).

We are confident that we can support it in the case Microsoft pulls the plug.

For example, that repository author recreated template functions and basic class element for creating web-components after trying FAST components library.

That part (template generators and web-components registration) is probably the easiest to swap with other libraries. The more complex part is the design system introduced by FAST. A design system is a set of linked variables that will be propagated to the component styles to create a design toolkit.

• They are multiple ways to create elements within JupyterLab. Is that a problem to have a multiple paradigm to create code for JupyterLab?

Probably ok to have different frameworks to coexist with the same application.

• Examples

  • Custom component from scratch: Date Field component
  • Extension using the components directly: [WIP] Jupyter Theme Builder
  • Extension using the components in React: Search in files

Conclusion

The attendees are in favor of adopting of a toolkit based on FAST design for JupyterLab

Next step

Request vote on the JupyterLab Council if there is not enough people at the next JLab meeting (April 27th) to reach consensus.

[isabela-pf]

Thanks for taking all these notes, @fcollonval! I'm very grateful to have a record of these discussions!

[fcollonval]

It was decided at the JupyterLab Weekly meeting to call for a vote on this proposal by @jupyterlab/jupyterlab-council as not enough members were present at Wednesday call.

I propose to vote on the first post using the following reaction emojis:

• 👍 = Agree
• 👎 = Disagree
• 👀 = No opinion

The vote will be closed in a week (aka Thursday May 5th - although May 4th would have been a nice deadline 😄 )

[ellisonbg]

Can we paste in the list of Council members with checkboxes so it is clear who is voting? Also, for those who haven't seen it, here is the decision making guidelines: https://github.com/jupyter/governance/blob/master/decision_making.md

…

On Wed, Apr 27, 2022 at 11:03 PM Frédéric Collonval < ***@***.***> wrote: It was decided at the JupyterLab Weekly meeting <#135 (comment)> to call for a vote on this proposal by @jupyterlab/jupyterlab-council <https://github.com/orgs/jupyterlab/teams/jupyterlab-council> as not enough members were present at Wednesday call. I propose to vote on the first post using the following reaction emojis: - 👍 = Agree - 👎 = Disagree - 👀 = No opinion The vote will be closed in a week (aka Thursday May 5th - although May 4th would have been a nice deadline 😄 ) — Reply to this email directly, view it on GitHub <#143 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGXUCQAZKMTWLOSAPMU6LVHIS2ZANCNFSM5SCUIFGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Brian E. Granger Senior Principal Technologist, AWS AI/ML ***@***.***) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

[afshin]

This vote has passed with 8 out of 13 members of the JupyterLab Council voting and 100% voting in favor.

[afshin]

Thanks for opening this discussion and vote @fcollonval!