Improving UI response

Progress Report #2

Now, milestone 2 is nearing completion, and PR has been made. It's discussed here.


The purpose of Milestone 2 is to reduce overheads using SideBar. The times of both note switchings using SideBar (wihin-a-notebook and between-notebooks) are reduced by 370-490 msec (35-37%). So, it seems to have served its purpose.


Milestone 1 is merged in v2.8.3.


Progress Report #3

Now, milestone 3 is half done, and 4 PRs have been made. It's discussed here.


The purpose of the first half of Milestone 3 is to reduce frequent but fine overheads and re-rendering. In general, about 20% of time is reduced.


Progress Report #4

Now, milestone 3 is nearing completion, and finally, 9 PRs have been made. It's discussed here.


The chart shows:

  • From milestone 2 to 3, in general, about 40% of time is reduced.
  • The final performance is about 2-4 times faster than the performance before this activity.

I've prepared a demo branch for those who would like to try the improved UI response.
(Note: For those who can build a binary from source codes)

It is based on the latest stable Joplin version 2.7.15 and contains 11 PRs in the above three milestones.




The result of this improvement activity is illustrated here.

The chart is based on the above survey summary chart. It shows where the performance of the reference PC (Core i5-4670, CPU Mark=5403, Win10) (white circles) is in the range of user PCs. Simultaneously, it shows where the improved performance of the reference PC (black stars) is.

According to the chart, it can be estimated that most PCs will have acceptable performance (less than 1 sec response) by applying PRs proposed in this activity.


Tested it with the patched repo, and the response speed improvement is obvious with 9+ plugins. Amazing work! I just wondered why obsidian is much smoother than Joplin when switching notes and found this post.

Hope all the PRs can be merged as soon as possible since I cannot build the *.dmg package successfully.


Just some tips for others who want to build the *.dmg package on macOS:

If you face the following error message during yarn run dist: gyp: name 'openssl_fips' is not defined while evaluating condition 'openssl_fips != ""' in binding.gyp while trying to load binding.gyp, then you can try to build with node@16 instead.

I also tried to merge all the commits in 2.8.0+ version to the patched repo. Most of the conflict files are easy to solve except for app-desktop/gui/NoteList/NoteList.tsx. It seems this file is almost completely rewritten.

Tested it with the patched repo, and the response speed improvement is obvious with 9+ plugins. Amazing work!

Thanks for your impression report!

I just wondered why obsidian is much smoother than Joplin when switching notes and found this post.

As you said, current Joplin seems to be slower than other note-taking apps. I've also heard opinions like "Why is Joplin so much slower than other Electron apps?"
However, it can be at least as fast as other apps.

Quick UI response is a very important factor for note-taking apps. When compared to other apps, I'm concerned that the current slowness of Joplin's UI is detracting from its appeal.


A new demo branch is prepared for those who would like to try the improved UI response.

It is based on the latest pre-release Joplin version 2.8.8 and contains 11 PRs in the above three milestones.

The demo based on 2.7.15 is still available here.



Now, 2.8.8 becomes the latest stable version, and this (2.8.8) improvement demo can be used as is.


It's been amazing 2 months since I tried quick-slim branch and I've decided to share my feedback with y'all :relieved:

For many, performance boost in this branch might seem minor thing, but for me personally, it made me truly appreciate so much more of Joplin.

Particularly, I was able to install and use a lot more of our great plugins. With little incremental impact on performance that felt quite liberating!

Since it got snappier, I noticed that I naturally spend more engaged time with Joplin: writing more detailed notes, organising notebook tree, saving and extending documentation. It very nearly became my go-to application for anything of substance. In this mindset, like many other members of our community, I even started to write little scripts and snippets helping me achieving my goals.

In social aspect, this improvement made me sure that I can recommend Joplin to older folks who often have quite outdated hardware and at the same time, are easily put off by minor inconvenience.

In conclusion, I want express my gratitude to all contributors: you're truly making my life and lives of my loved ones, easier and better. Thank you :clap:

Testing notes

Since changes in quick-slim branch involved switching between notes, notebooks and reducing rendered updates, I've been attempting to force it to get stuck on previously rendered note.

How: deleting notebook with currently focused note, transition from empty notebook, deleting tags, deleting last note in a tag list, using go-to, using favourites plugin, resolving conflicts, using internal links with # ancors and external links

Result: all passed

I've stumbled upon some flaky weirdness with notelist focus shortcut, but couldn't either localise or attribute it to the specific Joplin version.


when merge? :wink:

Thank y'all so much for all your contributions! :pray:

@graphit0, thank you for your great user impression review and test report!

Your points are very spot-on. As you wrote, this activity drastically changes Joplin's UX. That is, it delivers higher levels of comfort, usability and extensibility.

It has been six months since I first started this activity. I've been using this quick-slim-note branch since that time, and I can no longer imagine using Joplin without it.

I'm looking forward to sharing this wonderful experience with all users.


I am not a Joplin committer, so I can't answer the question directly.
Generally speaking, since Joplin is a volunteer-based OSS, users' activities play great roles. User voices will raise the priority, and user supports will speed up the merging process.

Code reviewing, user testing, bug reports, and user impression reports will all be helpful. Especially, code reviewing is essential.
I think @graphit0's recent post is a great example of such contributions.


Stable v2.8.8-based demo now includes PR#6640 fixing issue#6639.


Now, 5 PRs of all 11 PRs are merged, and some part of this improvement can be tried in v2.9.1.


Just wanted to say thank you for all the performance improvements. Among others, I use Joplin on quite underpowered hardware (e.g. Intel Atom tablets/netbooks) and the speed benefits are definitely noticeable on those :slightly_smiling_face:.

Just out of curiosity, as this isn't exactly related to the UI, do you think there's anything that could be done in terms of performance to improve the launch speed of the application? At the moment, Joplin requires quite a lot of I/O and CPU power just to start, which often takes as much as ~30 seconds or so on the slow hardware.


Thank you so much ken1kob. These speed improvements are much needed.

Yes on pre-release 2.9.1, mine take ~35 seconds with balanced power plan and 8-9 plugins. Without plugin about ~28 seconds.
In comparison Firefox take ~2 seconds to start.

1 Like