> HTML can easily be offline-able. Base64 your images or use SVG, put your CSS in the HTML page, remove all 2-way data interaction, basically reduce HTML to the same performance as PDF and allow it to be downloaded.
I built a tool for this exact purpose[0] since the HTML specification and modern browsers have a lot of nice features for creating and reading documents compared to PDF (reflow and responsive page scaling, accessibility, easily sharable, a lot of styling options that are easy to use, ability for the user to easily modify the document or change the style, integration with existing web technologies, etc.). In general I would rather read an HTML document than the PDF document since I like to modify the styling in various ways (dark theme extensions in the browser for example) which may be hard to do with a PDF, but its more of a personal preference. Some people will prefer that the document adjusts to the screen size of the device (many HTML pages), and others will prefer the exact same or similar rendering regardless of the screen size (PDF).
Either way, kind of a fun idea making a website using just PDFs. Not the most practical choice, but fun none-the-less.
There is also a similar program called HyperFiler[0]* that bundles web pages into single HTML files with a few more options such as a headless chromium transport option, built in minifiers, page sanitizers, and an option to grayscale the output pages, among other options. It's TypeScript based and has an programmatic API to customize the bundling process as well.
Same here, I think small comments every 3-10 lines adds a lot of value, especially to large code bases. Being able to quickly scan through comments visually when you only need a high level overview of a chunk of code can take a 5 minute task of reading and understanding 50 lines of code into a 15 second task of reading and digesting a few small comments.
Also, I'm curious to see how your experience was working on the firefox code base. I haven't checked out the code base myself, but have built from source a few times. Curious to see how the Rust progress has been going on the code base and which parts of firefox are currently implemented in Rust.
Firefox is still largely C++ and Javascript and that's not going to change anytime soon. But it makes sense, because mostly you're adding or changing stuff that's already deeply connected with all the existing code.
I think you see Rust when there are really big projects that can be treated as a library. For instance the network team is writing their QUIC implementation in Rust – called neqo – and I can imagine that this was possible because it's low level enough and separate enough from the rest of Firefox.
It's of course also a resourcing question. For instance the download-manager code in Firefox is a big, big mess and it's not really owned by anyone. But it works, is safe, and handles a lot edge cases. Rewriting this thing (even again in Javascript) would be an enormous effort, and that's true for so many parts of the code base that might benefit from rewrites. A rewrite would be nice, but there probably will always be more important things to work on.
Wow, this is an amazing collection of banners! For anyone have trouble with the page loading all of the gifs, I bundled all 4 of the pages into a single, massive 33 MB HTML page with all 3000+ of the GIFs encoded into data URIs. Here's the link, and all credit goes to the dabamos.de website owner for creating the collection:
A project that I created (written in TypeScript) to bundle web pages into single HTML files with the goal of producing as small of bundles as possible. Also includes a rich set of features to customize pages (around 100 command line arguments are available), and some other interesting features, such as the ability to inject a Flash player into the bundled page that will run flash content bundled in the page.
(The comment there that removing this "is going to help increase speed significantly in the future" is pure BS. If anything, user stylesheet functionality was handled in native code --- just adding another CSS to the page --- which makes it far more efficient than going through the whole JS/extensions route.)
Ironically, IE11 is the last MS browser to support user stylesheets (Tools->Options->Accessibility) but Edge doesn't.
Even in Firefox, the fact that it's named "toolkit.legacyUserProfileCustomizations.stylesheets" is ominous.
The Internet is becoming more and more user-hostile, and it's not just websites who are responsible.
>The Internet is becoming more and more user-hostile, and it's not just websites who are responsible.
That's because the webbrowser has been pushed away from hyperlinked documents viewer, to essentially a virtual machine running untrusted code from anywhere.
It's probably Googles fault somehow. They seem determined to ruin everything.
Issue asking for reintroducing native user style sheets in Chrome, with precise argumentation and long discussion. Does not seem likely to be heard, but symbolical starring doesn't hurt…
Reminds me of those times when I built a website that doesn't have a functioning mobile view, put it on reddit, and it turns out that everybody is mobile
You could probably make a bookmarklet to pull the stylesheet from github and add it to the document stylesheets. Maybe using the new Stylesheet constructor?
Heres a fun Firefox fact. Firefox handles audio/media files differently than chrome. Since it has a small market share, it becomes a rather annoying lose-lose: either spend a bunch of time to support Firefox for the ~20 people that will access your site using Firefox, or you don't support Firefox.
It's a shame that laziness is more important than interoperability. Part of the life of frontend or webdev is dealing with compatilibity issues, and it has been that way since forever. If you got into this biz thinking you could do that work and avoid those problems you thought wrong.
Laziness? Don't you mean unpractical and financially unviable? If I support Firefox do I support Edge, Opera, Android Webview, UC Browser? Explain how pragmatic prioritization can constitute as laziness.
you know it! It had a sleek and modern look for the time, while still having the simplicity and user-friendliness of MS Paint from Win 95/98. really wish this version of paint was still supported in Win 10
A sleek and modern look for the time? The basic UI was already over a decade old! (paintbrush)
It's cool that you like it, but that's a surprising way to describe it. As I recall (as a user of windows 3.1, 95, ME and XP), the consensus was that Paint was a retro holdover, like Minesweeper and Solitaire. People appreciated it in a kitschy retro way.
I wouldn’t be surprised if a stripped-to-the-bone installation of WinXP in a VM, running only Paint, is lighter on system resources than Electron running this.
A very basic XP install with a GUI can fit in 20-30 MB[1][2][3], using minlogon, but even with a "standard" Winlogon it should be below 50 MB, so it surely would take less disk space than the hypothetical 100 MB electron based version.
It can be packed very easily actually! It is a single HTML file, so you can easily embed it into an electron app or a webview if you wanted. Only problem is it would bring the total size to ~100 MB instead of ~1 MB, and would be tough to make it a single .exe file.
This is awesome! I Still use Paint.Net in my VMWare emulator. There's some things in Paint.Net I really like including Crop to selection and things involving layers. If you ever plan to expand to include that, I'd be all ears!
I built a tool for this exact purpose[0] since the HTML specification and modern browsers have a lot of nice features for creating and reading documents compared to PDF (reflow and responsive page scaling, accessibility, easily sharable, a lot of styling options that are easy to use, ability for the user to easily modify the document or change the style, integration with existing web technologies, etc.). In general I would rather read an HTML document than the PDF document since I like to modify the styling in various ways (dark theme extensions in the browser for example) which may be hard to do with a PDF, but its more of a personal preference. Some people will prefer that the document adjusts to the screen size of the device (many HTML pages), and others will prefer the exact same or similar rendering regardless of the screen size (PDF).
Either way, kind of a fun idea making a website using just PDFs. Not the most practical choice, but fun none-the-less.
[0] https://github.com/chowderman/hyperfiler