Az Electron van, hogy a legjobb alternatíva

Kérdés

Az az Electron, ami Javascriptre épül, és egy cross platform GUI toolkit. Az atom.io és a VS Code például abban íródott. Leggyakoribb kritika ami éri, az a magas memóriaigénye.

Van olyan eset, amikor egyértelműen az a legjobb választás egy új projekt elkezdésére?

Egyetértek
27% (138 szavazat)
Nem értek egyet, mindig van jobb alternatíva
32% (162 szavazat)
Fogalmam sincs.
41% (205 szavazat)
Összes szavazat: 505

( suckit | 2020. 12. 18., p – 21:37 )

Azt választanám, hogy:

- fogalmam sincs, de az atommal szerzett tapasztalataim alapján ennél bármi más csak jobb lehet

Hát, pedig az Atom nekem is a legszutyokabb editornak tűnt evör. Leglassabbnak, ahhoz képest legbutábbnak, ha meg felplugineled, akkor még lassabb. Annak a lomhaságával már csak a Commodo Edit vetekszik. Inkább 100× használnám a Sublime-ot mint az Atomot. És az Atommal nem is az a baj, hogy Electron-alapú, mert tudtommal a Visual Code is az, de az legalább mégis normálisabb. Persze leginkább egyik sem, nagyon megfelel a vim, igaz én nem vagyok fejlesztő, de sokat írok editorba, mindenféle szöveget, scriptet, config fájlt, stb.. Ha nem létezne vim, akkor Emacs irányba mennék. Ha mindenképp hagyományos GUI editor kell valakinek, akkor meg jó a Visual Code, Sublime, Windowson a Notepad++, de ha valakit nem zavar, hogy zárt, akkor akár az UtraEdit is.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Magyarral. Szerintem nem használhatatlan, mert parancsmódban azokat a billentyűket, amik a magyar kiosztásnál eltérnek, ritkán használod, pl. $ < > ; : * #, [ ] stb., ezeket max. AltGr kombóval használod, vagy lehet azt is, hogy vim-ben bekonfigolni, hogy normál meg vizuális módban egyes karatereket (pl. ékezetes karakterek) átcseréljen másra, ezzel kvázi kiosztást váltva automatikusan, vagy akár módváltáskor valami paranccsal setxkbmap-os kiosztásváltást beállításani). Először én is ez utóbbit használtam, de aztán rájöttem, hogy felesleges szívni vele, mert nem használom sokat ezeket a speciális jeleket, ha nagy ritkán kellenek, AltGr-rel elérem őket. A vim-es utasításbillentyűk nagyja egyszerű alfanumerikus karakter, amik magyar billentyűzeten is ugyanott vannak, másik részük írásjel, amik szintén elérhetőek AltGr nélkül, csak másik billentyűn, pl. / ' " = % ?, stb., de ezekből sincs sok. Ha megtanulod a vim-et, a funkciók 99,99%-a magyar billentyűzeten is használható különösebb nehézség nélkül.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( asch v | 2020. 12. 18., p – 21:41 )

Magam részéről zsigerből utálom, de elismerem, hogy racionális döntés lehet, ha egyszerre cél a netes megjelenés és a desktop-szerű működés egy programnál.

+1. Agyfaszt kapok amikor le kell szedni valami appot es az egy ilyen elektronos ize, ami azt jelenti hogy futtathatok meg + 1 chromiumot, ami szinten zabalja ossze-vissza a ramot es gtk3 is kell neki, es egy 300 MB-os appbol 290MB a chrome, a tobbi az app.

Ugyanakkor, fejlesztoi oldalrol tenyleg sokkal egyszerubb ha van 1 db kodbazis es az mukodik weben, windows, linux, mac, android, akarmin, nem kell oket mind kulon megirni oket nullarol. Ilyen szempontbol kicsit olyan ez, mint a jelenkor java-ja, a new swt-s java appok se neztek ki soha nativan. Az hogy kit mennyire zavar hogy nem teljesen nativon nez ki valtozo, de amig nem kell nagyon komplex guit csinalni addig talan vallalhato.

I hate myself, because I'm not open-source.

Meglepne, ha nem lenne egy idő után 1st class application mndkét mobil platformon a web, a PWA már nagyjából tart ott most is. És alapvetően megszületett a több párhuzamos chrome erőforrás igénye kapcsán is a döntés, hogy a programozó ideje, és a lehetséges bug-ok okozta kár drágább, mint a felhasználó vasa, azt úgy is fejleszti nekünk a konzúmer idióta magától, nincs itt probléma.

(Nem tartom jó iránynak gazdaságilag, de egyúttal nagyon nehéz lenne elmagyarázni az ügyfélnek, hogy ios-android-windows platformokra akkor most külön fejlesztésként írjuk meg az app-ot, ami egyébként bőven elfutna weboldalként is.)

Ha nem válaszolnék kommentben, hát küldj privátot!

1st class application mndkét mobil platformon a web

Nem lesz. Az elsődleges programozási nyelv iOS-re (nagyon helyesen) a Swift.

Aki macOS-re, iOS-re, iPadOS-re, tvOS-re, watchOS-re akar fejleszteni, az igenis lesz szíves és megtanulja a natív nyelvet, nem kezd el kókányolni mindenféle fos JavaScript(-helyettesítő) nyelvekkel.

A JavaScript elég kárt okozott a weben már így is. Franc akarja importálni a szart még a natív platformokra is...

Objective-C-vel én is hadilábon álltam. Úgy voltam vele, hogy addig, amíg az a nyelv az, amiben fejleszteni kéne, addig hozzá nem nyúlok az Apple platformhoz. Egyszerűen gusztustalan a szintaktikája (ebben hasonló a JavaScripthez).

Szerencsére az Apple a szokásos innovatív, felhasználó-, és fejlesztő központúságával bevezette a Swift-et és modernizálta a stack-et, így már jó pár éve meglehetősen fájdalommentes az Apple-ecosystemre való fejlesztés.

Próbáld ki egyszer: sose árt, ha szélesíted a látóköröd egy rendezett, normális, modern platformmal...

... máshol nehezen találsz ilyet.

Nyilván a weboldalakat is egy idő után swift-ben kéne írni, és a cordova és társai is be lesznek tiltva, csak én nem hallottam még róla? Tekintve, hogy már majdnem a komplett szakma letette a voksát a pwa irány mellett, szerintem nem a TV gyártóknak kéne megmondani, hogy milyen legyen a hírbemondó ruhája és az adás hangereje. Értem, élmény, meg hardware gyártóként a brand-em nehezen elválasztható a fogyasztott tartalom minőségétől, vagyis inkább a fogyasztás élményétől, de azt azért te is láthatod, hogy az Apple rengetegszer hajlott már meg. Ki is akarta először CSAK WEBES appokkal futtatni a telefonját? :)

(Mondom ezt webesként, pontosan látom, hogy a js még most se a legjobb megoldás, főleg nem mindenre, de mint írtam lentebb, ez egy cost-benefit számítás, sokan vannak, akiknek nem éri meg pénzügyileg több platformra fejleszteni. Nem beszélve arról, hogy a felhasználók is kevésbé hajlandóak app-okat telepíteni, frissítéseket megvárni, ...)

Ha nem válaszolnék kommentben, hát küldj privátot!

A PWA mellett nem a szakma, hanem a web"fejlesztők"taknyolók tették le a voksukat (sajnos ezek mostanság a hangos kisebbség).

Nekik minden is JavaScript alapúan kell múkodjon, mert máshoz nem értenek (Electron, NodeJS, meg az összes többi, ami prototipizálásra tökéletes -> ami egy script nyelvtől nyilván el is várható <-, de production-ben hányadék, karbantarthatatlan szar -> ahogy egy script nyelvtől nyilván várható <-> a prototipizálás után ugranak be az igazi programozók a script-kiddie-k helyett). A PWA-t a Google tolja, mert ők a vékony-kliensre, cloudra, webre esküsznek, hiszen nekik abban van a lóvé, ha a user adatai náluk elemződhetnek, nem a felhasználó eszközén, a Big Brother kémlelő szemeitől mentesen.

Igen, 10+ évvel ezelőtt, az első iPhone-nal az volt az elképzelés, hogy web alapú lesz. Ez az opció elég hamar el is lett vetve, mert szuboptimális UX-et eredményez; ehhez képest a kugli még mindig nyomja a megbukott paradigmát. Nem csoda, hogy nem képesek minőséget alkotni.

A PWA helyett az Apple normális eszközöket ad a fejlesztők kezébe: Swift + SwiftUI + AppClips

https://www.apple.com/uk/swift/

https://developer.apple.com/xcode/swiftui/

https://developer.apple.com/app-clips/

Semmi szükség az elbarmolt webes technológiák erőltetésének a natív élmény helyett. Próbálták ezt már a PhoneGap-pel, Cordovával, meg a mittudoménmivel. A cross-platform csodaszerek nem csodák, hanem pótcselekvések, sose lesznek pariban a natív eszközkészlettel: ld. Electron, Qt, Xamarin, régebben Adobe Air. (JavaFX, emlékszik még rá valaki?) Valahol mindig elvéreznek.

Pontosan tudom, hogy a messiásként ütvözölt cross-platform keretrendszerek szarok, mert évekig, évtizedekig abban reménykedtem, hogy: "na majd most. Majd most jó lesz". Sose lett jó. Ezért is kellett belemerülnöm az Apple ökoszisztémába, mert saját használatú cross-device (desktop/laptop, tablet, telefon, watch, okosTV) fejlesztésre nincs egy elérhető keretrendszer. Csak az Apple-nél.

Középszerű szoftver fejlesztésére, melyeknek csak egy dolga van, hogy felbasszák a fejlesztők/userek agyát, arra tökéletesek a cross-platform toolkitek.

Normális szoftver fejlesztésre viszont a natív technológiák valóak.

A LucasArts mar a 80-as evekben megcsinalta a SCUMM-ot, mert nem akartak ugyan azt a jatekot 5x megirni 0-rol. Egy nem teljesen nativan kinezo/mukodo app meg mindig jobb mint egy nem letezo. Biztos nagyon jo a swift, de hogy appleon kivul hasznalhatatlan barmire az teny. Cserebe az apple okoszisztema egy hulladek ha egy hangyafosnyival is el akarsz terni attol ahogy steve jobs vagy ki van most eppen megalmodta. Meg akarsz nyitni egy fajlt? Nehogy mar fopent hivj, az nem fog mukodni ha veletlenul nem pont abban a bugos unicode normalizalasi formaban van amit az OS elvar, de itt van ez a random objective-c fuggveny, hivd inkabb ezt. Meg a c/c++ linkeruk is egy katasztrofa.

I hate myself, because I'm not open-source.

( Hevi v | 2020. 12. 18., p – 21:54 )

Mindig a natívra kell törekedni, a cross-platform fejlesztés szub-optimális UX-et eredményez.

Manapság pl. a Teams idegesít fel naponta az OS-hez nem illeszkedő, egyéni notification-jeivel. Ahelyett, hogy simán jobbra swipeolhatnám az eltűntetéshez, pixelvadászkodnom kell az x-et.

Baromi zavaró az inkonzisztens működés.

( kisg v | 2020. 12. 18., p – 23:31 )

Az Electron nem "JavaScriptre" épül, hanem a Chromium böngészőmotorra, aminek valóban része a V8 JS motor. Ez azt jelenti, hogy magát a megjelenítést egy sokmillió USD-ből szénné optimalizált engine végzi, amit milliárdnyi ember használ naponta gyakorlatilag minden platformon (kivéve iOS, bár most, hogy a V8-nak van interpreter only üzemmódja, lehet, hogy a Chrome for iOS is V8-at fog használni, a Nativescript már átállt rá például). A V8 egy nagyon hatékony engine, és ha valaki semmiképpen nem akar TypeScriptet használni, akkor van opció másra WebAssemblyn keresztül.

Azt kell látni, hogy ha a feladat az, hogy Web, Windows, Linux, MacOS, Android és iOS platformon kell egy "üzleti" alkalmazással megjelenni (tehát listák, szöveg, képek, alapvetően 2D UI), akkor jelenleg ezt a Web platformmal + Electronnal + Nativescript (Vue) vagy React Native (React) lehet egy kódbázisból a legjobban lefedni. Ráadásul sok esetben el lehet indulni egy Web + PWA (mobil) irányból, és ha elég népszerű a termék, akkor mellé lehet rakni az Electronnal csomagolt "natív" appokat, és ha szükséges a mobil appokat is.

Természetesen nem állítom, hogy minden projektnél ez az üdvözítő út, de azt igen, hogy sok (és egyre több, ahogy az eszközök fejlődnek) projekt esetén reális alternatíva és ha jól csinálják, akkor olcsóbb, mint többször megírni ugyanazt. 

Memóriahasználat: nem méregettem, de nekem nem a VS Code, a Slack, a Skype vagy a Chrome szokta megenni a gép erőforrásait. És ha mondjuk a VS Code-ot nézzük, ha nem triviális méretű projektjeid vannak, akkor az IntelliJ-nél is kb. első dolga az embernek 4-8GB-re feltolni a JVM heapsize-t. Ehhez képest a VS Code egy multiprocess architektúrára épül (Unix hagyományok követése a Microsofttól!!!444! :) ), és az én tapaszalataim szerint sokkal jobban skálázódik, mint egy IntelliJ vagy Eclipse.

Nem állítom, hogy nincsenek hátrányok, pl. nagyobb a runtime, amit le kell küldeni akár mobilra akár desktopra, mintha az adott platform natív eszközeit használnánk. Emiatt jó mérnökként minden feladatnál meg kell vizsgálni, hogy az adott célra megfelelő-e.

Hadd csináljak a fentiekből egy rövid verziót (nyilván csorbítva):

A legtöbb webes eszközökkel készített program most már Chrome-ban fut (pl. a Cordova és hasonlókba csomagolt mobil app is), ami egy eszméletlen elterjedt és kitesztelt eszköz. A JS nem optimális megoldás egy üzleti alkalmazásra sem már, de üzletileg nehéz megindokolni sok esetben azt, hogy az amúgy elérhető hardware-ből kevesebbet használjunk, de ezért cserébe 4-8 platform függő eszköztárra fejlesszünk párhuzamosan.

Még rövidebben:

A web nem gyors, nem optimális, de multiplatform, és ez által nagyon sokszor olcsóbb. Ha az alkalmazás nem kívánja meg a nagy teljesítményt (kliens oldalon). Pl. ha amúgy is webre készülne, és az érdemi logika szerver oldalon van.

(Nem mellesleg sokszor adott a lehetőség a teljesítmény igényes részeket kiemelni natív kódba, Cordova-ban sokszor történik ilyen, Electron-t nem ismerem, de meglepne ha ott nem lenne ilyen megoldás, ha már a Chrome-ban többféle módon is adott ez, webassembly, extension-ön keresztül üzengetések, rég néztem, de mintha ez is kiszervezésre alkalmas lenne.)

Ha nem válaszolnék kommentben, hát küldj privátot!

"A legtöbb webes eszközökkel készített program most már Chrome-ban fut (pl. a Cordova és hasonlókba csomagolt mobil app is), ami egy eszméletlen elterjedt és kitesztelt eszköz. A JS nem optimális megoldás egy üzleti alkalmazásra sem már, de üzletileg nehéz megindokolni sok esetben azt, hogy az amúgy elérhető hardware-ből kevesebbet használjunk, de ezért cserébe 4-8 platform függő eszköztárra fejlesszünk párhuzamosan."

Úgy tudom, hogy a NativeScript és React Native esetén nem Chrome-ban fut – annak ellenére hogy JavaScript / TypeScript-ben írod az alkalmazást.

Azt aláírom, hogy rossz az Electron-alapúság, de nem minden Electron-alapú alkalmazás egyformán szar. Abból is vannak jobban és rosszabbul megírtak, ahogy anno Java-ban írt alkalmazásoknál is így volt. Aki gányol, annak mindegy milyen eszközt adsz a kezébe, azzal is gányolni fog, akár natív, akár webes.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( LCoder | 2020. 12. 19., szo – 11:26 )

A VS Code még mindig karcsúbb mint a Visual Studio a maga millió sornyi legacy win32-es C++ kódjával. Amúgy a web mint fejlesztõi platform tényleg egy fos, elsõsorban a Javascript miatt - bár ami azt illeti, a html mint olyan sem piskóta - viszont a web kliens oldalon ma sajnos megkerülhetetlen. Nyilván jobb lenne egy szerencsésebb csillagzat alatt született platform, ahol a form leíró nyelv nem egy xml alapú dokumentum formátum, ahol a mögötte lévõ kódot nem egy dinamikus típuskezelésû szutyokban írjuk meg, ami ráadásul text formában megy le a kliensre, de sajnos az evolúció ezt dobta.

A Visual Studiot nem a legacy win32 kódok teszik bloattá, hanem az idő előrehaladtával egyre inkább köré gányolt .NET-bloat betétek. Na, annál tényleg "hatékonyabb" egy jól megírt Electron app. Ez viszont nem az Electron vagy a Google érdeme, hanem a Microsoft szégyene.

( SPYFF v | 2020. 12. 19., szo – 11:29 )

Jól esik belekiabálni az éterbe így, hogy félig ontopic: utálom az Electront! Webes alkalmazások igénytelen módon asztalra portolva. Teljesen racionális, hogy ne kellejen semmit megírni kétszer, véletlenül se készüljön natív asztali alkalmazás még akkor sem, hogy amúgy több tíz vagy százmillió user van, milliárdos bevétellel. Ja és van memóriám meg a processzorom is erős, csak simán zavar hogy mindezek ellenére mennyire csiga lassúak ezek az Electronos hulladékok. Slacket és Discordot kiváltottam a Qt-s ripcord-al, első kettő együtt nagyjából 1-1,5 giga memórát evett, ez kb. 90 megát, sajnos a felülete nem a legjobb de cserébe rohadt gyors, minden késleltetés nélkül működik rajta. Igyekszem akivel lehet Telegramon tartani a kapcsolatot, szintén van natív alkalmazásuk minden platformra és szintén piszok gyors.

Egy méret felett megoldható a natív alkalmazás, sőt, elvárható lenne az optimizálás, de látod, úgy hozta a UX fókuszcsoport, hogy nem igénylik a vevők, vesznek inkább új telefont, mert lassúak már az appok, mintha a processzor rozsdásodna, vagy valami hasonló.

Viszont, mit mondanál annak a KKV-nak, aki szeretne megjelenni a szolgáltatásával, és ki akar lépni a böngészőből, de nincs pénze natív kódot íratni? Feltételezd, hogy mondjuk nem egy leszarom stílusú kóderük van, aki egyébként mondjuk nem azzal kezdi a fejlesztést, hogy beránt 32 Mb-nyi .js kódot, hanem kicsit inkább alulról építkezik? (Tudom tudom, nincs is ilyen. De van.)

Ha nem válaszolnék kommentben, hát küldj privátot!

látod, úgy hozta a UX fókuszcsoport, hogy nem igénylik a vevők

A jelenlegi marketing- és designer-diktatúrában egy UI elsősorban demózható lesz, másodsorban eladható, harmadsorban trendi és csak utolsósorban használható. A használati eseteket pedig többnyire IQ=80 ösztönlényekből összerakott fókuszcsoportokban mintázzák, hogy Tapicskoló Tamás egységsugarú tech-birka is tudjon vele valamit kezdeni anélkül, hogy esetleg rászánna időt, hogy megtanulja használni. Miközben meg úgy kellene eltiltani a digitális eszközök használatától, mint jogsi nélküli sofőrt az autóvezetéstől.

vesznek inkább új telefont, mert lassúak már az appok, mintha a processzor rozsdásodna, vagy valami hasonló

A tech-multik és a kereskedelmi szektor által folytatott fejlődésmániás marketing-hadjáratok elhitetik velük, hogy csak akkor lesznek menők™, csak akkor érnek valamit™ és csak akkor nem maradnak™ le™ semmiről, ha mindig mindenből megveszik a legújabbat.

Viszont, mit mondanál annak a KKV-nak, aki szeretne megjelenni a szolgáltatásával, és ki akar lépni a böngészőből, de nincs pénze natív kódot íratni?

Neki azt mondanám, hogy csak akkor adjon ki "natív" alkalmazást (mert ugye az Electron minden, csak nem natív), ha feltétlenül szükséges és a nyújtott szolgáltatás szempontjából van jelentősége annak, hogy az alkalmazás az ügyfél gépén fusson. Persze nem kémkedésről és nem olyan modern kori idealizmusokról beszélek, mint pl. a felhasználói "élmény" telemetriája, hanem pl. egy árusított termékhez kell lokálisan kapcsolódnia egy gépnek. Minden más esetben jobb, ha nem ad ki saját alkalmazást, inkább csinál jól összerakott, optimalizált, normális honlapot.

Ripcordban is van bloat, pl ha kettőspontot raksz akkor automatikusan elkezd mindenféle ábrákat, emotikonokat feldobni, mindezidáig nem tudtam kikapcsolni, de már hozzáfogtam a bináris patcheléséhez, nincs szétobfuszkálva. Valamint a jobb oldalt ha benne vagy több slack és discord csoportban, akkor össze tudnak folyni a dolgok, legalábbis nem túl jól szeparálja el a csoportokat, csatornákat és felhasználókat, 1 réteg mély az egész, nincs vizuálisan gyorsan felismerhető hierarchia és nem is túl konzisztens. Persze a gyakran használt partnereket és csatronákat kiraktam a favoritesbe és úgy már boldogulok. 

A Telegramnál az animációkat ki lehet kapcsolni, és az emotikon kiegészítést is. Azzal egyetértek, hogy a kelleténél nagyobb padding van a szövegek körül asztali gépen, de - szemben sok más progival - még ízléses és csak közepesen helypazarló (szubjektíven más alkalmazásokhoz képest amiket használok) így bármihez hozzáférek pár pillanat alatt. Ami még nagyon jó, az a keresője, hatékonyan tudok korábbi üzeneteket visszakeresni. Aminek valóban örülnék és ebben teljesen egyetértek, hogy jó lenne ha a fontokat lehetne Telegramban módosítani, lejjebb venni a méretüket, kiválasztani más betűtípust, stb. Sjnálom hogy ezt nem tették bele.

( dap | 2020. 12. 19., szo – 12:11 )

Az az Electron a desktopnak ami a Flash volt a webnek. 🤮

A Flash egy előremutató, innovatív platform volt, rendes OOP nyelvvel (ActionScript 3), vektorgrafikával, normális IDE-vel, normális debuggerrel, normális leíró nyelvvel (MXML).

A szar html5 tákolmányok a nyomába se érnek. Még ha anno a béna html5 helyett xhtml irányba mentek volna el, még csak-csak. De azt a fos JavaScriptet is le kellett volna már rég cserélni valami használható nyelvre, amiben nem csak kókányolni lehet.

A Flash fejlesztőkörnyezete egyértelműen rendezettebb volt a ma erőltetett megoldásoknál, ugyanakkor az előállított produktum futtatása ritka nagy bloat volt és alig volt olyan számítógép, amin kifogástalanul működtek akár az legegyszerűbb SWF-ek. Egy jól összerakott, nem bloated HTML5-CSS-JS megoldás egy 12 éves gépen is tud gyors lenni.

Sem a Macromedia, sem később az Adobe nem fordított elég erőforrást az optimalizálására. Biztonsági résekben vezette a CVE listákat. Más kérdés, hogy nem kisebb (sőt nagyobb) bloat egy modern kori webökör által HTML5-JS-CSS alapon összegányolt bloated framework-ös csiligány, animációbuzi szemétdomb, amit honlapnak nevez.

Tehát, maga a technológia sokkal összeszedettebb volt, mint a mai tákolmányok, de a megvalósítás és a karbantartás terén pocsék munkát végeztek multiék. Nyilván túl milliárdosok voltak ehhez (is).

( hory v | 2020. 12. 19., szo – 14:02 )

Szerkesztve: 2020. 12. 19., szo – 14:03

Sok esetben nem is az app-el van a baj, hanem hogy letezik egyaltalan az app. Baromi sokmindent lehet siman webrol intezni. Pl nemtom, miafaszra jo, hogy van index.hu app, reddit app, meg amazon app. Ezeknek kvazi az a funkcioja, hogy mindig a felhasznalo orra elott legyenek, ne felejtsen el rakattintani (komoly!). Weboldalt ugye elfelejti megnezni a csoka, letorli a linket veletlenul, ilyesmi. App-nal ez kevesbe jatszik be. Es persze az app tud notification-t kuldeni, amivel tovabbi modot ad a felhasznalo figyelmere (=hirdetes/bevetel).

Pontosan, ettől én is falramászok, hogy minden szirszar weboldal telepíteni akar. Szerintem is ennyi értelme van, hogy jobban az ember arcába tud úgy mászni. Notificationt most már weboldal is tud küldeni, nem? Azzal is zaklat minden hülye híroldal legalábbis de még egyre sem iratkoztam fel.

Ha valaki nagyon akarja, akkor még offline működést is tud csinálni az újabb Web API-k segítségével, szóval még az sem elég indok arra, hogy települni kelljen.

A PWA-ról egyébként az a véleményem, hogy olyan a "specifikáció", mintha szándékosan azt akarták volna, hogy komoly program írására alkalmatlan legyen: például éppen a storage méretére nem tudsz garanciát kérni, ha jól emlékszem. Írsz egy offline is működő alkalmazást és éppen a legrosszabbkor fogja eldobálni az adatot, ha nem vigyázol. Ha például valami adatbázist kezelnél, akkor ez elfogadhatatlan.

A PWA-nak szerintem pont ez az egyik legnagyobb korlátja, mint anno a mobilappok rendszerénél, hogy a localstorage az törlődhet, ha pl. frissül a chrome, vagy hogy is volt. Hát, nem egy üzleti célra elfogadható eset :). A fájl kezelés nem tudom most hol tart, de szerintem ez is mutatja, hogy a legtöbb üzleti cucc felköltözik végleg cloud-ba, lesznek lefedettség hiánya esetére edge case-re gyártott app-ok, és ennyi. Amikor már a gaming is megy cloud irányba, akkor mit vártok, hogy a fitness naptár nem megy majd oda?

Ha nem válaszolnék kommentben, hát küldj privátot!

Ez üzleti, nem technikai probléma. Van ahol azért érdemes app-ot készíteni telepíthető formában, mert legalább részben képes offline működni, de monduk a PWA korlátait nem szeretnéd kerülgetni, vagy adatbiztonsági okokból jobb szeretnéd külön tárolni az app adatait a böngészőjétől, esetleg tiltva van a böngésző. Ez mondjuk nem a reddit, vagy az amazon esetén igaz, ők csak szeretnének kikerülni a homokozóból, értesítéseket küldeni, adatokat figyelni, de ez megint annak a problémája, hogy a felhasználókat ez nem érdekli, telepítik, mert miért ne. Lehet nem is olyan fontos a személyes szféra? Lehet nincs is?

Ha nem válaszolnék kommentben, hát küldj privátot!

( Nickname | 2020. 12. 20., v – 10:01 )

Úgy gondolom, ahogy ti a html és a js css trió nem desktopra van/volt kitalálva. Ugyanakkor érthetetlen, higy most a fejlett html5 API stackkel már tényleg mindent is implementálni lehet.

A gond a nyelvi "fejeltlenség" és a tisztességes GUI toolkit hiánya. Ahogy anno létrejött ezért a qt aztán a gtk , tk és társai.

Aztán a java írd meg egyszer, futtasd bárhol filozófia létrehozta az awt,swing, javafx csodákat, megszűlte a wicket -et. Jött ugye az Applet, mint Messiás, később a JavaWebstart. De ez állam az államban hibrid erőszak volt. Ahogy a flash és a silverlight is.

Google kapcsolt annó elsőként észbe, még az Android era előtt, de már a JVM -es szerelemben a gwt-vel.

Ekkor érezte igazán, hogy elöl is lehetne tekerni a dolgon: legyen egy jó nagy okos optimalizált runtime elöl, ami platform inkább és nem csak egy display. Volt itt Google Native Client, Dartium is, végül a js motor csiszolásával, a nodejs hype-ra felülve adott egy js alapú böszme technológia stacket, amivel gyorsan lehet nagy batár dolgokat létrehozni és mindenhol futy ahol a böngésző, vagyis a java szelleme tovább kísért.

Amit most nézegetek az ő: http://www.jsweet.org/

Ha itt lenne egy tisztességes react/vue transpiler, tartana ott a tudomány, hogy eldöntenék végre, h a css vagy a js felelős-e viselkedésért gui oldalon, nos megvalósulna a tisztességes nyelv és a multiplatform nativ runtime concept. Mert igen, csak egy lépés innen webassembly -re tolni a JVM byte-code ot. És eljő a segfault a böngiben, ahogy a "csak egy browser a rendszer" concept felé tartunk is.

Újra. :-)

( zrubi v | 2020. 12. 21., h – 09:17 )

Szerkesztve: 2020. 12. 21., h – 09:18

Fogalmam sincs, hogy vim-nél mi lehet hatékonyabb ;)

eddig minden ment vele, soha nem merült fel, hogy valami kattintgatós izé lehet-e ennél hatékonyabb.

zrubi.hu