Funkcionální frontend - zkušenosti?

[Mirek Prýmek]

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.

Já ten koncept chápu, uznávám, že dává smysl, a kdybych stavěl komerční aplikaci na zelené louce s týmem lidí včetně kovaného frontenďáka, tak bych do toho asi šel. Ale to není moje situace.

Tak jiste, pokud mas uz BE hotovy vcetne sablon stranek, tak to za to nestoji.

Což je přesně moje situace Jeden z těch bodů motivace je, že mě baví Elixir a nebaví JS. A ty mi radíš vzít spoustu bezproblémově funkčního kódu v Elixiru a přepsat ho do JS frameworku, který neznám. To mi nepřijde, že by řešilo můj problém

[Reklama]

[andy]

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.

No jo, to platí pro desktop (proto taky když cíluju desktop, tak se ghcjs nebojím), ale pro mobily to funguje jinak. Ostatně - hezký příklad ghcjs aplikace je tady: http://markup.rocks/. Popravdě se mi to dost dlouho nahrává i na desktopu, natož na mobilu (který to nějak vůbec nechroustne).

[noef]

Pokud je problem, ze musis generovat HTML stejny kod jak na serveru tak na klientovi, tak to by SPA presne vyresilo. Psal jsem o ScalaJS, ktera ma binding pro Angular, takze to lze i "bez" JS. Uznavam, ze Angular ze zacatku muze pusobit slozite, ale tim, ze urcuje do urcite miry strukturu projektu vyvoj IMO v zaveru zlehcuje, protoze proste nasledujes best-practises a nemusis lepit dohromady mnoho knihoven (React osobne neznam, ale ten seznam me celkem vystrasil), protoze skoro vse, co potrebujes, mas primo v jednom frameworku pripravene k pouziti.

...
No jo, to platí pro desktop (proto taky když cíluju desktop, tak se ghcjs nebojím), ale pro mobily to funguje jinak. Ostatně - hezký příklad ghcjs aplikace je tady: http://markup.rocks/. Popravdě se mi to dost dlouho nahrává i na desktopu, natož na mobilu (který to nějak vůbec nechroustne).

Eh, Firefoxu to dalo hodne zabrat, nekolik (5?) vterin. Ale mozna teda za to muze nejaky addon, nevim. To chapu, ze by to nektere mobily polozilo. Ale treba ten overhead Scaly nepusobi tak hrozne, mozna vterina. A neni tedy lepsi misto ghcjs vzit radeji ten PureScript, ktery me jede jako blesk a je porad haskell-like?

[čumil]

FP jazyk bez reaktivity je pro real world použití naprosto nepoužitelný. A UI je real world použití ... ELM a nebo v JS skus React, dost si toho vypujčil z FRP.

[Mirek Prýmek]

ELM a nebo v JS skus React, dost si toho vypujčil z FRP.

ELM je momentálně můj favorit. Myslel jsem, že bych šel spíš do Motorcycle, ale jak jsem to testoval, tak bych si pro něj asi stejně musel dopsat tu logiku, která v Elmu je jako základ (událost -> stav -> view) a jedna věc mě dost drasticky odrazuje: pokud dojde k výjimce uvnitř promise (který se tam používají všude), tak prohlížeč nevyplivne řádek původního zdrojáku, ale řádek ve vnitřnostech knihovny. To je dost drastická komplikace, pokud se to nedá nějak řešit (a nevím jak by to šlo). Je to pěkně vymyšlený framework, ale to JS je tam prostě koule na noze...

[Reklama]

[Radek Miček]

ELM je momentálně můj favorit.

Já jsem v Elmu nic nenaprogramoval, ale asi by mi chyběla řada vlastností z jiných funkcionálních jazyků (zvláště, pokud by se jednalo o větší program).

[Mirek Prýmek]

Já jsem v Elmu nic nenaprogramoval, ale asi by mi chyběla řada vlastností z jiných funkcionálních jazyků (zvláště, pokud by se jednalo o větší program).

Co máš namysli? Hodně se probírá absence (haskellovských) tříd. Ještě něco? Jako jazyk jsem to nijak detailně nezkoumal, zatím mi šlo spíš o to si to vyzkoušet prakticky - získat z toho nějaký pocit, jak by se mi tímhle způsobem pracovalo...

Můžeš pls krátce napsat, jestli je tam něco, co by na (spíš jednodušší) praktické programování mohlo mít vliv?

[čumil]

Nevím jak je na tom Elm teď, hodně dlouho jsem ho nezkoušel, před hodně měsíci sem si v něm udělal takovou hodně easy hru. A můžu říct, vítek sem měl na Elm bambilion, proto sem ho v minulých diskuzích označoval za hračku. Kupříkladu mi tam scházeli eventy na klávesnici s vetší granularitou (myslím že keyup, už nevím, možná že už v STD lib je) takže sem si je musel dohackovat pomocí JS FFI. Bohužel jsem si ten svůj seznam kritiky smazal, takže nepomůžu. Absence typových tříd mi ani nevadila, nepochybně ale jen proto že jsem psal fakt hodně jednoduchou appku.

Co je (bylo?) tragické byla absence oficiální podpory node.js. A GUI blbinek v STD lib které znemožněj něco podobného v budoucnosti.

Multithreading je (byl?) kompletně ignorován. Sice workery jsou dost tvrdě nepoužitelný pro FP (nemaj sdílení paměti), pro FPR ne protože reaktivní uzly paralelně běžet bez sdílení paměti mohou. Sice by se musel při startu ELM runtime celej poslat do workeru, ale to by nebylo tak strašný když by těch workerů nebylo moc a existovali by po celou dobu běhu. A ELM runtime není moc velkej.

[Mirek Prýmek]

Nevím jak je na tom Elm teď, hodně dlouho jsem ho nezkoušel

Co jsem tak koukal kolem a kolem, vypadá to, že jde rychle dopředu, možná, že už leccos neplatí...

Kupříkladu mi tam scházeli eventy na klávesnici s vetší granularitou [...]Co je (bylo?) tragické byla absence oficiální podpory node.js. A GUI blbinek v STD lib které znemožněj něco podobného v budoucnosti.

To mě zrovna vůbec netrápí. Můj typickej use-case je tabulka nějakých položek, u každé je několik tlačítek (smaž, zobraz detaily,...) a přes WS přichází nové položky, které je do tabulky potřeba doplnit.

Takže potřebuju, aby FE uměl vzít data, vykreslit z nich tabulku, umět na stisknutí tlačítka poslat na BE přes WS událost ve stylu ["delete",ID], BE v DB smaže položku a zpátky pošle něco ve stylu ["remove",ID] a FE ten patřičný řádek z tabulky odstraní. Plus samozřejmě taková ta klasika jako uspořádání tabulky podle sloupce, na který se klikne apod. Technicky žádné extra špeky. Pokud by se to dalo napsat obecně, jako generická logika, které by se jenom předhodila definice struktury dat a seznam událostí, co to má umět, a všechny tabulky by byly obsluhovaný jedním kódem, bylo by to úplně ideální.

Taky mám pár trochu složitějších vizualizací v D3, ale ty můžu případně nechat v JS, to mi tolik žíly netrhá.

[Radek Miček]

Hodně se probírá absence (haskellovských) tříd.

To může být jeden z problémů. Dále tam chybí třeba rozšiřitelný pattern matching nebo automatické generování kódu (například parsování hodnot z JSONu nebo porovnávání hodnot si budete muset pro každý typ napsat ručně).

Často mi také chybí polymorfní varianty z OCamlu - zejména, když systém pracuje s mnoha událostmi a různé jeho části zpracovávají různé podmnožiny událostí (ve Scale jsme k tomu používali Coproduct z knihovny shapeless, nicméně komfortem je to daleko za OCamlem).

BTW při výběru jazyka (a knihoven) doporučuji dát pozor na rychlost kompilace.

[Mirek Prýmek]

Dále tam chybí třeba rozšiřitelný pattern matching

Co si pod tím mám představit?

nebo automatické generování kódu (například parsování hodnot z JSONu nebo porovnávání hodnot si budete muset pro každý typ napsat ručně).

Parsování JSONu jsem už zkoušel (kvůli těm WS zprávám) a je to pracné. Už jsem o tom psal výš. Zas ale se to dá docela hezky parametrizovat a navíc to člověka donutí k pečlivosti (z BE prostě musím poslat správně strukturovaný JSON). Je to takové pro a proti, to je přesně ten důvod, proč nad tím dumám

Utěšuju se tím, že se mi tam ty zprávy budou asi docela opakovat, takže nějaká znovupoužitelnost by se tam mohla vyklubat...

Často mi také chybí polymorfní varianty z OCamlu - zejména, když systém pracuje s mnoha událostmi a různé jeho části zpracovávají různé podmnožiny událostí (ve Scale jsme k tomu používali Coproduct z knihovny shapeless, nicméně komfortem je to daleko za OCamlem).

BTW při výběru jazyka (a knihoven) doporučuji dát pozor na rychlost kompilace.

OCaml neznám skoro vůbec a Scalu málo, takže závažnost tohodle taky neumím posoudit. Pokud správně tuším problém, asi na to člověk musí jít v Elmu dost "ručně" pomocí klasických "union types" (tak tomu říkají v Elmu, teď si nevybavím, jestli to má nějaký spešl název v Haskellu - prostě klasické "Result a = Err | Ok a"). Akorát takhle ošperkovat pak člověk musí všechny ty podčásti, se kterými bude chtít zvlášť pracovat a to je pracné, tomu rozumím.

Taky jsem moc nepochopil, proč se v Elmu nemůže stejně jmenovat typový a hodnotový konstruktor. Autor asi chtěl předejít zmatení začátečníků, ale přijde mi to trochu nepraktické (zbytečně nové identifikátory).

[Radek Miček]

Dále tam chybí třeba rozšiřitelný pattern matching

Co si pod tím mám představit?

Můžete si definovat vlastní vzory pro pattern matching. Například pro čísla si v F# (viz active patterns) můžete definovat vzor

Kód: [Vybrat]

let (|Even|Odd|) input = if input % 2 = 0 then Even else Odd

a pak psát (match ... with je jako case ... of):

Kód: [Vybrat]

match input with
| Even -> printfn "%d is even" input
| Odd -> printfn "%d is odd" input

V praxi to lze použít třeba pro parsování. Scala má něco podobného a říká se tomu extraktory.

Parsování JSONu jsem už zkoušel (kvůli těm WS zprávám) a je to pracné. Už jsem o tom psal výš. Zas ale se to dá docela hezky parametrizovat a navíc to člověka donutí k pečlivosti (z BE prostě musím poslat správně strukturovaný JSON). Je to takové pro a proti, to je přesně ten důvod, proč nad tím dumám

Ve Scale s knihovnou circe stačí deklarovat case classu (záznam) a pak napsat jen decode[Foo], kde Foo je název deklarované case classy. Pokud není k dispozici dekodér pro Foo, tak se pomocí implicitního makra vygeneruje automaticky.

Pokud správně tuším problém, asi na to člověk musí jít v Elmu dost "ručně" pomocí klasických "union types" (tak tomu říkají v Elmu, teď si nevybavím, jestli to má nějaký spešl název v Haskellu - prostě klasické "Result a = Err | Ok a").

Ano, to lze v OCamlu také (a říká se tomu varianty). Předpokládejme, že dále máme Barva = Zelena | Cervena | Modra. Polymorfní varianty dovolují napsat funkci, jenž zpracovává pouze zprávy Ok a | Zelena | Cervena (a když do ní zkusíte dát Modra nebo Err nebo něco jiného, tak to kompilátor označí za chybu). V OCamlu je rozdíl v syntaxi - názvy polymorfních variant začínají zpětnou uvozovkou. Další rozdíl je, že se nemusí dopředu deklarovat.

Oproti Coproductu z shapelessu to má o dost lepší typovou inferenci, nezpomaluje to kompilátor a podporuje to i rekurzivní typy.

[Mirek Prýmek]

Můžete si definovat vlastní vzory pro pattern matching.

Aha, takže něco jako guards v Erlangu, ale pojmenované a znovupoužitelné. To je dobrý, to se mi líbí.

Pro zajímavost: v tom patternu můžu použít libovolnou fci? V Erlangu je to omezené jenom na některé jednoduché fce, aby se v rámci matchování neděla nějaká zvěrstva

Ve Scale s knihovnou circe stačí deklarovat case classu (záznam) a pak napsat jen decode[Foo], kde Foo je název deklarované case classy. Pokud není k dispozici dekodér pro Foo, tak se pomocí implicitního makra vygeneruje automaticky.

Hmm, to je taky dobrý!

Polymorfní varianty dovolují napsat funkci, jenž zpracovává pouze zprávy Ok a | Zelena | Cervena (a když do ní zkusíte dát Modra nebo Err nebo něco jiného, tak to kompilátor označí za chybu).

Aha, takže můžu vybrat jenom některé varianty z různých typů? To je teda dost divočina A jaký typ se z toho pak inferuje, když je to částečně Result a částečně Color? Vytvoří automaticky při kompilaci nějaký interní typ "XXXX a = Ok a | Zelena | Cervena"?

[Mirek Prýmek]

Aha, takže něco jako guards v Erlangu, ale pojmenované a znovupoužitelné. To je dobrý, to se mi líbí.

Jak nad tím teď tak uvažuju, v Elixiru by se to dalo udělat pomocí makra. Ale bylo by to asi trochu syntakticky kostrbatější a byl by tam potenciál pro špatně čitelný chyby.

[noef]

Extraktory ve Scale jsou skvela vec, pattern matching je diky nim hodne silny. Jde to treba pouzit s regularnimi vyrazy:

Kód: [Vybrat]

val Pattern = "^(.*)@(.*)$".r
"my-email@seznam.cz" match {
case Pattern(name, domain) => println(s"Got a match! name = $name and domain = $domain")
case _ => println("No match found.")
}

Vystup:

Kód: [Vybrat]

Got a match! name = my-email and domain = seznam.cz
Online si to muzete zkusit tamhle -> http://ideone.com/Yd84oe.