The sync between large groups used to be slow because of amount of data, but Element X and "sliding windows" were rolled out to help with it.
AFAIK, the public Matrix server used to be slow because of a heavy load (I think), but on my self-hosted instance that's not a problem at all.
And event the slower Element seems far better than Discord that I'm forced to use, where I can't even scroll history without the whole thing stuttering.
I hope that at some point a focus of the Matrix project will become why this isn’t being done. A better developer experience would supercharge the ecosystem, IMO.
Matrix should be the default for anyone building a chat app, but for some reason it’s not.
Someone should tell the CEO/CTO of Element
That said, 70% of our users haven't got the memo yet - we'll do a hard-upgrade when the remaining missing features in Element X (Spaces & Threads) are fully out of Labs.
Meanwhile, Element Web is lagging behind Element X - but we're now in the middle of an incremental in-place upgrade (not a big-bang rewrite, thank goodness) to use matrix-rust-sdk - see our talk from FOSDEM last Sunday for the details: https://fosdem.org/2026/schedule/event/DZJVTS-an-element-web...
This isn't users not getting the memo yet, this is users being faced with an unfortunate choice between a buggy, slow client and a new client that doesn't implement important functionality like Spaces and Threads.
I've only started my Matrix journey, in the form of writing bots using the matrix Python library. I'm keeping my fingers crossed, as the Matrix protocol could be really impactful.
Both Spaces and Threads are about to land, and there are other lower-profile features that also need rounding out. We would expect full parity by April this year. At which point migration should be an obvious choice.
He's (in my mind) always positive, open, and willing to admit the shortcomings of the platform he shephards... but damn does he deal with a lot of undeserved criticism (and deserved criticism, where applicable)
But for what it's worth, as Zulip's lead developer, every time I'm looked at whether we could have built Zulip on top of Matrix, it just feels impossible to me. And a big part of it is the architectural decisions Matrix made to support a decentralized E2EE social network, which are not required for a self-contained chat system like Zulip or Slack (which can still be bridged with other chat systems). Permissions enforcement, performance, and lots of other details really benefit from the more focused goal, where we've explicitly decided we're not building a generic distributed network architecture and are not competing with WhatsApp.
That said, I think it's great that we have multiple OSS chat systems with different strategies that are targeting different collections of niches!
I will never understand why so many organizations entrusted the communications fabric of their organization to Microsoft and SalesForce Cloud services over the last decade. If an organization can succeed in escaping Teams or Slack to Element/Matrix, that's great, even if it's a use case where Zulip would be a better end-user experience for their requirements.
Element is the actual app being trialled here, which feels more like Slack and/or Signal than Zulip. The point is that you get something you can selfhost while also interoperating with other deployments… while also encrypting the data end-to-end with Signal protocol.