I can imagine many Joplin users are also using different read-it-later applications, and I would like to know your workflow of using those together with Joplin.
For example, do you try to centralize archiving all notes and articles in one place (Joplin)? Or do you distinguish between content types and use Joplin for note-taking and read-it-later applications for reading and archiving articles?
I am using Wallabag, an excellent self-hosted replacement for Pocket/Instapaper, and I am figuring out which strategy to follow.
Full articles scraped to Joplin can help keep the entire knowledge base in one place, but it may also clutter the notes' workspace. On the other side, keeping to separate archives for notes in Joplin and useful reference articles in Wallabag complicates keeping track of everything.
Also, Wallabag allows highlighting text in the articles, but the Joplin web clipper won't pick up those highlights when storing as a simplified page.
diibv, thanks for sharing. I'm also curious about this, and before I posted the question myself, I came across your post asking the same thing I had in mind I like your idea of using Joplin for notes about the articles, while keeping the articles in Wallabag, perhaps with an http link to Wallabag in the Joplin note. I agree though it does seem to get a bit complicated to track that way.
For myself, I use Joplin in part for a Getting Things Done-style to-do list system, which includes things I intend "to read". But I've also used Wallabag as my read-it-later app for years, and love it. So now I'm sort of torn, and in practice so far, I'm keeping "to-read" lists in both Wallabag and in Joplin, in various forms. My organizing system is still a little fuzzy in this area.
I'm not sure exactly what I'll end up deciding to do, but I agree it definitely seems like there's room for exploration, and possibly improvement, in the workflow for people like us who use Joplin as well as read-it-later apps.
I'm also tempted to imagine what a (hypothetical) Joplin plugin might do. I'm not sure about Pocket or others, but Wallabag provides a pretty good REST API that already several apps/browser plugins use to integrate with Wallabag. In theory, I suppose that using this API, a Joplin plugin might provide features to e.g. view/render and update your Wallabag articles in full, directly from within Joplin (including the Wallabag annotations, it looks like). I am not sure what the limitations would be, having no experience with writing Joplin plugins nor using the Wallabag API myself. But it seemed like an interesting thought to maybe explore further at some point.
Hiya.
I'll admit right away that my setup is a bit of a twelve-headed hydra, so beware.
I've tried Wallabag years ago, imported 12k articles, then stopped using it because I didn't like it. That... wasted a lot of time.
The relevant part of my setup is: I use Pocket as the read-it-later app, I use Joplin for notes, and I use Archivebox for link archival. I also have it set up in a way that when I add something to Pocket (among others), a that link gets automatically syndicated and archived in Archivebox.
My rationale is that I do want to keep copies of the things I've read, but realistically, I won't need to access most of them anytime soon. If something is important enough for me to take notes, I want it in Joplin, within easy reach.
Sometimes when there's a lot in an article, or if I think I might need to access it often, I scrape it to Joplin, and add highlights if needed. (Hint: the ==mark== syntax is handy here!)
Two more things to point out:
yes, searching through the entire dataset is impractical for me ATM. Since I also have other data stores, I'm currently thinking about building a universal search that would work over all of them. But yes, this is currently a drawback, though not one I struggle with.
One thing that annoys me the most when scraping to Joplin is that the web pages often have lots of tiny images, which creates lots of tiny resources in Joplin, which then take up space and sync time. Not much I can do about that at ATM, I guess.