Funkcionální frontend - zkušenosti?

[andy]

Navíc celej ten koncept SPA se mi nelíbí (nemožnost odkazovat přes URL zvnějšku apod.)

Tohle je ale dneska non-issue. V angularu se to dělá tak, že ve frontendové aplikaci byly view v "/app/cokoliv", server pro "/app/cokoliv" servíroval default HTML stránku, angular si následně z linku automaticky zjistil, na který jsi stránce a otevřel ti to view. Při kliknutí na link automaticky vyupdatoval URL v záhlaví. Takže jediná otázka je, jak se k tomu postaví search enginy a i ty už to dneska nějak zvládají.

Momentálně se snažím všechna data přenášet přes websockety (REST jsem už víceméně pohřbil), takže to je jenom otázka definice handlerů pro události ze strany serveru a funkcí pro volání z druhé strany. Nechám si to projít hlavou, možná spojení tohodle + nějaký rozumný framework (Cycle.js nebo React) by bylo pro mě nejlepší.

Erlang přístup Já používám v haskellu Servant a ten umožňuje jednoduše nadefinovat Rest API, ale na websockets v tom nic není - ale je to zajímavý, možná teď budu psát nějakou aplikaci, kde by se mi to hodilo, tak uvidím, co z toho vznikne.

To bych určitě nebyl ochotnej akceptovat. Jednak mě to dráždí principielně ale hlavně taky potřebuju servírovat mobilům a tam je to s těma datama pořád na štíru... Kolem 100kb je ok, níž se dneska člověk nedostane, kolem 200 už začínám brblat a 400 a víc by bylo vyloženě nepřijatelný

GHCJS na mobily není. To není principiální věc, prostě není, ten runtime je trošku žravý a mobily to nedávaj. Haste generuje výrazně menší kód a je dost haskell-compatibile, problém je, že i něco typu "90% kompatibilní" je na houby, když zrovna potřebuješ něco z těch 10%... možná teď budu psát aplikaci, která teoreticky bude i na mobily, tak budu asi zase hledat

[Reklama]

[Mirek Prýmek]

Erlang přístup

Jj. Moje největší webová aplikace je frontend k monitoringu a správě sítí, takže to jsou pořád nějaký tabulky a grafy a všechno by to mělo být pokud možno dynamický. Takže události, události, události, většina asynchronní - ideální use case pro Erlang

Nejčastější věc, kterou řeším, je vygenerování tabulky z nějaké datové struktury + její updaty (z obou stran - události ze server, události od uživatele). Doteď jsem to dělal "po staru": počáteční tabulka se vygeneruje pomocí tamplatu na backendu a úpravy pak řeší pomocí jquery. Ale už mě to začíná silně prudit, protože se ten kód duplikuje a špatně udržuje. Vždycky to začne s tím, že "jquery stačí, událostí bude málo" a jak se to postupně komplikuje, je to čímdál větší opruz.

Takže moje současná představa je dělat to tak, že template vytvoří jenom omáčku: vlastní stránku + menu a připojení na websocket. Hned po připojení se přes WS pošle init stav, který se vykreslí už čistě na frontendu, a změny se posílají už jenom přes WS. Blbý na tom je, že tímhle způsobem tam vznikne lag mezi vykreslením menu a contentu, ale co jsem to zatím testoval, je to celkem rychlý, takže by to nemělo vadit. Pokud bych zjistil, že to problém je, nechal bych komplet stránku vykreslit na frontendu. Lag tam sice pořád bude, ale aspoň se vykreslí všechno naráz, což je asi pocitově příjemnější.

Tahle představa je teď ve fázi testování, možná se to ukáže jako blbost a udělám to jinak Ale teď momentálně se mi ta představa líbí, je to takový hezky jednotný a přímočarý

[Mirek Prýmek]

BTW, jeden z důvodů, proč bych chtěl vykreslovat čistě na frontendu, je ten, že ty události chodí fakt kdykoli (z nižší vrstvy aplikace, úplně mimo web) a mezi vykreslením na backendu a připojením na websocket je mezera, ve které se nějaká událost může ztratit - na webu se neobjeví. Ne že by to byl nějakej třeskutej problém prakticky, ale pocitově mě to silně dráždí, protože to je návrhový nedostatek

[v]

já bych taky potřeboval GUI k aplikaci ve funkcionálním jazyce (Haskell), jestli mi poradíte jak na to tak se pak podělím o zkušenosti
dá se říct, že ve webových technologií jsem úplně ztracený
chci napsat co nejmíň html a js, data posílat přes ws a spa (jestli jsem to správně pobral) mi nevadí, možná právě naopak, charakteristika aplikace je shodná s tou prýmkovou (technologie něco dělá, stromy, tabulky a grafy se mění)

[noef]

Navíc celej ten koncept SPA se mi nelíbí (nemožnost odkazovat přes URL zvnějšku apod.)

Nemoznost odkazovat se na SPA - takovy problem davno neni. V Angularu to resi napr. ui-router a o vsechno to prepisovani URL a historii se to stara samo. K "apod." a "SPA se mi nelíbí" se bohuzel nemohu moc vyjadrit, chce to uvest konkretnejsi duvody.

Mně vyhovuje, že když mám oddělené stránky, můžu si na backendu řešit, která je jak autentizovaná apod. Tohle určitě měnit nechci.

Muzete mit oddelene REST end-pointy a ty authentizovat stejne, jak nyni mate stranky, nevidim v tom zadny problem.

Presne jak popisujete to generovani na serveru a pak znovu na FE, tak by to SPA elegantne preklenulo - proste se vsechny stranky generuji na klientovi a hotovo. Server pak muze "zhloupnout" a slouzit spis jako prostrednik na preposilani dat a overovanim auth tokenu.

[Reklama]

[bjarne]

Kdyby slo o SPA, tak bych jednoznacne kazdemu doporucil Meteor + React + Underscore a nejaky knihovny na routovani (asi ReactRouter) a formulare (asi formsy-react). Na normalni stranky je to zbytecny, to je jasny. Me se ted hodne zalibilo prave to Elm (vlastne si to myslim daval ty ten odkaz na nejakou prezentaci na YT), ale nemel jsem moc casu se na to podivat nejak podrobneji, protoze ted fusuju do neceho jinyho. To Elm pry resi vsechno co React a jeste daleko lepe a elegantneji (hlavne protoze to neni JavaScript).

[noef]

Ta ScalaJS vypada fakt zajimave, pusobi to na me, ze se celkem rozjizdi (musim se k tomu nekdy dokopat a zkusit ji). Ma to "bindingy" na React, Angular, Vue a dalsi. Z FP knihoven to podporuje i tezkotonazni Scalaz, coz me celkem prekvapilo. Vykonem i velikosti ty vypada i pouzitelne. Akorat teda nevim, jestli se to OP vyplati zkouset, pokud jazyk na BE ma uz zvoleny, protoze tim IMO prijde o tu nejvetsi vyhodu - jeden silne typovany jazyk na obou stranach, coz umozni sdileni kodu.

[Mirek Prýmek]

Nemoznost odkazovat se na SPA - takovy problem davno neni. V Angularu to resi napr. ui-router a o vsechno to prepisovani URL a historii se to stara samo. K "apod." a "SPA se mi nelíbí" se bohuzel nemohu moc vyjadrit, chce to uvest konkretnejsi duvody.

Jak jsem říkal, weby mě neživí, takže to nemám nastudované kdovíjak do hloubky. Věřím, že všechny problémy nějak řešit jdou, ale nemám motivaci je řešit, když ty problémy nemám Pro mě osobně je to dost narovnávák na ohýbák... Začít dělat SPA by mi nepřineslo nic než spoustu práce a problémů.

Presne jak popisujete to generovani na serveru a pak znovu na FE, tak by to SPA elegantne preklenulo

To ano, ale taky by se na FE přenesla logika, kterou tam mít nechci, protože si ji pohodlně a příjemně řeším na BE a nemám motivaci to měnit. Ten způsob s websockety, který jsem popisoval výš, je prakticky stejný, jenom ty stránky zůstávají. Kdybych časem zjistil, že se jich chci zbavit a přejít na SPA, tak už to potom bude snazší.

[BoneFlute]

- Zkompilovaný js je VELKÝ (1MB+)

Zkoušel jsi použít Google Closure Compiler? Teoreticky by měl umět vyhazovat smetí, nepoužité věci, a tak.

[Mirek Prýmek]

Me se ted hodne zalibilo prave to Elm (vlastne si to myslim daval ty ten odkaz na nejakou prezentaci na YT), ale nemel jsem moc casu se na to podivat nejak podrobneji, protoze ted fusuju do neceho jinyho. To Elm pry resi vsechno co React a jeste daleko lepe a elegantneji (hlavne protoze to neni JavaScript).

Elm se mi líbí hodně. Ale pořád si nejsem jistý praktičností. Přece jenom jeto haskellovitost - nemůžeš jenom tak někam šáhnou a udělat rychlou úpravu, protože se ti rozjedou typy... Mají skvělou JSON knihovnu http://package.elm-lang.org/packages/elm-lang/core/1.1.0/Json-Decode jenže zas - struktura JSONu musí přesně sedět. Když se tam objeví null někde, kde jsi ho nevyspecifikoval, celý JSON spadne pod stůl, protože se nenamatchuje...

Na kvalitní precizní práci a na větší projekty to musí být skvělý, to si umím přestavit. Jenom nevím, jestli já ty svoje věci nedělám trochu moc živelně na to, abych tohle mohl efektivně použít. A navíc Haskell sice trochu znám, ale nic reálnýho jsem v něm nedělal, takže je to pro mě trochu mindfuck Uvidím, jestli seberu odvahu se do toho pustit. Zatím se mi to líbí hodně.

[noef]

Jak jsem říkal, weby mě neživí, takže to nemám nastudované kdovíjak do hloubky. Věřím, že všechny problémy nějak řešit jdou, ale nemám motivaci je řešit, když ty problémy nemám Pro mě osobně je to dost narovnávák na ohýbák... Začít dělat SPA by mi nepřineslo nic než spoustu práce a problémů.

Zato presun na ciste funkcionalni UI problemy neprinese? Na narozdil od toho cisteho FP se SPA pouzivaji v obrovskych web aplikacich (predevsim Angular 1 a React), takze jak pises vyse, na ta jednoducha pouziti je to plne vychytane a na ta slozitejsi se muzes spolehnout obrovskou komunitu. To u Elmu nebo PureScriptu proste nemas a asi ani vyhledove v nekolika letech mit nebudes.

K "narovnávák na ohýbák" - ze zacatku jsem byl taky skepticky, ale bylo to dano jen tim, ze jsem byl zvykly na stary zpusob. O SPA premyslej jako o applikaci na smartphone, klientovi se jednou prenese (nainstaluje) a appka si sama vse rendruje a otravuje server jen kvuli datum a operace s daty, ne kvuli kazdemu prekresleni stranky, ktere musi byt specialne reseno pro kazdeho klienta.

Začít dělat SPA FP UI by mi nepřineslo nic než spoustu práce a problémů.

...

To ano, ale taky by se na FE přenesla logika, kterou tam mít nechci, protože si ji pohodlně a příjemně řeším na BE a nemám motivaci to měnit. Ten způsob s websockety, který jsem popisoval výš, je prakticky stejný, jenom ty stránky zůstávají. Kdybych časem zjistil, že se jich chci zbavit a přejít na SPA, tak už to potom bude snazší.

Tak jiste, pokud mas uz BE hotovy vcetne sablon stranek, tak to za to nestoji. Pokud ale ne a nemusis resis takove pytloviny jako podporovat ne-JS verzi a 10 let stary prohlizece, tak mi SPA prijde jako dobra volba. Resp. proc chces mit stav klienta na serveru? Vetsinou muze byt BE ukradeny, ze Lojza je na strance "o projektu". Definovani routovani je (z mych velmi omezenych zkusenosti s BE) hodne podobne jako na BE, akorat to pises pro klienta misto pro server. K tomu overovani, vzdyt to snad musis stejne resit primo na jedno pripojeni WS, takze v SPA verzi se nic nezmeni, ne (je teda mozny, ze to neni pravda, s WS jsem delal jednou)? Zrovna toho prihlaseni bych se treba v Angularu vubec nebal, je to v podstate jen jeden interceptor, kterej do kazdeho dotazu prihodi token a pak to "magicky" funguje vsude. Server si akorat zkontroluje token, pokud klient pristupuje k zabezpecenmu zdroji a konec. BE nehrabe jakkoliv do HTML, maximalne posle staticky soubor (sablonu) FE a ten si ji prechroupa. Libi se mi to oddeleni, ze na severu se neresi zadne vizualni veci, to vsechno patri na FE.

[andy]

- Zkompilovaný js je VELKÝ (1MB+)

Zkoušel jsi použít Google Closure Compiler? Teoreticky by měl umět vyhazovat smetí, nepoužité věci, a tak.

Oni se ghcjs snaží udělat tak, aby s tím fungovalo (a při nějaké rozumné optimalizaci s tím snad funguje), ale nějak extra výrazně to nezmenší. Navíc jak je Haskell lazy, tak ten runtime je prostě trošku žravější... ale možná to ještě zkusím, mrknu, co to udělá.

[noef]

Eh, >1MB je teda zatracene velky. Ta ScalaJS mela runtime myslim 50kB. Jen tak pro srovnani - Angular, ktery je na pomery JS sveta obrovsky, ma ~150kB.

[Radek Miček]

Eh, >1MB je teda zatracene velky. Ta ScalaJS mela runtime myslim 50kB. Jen tak pro srovnani - Angular, ktery je na pomery JS sveta obrovsky, ma ~150kB.

V tomhle jsou dobré kompilátory OCamlu do JavaScriptu. Například ze stránky BuckleScriptu (zatím není vhodný pro produkční nasazení):

Runtime performance:
    BuckleScript Immutable Map: 1186ms
    Facebook Immutable Map: 3415ms

Code Size:

    BuckleScript (Prod mode): 899 Bytes
    Facebook Immutable : 55.3K Bytes

[noef]

Tak pokud by slo hodne o velikost, tak bych tipoval ze bude dobre se drzet co nejblize JavaScriptu (napr. Flow nebo LiveScript, ktery se mi dost libi) a ne se snazit dostat behove prostredi z JVM do JavaScriptu jako v pripade Scaly. Ale abych pradu rekl, tak si myslim, ze problem velikosti JS souboru je zbytecne precenovany. Pokud mate dobre nastavene cachovani, tak to klient bude stahovat prave jednou. Navic lze pouzit nejake verejne CDN a pak to muze klidne vychazet, ze to klient (v prepoctu na vasi stranku) bude stahovat napr. 0,1 krat za rok.