Hello,
I don't think that this is a choice that we should be mandating either,
these are simply two different use cases.
For publications that are truly native to the Web, they can either decide
to provide a fallback for progressive enhancements that might be missing in
browsers currently, or completely ignore them.
These types of publications are IMO much more likely to embed JS, but it
remains entirely their choice.
We just need to figure out a way to:
- identify that a JS provides such progressive enhancements in order to
turn it off eventually
- make sure that each progressive enhancement can be tested
individually, this way we can have a much more fine grained approach for
such a "Web Publication Polyfill"
I've listed a few of the progressive enhancements that could be supported
at:
https://github.com/HadrienGardeur/webpub-manifest/wiki/Web-Publication-JS-Features
For publications that are not native to the Web (for example when an EPUB
is turned into a Web Publication), I think we're much more likely to see JS
used for a separate Web App that behaves like a reading system/app.
This is what Dave has built with ACME JS, and I've also built a similar
prototype at: https://github.com/HadrienGardeur/webpub-viewer
Someone from my team at Feedbooks (Bastien Quelen) even built a simple
prototype in Go that takes an EPUB and:
- generates a Web Publication Manifest on the fly using the info
extracted from the OPF
- streams individual resources from the publication using HTTP
This project is available at: https://github.com/banux/webpub-streamer
Hadrien