9 ms·

This is something I've always wanted for virtual textbooks. A single .html file with all the JS, CSS, images as inline data blobs, etc. For most physics, math,

by sxp 5y ago

This is something I've always wanted for virtual textbooks. A single .html file with all the JS, CSS, images as inline data blobs, etc. For most physics, math, CS, etc books, this should be possible. It would make it trivial to download the book for offline use and share it with others. Other than the raster images, the entire content of these types of books would probably fit in a couple MB of text. The use of #anchors or other smart URL manipulation would also make it easy to share internal hyperlinks if you want to tell a friend to look at chapter/section #foo_bar of the book.

andyp-kw 5y ago
You're describing PDF files, but unfortunately Adobe didn't invest much time or money into making them interactive with a scripting language.
- nextaccountic 5y ago
  PDF has a limitation: it defines page size and the layout of everything fixed to this page, and thus can't do responsive layout like HTML can (reorganizing stuff in the page to match the screen size)
  - mmh0000 5y ago
    I wouldn't call that a limitation. In fact that is one of the major selling points of the PDF format. The document looks as intended* by the creator on all platforms whether display or print media. * Yes, I know, PDF doesn't -always- do this, but a well designed PDF generally does.
    - Tagbert 5y ago
      True, but the rigid layout is what makes PDF unsuitable for some use cases. It’s main use is to represent a printed page of a very specific size. Anything outside that just requires too much flexibility.
    - vgel 5y ago
      It is a limitation. Anyone who's ever tried to read a PDF journal article on their phone has experienced it. (and don't even get me started on Unicode copy/paste...) HTML can be styled in a fixed layout if desired, and reflowed by a reader mode if needed. PDF can't be styled in a responsive way, and there's no (easily accessible) reader mode equivalent for PDFs. HTML is a far better document format than PDF.
      - bee_rider 5y ago
        A significant advantage of the two column journal format (although still they end up feeling pretty clunky on a phone).
      - dragonwriter 5y ago
        > there's no (easily accessible) reader mode equivalent for PDFs. It’s called Liquid Mode in Reader, and it is, in fact, easily accessible. > HTML is a far better document format than PDF. HTML is better for some things, PDF for others. That's why PDF is widely used on the web when HTML is available.
        bananamerica 5y ago
        Liquid mode only works we for a subset of PDF files. And sometimes it doesn't work at all.
        dragonwriter 5y ago
        Reader mode only works well for a subset of HTML files, too.
        bananamerica 5y ago
        Yes, of course.
      - deleted 5y ago
        [deleted]
  - dredmorbius 5y ago
    Feature. The dimensioning problem isn't PDFs. The dimensioning problem is computer displays. Get yourself an e-ink display of 10" or 13" (standard dimensions offered by the patent-monopoly vendor across multiple OEMs), and discover that online reading of PDFs is 1) quite pleasant (so long as the underlying PDF formatting itself is sane) and 2) vastly preferable to either HTML or "fluid" ePub or Mobi file formats. Book formats developed over about 500 years largely guided by the capabilities and limitations of human eyes and hands. Typical mass-market books range in size from roughly 6" to 12" diagonal measure. Yes, there are smaller and larger formats, these are deviations from the norm and impose compromises for other concerns (portability for smaller formats, resolution for larger ones, typically pictoral or graphical in nature). A 5" or 6" mobile device presents less display area than an index card. Laptop displays are too short to display a portrait-mode document one page at a time, and in almost all cases too small to present a 2-page up display. (You can verify this yourself trivially at the Internet Archive using its BookReader, e.g., https://archive.org/details/UnderstandingPhotoTypesetting/page/n5/mode/2up?view=theater https://archive.org/details/UnderstandingPhotoTypesetting/pa...) When wedding PDFs with an appropriate display technology, the frustrations fixed-proportion PDF display disappear. This does rely on the PDF being dimensioned for a typical book size, though there's considerable flexibility here, and any dimensions from ~6" to well over 12" will tend to be readable, there's no need for precisely matching device to document size. I'm saying this as someone who's long railed against PDFs for documentation. My mind's been changed.
    - LordDragonfang 5y ago
      >Get yourself an e-ink display of 10" or 13" (standard dimensions offered by the patent-monopoly vendor across multiple OEMs), and discover that online reading of PDFs is 1) quite pleasant (so long as the underlying PDF formatting itself is sane) and 2) vastly preferable to either HTML or "fluid" ePub or Mobi file formats. Notably this is not the standard size for most e-ink devices though, on which pdfs are a pain to read. Mobi/epub files, in contrast, are fantastic on my kindle (and on my phone, and on desktop). If your argument has to boil down to "this file format is great if you just buy a specific device for viewing them, and eschew viewing them on any of the other devices you already own and use more frequently", I'd say your argument provides more evidence for the counterpoint than for the one you're arguing. I'm happy you found a good way to consume a fundamentally outdated format, but PDFs are a bad format for the majority of use cases.
- Encounter 5y ago
  Think about how much worse PDF exploits would be if they did!
- asciimov 5y ago
  The problem with PDF's has always been the layman can't create them without some expensive Adobe program.
  - TylerE 5y ago
    This is categorically false. There have always been other tools for producing PDF (E.g. TeX) and there are also tons of free converters, print-to-PDF drivers, etc.
    - LordDragonfang 5y ago
      I have never seen anyone I would remotely describe as a layman using TeX.
  - garbagecoder 5y ago
    macOS hasn’t had this problem in 20 years.
    - elcapitan 5y ago
      Yes, it's literally just Print dialogue -> Save as pdf. Also worth noting that the PDF preview on the Mac has very nice simple editing capabilities to combine pages, delete pages, crop etc.
  - samus 5y ago
    Any modern office suite (MS Office, Libreoffice, Google Apps) has PDF export. Many image editing applications can do it too.
- dragonwriter 5y ago
  > but unfortunately Adobe didn't invest much time or money into making them interactive with a scripting language. Yes, they did. (Non-Adobe readers often don't support JS, though some do, but Adobe definitely built the support for interactivity.) Also 3D content and a lot of other things most people probably aren't aware of, because they are peripheral to the common use cases of PDF.
- nine_k 5y ago
  Emphatically no. HTML can be responsive, like an electronic document should. PDF was designed to faithfully represent paper, and it has all the fluidity and customizability of a stack of printed paper. It's also completely anti-semantic: it has no document structure beside pages, and each page just describes how to put ink onto paper. I think that the principal application area of PDF is just that: to represent paper, for printing purposes. For everything else, it's not exactly great.
- naikrovek 5y ago
  > Adobe didn't invest much time or money into making them interactive with a scripting language. yes they did. JavaScript, though I have no idea if there is a DOM or anything like it. pdf is kinda messed up in ways like that.
- zffr 5y ago
  PDFs actually have some support for javascript! I don't know any serious use for it and some PDF viewers refuse to support it (ex: Apple's Preview app), but it does exist.
  - jraph 5y ago
    Form verification for instance, if I remember correctly.
  - tonyedgecombe 5y ago
    PDF would have probably been better without it but Adobe couldn't resist adding new features so they could flog more copies of Acrobat.
terpimost 5y ago
And images can be also embedded. These days you can fake a real URL completely on a fronted side.
- laumars 5y ago
  I absolutely hate it when people do this.
- www_harka_com 5y ago
  What do you mean by faking a real URL on frontend side? I'm genuinely interested.
BeefWellington 5y ago
MHT did this 20 years ago and got all but abandoned (probably for good reasons).
- adzm 5y ago
  Interestingly, the support for mht/multipart is still there in Chrome and Firefox; or at least it was relatively recently. However it only works for files and not when accessing an mht file over http. The format itself is relatively simple.
  - BeefWellington 5y ago
    Yeah it's pretty much the MIME email format as a container for a webpage. A lot of the issues "solved" in modern frameworks could have been addressed by using this, but instead things went a different path.
- gildas 5y ago
  Web bundles is supposed to replace it, cf. https://web.dev/web-bundles/ https://web.dev/web-bundles/
tambourine_man 5y ago
You can even embed images with a src converted to base64. This method even works well with the back/forward browser buttons, something that a naive show/hide JavaScript solution wouldn’t.
- gildas 5y ago
  Or even store the whole page as a self-extracting zip file. This page is a zip file: https://gildas-lormeau.github.io/ https://gildas-lormeau.github.io/
zozbot234 5y ago
Isn't that what .epub is for?
AdmiralAsshat 5y ago
I think you've just described an EPUB?
- tingletech 5y ago
  I thought epub files were basically zip archives of all the required files
  - m-p-3 5y ago
    You could make an ePub of a single HTML file with all the binary blobs embedded.
  - dredmorbius 5y ago
    ePub, as with PDF, is a container-file format. (A ZIP file with a specified structure.) If you want to consider that single or multiple files ... quickly veers into semantics.
  - ryantriangles 5y ago
    An epub is indeed a zip file containing HTML, CSS, font, image, and metadata files. I'd argue that that's not meaningfully different to OP's suggestion of a HTML file with all the content inlined, though. It's still a single file grouping everything required together and can be easily edited and read practically anywhere. It has a few advantages over the inlined-content HTML file, too: - You can read the compressed file directly, an epub being typically half the size of the uncompressed files (going by a quick test of 30 randomly-selected files I had on hand). - Storing the actual JPEG, PNG, OTF, etc files inside the zip is more efficient than inlining them as base64 and then making the browser decode them, in terms of both speed and filesize. - While reading an epub, different sections can be a different HTML files, and only one needs to be loaded into memory at a time. This can be irrelevant for smaller things but it can make a big difference sometimes--with pages that include many charts and tables, documentation for graphics libraries that include images and animations for each documented function, etc. - Epub files have native support for highlighting and bookmarking, to keep your place in long documents and share the file with your highlights attached.
50 5y ago
Yes, maybe something like https://portable.fyi/#2021-01-02-pocket-web-books https://portable.fyi/#2021-01-02-pocket-web-books.
AprilArcus 5y ago
I don't see why you couldn't handle images with base64 data urls...
dredmorbius 5y ago
Keep in mind that single integrated book formats are highly viable now. It's in the interest of publishers not to offer them, however. A chief example that comes to mind is the Feynman Lectures in Physics series, which are available online but only in a chapter-by-chapter basis in HTML format. (Quite beautifully formatted, FWIW.) If you want to glue those together into a single integrated whole, you'll have to do that yourself. PDFs and ePubs afford the single-file format.
- judge2020 5y ago
  It makes sense from a DRM standpoint - PDFs and ePub are easy to crack if you offer it at all, so the only way to fix this is to go web-only and assume nobody will want to dig into turning that into a sharable PDF. Bonus points if you make it a SaaS test platform and get universities to buy into it, forcing every student to purchase the 'book' to receive grades.
  - dredmorbius 5y ago
    The multi-page format makes access all the more inconvenient. Copyright status means that anyone who glues together the set will find themselves pursued for infringement. In practice, the question's moot as the Feynman Lectures are available via LibGen, ZLib, and similar resources.
  - rewgs 5y ago
    > Bonus points if you make it a SaaS test platform and get universities to buy into it Surely this exists already? It's good and obvious an idea to not be taken already.
    - LordDragonfang 5y ago
      Multiple times over, yes, which is what the poster was alluding to.
adamddev1 5y ago
That could easily be made into a PWA that people could save and view offline. I've been doing this with create-react-app and markdown files (muuuch bulkier solution) but it's an offline docs-like SPA people can click around with interactive examples and shareable links etc. Seems like offline availability was not a priority for other docs-making tools like docosaurus etc (last time I checked)
- jraph 5y ago
  Please, don't make me run React to read your document, and don't make my device parse Markdown and generate HTML on each visit. This is wasteful. I and the planet should not suffer because you decided to author your book using Markdown (which is a fine format, but my browser does not understand it natively). A virtual book is best served as plain old static HTML pages. Shareable links is indeed an impressive feature, but it has been a given on the Web since 1991, I think we don't need to be impressed by it in 2021. You can add some JS here and there for the few really interactive elements of the document but my browser already has all the features to render documents and links perfectly fine. People have been able to "click around" since 1991 and we never needed to download, parse and execute 2MB of JS for this. Your book is probably big, and I'm probably not reading it in one go, so if it includes images and videos, downloading it all is probably unnecessary and the book is probably best split in several HTML pages. If you want to allow me to consult it offline, that's very kind and noble. Just put a zip file somewhere I can download. Sorry for the rant, but I'm a bit fed up by having to download run megabytes of Javascript I can't control (and even read, because yay, bundles!!) to browse the web, just because.
  - chalupa-man 5y ago
    > If you want to allow me to consult it offline, that's very kind and noble. Just put a zip file somewhere I can download. To play devil's advocate: a majority of web traffic is on phones and tablets now, especially for long-form content where you will frequently see people request a page on a desktop, then request it two minutes later from a phone or tablet where they can read it more comfortably. 99% of mobile users will be happier when a text-heavy site is a PWA that caches itself, rather than a static HTML site that asks them to download a zip file, install an app to work with zip files on their device, unzip it to a folder of hopefully-relevantly-named HTML files, and then browse those, in the process breaking link sharing, link navigation (depending on OS), cross-device reading and referencing of highlights/notes, site search, and so on. Not to mention the limitations imposed on file:/// URIs, like browser extensions not working on them by default, which is a real problem for users relying on them for accessibility (e.g. dyslexia compensation, screen reader integration, stylesheet overrides). A lot of times that won't even be possible on a dedicated reading devices; my ereader will cache PWAs but will not download arbitrary files, if you make your site a PWA I can read it during my commute, if you make it static HTML with a zip file I can't. These are features most users appreciate a lot more than not having to load a 60k JS bundle (current size of React gzipped).
tomjen3 5y ago
That would be perfect for books, but I rather they take advantage of the medium and make the examples interactive: I rather see how the results change when I change the inputs than have it all in one file.

by sxp 5y ago

andyp-kw 5y ago

You're describing PDF files, but unfortunately Adobe didn't invest much time or money into making them interactive with a scripting language.

nextaccountic 5y ago
PDF has a limitation: it defines page size and the layout of everything fixed to this page, and thus can't do responsive layout like HTML can (reorganizing stuff in the page to match the screen size)
- mmh0000 5y ago
  I wouldn't call that a limitation. In fact that is one of the major selling points of the PDF format. The document looks as intended* by the creator on all platforms whether display or print media. * Yes, I know, PDF doesn't -always- do this, but a well designed PDF generally does.
  - Tagbert 5y ago
    True, but the rigid layout is what makes PDF unsuitable for some use cases. It’s main use is to represent a printed page of a very specific size. Anything outside that just requires too much flexibility.
  - vgel 5y ago
    It is a limitation. Anyone who's ever tried to read a PDF journal article on their phone has experienced it. (and don't even get me started on Unicode copy/paste...) HTML can be styled in a fixed layout if desired, and reflowed by a reader mode if needed. PDF can't be styled in a responsive way, and there's no (easily accessible) reader mode equivalent for PDFs. HTML is a far better document format than PDF.
    - bee_rider 5y ago
      A significant advantage of the two column journal format (although still they end up feeling pretty clunky on a phone).
    - dragonwriter 5y ago
      > there's no (easily accessible) reader mode equivalent for PDFs. It’s called Liquid Mode in Reader, and it is, in fact, easily accessible. > HTML is a far better document format than PDF. HTML is better for some things, PDF for others. That's why PDF is widely used on the web when HTML is available.
      - bananamerica 5y ago
        Liquid mode only works we for a subset of PDF files. And sometimes it doesn't work at all.
        dragonwriter 5y ago
        Reader mode only works well for a subset of HTML files, too.
        bananamerica 5y ago
        Yes, of course.
    - deleted 5y ago
      [deleted]
- dredmorbius 5y ago
  Feature. The dimensioning problem isn't PDFs. The dimensioning problem is computer displays. Get yourself an e-ink display of 10" or 13" (standard dimensions offered by the patent-monopoly vendor across multiple OEMs), and discover that online reading of PDFs is 1) quite pleasant (so long as the underlying PDF formatting itself is sane) and 2) vastly preferable to either HTML or "fluid" ePub or Mobi file formats. Book formats developed over about 500 years largely guided by the capabilities and limitations of human eyes and hands. Typical mass-market books range in size from roughly 6" to 12" diagonal measure. Yes, there are smaller and larger formats, these are deviations from the norm and impose compromises for other concerns (portability for smaller formats, resolution for larger ones, typically pictoral or graphical in nature). A 5" or 6" mobile device presents less display area than an index card. Laptop displays are too short to display a portrait-mode document one page at a time, and in almost all cases too small to present a 2-page up display. (You can verify this yourself trivially at the Internet Archive using its BookReader, e.g., https://archive.org/details/UnderstandingPhotoTypesetting/page/n5/mode/2up?view=theater https://archive.org/details/UnderstandingPhotoTypesetting/pa...) When wedding PDFs with an appropriate display technology, the frustrations fixed-proportion PDF display disappear. This does rely on the PDF being dimensioned for a typical book size, though there's considerable flexibility here, and any dimensions from ~6" to well over 12" will tend to be readable, there's no need for precisely matching device to document size. I'm saying this as someone who's long railed against PDFs for documentation. My mind's been changed.
  - LordDragonfang 5y ago
    >Get yourself an e-ink display of 10" or 13" (standard dimensions offered by the patent-monopoly vendor across multiple OEMs), and discover that online reading of PDFs is 1) quite pleasant (so long as the underlying PDF formatting itself is sane) and 2) vastly preferable to either HTML or "fluid" ePub or Mobi file formats. Notably this is not the standard size for most e-ink devices though, on which pdfs are a pain to read. Mobi/epub files, in contrast, are fantastic on my kindle (and on my phone, and on desktop). If your argument has to boil down to "this file format is great if you just buy a specific device for viewing them, and eschew viewing them on any of the other devices you already own and use more frequently", I'd say your argument provides more evidence for the counterpoint than for the one you're arguing. I'm happy you found a good way to consume a fundamentally outdated format, but PDFs are a bad format for the majority of use cases.
Encounter 5y ago
Think about how much worse PDF exploits would be if they did!
asciimov 5y ago
The problem with PDF's has always been the layman can't create them without some expensive Adobe program.
- TylerE 5y ago
  This is categorically false. There have always been other tools for producing PDF (E.g. TeX) and there are also tons of free converters, print-to-PDF drivers, etc.
  - LordDragonfang 5y ago
    I have never seen anyone I would remotely describe as a layman using TeX.
- garbagecoder 5y ago
  macOS hasn’t had this problem in 20 years.
  - elcapitan 5y ago
    Yes, it's literally just Print dialogue -> Save as pdf. Also worth noting that the PDF preview on the Mac has very nice simple editing capabilities to combine pages, delete pages, crop etc.
- samus 5y ago
  Any modern office suite (MS Office, Libreoffice, Google Apps) has PDF export. Many image editing applications can do it too.
dragonwriter 5y ago
> but unfortunately Adobe didn't invest much time or money into making them interactive with a scripting language. Yes, they did. (Non-Adobe readers often don't support JS, though some do, but Adobe definitely built the support for interactivity.) Also 3D content and a lot of other things most people probably aren't aware of, because they are peripheral to the common use cases of PDF.
nine_k 5y ago
Emphatically no. HTML can be responsive, like an electronic document should. PDF was designed to faithfully represent paper, and it has all the fluidity and customizability of a stack of printed paper. It's also completely anti-semantic: it has no document structure beside pages, and each page just describes how to put ink onto paper. I think that the principal application area of PDF is just that: to represent paper, for printing purposes. For everything else, it's not exactly great.
naikrovek 5y ago
> Adobe didn't invest much time or money into making them interactive with a scripting language. yes they did. JavaScript, though I have no idea if there is a DOM or anything like it. pdf is kinda messed up in ways like that.
zffr 5y ago
PDFs actually have some support for javascript! I don't know any serious use for it and some PDF viewers refuse to support it (ex: Apple's Preview app), but it does exist.
- jraph 5y ago
  Form verification for instance, if I remember correctly.
- tonyedgecombe 5y ago
  PDF would have probably been better without it but Adobe couldn't resist adding new features so they could flog more copies of Acrobat.

terpimost 5y ago

And images can be also embedded. These days you can fake a real URL completely on a fronted side.

laumars 5y ago
I absolutely hate it when people do this.
www_harka_com 5y ago
What do you mean by faking a real URL on frontend side? I'm genuinely interested.

BeefWellington 5y ago

MHT did this 20 years ago and got all but abandoned (probably for good reasons).

adzm 5y ago
Interestingly, the support for mht/multipart is still there in Chrome and Firefox; or at least it was relatively recently. However it only works for files and not when accessing an mht file over http. The format itself is relatively simple.
- BeefWellington 5y ago
  Yeah it's pretty much the MIME email format as a container for a webpage. A lot of the issues "solved" in modern frameworks could have been addressed by using this, but instead things went a different path.
gildas 5y ago
Web bundles is supposed to replace it, cf. https://web.dev/web-bundles/ https://web.dev/web-bundles/

tambourine_man 5y ago

You can even embed images with a src converted to base64. This method even works well with the back/forward browser buttons, something that a naive show/hide JavaScript solution wouldn’t.

gildas 5y ago
Or even store the whole page as a self-extracting zip file. This page is a zip file: https://gildas-lormeau.github.io/ https://gildas-lormeau.github.io/

zozbot234 5y ago

Isn't that what .epub is for?

AdmiralAsshat 5y ago

I think you've just described an EPUB?

tingletech 5y ago
I thought epub files were basically zip archives of all the required files
- m-p-3 5y ago
  You could make an ePub of a single HTML file with all the binary blobs embedded.
- dredmorbius 5y ago
  ePub, as with PDF, is a container-file format. (A ZIP file with a specified structure.) If you want to consider that single or multiple files ... quickly veers into semantics.
- ryantriangles 5y ago
  An epub is indeed a zip file containing HTML, CSS, font, image, and metadata files. I'd argue that that's not meaningfully different to OP's suggestion of a HTML file with all the content inlined, though. It's still a single file grouping everything required together and can be easily edited and read practically anywhere. It has a few advantages over the inlined-content HTML file, too: - You can read the compressed file directly, an epub being typically half the size of the uncompressed files (going by a quick test of 30 randomly-selected files I had on hand). - Storing the actual JPEG, PNG, OTF, etc files inside the zip is more efficient than inlining them as base64 and then making the browser decode them, in terms of both speed and filesize. - While reading an epub, different sections can be a different HTML files, and only one needs to be loaded into memory at a time. This can be irrelevant for smaller things but it can make a big difference sometimes--with pages that include many charts and tables, documentation for graphics libraries that include images and animations for each documented function, etc. - Epub files have native support for highlighting and bookmarking, to keep your place in long documents and share the file with your highlights attached.

50 5y ago

Yes, maybe something like https://portable.fyi/#2021-01-02-pocket-web-books https://portable.fyi/#2021-01-02-pocket-web-books.

AprilArcus 5y ago

I don't see why you couldn't handle images with base64 data urls...

dredmorbius 5y ago

Keep in mind that single integrated book formats are highly viable now. It's in the interest of publishers not to offer them, however. A chief example that comes to mind is the Feynman Lectures in Physics series, which are available online but only in a chapter-by-chapter basis in HTML format. (Quite beautifully formatted, FWIW.) If you want to glue those together into a single integrated whole, you'll have to do that yourself. PDFs and ePubs afford the single-file format.

judge2020 5y ago
It makes sense from a DRM standpoint - PDFs and ePub are easy to crack if you offer it at all, so the only way to fix this is to go web-only and assume nobody will want to dig into turning that into a sharable PDF. Bonus points if you make it a SaaS test platform and get universities to buy into it, forcing every student to purchase the 'book' to receive grades.
- dredmorbius 5y ago
  The multi-page format makes access all the more inconvenient. Copyright status means that anyone who glues together the set will find themselves pursued for infringement. In practice, the question's moot as the Feynman Lectures are available via LibGen, ZLib, and similar resources.
- rewgs 5y ago
  > Bonus points if you make it a SaaS test platform and get universities to buy into it Surely this exists already? It's good and obvious an idea to not be taken already.
  - LordDragonfang 5y ago
    Multiple times over, yes, which is what the poster was alluding to.

adamddev1 5y ago

That could easily be made into a PWA that people could save and view offline. I've been doing this with create-react-app and markdown files (muuuch bulkier solution) but it's an offline docs-like SPA people can click around with interactive examples and shareable links etc. Seems like offline availability was not a priority for other docs-making tools like docosaurus etc (last time I checked)

jraph 5y ago
Please, don't make me run React to read your document, and don't make my device parse Markdown and generate HTML on each visit. This is wasteful. I and the planet should not suffer because you decided to author your book using Markdown (which is a fine format, but my browser does not understand it natively). A virtual book is best served as plain old static HTML pages. Shareable links is indeed an impressive feature, but it has been a given on the Web since 1991, I think we don't need to be impressed by it in 2021. You can add some JS here and there for the few really interactive elements of the document but my browser already has all the features to render documents and links perfectly fine. People have been able to "click around" since 1991 and we never needed to download, parse and execute 2MB of JS for this. Your book is probably big, and I'm probably not reading it in one go, so if it includes images and videos, downloading it all is probably unnecessary and the book is probably best split in several HTML pages. If you want to allow me to consult it offline, that's very kind and noble. Just put a zip file somewhere I can download. Sorry for the rant, but I'm a bit fed up by having to download run megabytes of Javascript I can't control (and even read, because yay, bundles!!) to browse the web, just because.
- chalupa-man 5y ago
  > If you want to allow me to consult it offline, that's very kind and noble. Just put a zip file somewhere I can download. To play devil's advocate: a majority of web traffic is on phones and tablets now, especially for long-form content where you will frequently see people request a page on a desktop, then request it two minutes later from a phone or tablet where they can read it more comfortably. 99% of mobile users will be happier when a text-heavy site is a PWA that caches itself, rather than a static HTML site that asks them to download a zip file, install an app to work with zip files on their device, unzip it to a folder of hopefully-relevantly-named HTML files, and then browse those, in the process breaking link sharing, link navigation (depending on OS), cross-device reading and referencing of highlights/notes, site search, and so on. Not to mention the limitations imposed on file:/// URIs, like browser extensions not working on them by default, which is a real problem for users relying on them for accessibility (e.g. dyslexia compensation, screen reader integration, stylesheet overrides). A lot of times that won't even be possible on a dedicated reading devices; my ereader will cache PWAs but will not download arbitrary files, if you make your site a PWA I can read it during my commute, if you make it static HTML with a zip file I can't. These are features most users appreciate a lot more than not having to load a 60k JS bundle (current size of React gzipped).

tomjen3 5y ago

That would be perfect for books, but I rather they take advantage of the medium and make the examples interactive: I rather see how the results change when I change the inputs than have it all in one file.