Mind the age! Most likely, its content is outdated. Especially if it’s technical.
JavaScript mám docela rád. Kór dnes s ES6, ES7 a Reactem je psaní SPAček
radost. Dokud není potřeba využít nějakou knihovnu. To pak přestává být
sranda. Původně jsem chtěl napsat do nadpisu nepoužitelnost, ale nakonec lze
knihovny nějak použít. Je s tím však spousta trápení.
Jeden z příkladů může být samotný React a známé a používané knihovny. Vyšel
nový React 0.14, který přinesl zajímavé featury. Především stateless
komponenty. Samozřejmě, že po pár týdnech jsem se rozhodl novinek využít.
Jenže problém – používám taky react-bootstrap a podpora je až od verze 0.27. O
pět čísel větší než s kterou jsem web napsal. Za tu dobu samozřejmě stihli
sáhnout přesně na ty komponenty, které používám. Takže jsem šel upravovat
čerstvě napsaný kód…
Což ještě není to nejhorší, horší je závislost na knihovnu, která na
kompatibilitu kašle. Pak jen koukáte do konzole, jak React warninguje, a
doufáte, že autor knihovny to také upraví. Nejpozději do vydání nové verze,
která warningy transformuje na errory. S takovou zkušeností mi přijde, že se
vyplatí záviset jen na populární knihovny a zbytek si udělat sám.
Má to ještě jeden ironický důvod. Možnost výběru je zlo. Pro různé úlohy
existuje bambilion různých balíků. Každý si napsal něco a řekl si „to se bude
někomu hodit, zveřejním to“. Taková blbost! Nyní je těžké se v nepřeberném
množství zorientovat. S absencí dokumentací (pahýly mezi dokumentace
nepočítám) je pak těžké najít, co vlastně řeší můj problém. A hlavně aby
taková knihovna byla udržovaná a stabilní, tedy neprefixovaná nulou.
Další extrémní příklad je pořádná výzva: ES6 a pár ES7 featur, React, JSX.
Zkuste s takovou kombinací rozchodit testy. A to ještě není nejhorší varianta!
S takovými AMD moduly to je ještě větší sranda. V práci jsme narazili na bug
v testovací knihovně. Možnosti jsou dvě – buď se o verzi vrátit. Nebo ve světě
JS je naopak vždy dostupná novější verze, takže upgradovat. To nám ale zařvalo
z důvodu absence nejnovějšího Nodu. Čerstvého Node 4. Na Debianu samozřejmě
není dostupný, ale ne protože to je Debian, kde jsou balíky se zpožděním, ale
protože to chce nový gcc dostupný až pod Jessie. Tedy: chceš testovat
JavaScript? Upgradni si operační systém. Jo a taky si to zkompiluj…
Lehce to zveličuji. JavaScript se mi líbí. Občas ale dokáže vytočit. Proto
chci spíš šířit následující zprávu, která se nemusí nutně vztahovat na
JavaScriptí svět (jen to pro něj patří z důvodu spoustu edge novinek
dvojnásob):
Chápu, každý chce být autorem populární knihovny. Populární knihovna ale
nevznikne rychlým nabastlením, zveřejněním a doufat v open source boha. Už na
začátku je potřeba se ke kódu chovat jako bych ho měl maintenovat do konce
života. Což znamená si dobře promyslet API hned při prvním návrhu, aby se
později měnilo minimálně. Také to znamená být připraven řešit všechny use-
casy. Jak by se asi používalo request-get, request-post, request-json, …
pokaždé od jiného autora? V neposlední řadě řádně zdokumentovat, co vlastně
moje knihovna řeší a popsat jak s ukázkami.
9
reakcí
"chceš testovat JavaScript? Upgradni si operační systém"
Právě zejména kvůli Node.js microservicám jsme naplno docenili Docker. A to už jsem zažil nejen upgrade na Node.js 4, ale také downgrade, když se ukázalo, že se tím něco rozbilo. Teď mám na jednom serveru cca 10 microservice a je mi jedno, že každé je v jiné verzi Node.js
Vaclav,
14. 12. 2015
@Vaclav Upgrade na Node 4 a pak kvůli bugům downgrade je přesně to, o čem tu mluvím. Neustálé hledání co s čím jak dobře funguje je v JS světe opravdu problém a přijde mi, že se to nijak nelepší. Ba naopak každou chvíli vznikne něco nového, co je „lepší“ a funguje s tímhle, ale už ne zase s něčím jiným…
Michal Hořejšek,
14. 12. 2015
“Populární knihovna ale nevznikne rychlým nabastlením, zveřejněním a doufat v open source boha.”
Přesně takhle ale populární knihovny vznikají :) Někdo něco udělá, aby si usnadnil práci, zveřejní to, zeptá se v na mailinglistu nebo IRC, jestli se to ostatním taky líbí, a pokud ano, ale je to udělané špatně, tak následuje verze 2 a další, nebo fork, nebo nová knihovna, která na to jde jinak. Jestli ty dokážeš API navrhnout hned napoprvé, tak prosím napiš do Facebooku, jak to mají konečně udělat správně. Zatím ale nic tak geniálního na tvém Githubu nevidím :)
Vývoj okolo node.js je překotný, holt to nejsou pluginy do Wordpressu nebo Djanga. Buď musíš vědět, co děláš, nebo pět let počkat, až se to usadí, nebo neplácat náhodně knihovny dohromady a řídit se šablonou projektu, kterou někdo, kdo se v tom šťourat chtěl, připravil. My třeba sledujeme projekty typu Este, co a proč tam vyvádějí. (Ok, tohle asi neřeší konkrétně problém s react- bootstrap.)
Co se Debianu týče, tak když se kouknu do Dockerfile, tak si docela pěkně vystačíme s deb.nodesource.com :)
Messa,
14. 12. 2015
@Messa Stále si stojím za svém, že by měl programátor sdílet kód s tím, že ho bude podporovat do konce života. A tím si dobře rozmyslet, co sdílí. Problém vidím v tom, že každý si řekne „usnadním si práci, zveřejním to a počkám, kdo se přidá“. Dopadá to tak, že na vše je bambilion knihoven, žádná není dotažená, a teď babo raď, kterou si vybrat.
Mimochodem žádný projekt typu Este nevyřeší vše. Navíc konkrétně Este, nevím jak dnes, ale když jsem se na něj díval poprvé – vůbec jsem nepochopil, jak vlastně s ním něco vytvořit. A po chvilce změnil sadu knihoven. Tedy sledovat = často měnit knihovny a přepisovat. To zrovna nic moc neřeší.
Navíc je smutné, že člověk je nucen využívat Docker jen kvůli vývoji v JavaScriptu. To prostě děsně smrdí. Jako by nestačilo, že knihovny v npm mají občas mezi sebou problémy…
Michal Hořejšek,
15. 12. 2015
Nezkoušel si ClojureScript https://github.com/clojure/clojurescript ? Já si s ním hraju zatím rekreačně, ale mám s ním mnohem lepší zkušenost než z celým prostředím kolem NPM apod.
BTW: Este je přesně ten příklad, jak se to dělat nemá.
Lukáš,
15. 12. 2015
@Lukáš Nezkoušel. Z funcionálních jazyků jsem začal u Scaly a po zjištění, že tam je na mne stále moc javy, přešel úplně mimo javu k pure funkcionálnímu Haskellu, který jsem si nečekaně oblíbil. :-) Ale mám v plánu se na Clojure jednou taky podívat.
Michal Hořejšek,
15. 12. 2015
@Michal Clojure jako takové běží na JVM, ale není "zasaženo" Javou jako Scala (což je dost positivní).
Lukáš,
15. 12. 2015
@Lukáš Jo, to vím. Málo jsem naznačil. Něco málo jsem četl od Knesla tuším, si Clojure vychvaluje. Jen po zkušenost se Scalou jsem raději sáhl rovnou po něčem úplně jiném.
Michal Hořejšek,
15. 12. 2015
Nějak mi nedá nereágovat na tento post. Myslím si, že google chrome ukazuje cestu že software se dá vyvíjet v hodně rychlém tempu viz. jeho verzování (Edge a Firefox se přidávají). A tady začína fungovat JS svět, který se ubírá stejným směrem. Předpokládám, že do budoucna budou specifikace v podobném znění ES2015, ES2016, ES2017, ES.... Javascript si půjčuje to nejlepší co potkává u jiných jazyků např. moduly a další věci v ES2015. A na řadu přichází npm balíky, které jsou tak jednoduše publikovatelné, že to zvládne i dítě na windows. To znamená, že člověk udělá balík (neví co dělá) a dá NPM PUBLISH (hotovo balast je na světě). Viz. post Erica Elliota https://vimeo.com/89258863 publikace npm balíku v křivkách jde hodně rychle nahoru. Použít zrovna onen balík? Dal bych hodně na indikátory jako ISSUES, TESTS, TESTS COVERAGE, styl psaní (použití rozumných patternu), STARS, CONTRIBUTORS. Podle tohoto se dá vycítit jestli balík bude po nějaký čas funkční.
v kategorii 
kanálu