JabRef is an app built in Java, and does not use a frontend stack like [HTML, CSS, and JavaScript], React, etc., correct?
I am not that experienced in application development, though I have some experience using and modifying apps built in Electron like Obsidian. They seem to have a lot of flexibility and extensibility in terms of both user interface and functionality. In using JabRef, I have sometimes found myself wishing for the customizability of Obsidian (changing the UI with CSS, adding functionality via plugins, etc.).
Is there any interest in utilizing any of these technologies in JabRef?
Again, my knowledge around Java is minimal, so please let me know if this question is totally off-base.
Thanks for all the work you’ve done over the years!
A trivial change to the JabRef theme CSS, enabling word-wrapping in the entry table was a game changer for me! Very helpful when entries have the same or similar title until the end of the field (such as ending in “… Part I” and “… Part II”). Line wrap in entry table
The past several years have been a frustrating time as mainstream reference managers have had their features stripped and meaningful development halted while the products migrated to the web. Most of the commercial products are really licensing-platforms now as much as ‘reference managers’. I used one that could not even import CSV data that came from the same product. Shocking. Meanwhile @Siedlerchr’s was making JabRef import complicated Citavi annotations. Whatever the technology platform, please keep up JabRef’s satisfying focus on what users want to do with their references!
@mkdjr If you have time, you are very welcome to rewrite JabRef’s UI using HTML technology. Please get in contact with me. You can also recruit more volunteers. The reward is experience and the endless gratitude of us and the users. Based on your experience description, I estimate the time for a complete rewrite of 3 years, if you will invest 20 hours/week.
Sometimes, the decision of a UI-framework is not hype driven, but capability driven. Back in 2015, we had around 5 maintainers. We all were Java-experienced and had some experience with Swing. Swing was getting outdated back then and we wanted to modernize the UI framework. We had a look at JavaFX and saw that it had potential. We also had one person in the team developing in Angular2. Only part-time. The team said: If we use JavaFX, all of us can have a look and provide feedback on the code. They also said: If we opt for Angular2 or other Web technologies, we might leave the project, because this technology stack is so fast moving - and we do not want to keep up that pace in our free-time project.
Although we are hitting serious UX bugs in JavaFX (e.g., Loading..., Loading... and more), we are also happy that our contributors “just” need to know about Java - and not two languages.
We also thought about complete rewrites. Maybe, in Python. Maybe in Rust? In Python, because many scientists use that language and might contribute. In Rust, because it is a promising language and also aims for code quality and stability. OK, it mixes HTML and Rust - as once can see at Ballroom Dancing / samba · GitLab, but I think, this is doable.
The current developer community is bound to Java (with some tendency to Kotlin). If JavaScript is intended, JabRef online should be considered. If someone wants to think of a Rust-based rewrite, please contact me. The most important thing is to commit for more than one year and to also spend time with the community (contributors, issue management) to enable the JabRef developer community growing.
