Funkcionální frontend - zkušenosti?

[Mirek Prýmek]

Zdar vespolek,

chtěl bych se zeptat na vaše názory a zkušenosti s funkcionálními jazyky/frameworky na webovém frontendu. Konkrétně mě zajímá, jak vidíte zralost, použitelnost a přínosnost jednotlivých řešení, která se poslední dobou vynořují. ...a taky, jakou cestou podle vás má smysl v současné době jít pro jaký usecase a míru odvahy Weby mě neživí, dělám je jenom pro interní potřebu, takže tu oblast úplně detailně nesleduju a budu rád za postřehy vás, kteří se v tom pohybujete víc a máte smysl pro FP.

Obecně mě zaujala myšlenka virtuálního DOMu, kompletní umístění view logiky na frontend (konec dvoukolejnosti) a její znovupoužitelnost a možnost nepřepínání se z funkcionálního světa (v mém případě http://www.phoenixframework.org/) do [doplňte sami] javascriptu.

Co jsem tak koukal, mám dojem, že jsou dvě základní možnosti:

• buď nějaký javascriptový framework, který FP principy aspoň trochu ctí a využívá (React, Flux? Hodně mě zaujal Cycle.js a ještě víc jeho úspornější varianta Motorcycle)
• nebo plnotučný jazyk překládaný do JS: Elm, Purescript

Víc mě láká druhá varianta, protože bych rád z JS světa utekl, ale nejsem si jistý, jak zralé ty věci jsou (pro ne úplně kritické nasazení, ale i tak chce člověk rozumnou zralost minimálně aby se to dobře používalo a nemusel řešit koniny) a taky si nejsem jistý, jestli se výhoda striktně čistého haskelloidního FP neprojeví spíš na větším projektu. Prostě, lidově řečeno, jestli si u menšího projektu člověk trochu nenaběhne na vidle - propojit pár tlačítek a WS událostí s nějakou víceméně jednoduchou akcí může být příjemnější pár řádky JS (?), ne-čistý jazyk umožňuje pohodlně si někam přidat ladící výpis, rychle drobně doladit logiku a neřešit změnu typu v půlce kódu...

Prostě, sečteno a podtrženo, docela mě ta představa láká, ale je to dost velká investice a nejsem si jistej, jestli to dává racionálně smysl. V současnosti jsem nejvíc nakloněnej Elmu, ale nechám si poradit

Dík za vaše zkušenosti a názory. Hlavně těm, kdo s něčím z popsanýho mají větší reálné zkušenosti.

EDIT: jo, ještě jsem zapomněl důležitou poznámku: SPAs mě nezajímají, dělám klasické "stránkové" aplikace, i když třeba s dynamickým obsahem ládovaným pomocí WS.

[Reklama]

[Pavel Tisnovsky]

Uvazoval jsi o ClojureScriptu? Celkem se to rozjizdi a lidi si nejvic povazuji stejny jazyk na frontendu a backendu (JS jde na to stejny z druhe strany :-)

[Mirek Prýmek]

Uvazoval jsi o ClojureScriptu?

Ne, protože LISP-like jazyky nějak nejsem schopnej překousnout Je v Clojure-světě nějaký vyloženě famózní framework, který by stál za to se kousnout a tu nechuť překonat?

Tak mě napadá, nerozhlížel jsem se ani v F# světě, jestli něco nemají. Nebo že by OCamláři?

[Pavel Tisnovsky]

Uvazoval jsi o ClojureScriptu?

Ne, protože LISP-like jazyky nějak nejsem schopnej překousnout Je v Clojure-světě nějaký vyloženě famózní framework, který by stál za to se kousnout a tu nechuť překonat?

jj chápu, může to být nezvyk. Nějaký úplně skvělý framework, okolo kterého by byl hype jako v dobách RoR, tady asi (pro CljS) není. Spíš to jsou jednotlivé knihovny, které si člověk sám poskládá dohromady přesně tak, jak potřebuje. Takže možná to F#.

[Mirek Prýmek]

Nějaký úplně skvělý framework, okolo kterého by byl hype jako v dobách RoR, tady asi (pro CljS) není. Spíš to jsou jednotlivé knihovny, které si člověk sám poskládá dohromady přesně tak, jak potřebuje. Takže možná to F#.

Tak to by nebylo nic pro mě, to mi za prošoupané klávesy se závorkami nestojí )

[Reklama]

[Radek Miček]

Mám dobrou zkušenost s F# a frameworkem WebSharper. HTML však renderuji pomocí Reactu.

Obdobně dobrou zkušenost mám se Scalou a ScalaJS. Navíc ScalaJS má binding pro React (osobně jsem ho však nezkoušel, když jsem to používal, tak ještě neexistoval).

nebo plnotučný jazyk překládaný do JS: Elm, Purescript

V těchto jazycích ale nejde napsat serverovou část, nebo ano? Navíc budou mít menší komunitu než F# a Scala.

Nebo že by OCamláři?

AFAIK tam žádný rozumný framework není, akorát existuje pár bindingů pro js_of_ocaml.

[Mirek Prýmek]

Mám dobrou zkušenost s F# a frameworkem WebSharper. HTML však renderuji pomocí Reactu.

Matně si vzpomínám, že jsem o WebSharperu něco někdy slyšel. Díky za tip, kouknu. Jak je to ale s praktickým používáním? Vidím tam VisualStudio, NuGet... to jsou vody, do kterých bych se nerad namočil jenom kvůli frontendu

A jaký je ten React? Pracuje se s tím dobře, je to dobře navržené? Četl jsem tak porůznu všelijaké poznámky, že si to na FRP jenom hraje...

Obdobně dobrou zkušenost mám se Scalou a ScalaJS. Navíc ScalaJS má binding pro React (osobně jsem ho však nezkoušel, když jsem to používal, tak ještě neexistoval).

Díky, to jsem taky nezkoumal.

V těchto jazycích ale nejde napsat serverovou část, nebo ano?

Nejde mi o sjednocení frontendu a backendu (možná jsem to napsal trochu nesrozumitelně). S Phoenixem jsem extrémně spokojenej a nedám ho ani za nic Hlavní motivace, proč uvažuju o změně, jsou asi tyhle:

• činí mi utrpení se neustále přepínat z funkcionálního (Elixir) módu myšlení do JS
• JS celkově nemám rád (ES6 je výrazně stravitelnější, ale pořád nepříjemný)
• nebaví mě řešit neustále boilerplate kolem komunikace tam a zpátky
• doteď jsem si docela vystačil s vlastním JS kódem+jquery, ale jakmile věci trochu narostou, je to utrpení

ad 1 - celkem bych byl ochotnej akceptovat i JS framework, který je napsaný funkcionálním stylem. Ten Cycle.js mi přijde v pohodě. Opravdu funkcionální jazyk je spíš takový trochu bonus navíc, úplně nutně na tom netrvám.

ad 4 - teď řeším view převážně templatama ve Phoenixu, s tím, že když potom chci něco udělat dynamičtější, tak k tomu napíšu nějaké ty transformace v jquery. Vede to ale k tomu, že ty věci pak píšu dvakrát, někdy i třikrát. Chtěl bych nějakou modularitu, nějaké komponenty, ale zase ne šílenou jadernou elektrárnu. Proto mi přijde, že funkcionální framework by byl prima - hodím mu data, vykreslí HTML. Snadným, předvídatelným, srozumitelným způsobem. Žádné tisíce monkeypatchovaných JS objektů dělajících kdovíco kdovíkde...

Navíc budou mít menší komunitu než F# a Scala.

To rozhodně - předpokládám, že o několik řádů

[alex]

FP na webu? Javascript. A každý jazyk nakonec dopadne jako JS. Další verze jeho funkcionální povahu budou postupně oslabovat.

[Radek Miček]

Mám dobrou zkušenost s F# a frameworkem WebSharper. HTML však renderuji pomocí Reactu.

Vidím tam VisualStudio, NuGet... to jsou vody, do kterých bych se nerad namočil jenom kvůli frontendu

...

Nejde mi o sjednocení frontendu a backendu (možná jsem to napsal trochu nesrozumitelně).

Aha, pak ten F# a WebSharper nemá asi cenu zkoušet. Osobně se mi na něm líbí, jak jednoduché je volat serverové funkce z klienta (funkci na serveru stačí označit atributem Remote a WebSharper se o zbytek postará - např. při kompilaci klientského kódu zkontroluje, že serverová funkce existuje a má správný typ), nebo raději spravuji stav klientské části aplikace v F# než v JavaScriptu (F# má například algebraické datové typy).

A jaký je ten React? Pracuje se s tím dobře, je to dobře navržené?

Ano, pracuje se s ním dobře. Nicméně idea, že UI je čistou funkcí stavu, jenž je uložen na jednom místě a spravujete jej např. v F# nebo Scale, v praxi IMO úplně neplatí - některé komponenty si drží vlastní stav (např. kde je posuvník nebo stav týkající se animace). V té Scalovské aplikaci jsme měli problémy s výkonem (stav UI se měnil příliš často a přerenderování celého UI bylo příliš pomalé), ale podařilo se je snadno vyřešit pomocí shouldComponentUpdate (jednoduše jsme ve Scale porovnali části stavu, na nichž daná komponenta závisí).

Četl jsem tak porůznu všelijaké poznámky, že si to na FRP jenom hraje

Osobně FRP chápu jako programování se signály, jenž se mění (mění svou hodnotu) v čase. V tomto ohledu React skutečně není FRP.

[Radek Miček]

A jaký je ten React?

Hlavní výhodou Reactu a podobných frameworků je, že stačí napsat kód pro vytvoření UI, ale nemusíte psát kód pro jeho aktualizaci (např. když nastane nějaká událost), což u složitějších UI výrazně zjednodušuje práci. Proto s WebSharperem používám React a nepoužívám Formlety, Piglety a jiné nástroje pro tvorbu klientského UI, jenž jsou přímo součástí WebSharperu.

[Filip Jirsák]

možnost nepřepínání se z funkcionálního světa do javascriptu.

Tomuhle nerozumím. Vždyť JavaScript je také funkcionální. Chcete jazyk, který bude jen funkcionální a nebude podporovat jiná paradigmata?

[Ivan Nový]

možnost nepřepínání se z funkcionálního světa do javascriptu.

Tomuhle nerozumím. Vždyť JavaScript je také funkcionální. Chcete jazyk, který bude jen funkcionální a nebude podporovat jiná paradigmata?

Programovat funkcionálně lze v každém jazyku. Je to jen věc vnitřní disciplíny, která patří k mistrovství v každém oboru.

[Mirek Prýmek]

Tomuhle nerozumím. Vždyť JavaScript je také funkcionální. Chcete jazyk, který bude jen funkcionální a nebude podporovat jiná paradigmata?

V JS se dají používat některé FP patterny. Napsal jsem, že bych byl ochotný používat framework, založený jenom na nich (jako je např. ten cycle.js - viz http://cycle.js.org/ ) a pro moje účely by to možná bylo i racionálnější než čistě funkcionální jazyk.

[andy]

Obecně mě zaujala myšlenka virtuálního DOMu, kompletní umístění view logiky na frontend (konec dvoukolejnosti) a její znovupoužitelnost

EDIT: jo, ještě jsem zapomněl důležitou poznámku: SPAs mě nezajímají, dělám klasické "stránkové" aplikace, i když třeba s dynamickým obsahem ládovaným pomocí WS.

S umístění view logiky na frontend jsem začal s Angularem - a v momentě, kdy to uděláš, tak na backendu v podstatě nepotřebuješ framework a vznikne ti SPA. Následně jsem zjistil (možná to jiní budou mít jinak), že už nikdy žádný backendový framework nechci potkat. Je to trošku syndrom "když máš kladivo, je všechno pro tebe hřebík", ale psaní aplikací tímhle způsobem je prostě komfortní a hlavně z ničeho nic můžeš mít naprosto "normální" backend psaný v "normálním" jazyce bez nějakých frameworkových vymyšleností (nemám zkušenosti s tím, jak frameworky "pomáhají" řešení autorizace, nevím, nakolik to u REST API jde principiálně zjednodušit). Mám trochu pocit, že SPA a "view logika na frontendu" je v podstatě totéž (protože když už tu view logiku děláš na frontendu, tak mi trochu nedává smysl dělat ovládání toho view na backendu).

Mám trochu zkušenosti s GHCJS.
+ Sdílení kódu s backendem
+ Prakticky neřešíš API mezi backendem a frontendem - stačí mít serializační instance pro data (auto-generované), která si posíláš, "a je to". Když v API něco změníš, kompilátor ti pohlídá, že ti to na frontendu i backendu souhlasí
+ Normální (i nenormální - s extensionama) haskell
- Pokud knihovna používá nějaké C FFI, tak to nemusí fungovat - ale většina běžných knihoven funguje, je možnost to doplnit přes "JS shims"
- V angularu jsem byl zvyklý používat angular-bootstrap jako UI knihovnu - v ghcjs (resp. reflex) to není, a je to potřeba napsat (možná časem něco zveřejním)
- Reflex (FRP)....je trochu zvláštní. Když máš stránku, kde na sobě navzájem závisí několik různých prvků, tak skončíš s  "pavučinou" napsanou v RecursiveDo. Zatím mi to nepřipadá úplně "skvělé a úžasné", na druhou stranu nevím, jestli principiálně existuje možnost to zjednodušit, protože na té stránce skutečně ty prvky mezi sebou mají pavučinu závislostí. Asi se časem poohlédnu po alternativách - existují bindingy React, možná se s tím bude psát lépe? Když v jQuery člověk napíše nějaký selector, tak je to vlastně strašně silný nástroj, jenže bez typové kontroly....
- Zkompilovaný js je VELKÝ (1MB+)
- Rychlost - není to úplná tragédie, zas to není nějaká extra výhra. Ono se to tak trochu renderuje "postupně" ("Dynamic v Dynamicu") a pokud je nějaká výrazně dynamičtější stránka (generovaná stylem dynamic v dynamicu), tak to je vidět
* kupodivu to funguje jak má - ne že by člověk nenarazil občas na chybu, ale zatím nic zákeřného

Alternativa je Haste, který by se měl kompilovat do výrazně menšího JS, zas spoustu věcí z haskellu neumí, což je trochu problém. Sdílení kódu (nebo aspoň datových struktur) s PureScriptem a Elemem je prý možné, ale nic moc...

[Mirek Prýmek]

Díky, Andy, za zajímavý zkušnosti!

S umístění view logiky na frontend jsem začal s Angularem - a v momentě, kdy to uděláš, tak na backendu v podstatě nepotřebuješ framework a vznikne ti SPA. [...] Mám trochu pocit, že SPA a "view logika na frontendu" je v podstatě totéž (protože když už tu view logiku děláš na frontendu, tak mi trochu nedává smysl dělat ovládání toho view na backendu).

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. Navíc celej ten koncept SPA se mi nelíbí (nemožnost odkazovat přes URL zvnějšku apod.)

stačí mít serializační instance pro data (auto-generované), která si posíláš, "a je to". Když v API něco změníš, kompilátor ti pohlídá, že ti to na frontendu i backendu souhlasí

Tohle bych právě hodně chtěl, ale určitě kvůli tomu nebudu přecházet na Haskell na backendu. Spíš si asi zkusím promyslet, jestli by se to nedalo pořešit nějakýma makrama v Elixiru, který by mi třeba vygenerovaly boilerplate v JS pro přístup k datům. 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ší.

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

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ý