Přejít k navigační liště

Zdroják » JavaScript » React.js Conf 2015 – Co musíte vědět

React.js Conf 2015 – Co musíte vědět

Články JavaScript

Minulý týden proběhl druhý ročník konference React.js organizované Facebookem a byla to naprostá bomba. Jestli se dnes děje v oblasti vývoje webových aplikací něco opravdu zajímavého a inovativního, tak je to v ekosystému React.js a s ním souvisejích projektů.

Nálepky:

Autor článku pořádá školení, která si můžete objednat na Javascript-skoleni.cz.

Na todomvc.com naleznete desítky různých frameworků, ale nenechte se zmást, skoro všechny jsou v principu velmi podobné. Inovativní je však pouze jeden – React.js. Proto není divu, že Ember i Angular od Reactu opisují. Ember více, Angular méně, což je dané tím, že Angular trpí krizí identity.

Angular 1 je mrtev, zabil ho sám tým Angularu ohlášením Angularu 2, o kterém se ví, že bude hodně moc jiný, nicméně ještě ani neexistuje. Takže zatímco tým Reactu inovuje a inovuje, tým Angularu marní čas vymýšlením nových bizarních syntaxí a dalších abstraktních vrstev, které ve skutečnosti programátor nepotřebuje a budou ho jen brzdit. Týmu Angularu jejich úděl opravdu nezávidím. Ale dost o Angularu a pojďme se podívat, jaké úžasnosti nám přináší inženýři největší open source firmy na světě.

image01

React.js

O Reactu se na React.js Conf 2015 hovořilo jen málo. Proč? Protože je hotov a vyvíjí se už jen evolučně, pomocí drobných změn směřujících k lepší podpoře ECMAScript 6. React má minimální API, a kde všude to je možné, využívá JavaScript. Takže zatímco Ember i Angular nutí programátory učit se novou syntax a nová klíčová slova a nové nástroje (linter, formátování, debugging), React spoléhá všude jen a pouze na JavaScript. Proč vymýšlet nový a omezenější jazyk, když jeden už máte? (Pozor, React JSX není jazyk, ale pouze syntax, aby HTML v kódu vypadalo jako HTML, i když jsou to jen klasické JavaScriptové funkce.)

Přichází React Native

React Native vám umoží psát nativní mobilní aplikace pro iOS a Android v JavaScriptu a subsetu CSS. Ve skutečnosti React nikdy nebyl omezen pouze na DOM prohlížeče. Pomocí Reactu můžete renderovat nejen HMTL, SVG, a Canvas, ale nově také nativní mobilní UI. React Native není žádný vaporware, Facebook Groups aplikace, která byla napsána pomocí React Native, je už k dispozici v Apple store. Návštěvníci konference dostali přístup, plné zveřejnění se očekává v řádu týdnů. Za pozornost stojí workflow, které se snaží kopírovat workflow webových aplikací. Ano, reload na uložení souboru, není třeba nic kompilovat. Pro stylování se zase používá subset CSS a Flexboxu.

Srovnání s Apache Cordova/PhoneGap a Titanium

Apache Cordova stejně jako PhoneGap k renderování používá webview, tedy osekaný prohlížeč. React Native DOM nepoužívá, pouze JavaScript.

Titanium také nepoužívá DOM, nicméně kompiluje JavaScript do nativního kódu. React Native nic nekompiluje, proto je možné vyvíjet bez čekání. Výsledkem je tedy skutečná nativní aplikace, bez kompromisů. Že to klukům ve Facebooku pálí, dokazuje i toto krásné nové paradigma: „Learn once, write everywhere„, která má k realitě podstatně blíže, než marketingové „Write once, run everywhere„.

Jeden z vývojářů React Native možná trochu překvapivě sdílel tento článek, ve kterém se píše, že mít společný framework pro iOS i Android je pošetilé, a že rozdílů především na UI je mnoho. Sdílel ho s tím, že se všemy body souhlasí, a ať se necháme překvapit. Vzhledem k tomu, že Facebook React Native již pro interní aplikace používá, jak píše jeden můj kamarád ještě z dob Mootools, můžeme jim snad věřit.

Ale to není všechno. Ta největší změna oproti existujícím frameworkům, jedno, jestli Titanium nebo Cordova, je funkcionální přístup k psaní UI – více v článku Why React Native Matters. Nicméně, React Native Cordovu a její princip nezabíjí, jen doplňuje.

Relay

Nejen Reactem (čili view) živa je webová aplikace. Facebook Flux jasně a zcela zřetelně řekl, že kaskádové změny, tedy implementace data flow pomocí eventů nebo observerů/watcherů (ahoj Angulare), jsou špatné. Flux je velmi jednoduchý, přesto mocný pattern. Implementace má pár stovek řádků a funguje parádně. Dirty watching je proti tomu skutečně špína – pomalý a zrádný. Object.observe není řešení a časem se z něj stane nový JavaScript with – podivná konstrukce jazyka, která vlastně k ničemu užitečnému není, a je dobré se jí vyhnout.

Facebook neusnul na vavřínech, stvořil novou kulervoucí technologii – Relay. Jestli je React Native naprostá bomba, Relay je kobercový nálet. Nevím jak vás, ale mne REST vždy dost… nepěkná věc. Principy RESTu jsou správné, ale v praxi narážíte na celou řadu problémů.

Relay je nový efektivní způsob načítání dat ze serveru, který řeší mnohé.

Základní problém je ten, že nikdy přesně nevíte, jaká data bude aktuální stránka potřebovat. Představte si Facebook feed. Ten obsahuje desítky modelů, ale vy nechcete načíst všechny, od uživatele vám stačí jméno, fotka, id. Od jeho statusu jen pár prvních komentářů, pak link na lajky, možná sem tam reklama, a tak dále a tak dále. Nativní způsob povede k tomu, že budete načítat mnohá data zbytečně, nebo ve špatném pořadí, nebo budete generovat množství opakovaných dotazů na stejný endpoint, dost možná uděláte překlep, potrápí vás hierarchická data, a tak dále a tak dále. To je past vedle pasti, pičo!

O Facebook Relay se toho ještě tolik neví, opět jen to, že Facebook už jej používá v produkci (Angular 2 ehm ehm), a soustředí se především zveřejnění open source knihoven. Více o Facebook Relay zde: https://gist.github.com/wincent/598fa75e22bdfa44cf47

Facebook Relay mi připomíná Firebase api, které zdaleka není tak mocné, ale snaží se řešit podobný problém. Rozhodně nejde o náhradu REST, ten zůstane vždy základním stavebním kamenem interoperability.

Immutable.js

Shared mutable state is the root of all evil.

Aneb proč je software nestabilní a vývoj složitějších aplikací je tak obtížný.

 

Facebook vyvíjí knihovnu Immutable.js, a její autor měl na konferenci také přednášku. O immutable-js napíšu na zdroják později více v samostatném článku.

Závěr

Takhle nadupanou konferenci jsem dlouho nezažil, a to jsem nezmínil zdaleka vše. Za pozornost stojí i Flow, statický type checking pro JavaScript, nebo react-router, a další.

React prochází mohutnou adobcí mnoha firem. Za pozornost stojí, že React se nepoužívá jen v prohlížeči, ale i v Atom editoru, v Netflix TV setech, na serveru se s ním renderuje statické HTML, díky React Native i v nativních mobilních aplikacích, konce to nemá.

Videa všech přednášek najdete na: https://www.youtube.com/playlist?list=PLb0IAmt7-GS1cbw4qonlQztYV1TAW0sCr

Pozvánka

26. února připravujeme s Láďou Prskavcem poslední čtvrtek věnovaný Reactu a s ním souvisejících technologií – Praguejs.cz Přijďe se podívat, popít, pobavit.

Představím také nové Este.js – es6te zero bus factor edition. Ano, nebude tam ani řádek mého kódu – dev stack a framework poskládaný pouze z komponent třetích stran :-) Prozatím jen klíčová slova: ES6, WebPack, React, Flux, Flow, immutable.js, gulp, TDD ready…

 

Komentáře

Subscribe
Upozornit na
guest
40 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
David Marko

Pro ty, kteří nad Angularem hůl nezlomili přikládám odkaz na pár dní starou prezentaci o tom, jak Angular 2 vypadá v reálu (v zatímní verzi). An Angular2 Todo App: First look at App Development in Angular2 Na konci jsou odovědi na různé dotazy, včetně důvodů, proč zvolili novou syntaxi apod. Určitě to stojí za podívání …

Radek Miček

Za pozornost stojí i Flow, statický type checking pro JavaScript

Bohužel, JavaScript má mnoho neduhů, které typový systém nenapraví.
To už je lepší použít Dart nebo ještě lépe F# (WebSharper) nebo Scalu (ScalaJS).

Jarda

Představím také nové Este.js – es6te

Už zase? Kdysi jsem udělal tu chybu, že jsem na jeden projekt použil Este. Od té doby je potřeba neustále po každém představení nového Este aplikaci přepisovat. Tuhle chybu už neudělám.

Robert

Proč přepisovat? Není důvod, každá verze Este je dále udržovatelná do nekonečna. Este je stejně jen pojivo existujících frameworků, které se vyvíjejí bez ohledu na verzi Este.

Tomas Dvorak

Taky se vám článek tak těžce čte? Pokaždé, když narazím na článek od tohoto autora, bojuju s tím vůbec jej dočíst. Je to vždy změť odkazů kamsi, nesouvisejících informací (něco jako Dočekalův #Týden na lupě), výkřiků typu „kulervoucí technologii“, „past vedle pasti, pičo!“, „zero bus factor edition“… Asi nejsem ta správná cílová skupina (jak by java vývojář mohl), ale zajímalo by mě, jestli to lidem z JS světa dělá taky takové problémy.

mjinoch

plus „všemy“ a „adobcí“

Já

Protože trpí ADHD z toho jak musí každejch půl roku předělávat projekty na novou kulervoucí technologii, pičo.

Robert

Mě se to čte skvěle a děkuji za každý odkaz, protože Steida umí vypíchnout opravdu skvělé zdroje!

Dočekala sem netahej, to je regulérní exot.

Jakub

+1

Ondřej Žára

Ano, i lidem z JS světa dělá taky takové problémy.

Na druhou stranu mi přijde lepší takovýhle subjektivní výkřik, než nekonečné ticho po pěšině Zdrojáku.

RDPanek

Čte se to velmi dobře, protože je jen málo lidí, kteří se podělí o to, co vyzkoušeli. A protože jako developer nechci zamrznout ( v Angluaru jsem taky napsal větší appku, tak s Danem musím souhlasit ), tak si o tom co Dan píše vyzkouším a sám si vyberu.
Já bych řekl, že hodnocení tohoto článku a Danova přínosu lze chápat spíše tak, jestli ten článek čte proaktivní developer, který si to aspoň vyzkouší aby si udělal vlastní názor, nebo osmihodinová pecka ;-)

A určitě doporučuji zkouknout ty přednášky.

Radim

Příliš mnoho vzletných slov (kulervoucí, nálety…), pocitů a málo faktů. Myslím, že David umí napsat lepší články.

Občas mám fakt pocit, že si někdo myslí, že za nás problémy, kterým na projektu čelíme, vyřeší ty technologie.

arron

Tak účel toho článku taky není o faktech, ale o informaci, že se stalo něco významného.

Lidé to dost podceňují, ale pokud bude všechno fakt fungovat tak, jak se to podle těch přednášek jeví, tak to v podstatě postaví na hlavu webový vývoj a vývoj mobilních aplikací (snad kromě her) a pokud se využije ten potenciál, tak se to projeví i ve vývoji nemobilních aplikací. Což si ty velké firmy už uvědomily a proto React adoptují.

Fakt doporučuju tomu věnovat chvíli času a kouknout se alespoň na ty dvě přednášky, které jsou odkázané ve článku :-)

Radek Miček

Lidé to dost podceňují, ale pokud bude všechno fakt fungovat tak, jak se to podle těch přednášek jeví,

Třeba nebude.

Problém může být v náročnosti na CPU (máte-li aplikaci s textovým polem, stačí podržet klávesu a sledovat, co dělá CPU). Nebo, když máte rozsáhlejší komponenty a k aktualizacím dochází často, musíte řešit, abyste je zbytečně neaktualizoval (např. pomocí shouldComponentUpdate nebo jinak) nebo obsah virtualizovat.

AFAIK momentálně React nijak neřeší izolaci stylů (to vyřeší webové komponenty).

steida

Ad „JavaScript má mnoho neduhů, které typový systém nenapraví.“
Zatím si JavaScript vede docela dobře. Projekty, které jste vyjmenoval jsou úplně minoritní. Z části ale máte pravdu, avšak opomenul jste ClojureScript který opravdu nelze přehlédnout, což značí že žonglujete s termity.

Ad „Problém může být v náročnosti na CPU“
Jste šarlatán. Vyjadřujete se k nějaké technologii aniž byste si přečetl co umí a proč. Obsah virtualizovat? Co je to za nesmysl? I bez shouldComponentUpdate to opravdu problém není, to byste musel napsat tisíce znaků za sekundu, nesmysl.

Ad „AFAIK momentálně React nijak neřeší izolaci stylů“
Jednak to není ve scope Reactu, a druhak to řeší jinej Facebook projekt.

Result: Méně pište, více čtěte, anepředstírejte znalosti technologie.

Radek Miček

Projekty, které jste vyjmenoval jsou úplně minoritní.

Vyjmenoval jsem projekty, které mi přijdou dobré (mj. mají typový systém a infixovou syntax), proto jsem nejmenoval ClojureScript.

Zatím si JavaScript vede docela dobře.

Je to špatně navržený jazyk. V jakém smyslu si vede dobře, je to proto, že kolikrát vývojář nemá jinou možnost?

Obsah virtualizovat? Co je to za nesmysl?

Virtualizace UI a dat – viz http://blogs.msdn.com/b/albulank/archive/2009/11/12/data-and-ui-virtualization-in-wpf.aspx

I bez shouldComponentUpdate to opravdu problém není, to byste musel napsat tisíce znaků za sekundu, nesmysl.

Zkuste si formulář v Reactu a srovnejte to s obyčeným textboxem. Jinak mluvím o větších komponentách, kde se bez toho neobejdete.

steida

Tak určitě.

jan.vojir

Jaromire, prehlasilo te to!

arron

Facebook tvrdí, že všechno z toho, co teď představil, tak už reálně používá a v přednáškách jsou i live dema, takže z toho nemám takovy strach, že by to nefungovalo. Ale zatím to nevydali, proto jsem to napsal tak, jak jsem to napsal.

V dalších přednáškách je (mimojiné) live demo, které obsahuje stovky až tisíce komponent, které se rychle aktualizují a srovnávají implementaci v Emberu, Angularu a Reactu. O rychlost fakt nemám strach ;-) IMHO, pokud mám cokoliv, co se aktualizuje fakt často, tak to vždycky bude nějaký ten procesorový čas brát, že jo.

Radek Miček

V dalších přednáškách je (mimojiné) live demo, které obsahuje stovky až tisíce komponent, které se rychle aktualizují a srovnávají implementaci v Emberu, Angularu a Reactu. O rychlost fakt nemám strach ;-)

Ok, nevím, jak to je v poslední verzi, ale ve verzi 0.10 jsme tento problém měli (jednalo se o větší komponentu s řadou podkomponent – konkrétně tabulka se statistikami, jenž se každou sekundu nebo i častěji aktualizují). Vyřešili jsme to právě tak, že se napřed dělala určitá porovnání na modelu, aby se určilo, jaké komponenty je nutné přerenderovat.

arron

Na tom ale přece není nic nepřirozeného, že se dělají optimalizace na rychlost tam, kde je to potřeba, ne? Dělá se to v databázových dotazech, v serverovém kódu a je samozřejmě potřeba to udělat i v JS kódu, pokud je vyžadován extrémní výkon (popřípadě efektivita). V další z přednášek je rozebráno i toto téma :-)

Radek Miček

Na tom ale přece není nic nepřirozeného, že se dělají optimalizace na rychlost tam, kde je to potřeba, ne?

Že se dělají optimalizace souhlasím (psal jsem to ostatně i v té první reakci „když máte rozsáhlejší komponenty a k aktualizacím dochází často, musíte řešit, abyste je zbytečně neaktualizoval“).

Jenže lepší by byl framework, kde tohle řešit nemusíte. Zvlášť, když v dnešní době takováhle situace není ojedinělá. Kdyby React hlouběji rozuměl JavaScriptovým funkcím a věděl, co se změnilo v modelu, nemusel by zbytečně generovat a porovnávat virtuální DOM.

Podobná idea je například v Prologu (nebo Constraint Handling Rules nebo produkčních systémech založených na Rete algoritmu) – mnohé implementace používají indexování, aby zbytečně nezkoušeli některé unifikace.

steida

Ad změny technologií – Pět let používám Closure Tools, Před dvěma lety jsem přidal React, před rokem Flux. Este vždy ukazuje, jak dané technologie používat společně. Technologie vybírám dlouho, a dlouho se jich pak držím. Tady si někdo zase rád zapomlouval. Nj, anonym na zdrojáku – ostuda webu.

Michal Till

Čte se to normálně. Každý má svůj styl komunikace. Dan má velmi dobrý odhad na technologie, ale debatovat se s ním nedá ;-)

steida

Žvatlavé plácání se po zádech fakt pro mne není :-) Ale kdo se zeptá, ten odpoveď dostane.

Kolemjdouci

Pán má nosánek kapánek vysoko, že?

Daniel

Ale ne, to jen ostatní čmuchají moc při zemi ;)

Kolemjdouci

Haha :-)

pavel

Coze to vlastne React.js je? A Angular? Ja jedu na jQuery-UI a D3.JS…

steida

Co to vlastně pavel je? Sedí to doma, nudí se, a tak to píše stupidní komentáře na zdroják. Než si něco vygooglovat, přečíst si, poučit se, pak se třeba zeptat, tak se raději vyblejt. Komentáře by měli být placené. Přestávám je sledovat, tímhle fakt nemá cenu trávit čas.

Kdo bude mít nějakou relevantní otázku, pište přes Twitter. Děkuji.

HonzaMarek

Dane, máš tam hrubku. Správně by mělo být „komentářové by měli být placení“.

Pavel Lang

Než cokoli otevřou, tak udělají prezentace, navnadí vývojáře a společnosti, a pak z toho těží. Mají feedback bez emocí. Viz Flux. To je záruka kvality. Řvouni nemají šanci, ale každý kdo s láskou napíše nějaký kód ano. Proto se těším na Relay. I když je to jen příslib stejně jako Flux. Bude to cool věc!
O Reactu se bavit nemusím. Nic hezčího jsem na webu neviděl.

Yosef

Pro vyvoj aplikaci je dulezity i design UI a ten nyni nejlepe resi Material Design!!!
Material Design nejlepe implementuje Polymer diky znova pouzitelnym elementum.
https://www.polymer-project.org/docs/start/reusableelements.html

Polymer je budoucnost, viz stranky Google IO 2015
https://events.google.com/io2015/

Kdo by mel zajem si Polymer vyzkouset, tak muze zacit pomoci Polymer Starter Kitu…
https://github.com/StartPolymer/polymer-starter-kit

Jirka Kosek

Zas to nesmíte Googlu tak žrát.

Web Components jsou určitě budoucnost, ale je potřeba, aby to implementoval ještě Apple a IE nativně. A zvláště Apple se k současné verzi staví dost vlažně.

Yosef

IE je mrtvy, nova verze co ma prijit to nezachrani, Safari je minorita…

Sepsal jsem nekolik odkazu, ktere rikaji, ze Chromium / Chrome je velmi silne a jeho obliba velmi roste…

https://gist.github.com/b616c08c435a6beb7ef2

Jirka Kosek

To mi připomíná argument, který tuhle někdo říkal v hospodě — jak by bylo skvělé, kdyby všechni používali stejný prohlížeč, nebo by bylo alespoň jen jedno jádro, třeba WebKit. Odborně se tomu říká krátkodobismus. Jakmile by existoval jen jeden prohlížeč, veškerý vývoj se zastaví. Vzpomínáme ještě na IE6?

Yosef

Web Components bezi diky polyfillum dobre na ostatnich WB, kdyz nekdo bude chtit zazit rychlost moderniho webu bez polyfillu, tak bude muset stahnout nejaky derivat Chromia. ;-) Firefox nyni maka na Web Components. Ostatni se treba pridaji, kdyz Google predvadi jak Polymer je silnej a easy. IO 2015 bude urcite zajimave…

Yosef

Chromium je velky Open Source, neda se to porovnavat s uzavrenym IE. U tak velkeho OSS se vyvoj jen tak nezastavi…

Yosef
steida

Nejlepší a nejmodernější TodoMVC zde: https://github.com/steida/este-todomvc

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.