Redmine

Thank you for your contributions. I think it is very worthwhile to explore options to modernize these parts of Redmine to allow more a straight-forward development and better security.

With that being said, Redmine is quite mature software. It was able to keep up with development of internal changes and external requirements over the last 18 years. One reason this was possible with a rather small and changing number of contributors is that Redmine generally is and was quite conservative with adopting or requiring external software components.

Redmine deliberately did not follow many trends-of-the-day in both Rails and Javascript development which has helped the project to be able concentrate on Redmine itself rather than running behind fast-changing (and often also quickly abandoned) external dependencies which is quite extrem esp. with many Javascript frameworks and also a lot of past approaches of Rails/Javsscriot integration frameworks. I strongly believe that with Redmine relying on JQuery and JQueryUI, we have absolved us of A LOT of unnecessary busywork in the past.

As such, I believe we should continue to be very conservative when adopting external or additional frameworks, even if they may be considered the current state of the art. Specifically, I believe Redmine should keep its current approach of using regular page requests which return full-page server-rendered HTML as much as possible in order to control as much of the rendering as possible from the server.

I see the appeal of newer approaches for getting rid of the ERB-generated JS responses and to be able leverage more security features such as strict CSP rules. However, I'd rather prefer a more focused approach here which does not tie us into quickly changing external frameworks. If we are to tie us to this framework, I think its advantages should be clearly spelled out and must be shown to be overwhelming in favor of this approach.

From your proposal, I'm especially concerned about the adoption of Turbo and Hotwire. Right now, I do not believe that it would gain us significant advantages, compared with the hassles of having to deal with all the small gotchas and interaction particularities it brings and having to deal with required updates once the new hot trend comes around in a few years. In my eyes, the majority of the ecosystem of Hotwire and Turbo is overkill for Redmine and instead introduces a lot of moving parts and dependencies which would be very hard to get rid of later on.

Again: the stability of JQuery over the last > 15 years has been very helpful for Redmine and we should be very careful to throw this away...

Hello, and thank you for your work, Takashi.
I did some quick research and found that you’re not the only one working on this change. Some initial steps have already been taken to integrate Stimulus into Redmine.

Redmine 6.1.0 will include Stimulus and use ImportMap, since these patches have already been committed to the main branch:
https://www.redmine.org/issues/42510
https://www.redmine.org/issues/42515

The modernization of existing features will likely need to happen gradually, step by step, to reduce the dependency on deprecated libraries.

Hello, and thanks to everyone for your contributions. Takashi Kato, your work is impressive; thank you!

Yes, Stimulus and ImportMap are now part of the core and will be included in 6.1.0 with minimal features implemented using this approach. Starting with Redmine 7, it will become an important component of our ecosystem, both for new features and refactorizations.

• rails-ujs is removed in Rails 8
• jQuery UI is in maintenance-mode
• some limitations that I hit lately (see #39130#note-8)
• the limited number of active contributors

I believe that we should carefully plan our efforts in the next versions in order to continually ship new and long awaited features and also, some modernizations under the hood.

Takashi Kato, thanks again for your work, I will review a part of your work to see if something can be delivered in 6.1.0, otherwise I will postpone some changes that make sense for most of the active contributors in Redmine 7.