Reduce the surface area - deprecate the JS cookiecutter

[ibdafna]

cc @jupyter-widgets/jupyter-widgets-council

Following the feedback we received during JupyterCon 23 about seeding new widget projects from the TS/JS cookiecutters, and in line with more recent discussions on the same topic during our weekly dev meetings, I propose that we reduce the surface area and deprecate the JS cookiecutter, so we can focus on maintaining only one cookiecutter. TypeScript has come a long way since the early days of widgets and is considered best practice nowadays. This will also be a great opportunity to modernize our TS cookiecutter and make it a good experience for new widget developers.

[ibdafna]

We've gotten four thumbs-up on this, which is great - but I'd like to make sure everyone has had the chance to properly vote on this.

Are you in favor of deprecating the JavaScript cookiecutter for jupyter-widgets extensions?

• @ivanov
  • Yes
  • No
  • Abstain
• @jasongrout
  • Yes
  • No
  • Abstain
• @vidartf
  • Yes
  • No
  • Abstain
• @jtpio
  • Yes
  • No
  • Abstain
• @mwcraig
  • Yes
  • No
  • Abstain
• @maartenbreddels
  • Yes
  • No
  • Abstain
• @SylvainCorlay
  • Yes
  • No
  • Abstain
• @davidbrochart
  • Yes
  • No
  • Abstain
• @marimeireles
  • Yes
  • No
  • Abstain
• @martinRenou
  • Yes
  • No
  • Abstain
• @ibdafna
  • Yes
  • No
  • Abstain

[jtpio]

Of note, anywidget seems to be getting some traction for authoring custom widgets: https://github.com/manzt/anywidget. Which can be a good replacement for those looking for a JavaScript cookiecutter.

Maybe the ipywidgets docs or the TypeScript cookiecutter could link to it as another option, with the disclaimer that it is not officially supported.

[ibdafna]

We should mention anywidget in the documentation for sure. I'd also like to discuss potentially using it at some capacity in ipywidgets - perhaps in the next meeting?

[davidbrochart]

Having tried anywidget, I'm not going back to the cookiecutter.

[maartenbreddels]

offtopic: I feel the time is ripe to propose to serve all ipywidgets assets from the kernel instead of the jupyter server (like anywidget does) so we'll have 0 installation issues 🥳

ontopic: yes, i think we should advertise the low friction entries sooner, ipyvue(tify), ipyreact and anywidget (in particular).

I'd also like to discuss potentially using it at some capacity in ipywidgets - perhaps in the next meeting?

Seriously, I think we should think about serving all widget assets as (es) modules from the kernel.. so yes, I think we should use the underlying ideas.

[martinRenou]

offtopic: I feel the time is ripe to propose to serve all ipywidgets assets from the kernel instead of the jupyter server (like anywidget does) so we'll have 0 installation issues 🥳

Staying offtopic: that means not benefiting from the browser caching, right? Duplication of style assets and JS in the page whenever you restart the kernel may be an issue as well, or when you have multiple kernels.

[maartenbreddels]

Still offtopic, but not quite maybe: I think styling collisions can happen, but we can maybe be careful about that with ipywidgets 9 at least. But I think both browser cache can work, and multiple jupyter-widgets versions can live on a single page.

I wouldn't say it is easy to solve, but I think with collective brainpower feasible, and a huge win for usability.

[martinRenou]

serving all widget assets as (es) modules from the kernel

I would not be in favor of this BTW. That means getting rid of TypeScript and going back to JavaScript everywhere, right? At least, I understand that the point of anywidget is to get rid of all the complicated dev tooling around widgets, like TypeScript compilation and webpack, which makes it appealing to newcomers.

[maartenbreddels]

No, anywidgets loads an ES module, which you can generate using webpack, esbuild, vite and probably a few more. The simplest case is to manually write it, as most anywidget examples will show. So we can keep using whatever build chain we like. With the (es) between parenthesis I mean not per se en ES module, anything will be fine for me, as long as they come from the kernel.

[ibdafna]

@jasongrout @ivanov @marimeireles @davidbrochart @vidartf Gentle reminder to cast your vote 😸 We'll look to finalize a decision in the next meeting!

[ivanov]

@ibdafna I can't edit your comment so I'm probably not on the appropriate team, but my thumbs up was intended as a yes vote, so please go ahead and adjust that accordingly.

[jasongrout]

The thing I've always preferred about the js cookiecutter is that it is very minimal, so it was easier to see what the essential parts of a widget were, to integrate into existing workflows, etc. It would be nice if there was a very minimal barebones typescript widget example or cookiecutter. (Or perhaps anywidget fills that roll?)

That said, I won't stand in the way of deprecating the js cookiecutter either.

[jtpio]

So the current vote seems to show a majority of 👍

Should we go ahead and deprecate the JS cookiecutter? Or should this be discussed more?

so it was easier to see what the essential parts of a widget were, to integrate into existing workflows, etc. It would be nice if there was a very minimal barebones typescript widget example or cookiecutter. (Or perhaps anywidget fills that roll?)

Agree that having a simple version is good for newcomers, or widget authors who don't have time to learn TypeScript. anywidget seems to be quite popular these days and simple to get started. So maybe this could be the replacement for the JS cookiecutter? In that case it could be mentioned in the documentation as an alternative to using the TypeScript cookiecutter.

[ibdafna]

@jtpio Yes, let's deprecate it - there's consensus from the majority of the team. The concern for having an accessible entrypoint for newcomers to learn widgets is valid, and I do agree with it. Hopefully adding links in the deprecated JS cookiecutter page (and maybe even the TS one) to the anywidget documentation should help.

[ibdafna]

Completed via jupyter-widgets/widget-cookiecutter#109