Are you really going to use electron for Zotero?


On this forum thread we can learn that Zotero will move to electron!msg/zotero-dev/yy4-q_ZUA4M/dcFYzCWTDAAJ

Is this a definitive choice? I used a couple of electron app, and they didn't feel right: slow to start, UX feel strange, not accessible. I guess it's stuff that can be fixed but that doesn't come for free.

Mainly the memory footprint is insane. Also it seems very strange to launch a Chrome browser for each electron app.

Why not use Qt Even Tk seems saner than electrons.

I'm also not sure electron will still be a big thing in 5 years, but I'm pretty sure Qt will still be around.
  • edited August 13, 2017
    Not all electron-based projects are horribly bad. When done right, one can get a lot out of it (Microsoft's VSCode is the best example IMO). I'm not a dev, just a worried user as you are:)
  • The standalone Zotero app has been built on a web browser instance from the beginning — when you start Zotero, you're starting an instance of Firefox. With Electron, it'll be Chromium (and a vastly better development environment). There's just no other comparable cross-platform option for a JavaScript-based codebase at this time.
  • (For those interested, here's CHNM's first Electron app, recently released in beta: )
  • Qt can run JavaScript and have official binding but I understand you want to stay in the same environment (a browser). I still think electron app are not that good for the user:

    XULrunner was bringing a GUI toolkit, not only a JavaScript runner with a system API.

    VSCode (using ~320MB RAM when open!) is impressive but very slow to start compared to native similar editor like TextMate2 (~30Mb RAM) or Sublime.
  • XULrunner was bringing a GUI toolkit, not only a JavaScript runner with a system API.
    And Electron gives us an immense Node module and React component ecosystem, as well as the ability to reuse components between the website and the desktop app. Qt is not a realistic alternative for our purposes.

    The issues with Electron are well-known, and I don't think there's any reason to think that there won't be improvements in those areas.

    Beyond all the benefits of Electron for development, Zotero simply relies heavily on web technologies to function. When you use Add Item by Identifier or Retrieve Metadata from PDF, or when you save a snapshot, or when you do anything else that uses translators, it uses a browser to perform those operations. While there are ways those could possibly be made to work without a full browser engine, it's a pretty natural fit.

    (I think the most promising alternative to Electron is React Native, by the way, but that's not yet a realistic option.)
  • From my point of view as an end user, the Android support is important. Unfortunately, Electron currently does not support a development of applications for Android.
  • | when you start Zotero, you're starting an instance of Firefox. With Electron, it'll be Chromium

    Does that mean for the future, running Zotero will mean silently running Chromium? Will that imply data privacy issues, sending Google informations about my usage profil?!

    I know it is not your fault that Mozilla drops XUL based add-in support, but I hope and strongly recommend that you look for options that respect and protect peoples data privacy! I decidedly do not use google Chrome for that reason.
  • Will that imply data privacy issues, sending Google informations about my usage profil?!

    Chromium isn't Chrome, and Electron isn't just a stock build of Chromium. Among Electron apps, I have Slack and Atom on my machine, and neither has ever tried to connect to Google (other than the safe-browsing endpoint in Slack's case, and Slack clarifies that "Slack does not send any customer data to Google"). Similarly, an Electron-based Zotero won't send user data to Google.
  • That is good news. Thanks for make that clear!
  • edited August 22, 2017
    Chrome tracking is not present in Chromium and Electron. Yet some Electron API do make external call to google services:

    Using those API (localisation, voice recognition, ...) is, of course, optional and alternative can be used.

    What is sure is by using chromium you help the "Chrome ecosystem" and therefore participate indirectly to Google web domination.
  • This may sound intrusive, but I'm wondering whether it's possible to keep an eye on the Electron-based Zotero development, or even try nightly builds. Is there a dedicated GitHub repo or certain place when one could watch the current status?
  • It's a reasonable question, but as far as I know, there's no such repository (Zotero does have some private repos, but I'd be surprised if they used those for Electron). I don't think work on Electron Zotero per se has begun (though the recent release of Tropy by the same center will certainly help. You can find Tropy's code here:
  • edited January 2, 2018
    Tropy looks a lot like Zotero in terms of interface and how it stores the metadata (RDF). I have a suspicion that Tropy may occasionally become the next iteration of Zotero after adding styles and PDF support, rendering Zotero obsolete. Am I overthinking?:)
  • Yes, the projects aren’t likely to merge, as they serve very different functions. But Zotero will likely be able to re-use code and lessons learned from Tropy development.
  • The German IT security expert Felix von Leitner recommends to stay away from Electron. See

    Below is a current vulnerability.
  • I think switch to Electron is a good idea.
    XUL is abandoned by Mozilla, Electron will be future for the next decade.
    Do you guys really think that a framework without maintenances will have better privacy protection and security than the latest one ?
  • Excited to see this new Electron app. Thank you for all your hard work on this!

    About the Android question above, I understand that concern. Android options are even more limited than iOS, though its global install base dwarfs iOS. I use Zoo for Zotero on my Samsung tablet and Papership on my iPhone (I bought a Samsung tablet rather than an iPad for several reasons, one of which was price). While I'm extremely grateful for Zoo for Zotero, the Android platform has nothing even remotely comparable to Papership.

    I'm not a developer, but, from what I can see, it doesn't look like it's possible to port anything developed in Electron to mobile (iOS or Android). At least, not with the ease that React Native would allow. But maybe building for Electron is more straightforward than building in React Native...dunno!

    At any rate, I'm extremely grateful to the developers for the desktop app. I love Zotero.
  • I'm absolutely no expert in this field, but something intrigues me about Tauri that may be worthwhile to consider as an alternative to Electron.
  • That says the backend of the application (which I think means "anything not UI") would be to be written in rust. That means a large chunk of zotero would need to be rewritten. I think Tauri casters to a different crowd.
  • I've also been trying for days to get any one of their examples going without results.
  • Hmm, you could well be right. I'm really no expert on this. Also, they are currently in early alpha state...
  • Are there any updates on the state of development of Electron based Zotero?
  • Us *BSD users eagerly await updates on this part of the Zotero project, as there has not been a way to run Zotero natively (or pseudo-natively) in the *BSDs since the move away from strict Firefox integration.

    Please let us know if there is a way/place to build an early testing version of this. Many thanks.
  • Zotero won't be moving to Electron anytime soon.

    We are planning to move to a more current version of the Firefox base later this year.
  • @dstillman : Thank you for the response. Firefox is a more desirable base writ large than Electron, in my book. In any event, my interest is *BSD support -- not the base.

    With FreeBSD in particular, the Windows binary is hit-or-miss in Wine (when it does work, everything works; when it does not work, nothing works), and the build process with Linuxulator is cumbersome with no guarantee of success. There are various posts about Zotero in FreeBSD in these forums, GitHub, and the FreeBSD Forums.

    I (for one) would be willing to pay to use a native binary on FreeBSD (+ other *BSDs), and I would not be surprised if others think the same.

    All that aside, keep up the great work. Zotero is fantastic. We simply need it in the *BSDs, too :)
Sign In or Register to comment.