I am interested in collaborating on long-horizon superseding 'elastic'. I understand the gravity of the task I'm proposing. (detail inside)
I have used Roundcube for roughly 15 years. It is the only good self-hosted mail client. Butt the UI/UX has fallen behind what users now expect from accessibility, responsiveness, and general interaction design. Additionally, from my investigation I found some really... uh.... there is a lot of 'unsafe-inline' in there.
I am well aware that Roundcube is foundational internet technology and ships with all cPanel installations and 3rd party folks have relied on the plugins touchpoints for many years. I am not proposing chopping those off. Below I'll explain my proposed approach that does a strangler migration on the codebase and frees The Maintainers & Roundcube of legacy cruft without breaking existing flows. There are a few strategic chokepoints that can be exploited to accomplish this atomic-ish update.
I have the time and interest to work on replacing it, and I am interested in doing that work upstream rather than building a private skin that only I use.
I am not proposing a large cosmetic rewrite on top of Elastic. The current frontend is tied closely to server-generated HTML, inline event handlers, executable AJAX responses, jQuery, Bootstrap, and plugins that expect those things to exist. Trying to hide all of that behind a JavaScript compatibility shim would likely create more legacy code than it removes.
I think the useful boundary is on the PHP side.
The rough plan would be:
Put the existing HTML and AJAX output behind a replaceable client boundary without changing its behavior.
Separate application behavior from presentation. Mailbox data, message lists, message operations, compose state, contacts, and settings should produce structured results before being turned into HTML or JavaScript calls.
Keep Elastic rendering those results in its existing format while a new client receives them through a versioned structured protocol. The mail behavior itself only exists once.
Build the new client in a fixed order: mailbox, message list, message view, mutations, compose, contacts, and settings. It would not depend on jQuery or Bootstrap, would not use inline handlers or eval(), and would be expected to work under a strict Content Security Policy. Accessibility would be a release requirement from the beginning.
Preserve existing plugins through an explicit compatibility path. The new client would need a smaller structured extension API, and bundled plugins would be ported as part of the work. Plugins written for the old DOM should run in the old client rather than half-working inside the new one. <- In my opinion this is very important. Maintaining a zombie layer for another decade is a non-starter.
Once the new client reaches real parity, make it the default and stop adding new UI features to Elastic.
Move Elastic and its supporting template/JavaScript runtime into an optional (but complete) compatibility package. This is where the 1st step (replaceable client boundary) becomes useful. Since we're doing a binary choice of which UI to show the binary (at some point in the future) becomes a binary with a single choice.
Distributors such as cPanel could continue shipping it for installations that still require old plugins or customizations, while Roundcube core would have a path to stop carrying that runtime forever.
This is essentially a strangler migration, but I do not mean indefinite coexistence. The destination should be agreed upon before work begins: the new client replaces Elastic in core, and the compatibility client has a planned exit.
The work would arrive as reviewable PRs, but they would be parts of one migration rather than unrelated cleanup that may or may not eventually become a new UI. Each change should either establish a necessary boundary, move a complete capability onto the shared application layer, or remove legacy responsibility.
The first PR would probably contain no new UI. It would separate one existing structured model from its HTML rendering while proving that Elastic’s behavior remains unchanged. That would test the approach before committing the project to a frontend implementation.
I am willing to do the work and continue maintaining it. Before beginning, I would like to know:
- Is this general direction something the maintainers would accept?
- Is eventual removal of Elastic from core acceptable once compatibility and parity requirements are met?
- Would a maintainer be willing to collaborate on the architectural boundaries as the migration proceeds?
Roundcube today
│
├── PHP actions + business logic + HTML generation
│ ├── <roundcube:...> template engine
│ ├── executable AJAX responses
│ └── plugin-generated HTML
│
└── Elastic
├── Bootstrap 4
├── jQuery / jQuery UI
└── legacy plugin JavaScript
CHANGEOVER
│
▼
Roundcube core
│
├── Shared application layer
│ ├── Mailboxes
│ ├── Message lists
│ ├── Message reading
│ ├── Message operations
│ ├── Compose / send
│ ├── Contacts
│ └── Settings
│
├── Versioned structured UI protocol
│
├── Modern client
│ ├── Standards-based components
│ ├── Responsive layout
│ ├── Accessible interactions
│ ├── Strict CSP
│ └── Modern plugin API
│
└── Legacy client provider
├── Elastic
├── <roundcube:...> templates
├── executable AJAX protocol
├── Bootstrap 4
├── jQuery / jQuery UI
└── legacy plugin compatibility
AFTER PARITY
│
▼
Roundcube core
│
├── Shared application layer
├── Versioned structured UI protocol
├── Modern client (default)
└── Modern plugin API
Optional legacy compatibility package
│
├── Elastic
├── Legacy template engine
├── Legacy AJAX runtime
├── Bootstrap / jQuery
└── Legacy plugin support Source: roundcube/roundcubemail