Why we use plugins anyway? I don't get it

So I wan't to know something, I using Joplin quite a while of time, but I always think about plugins.
A lot of good and good functionality is adding by plugins developers.

Why? For what purposes? Plugins are not make the Joplin more heavy loaded and slower work?

I mean maybe it was good on low level languages, but on electron and react-native is not a good idea(for me), its like using vscode with plugins, more plugins more usage of resources.

Why we can't add the functionallity that plugins provide to Joplin itself and ask quite a nice for plugins developers to implement those functionality to Joplin.

I don't mean to be harsh to anyone here.

From what I read here: It’s all about capacity for maintenance, I think. Once a plugin is an integrated part of Joplin core, it has to be maintaint by the core team, which is really, really small from what I know.

If a plugin is outdated…it’s maybe not nice, but no dealbreaker for the Joplin core as a whole.

And is it perhaps easier to add a plugin, than to integrate a function into the main code, if you as a developer just like to contribute this one desired functionality, that you need?


If only a fraction of the user base needs a certain feature (and there are loads of plugins that are for features like that) then it doesn't make sense to complicate the whole app.

There is always the possibility to eventually move a plugin's functionality into core. But I don't think that has happened yet.


There is another aspect not mentioned ... speed. Each plugin or feature adds to the overhead of the program. And if you get a lot of them, you can see it start to affect your system. With plugins, you can install what you need, and turn it off or uninstall when you don't to save resources. If it was internal, you may not have this option.


Exactly. And I can't tell you how many times in FOSS they will add a new feature to the core code and it's met with a chorus of "Give us the option to disable!!!" :joy:



IMHO there is only one plug-in so far that has the functionality that I believe would be better as part of the core package. That is the Simple Backup plug-in. I feel that users should have the facility to backup from the point of install rather than have to learn that plug-ins exist and then go and search to see if something is available to make backups.


I completely agree. That one (backup) was the one plugin, that I was thinking of being a core feature naturally, when writing my last message here.


I see plugins as a way to allow those 2 or 3 people that want a feature to have it without forcing everybody else to slow down their system. I've seen Joplin go from 94MB to today's 234MB and a lot of that may be due to new "features" that people have requested. Pretty soon it will move into the Evernote class where it will do everything, it will just take ten minutes to do anything. I love plugins because I can ignore those I don't need.


Your words have a lot of logic here. If the core functionality will grow, the Joplin will be eating resources as good browser.

But this is electron and react native frameworks, and this is the problem with that.
It's not resource optimized that all.

But can we create the option to turn on and off the options? Like in native android apps on java\Kotlin?
If I need that option, I will on, if not it will off.

That what I talking about. A perfect plugin functionallity that indeed needed be in Joplin core. But sometimes it scares me how the Joplin is growing fast with electron and react native

On the flip side, overhead from a feature implemented as a plugin is higher compared to the same functionality added to the app itself.

But then I don't have to use the plug-in whereas I would be stuck with the extra size of Joplin core. If every plugin was built into Joplin there wouldn't be many systems that could run it. Keep the plugins, keep the core size down and the speed up.

Sounds like given the code maintenance requirements, the efficiency argument might justify incorporating into the main app only those plugins with very high penetration. That might be a few at most; though one could argue that plugin penetration isn't very high because many new users are simply unaware they exist.

But can we find a good between options?
I mean not increase Joplin core size and in another case implement plugin functionallity to Joplin without increasing resources?
Is this can really be done?

A sort of middle-ground might be Joplin's "Welcome" note, that thing that gets read about as often as the typical "Terms of Service" or "Privacy Policy" document.

Determine the most popular plugins (how is a big question) and prominently bring them up on the opening screen. Promote the ability to do backups "with the plugin "xyzback" or the ability to locate left-threaded screws with the fantastic "Screw Locater" plugin or the "never lose that pen again" Pen-Finder plugin or whatever.

If people are complaining that Joplin can't do something, and there's a plugin that solves the issue, put the solution front and center when Joplin starts up for the first time. Bring the concept of plugins to the attention of newbies and solve two problems. One, the "it doesn't do this" complaint and two, help the first-time user get comfortable with the flexibility Joplin offers via an architecture that allows the expansion plugins afford. A quick link to the plugin page on the initial splash might help. At the very least it would allow Joplinites to say "It's your own fault, you didn't read the opening screen, did you?"


For sure there is a huge need for education regarding plugins. No shortage of threads here and on r/Joplin where people are asking for a feature that already exists via plugin. And for every person who asks on a forum about a 'missing' feature, there are likely many others who assume Joplin doesn't have that particular feature, and either live without it or move on to another note app.

This is then exactly like the current situation with plugins

Also, how does it get decided which plugins remain plugins and which get integrated?

1 Like

I find this a slightly odd take seeing as the application that invented Electron, Atom, relies on packages for literally everything - the settings page is a package, the tree-view is a package, the command palette is a package. If anything this is exactly how Electron was meant to be used from the start.


I don't think anything has gotten integrated yet, but others would know better. I believe the backup plugin was the strongest candidate and it hasn't been added to core yet.