It’s a replacement for the Lemmy backend. It’s designed to be API-compatible initially so existing Lemmy clients, including Lemmy-UI can just plug right in.
It’s in Java, so there’s that overhead. I don’t speak for the project, but mostly, it’s less about “efficiency at all costs” and more about maintainability, being easier to contribute to / review, and having a less toxic development community. It’s got more developers working on it than Lemmy, and it’s in a language more people are familiar with (Java). It’s roadmap is also not constrained by the viewpoints of a small group of fairly, uh, controversial figures.
After the 1:1 compatibility phase is over, they’re both free to and planning to implement more features that the Lemmy devs either won’t or can’t be arsed to do.
I might be missing this each time I check, but what is different about sublinks? Visually the demo looks the same
Is it a front-end that’s easier to contribute to? Can instances come back to Lemmy if it doesn’t work out?
It’s a replacement for the Lemmy backend. It’s designed to be API-compatible initially so existing Lemmy clients, including Lemmy-UI can just plug right in.
I see
How would this compare efficiency wise, because my understanding was that Lemmys backend was very efficient and that was a big advantage
It’s in Java, so there’s that overhead. I don’t speak for the project, but mostly, it’s less about “efficiency at all costs” and more about maintainability, being easier to contribute to / review, and having a less toxic development community. It’s got more developers working on it than Lemmy, and it’s in a language more people are familiar with (Java). It’s roadmap is also not constrained by the viewpoints of a small group of fairly, uh, controversial figures.
After the 1:1 compatibility phase is over, they’re both free to and planning to implement more features that the Lemmy devs either won’t or can’t be arsed to do.