too heavy on mobile

[jaroslaw-weber]

mdbook has lot of features but its getting heavy on mobile. i was able to make a static website with most of the functionality and go down to 70kb (cookbook is 250, rust book is over 300) so i think there is a room for improvement.

what can we do:

• remove jquery
• create custom icon pack
• ... ?

[sorin-davidoi]

Would a PR that removes jQuery (uses native DOM APIs instead) be accepted?

[Michael-F-Bryan]

It'd be really nice to get rid of the JQuery dependency. Besides the fact that it makes the generated website smaller it'll also make packaging mdbook a lot easier on platforms where installers aren't allowed to access the internet.

In particular @tjis (#271 (comment)) and @infinity0 (#495) have had issues trying to package Rust on Debian because The Book uses mdbook.

[steveklabnik]

No, as that goes against distro policy. That said, we removed jquery in rustdoc as well.

…

On Fri, Jan 12, 2018 at 3:06 AM, Sorin Davidoi ***@***.***> wrote: Wouldn't that be solved by ditching the CDN links and including the resources in the repository? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#475 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABsiogA3m_PTimYbMjx4PIRmfnjuafuks5tJxKFgaJpZM4QFRke> .

[sorin-davidoi]

^ Is in response to my question (why don't bundle jQuery locally) which I shouldn't have deleted.

[infinity0]

To clarify on @steveklabnik's answer, the preferred solution for distros is if there were options to allow linking to locally-installed versions of JS libraries (including jquery) rather than remote-loading from a CDN all the time. Bundling copies of dependencies together with the repo would not be helpful - but also wouldn't hinder packaging; we'd just ignore those copies and link to locally-installed ones where possible.

Also jQuery is not a problem for Debian, it is already packaged, it has no dependencies and uses a simple standard buildsystem. It's other NPM packages with masses of pointless 10-liner dependencies and special-snowflake-buildsystems that are the problem.

[sorin-davidoi]

What about polyfills? Are those fair to bundle? I cannot image Debian packaging every polyfill out there.

[infinity0]

That depends on the packager and the specific situation. I for one would reuse an existing polyfill that's already packaged by Debian, e.g. es6-promise, instead of packaging a new Promise polyfill. Then I'd add a Debian-specific patch to make that package use es6-promise. Usually it's just a few lines in package.json. (I've done this a few times already.)

[steveklabnik]

@sorin-davidoi oops, hehe, I replied via email so I didn't see it.

[Michael-F-Bryan]

Looking through the comments made from @steveklabnik and @infinity0 it seems like my earlier thought of "remove all the JS dependencies" was a bit too wide-sweeping. If it's easy enough for Debian to do a ln -s to override the vendored JQuery before mdbook gets compiled, then there's no longer any reason to remove it.

@sorin-davidoi, what are your thoughts?

[sorin-davidoi]

I am not familiar with the packaging process - my view on this is that removing jQuery is good for the performance of the page (less JS to load, parse and keep in memory).