Portál AbcLinuxu, 1. května 2025 17:57
Byla vydána verze 7.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí HTML, CSS a JavaScriptu Electron (Wikipedie, GitHub). Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Tiskni
Sdílej:
co je to za dobu, kdy primitivni aplikace/utilita potrebuje pro svuj beh dve instance JS enginune, ale takove metriky jsou povetsinou (nejen) ve vyvoji software irelevantni.
Myslím ale, že takoví lidé patří spíše do psychiatrické léčebny, než na pozice, kde o čemkoliv rozhodují.Jasne a proto jsou na CEO pozicich lidi jejich ultimatni prioritou je snizit pocet promrhanych CPU cyklu. Realita je jeden velky kompromis. Electron je pro mnoho aplikaci slusny kompromis mezi portabilitou, snadnosti vyvoje, dostupnosti vyvojaru a ma pritom dostatecne nizke systemove naroky (ve smyslu aplikace jsou dostatecne pouzitelne pro vetsinu lidi). To, ze se ti to nelibi na teto skutecnosti nic nezmeni.
RAM toho zase až tak veľa nespotrebuje. V porovnaní s priemyslom, dopravou, vykurovaním sú to smiešne zanedbateľné čísla.
Núti vás niekto používať tieto aplikácie? Nemajú žiadnu použiteľnú alternatívu? Ja som zatiaľ u seba na desktope nepoužil žiadnu electron aplikáciu. Moja posledná skúsenosť s electronom bola pred pár rokmi keď mi spustenie atomu okamžite zhodilo grafický server (chyba v ovládačoch intel).
Skôr ma trápi bloatware na webových stránkach. Nedávno sme v práci preberali mikro frontendy. No stránka skladajúca sa z komponentov, ktoré sú oddelené a každý má vlastné knižnice (napr. jedno tlačidlo má react, druhé angular, tretie react v inej verzii atď).
veci co priamo s tym suvisia ako napr cowTo je docela sranda, protože kdykoliv jsem tady v průběhu minulých 8 let obhajoval btrfs, tak mi na to někdo napsal, že toto od fs neočekává a fs je pouze to co bylo před btrfs.
metadata moze veselo riesit nieco nad tymCož se v praxi ukazuje být docela problém. Různé indexátory si to většinou řeší na vlastním písečku a ano, na určitém DE si můžu k souborům přiřadit tagy a někde podle toho vyhledávat, ale toto už nebude v jiném DE fungovat. Nehledě na to, že bych ten disk vzal a zapojil do jiného kompu. (Index je umístěn jinde než data, takže když vezmu datový disk a ne svůj home, tak ten index nemám.)
(Index je umístěn jinde než data, takže když vezmu datový disk a ne svůj home, tak ten index nemám.)A když se to řeší jako v macOS, kde se v každém adresáři se soubory vytvoří adresář .DS_Store, tak se zase každý rozčiluje, že jsou všude tyhle adresáře a administrátoři Samby blokují zápisy těchto názvů nebo dávájí do cronu pravidelné promazávání...
ne velikost binarky v bytech nebo pocet renderovacich enginu.Nejde o velikost binarky, ale naprostou neefektivitu a mrhani zdroji. A neni to nejake virtualni mrhani zdroji, ktere me trapi, ale to, ze ty aplikace jsou nenazrane a pomale a neni k tomu duvod. Bystroushaak tu nedavno psal, o VSCode, ktere je schopne sezrat 16GB pameti.
ne, ale takove metriky jsou povetsinou (nejen) ve vyvoji software irelevantni."Plytvani" hardwarovymi prostredky je ve vyvoji software bezne a neni to apriori spatne. Co je spatne, je plytvani prostredky, ktere nema skutecne opodstatneni. V takovem pripade jde o obycejny cargo cult. Ve srovnani s dalsimi platformami to prakticky nezjednodusuje vyvoj (mam pocit, ze spis na opak), prenositelnost je z meho pohledu taky sporna (clovek musi resit binarky pro ruzne OS, to uz Java se svym write-once-run-anywhere funguje lip a pri mensich hw narocich). Jedine plus je v tom, ze to muzou pouzivat decka, ktere se naucily HTML a neco malo JS.
Bystroushaak tu nedavno psal, o VSCode, ktere je schopne sezrat 16GB pameti.Bylo to 20+GB paměti (musel jsem upgradovat na 32GB aby to vůbec jelo), ale zároveň jsem taky psal, že za to nemůže nenažraný electron, ale debilně napsaná analýza kódu Visual Studio IntelliCode. Samotné VS Code jde provozovat s 8GB paměti, i když už je to na hraně.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.