“Lossless” has a specific meaning, that you haven’t lost any data, perceptible or not. The original can be recreated down to the exact 1s and 0s. “Lossy” compression generally means “data is lost but it’s worth it and still does the job” which is what it sounds like you’re looking for.

With images, sometimes if technology has advanced, you can find ways to apply even more compression without any more data loss, but that’s less common in video. People can choose to keep raw photos with all the information that the sensor got when the photo was taken, but a “raw” uncompressed video would be preposterously huge, so video codecs have to throw out a lot more data than photo formats do. It’s fine because videos keep moving, you don’t stare at a single frame for more than a fraction of a second anyway. But that doesn’t leave much room for improvement without throwing out even more, and going from one lossy algorithm to another has the downside of the new algorithm not knowing what’s “good” visual data from the original and what’s just compression noise from the first lossy algorithm, so it will attempt to preserve junk while also adding its own. You can always give it a try and see what happens, of course, but there are limits before it starts looking glitchy and bad.

I know TiddlyWiki quite well but have only poked at Logseq, so maybe it’s more similar to this than I think, but TiddlyWiki is almost entirely implemented in itself. There’s a very small core that’s JavaScript but most of it is implemented as wiki objects (they call them “tiddlers,” yes, really) and almost everything you interact with can be tweaked, overridden, or imitated. There’s almost nothing that “the system” can do but you can’t. It’s idiosyncratic, kind of its own little universe to be learned and concepts to be understood, but if you do it’s insanely flexible.

Dig deep enough, and you’ll discover that it’s not a weird little wiki — it’s a tiny, self-contained object database and web frontend framework that they have used to make a weird little wiki, but you can use it for pretty much anything else you want, either on top of the wiki or tearing it down to build your own thing. I’ve used it to make a prediction tracker for a podcast I follow, I’ve made my own todo list app in it, and I made a Super Bowl prop bet game for friends to play that used to be spreadsheet-based. For me, it’s the perfect “I just want to knock something together as a simple web app” tool.

And it has the fun party trick (this used to be the whole point of it but I’d argue it has moved beyond this now) that your entire wiki can be exported to a single HTML file that contains the entire fully functional app, even allowing people to make their own edits and save a new copy of the HTML file with new contents. If running a small web server isn’t an issue, that’s the easiest way to do it because saving is automatic and everything is centralized, otherwise you need to jump through some hoops to get your web browser to allow writing to the HTML file on disk or just save new copies every time.

If you run the Node.js version, that’s all handled for you. It’s only if you want to do the party trick of keeping it all in a single HTML file that you need to worry about a plugin or anything like that. And even then, the server version exports to a standalone HTML file with one or two clicks.

Edit to add: it’s the only substantial Node package I’ve ever seen with zero dependencies. Very lightweight and simple to run.

OPML files really aren’t much more than a list of the feeds you’re subscribed to. Individual posts or articles aren’t in there. I would expect that importing a second OPML file would just add more subscriptions, but it’d be up to the reader app to decide what it does.

There just isn’t much use for an approach like this, unfortunately. TypeScript doesn’t stand alone enough for it. If you want to know how functions work, you need to learn how JavaScript functions work, because TypeScript doesn’t change that. It adds some error checking on top of what’s already there, but that’s it.

An integrated approach would just be a JavaScript book with all the code samples edited slightly to include type annotations, a heavily revised chapter on types (which would be the only place where all those type annotations make any difference at all, in the rest of the book they’d just be there, unremarked upon), and a new chapter on interoperating with vanilla JavaScript. Seeing as the TypeScript documentation is already focused on those exact topics (adding type annotations to existing code, describing how types work, and how to work with other people’s JavaScript libraries that you want to use too), you can get almost exactly the same results by taking a JavaScript book and stapling the TypeScript documentation to the end of it, and it’d have the advantage of keeping the two separate so that you can easily tell what things belong to which side.

I use TiddlyWiki for, well, a bunch of my projects, but primarily for my task management. You can use it as a single HTML file, which contains the entire wiki, your data, its own code, all of it, and of course use it in any browser you like. Saving changes is a bit of a pain until you find a browser extension or some other way of enabling more seamless editing than re-saving the edited wiki as another single HTML file, but there are many solutions to that as described on their site above.

The way I use it, which is more technical but also logistically simpler, is by running their very minimal Node.JS server which you can just visit and use in any browser which takes care of saving and syncing entirely.

The thing I like about TiddlyWiki is that although on its surface it’s a quirky little wiki with a fun party trick of fitting into an HTML file, what it actually is is a self-contained lightweight object database with a simple yet powerful query language and miniature front-end web development environment which they have used to implement a quirky little wiki. Each “article” is an object that is taggable and has key/value data, and “widgets” can be used in the text to edit and display that data, pulling from the “database” using filters. You can use it to make simple web apps for yourself and they come together very quickly once you know what you’re doing, and the entire thing is a demonstration of a complex web app that is also possible. The wiki’s implemented entirely using those same tools, and everything is open for you to tweak and edit to your liking.

I moved a Super Bowl guessing/fake gambling game that I run from a form and spreadsheet to a TiddlyWiki and now I can share an online dashboard that live updates for everyone and it was decently easy to make and works really well. With my task manager, I recently decided to add a feature where I can set an “agenda” value on any task, and they all show up in one place, so I could set it as “Boss” and then quickly see everything I wanted to bring up in our next 1 on 1 meeting. It took just a few minutes to add the text box to anything that gets tagged “Task” and then make another page that collected them all and displayed them in sections.