4 ms·
I'm fully on board with the author's "I want to replace PDF" sentiment. It's true that running code in the document has some downsides, but the vast majority o
by mr_mitm 3y ago
I'm fully on board with the author's "I want to replace PDF" sentiment.
It's true that running code in the document has some downsides, but the vast majority of people does it all the time in their browsers. And it comes with tremendous upsides. Just imagine large amount of data presented in interactive tables which can sort, filter and export or interactive graphs inside the document. We already use HTML+JS so much, why should we stop at documents? Yes, they can't be printed, but in my observation less and less people even own a printer these days, and I see no reason why this trend should not continue. I bet the future will be mostly living, interactive documents.
It's funny that I just mentioned this in the other thread [1], but I also felt that there is a need for a format that is self-contained and widely supported by standard software (by which I mean browsers). A well-specified open format would be great, but until then I tackled the self-containedness problem with JS and wrote a Python script that zips and bundles all assets and embeds them as a SPA into one HTML file [2]. The focus is on Sphinx docs but it should work in general with all distributed HTML docs.
[1] https://news.ycombinator.com/item?id=39138444 https://news.ycombinator.com/item?id=39138444
[2] https://github.com/AdrianVollmer/Zundler https://github.com/AdrianVollmer/Zundler
- fodkodrasz 3y ago> It's true that running code in the document has some downsides, but the vast majority of people does it all the time in their browsers. This probably has to do something with them having nothing to do, as the big companies managed to convince the frontend dev community that the single best thing to generate layout is on the client machine on the fly. Of course they did it so the users will have a hard time selectively blocking the layout scripts from the ad/spyware most contemporary (web)software development is about. This led us to the point where saving (or God forbid printing!) an article needs a lot of effort in many cases. My observation is: when I need to go to work on the field, I need printed documents. Printed documents don't need firmware updates, their batteries don't run out, and no, I don't need interactivity in documents. Self contained HTML is a good - and necessary - step, but interactivity and executable code is not something we usually need in documents, I only saw somewhat legit need for it on corporate abomination of documents (and some teaching materials possibly).
- jxdxbx 3y agoI understand all this but there needs to be a simple format for just regular books without all this complication. I thought that’s what ePubs were for. What I want it basically an ebook format that is mostly zip files of plain text.
- mr_mitm 3y agoWhat are you missing in epub?
- jxdxbx 3y agoSimplicity? A guarantee that the file will be readable in 20 years? Project Gutenberg still treats plain text as the default format for a reason.
- velcrovan 3y agoThe ePub standard is 17 years old, it consists of HTML which is 31 years old and CSS which is 27 years old, packaged in ZIP format which is 34 years old, and all are still in widespread active commercial use and very easy to write parsers for. I think you'll have problems with the physical media you use to store your plain text files before you ever have problems finding software to read ePub file contents.
- larme 3y agoIt's just a fucking book. Don't push your shits like js or SPA or d3 or webgpu to a fucking book. I just want to read it like a dead tree book.