assess move to reveal.js v4.3

[parmentelat]

as of v5.7, RISE relies on reveal.js version 3.9.2 that is now 2 years old

it would make sense to move to the latest release i.e. 4.3.0 as I am writing this

[parmentelat]

as far as I can tell, reveal-4.3.0 only ships as an ES module:

$ head -5 ../rise-reveal/export/reveal.js/js/reveal.js
import SlideContent from './controllers/slidecontent.js'
import SlideNumber from './controllers/slidenumber.js'
import Backgrounds from './controllers/backgrounds.js'
import AutoAnimate from './controllers/autoanimate.js'
import Fragments from './controllers/fragments.js'

however the rise entry-point is loaded as a text/javascript thing:

which keeps the browser from loading reveal.js properly

so we need a - even quick and dirty - trick to be able to load rise/main.js within a <script type="module" ...> tag

[damianavila]

Do we really want to upgrade the "legacy" RISE 😉?

I mean with notebook v7 based on JupyterLab component (previously known as retrolab) the next iteration for RISE should also be based on Labs components, IMHO. And, if that is the case, we should focus our efforts on the new iteration and just keep the "legacy" RISE as it is right now (with maybe some minor fixes if there is a huge bug/blocker). I do not think we have the human power to maintain two different codebases and keep them in sync and even with enough resources, I do not think it is a good idea.

I think anything new, ie. a new reveal.js version, should only be available in the new thing: #605.

On the other hand (and thinking against my previous thoughts 😜), since 605 was not yet merged nor released, I guess, we could try to upgrade reveal.js in the legacy RISE and also in 605. I will OK-ish with that as long as the upgrade is not a big task...

[damianavila]

On the other hand (and thinking against my previous thoughts 😜), since 605 was not yet merged nor released, I guess, we could try to upgrade reveal.js in the legacy RISE and also in 605. I will OK-ish with that as long as the upgrade is not a big task...

Mmm... maybe this one (reveal.js 4) is our RISE 6 and then we have RISE 7 as the lab-based one... that feels natural and compatible with the notebook story, IMHO.

[damianavila]

Well, there were some interesting conversations in the last few days (I just missed one week, come on... ja ja): https://github.com/jupyter/notebook-team-compass/issues/10

Since now it would be possible to have the classic and v7 notebook side by side, then we would need to think about how we want to ship RISE... mmm... moving sands underneath 😜 (context: my previous comments were done with the mental model where v6 and v7 notebook can not be run on the same environment, but the linked proposal - which is super reasonable, IMHO - goes in the opposite direction).

[parmentelat]

to be clear: my reasoning here is, we're already 2-year behind in terms of the reveal version, and at some point we're going to have to follow suit so, the ultimate target indeed is to have rise work within jlab and the latest reveal

however, this looks like 2 different steps along 2 orthogonal directions, and it seems only reasonable to achieve these 2 steps independantly; so my proposal was to target, as part of the current move, notebook-classic(6)+reveal-4.n ; mostly, as the title for this issues reads, in order to assess the changes required on our end to deal with reveal-4.n, and get familiar with that tool

it may or may not ship as an official version of rise; at first sight, it's probably not going to... given that, precisely, the notebook classic extension loader might just turn out to be unable to cope with ES6 modules...

(of course if we already had a decent jlab-based rise as a starting point, I might try to go down that road instead, but that is not yet the case, or is it ?)