Moment, w którym stało się to oczywiste
Wydarzyło się to podczas rozmowy wideo. Ktoś udostępniał swój ekran i widać było, jak kursor myszy się zacina. Sama rozmowa działała dobrze — problemem był Slack działający w tle, zużywający około 4% CPU i ponad 1 GB RAM na maszynie z łącznie 16 GB pamięci.
To nie jest komputer z ograniczonymi zasobami. To nowoczesny komputer wymiernie spowalniany przez aplikację do czatu. A osoba po drugiej stronie rozmowy po prostu przyjęła to jako normę.
Nie byliśmy jedyni
Ta frustracja nie jest niszowa. Wyszukaj „Slack RAM” albo „Slack wolny”, a znajdziesz lata wpisów na forach, wątków na Reddicie i sekcji komentarzy — wszystkie mówiące to samo. Odpowiedź Slacka niezmiennie brzmiała: „pracujemy nad wydajnością”. Aplikacja poprawiła się na marginesach, ale architektura się nie zmieniła: to wciąż pełna przeglądarka internetowa wbudowana w klienta czatu.
Ta architektura oznacza minimalne obciążenie rzędu 150–200 MB samego frameworka, zanim jeszcze uruchomi się jakakolwiek logika aplikacji. Każda przestrzeń robocza to mnoży. Kumuluje się to w ciągu dnia pracy.
Dlaczego nie zrobiliśmy po prostu nakładki na aplikację webową?
Oczywista droga na skróty to: wziąć interfejs webowy Slacka, opakować go w okno desktopowe i nazwać lżejszym klientem. Kilka narzędzi robi dokładnie to.
Nie chcieliśmy budować czegoś takiego. To rozwiązuje problem zarządzania oknami — o jedną kartę przeglądarki mniej do przełączania — ale nie robi nic dla pamięci ani CPU. Wciąż uruchamiasz Chromium. Wentylator nadal się kręci. Bateria nadal się rozładowuje.
Jeśli rozwiązanie nie usuwa pierwotnej przyczyny, to nie jest tak naprawdę rozwiązanie.
Decyzja o budowie natywnej
Wybraliśmy Qt6 — ten sam framework UI, który napędza Telegram Desktop. Qt kompiluje się do prawdziwego natywnego kodu: bez wbudowanej przeglądarki, bez środowiska JavaScript, bez maszyny wirtualnej między naciśnięciami klawiszy a ekranem. Rezultatem jest aplikacja, którą system operacyjny traktuje jak każdą inną aplikację natywną.
Kompromis jest realny. Natywne tworzenie oprogramowania iteruje się wolniej niż technologie webowe. Budowanie funkcji trwa dłużej. Nie możemy po prostu wrzucić biblioteki JavaScript, gdy potrzebujemy nowego komponentu. Ale efektem jest aplikacja, która uruchamia się w niecałą sekundę i utrzymuje ~0% CPU w stanie spoczynku. To właśnie chcieliśmy naprawić — i jest naprawione.
Z czego zrezygnowaliśmy — i dlaczego to w porządku
msga nie ma dziś pełnego zestawu funkcji Slacka. Połączenia głosowe i wideo, Huddle, Canvas oraz integracje z aplikacjami są w planach. Jeśli którakolwiek z nich jest kluczowa dla Twojej codziennej pracy, oficjalna aplikacja na razie pozostaje właściwym narzędziem.
Ale bardzo wiele osób używa Slacka przede wszystkim do tekstu: wysyłania wiadomości, czytania kanałów, odpowiadania w wątkach, wyszukiwania czegoś, co ktoś powiedział w zeszłym tygodniu. Do tego zastosowania msga się sprawdza — bez obciążenia, które spowalnia Twój komputer.
Co dalej
Wsparcie dla macOS i Windows jest w trakcie tworzenia. Celem jest to samo doświadczenie na wszystkich trzech platformach: uruchamianie w niecałą sekundę, cisza w stanie spoczynku, niewielkie zużycie pamięci.
msga jest darmowy, open source na licencji GPL-3.0 i tworzony publicznie na GitHubie. Jeśli masz dość spowalniania Twojego dnia pracy przez Slacka, wypróbuj go.