Vlákno názorů k článku Vývojáři navrhují přepsat Thunderbird pomocí web technologií od Vít Šesták - To je těžké. Současný Thunderbird nějak funguje na XULu...

To je těžké.

Současný Thunderbird nějak funguje na XULu a má nějaký zajímavý ekosystém rozšíření, byť se to moc nerozvíjí.

Pokračovat stejným směrem by kromě stagnace znamenalo taky nutnost udržovat něco, co dosud bylo od Mozilly bez práce. Znamenalo by to více úsilí než doposud.

Přepsat všechno najednou je dost riskantní krok. Na jednu stranu se těším na to, co to (snad) přinese, na druhou stranu vidím pár rizik. Zaprvé kompletní přepis bývá podceňovaná věc a ne vždy je výsledkem produkt v požadované kvalitě dodaný v plánovaném to termínu. Zadruhé, celkem jistě si to vyžádá přepis dnešních rozšíření, která fungují snad výhradně na XULu. Jsem dost zvědavý, kolik z nich zanikne a kolik bude přepsáno. V poslední řadě během přepisu se obvykle nevěnuje moc sil vylepšování starého kódu. Thunderbird se ale poslední dobou moc nemění, takže to bude asi celkem malá oběť.

Postupný přepis by možná šel, kdybychom měli něco jako Electron/Cordovu na Gecku. Pak by snad šlo rozumně kombinovat legacy kód s moderním. Třeba editor zpráv by byl přepsán, zatímco seznam zpráv by zůstal v původní podobě. Ale o ničem takovém nevím. A i kdyby něco takového existovalo (v požadované kvalitě), mohou tu být další bariéry, o kterých zatím nevím.

Ať už zvolí cokoli, je jisté, že tu bude početná skupina uživatelů, kterým se to líbit nebude. Řekl bych, že je to o hledání nejméně špatné volby.

Co mi na přechodu od XUL u Firefox/Thunderbird na "moderní technologie" vadí:

1. wrappery Chrome/Chromia (jako je Electron) sežerou neuvěřitelný množství paměti. Nativní Slack třeba běžně sežere 1 GB RAM. A to jde jen o glorifikované IRC.
2. všechno, co fungovalo, půjde do alphy - tohle bylo krásně vidět u KDE, jak šíleně bolestivě se zahodila verze 3.5, aby se několik let vyvíjela KDE 4, a až byla stabilní, tak se zahodila, a teď máme pořád nedodělané KDE 5 (Plasma 5)
3. XUL addony jsou největší výhodou Firefoxu - umožňují dělat věci, co web extensions neumí. V Chrome nelze udělat ani tak debilní věc, aby fungovaly mouse rocker gestures (gesta levé-pravé nebo pravé-levé myšítko). U Thunderbirdu jde snad hlavně o Lightning a Enigmail, ale u Firefoxu skončíme s tém, že všechno je vlastně Chrome: Chrome je Chrome, Opera je Chrome, Vivaldi je Chrome, Firefox je Chrome

U Thunderbirdu po letech registruju jen 2 bugy: S/MIME nebo GPG zašifrované zprávy nelze prohledávat a po suspend/wake cyklu se rozpadne občas synchronizace u IMAP foldrů (musí se na ně explicitně kliknout). Zvláštní je, že RHEL 6 Thunderbird má nějaký patch, který tohle řeší, ale nenašel jsem který přesně.

1. No, nevím, jestli je na tom XUL o tolik lépe. (A blbě se to srovnává. Ideální by bylo porovnávat dostatečně podobné aplikace. Chrome vs. Firefox se liší už používáním procesů a přímé srovnání je problematické.)
2. Ano, toho se bojím. Odhadují tři roky, reálně po čtyřech letech vyjde nestabilní nedodělek. (Teda třeba ne, ale něco takového jsme tu už viděli tolikrát…)
3. XUL addons jsou kontroverzní. Ale nejde až tak o XUL, jako o overlays (které můžeme ale mít klidně i s HTML5). Na jednu stranu nejsme svázani poskytnutým API a můžeme si dělat, co nás napadne, na druhou stranu nemáme jasné API (problémy s kompatibilitou při upgradu Firefoxu) a rozšíření si mohou dělat, co autory napadne (není žádný sandbox, rozšíření může šahat kamkoli). V principu nemůžeme chtít všechno.

Mimochodem, ono to není buď-anebo. Můžeme mít XUL a WebExtensions vedle sebe. Nebo WebExtension může mít k dispozici API, kterým získá privilegovaný přístup, a pak je to podobná situace jako s XULem.

S Lightningem by snad nemusel být problém, to je skoro samostatná aplikace, nepotřebuje se nějak hluboce integrovat. S Enigmailem to může být horší, ale pokud bude podpora pro S/MIME, tak snad by to mohlo jít…

Myslím že kombinovat různé UI frameworky ("editor zpráv by byl přepsán, zatímco seznam zpráv by zůstal v původní podobě") nemá moc smysl. Spíš bych se soustředil na lepší oddělení front-endu a back-endu, a zachování maxima z toho back-endu. Front-end by bylo dobré napsat v nějakém vyšším jazyku, který nesvádí k chybám, a když už se vyskytnou, umožní je dobře odchytat. Z hlediska jazyka zní nejlépe C# a Java, jenže z praktických důvodů to první na Unixech není moc dobrý nápad, a to druhé není dobrý nápad nikde. Framework by měl být multiplatformní a podporovat mobilní zařízení. Nabízí se Qt s QML, otázkou je v čem psát kód. Alternativně Mono framework, i když si umím představit, že proti tomu by někteří uživatelé na Linuxu protestovali. V každém případě se dá čekat, že rozšíření bude potřeba přepsat.

Řešit to pomocí webových technologií bych považoval za dost nešťastné.

> Myslím že kombinovat různé UI frameworky ("editor zpráv by byl přepsán, zatímco seznam zpráv by zůstal v původní podobě") nemá moc smysl

Jako trvalé řešení určitě. Jako dočasné řešení pro přechod mi to smysl dává, pokud je to technicky/eko­nomicky schůdné.

> v nějakém vyšším jazyku, který nesvádí k chybám, a když už se vyskytnou, umožní je dobře odchytat.

Souhlas, ale bohužel je tu spousta lidí, kteří to vidí jinak. Navíc toto nejde tolik dohromady s návrhem zachovat co nejvíce z backendu, který je z velké části v JS, což při volání z jiných jazyků může činit větší či menší obtíže.

> Z hlediska jazyka zní nejlépe C# a Java, jenže z praktických důvodů to první na Unixech není moc dobrý nápad, a to druhé není dobrý nápad nikde.

Proč? Takové Banshee (Mono) funguje dobře, aspoň na linuxu. A Java – pokud se nepoužije Swing (nebo pokud se Swing zkulturní, jako to udělali v JetBrains), nevidím v tom problém.

> Alternativně Mono framework, i když si umím představit, že proti tomu by někteří uživatelé na Linuxu protestovali.

Někteří ano. Ale najděte technologii, proti které nebude nikdo protestovat…

> Řešit to pomocí webových technologií bych považoval za dost nešťastné.

Na jednu stranu ano. Na druhou stranu, teď má projekt nějaké přispěvatele s nějakými znalostmi a zkušenostmi, které jsou webu blízko. A pokud nový Thunderbird má se starým mít společného i něco jiného než název a logo, hodilo by se nedělat radikální řez do týmu

Aspoň jsem byl přesvědčen, že to je v JS. Mohl jsem se mýlit – třeba je část nebo všechno v C/C++ a integrovaná pomocí XPCOM.

Ad kombinovat různé UI frameworky nemá moc smysl; Jako dočasné řešení pro přechod mi to smysl dává, pokud je to technicky/eko­nomicky schůdné - tam bude asi problémem ta schůdnost

Ad bohužel je tu spousta lidí, kteří to vidí jinak - takovým přeju, aby na podobném projektu pár let kódovali. Za následky na jejich zdraví neručím :)

Ad toto nejde tolik dohromady s návrhem zachovat co nejvíce z backendu, který je z velké části v JS - back-end v JS? Fakt? Někdo tu uváděl, že TB má 63% v C/C++ a 22% v JS. Tipnul bych si, že v C/C++ bude primárně back-end. Obsluhu tlačítek a zaškrtávátek bych naopak čekal v tom JS.
https://www.root.cz/clanky/vyvojari-navrhuji-prepsat-thunderbird-pomoci-web-technologii/nazory/918761/

Ad Banshee (Mono) funguje dobře, aspoň na linuxu - vím že projekt Mono udělal velký pokrok, ale nejsem schopný posoudit, jak si na Linuxu stojí. Jestli dobře, tak by to asi mohlo být řešení.

Ad Java, pokud se nepoužije Swing (nebo pokud se Swing zkulturní, jako to udělali v JetBrains), nevidím v tom problém - Java je pěkný jazyk, ale dost mizerná platforma. Vývoj Javy prakticky stojí, bezpečnost je hrozivá, a upřímně: HW náročnost Java aplikací je někdy dost překvapující.

Ad najděte technologii, proti které nebude nikdo protestovat - velký souhlas

Ad teď má projekt nějaké přispěvatele s nějakými znalostmi a zkušenostmi, které jsou webu blízko - v podstatě mohou udělat to co jsem popsal, nebo strávit léta ohýbáním a doděláváním nějakých frameworků... a nebo vymyslet lepší migrační cestu, která jim bude vyhovovat.

> Tipnul bych si, že v C/C++ bude primárně back-end.

Možné to je, potom by se situace trochu měnila.

> vím že projekt Mono udělal velký pokrok, ale nejsem schopný posoudit, jak si na Linuxu stojí. Jestli dobře, tak by to asi mohlo být řešení.

Nemám s Monem až tak velké zkušenosti, ale mám z něj pocit, že záleží, jestli s ním vývojáři počítali. Pokud ano, pak funguje dobře. Pokud ne (tzn. vývoj probíhal spíše pro MS .NET a s Monem se nepočítalo), pak ve složitější aplikaci skoro jistě najdeme problém. Problém Mona budou tedy spíše edge cases nebo feature parity s MS .NET než stabilita.

Ostatně na Monu se dělají i aplikace pro Android a iOS – vizte Xamarin.

> Vývoj Javy prakticky stojí

To bych řekl spíše v době Javy 6, ne dnes.

> bezpečnost je hrozivá

Pokud chcete v JVM spouštět cizí kód a uzavírat jej do sandboxu, pak ano – většina zranitelností Javy je právě o úniku ze sandboxu. Jinak mi to – s ohledem její rozsah – nepřijde jako tak velké množství zranitelností. Ne každá zranitelnost je zneužitelná s každou aplikací. Pokud jde ale o poštovního klienta, tam nepotřebujeme snad primárně sandboxovat Javový kód (i když, pro extensions by se to mohlo hodit, ale tam je menší riziko útoku) a ani z ostatních nebude zdaleka všechno aplikovatelné.

> a upřímně: HW náročnost Java aplikací je někdy dost překvapující.

S čím to srovnáváte? Pro jaké scénáře? Často takové srovnání vidím s nějakou o poznání jednodušší aplikací (typu IDEA vs. Vim). Nebo pro scénáře, které sice nejsou silnou stránkou Javy, ale ne vždy jsou podstatné (rychlost startu). Nebo 10+ let stará srovnání. Ano, žere to typicky více RAM než obdobná aplkace v C (pro CPU bych si s tím už nebyl jist), ale zase komfort vývoje a memory safety jsou někde jinde. A pokud budeme srovnávat s JS, tak Java nejspíš vyhraje. (Jasně, vždy lze najít dostatečně zpackaný kód…) Srovnání s .NET bych čekal celkem vyrovnané, možná až na cold performance.