Strucna historie Yarnu
Yarn je balickovaci manager pro JavaScript, alternativa k NPM, z dilny Facebooku. Vznikl v roce 2016 jako reakce na problemy s NPM. Specificky na frustraci autoru z produktoveho managementu a prioritizace vyvoje NPM. Fakticky se lisil ve dvou zasadnich vecech:
- Byl rychlejsi. Benefity jsou obvious.
- Umoznoval ulozit .lock soubor do repozitare. S rostouci slozitosti JS ekosystemu byla prenositelnost nutnost.
Takze mame rok 2016 a konkurencni nastroj k NPM se dvema naprosto killer features. Co dal? NPM si vsiml, ze lide odchazeji a prioritizace se zmenila. Hned v roce 2017 reagoval vlastni .lock featurou. Ale i zbytek inovaci Yarnu ovlivnil prioritizaci vyvoje NPM a v role 2020 se oba nastroje v podstate vyrovnali.
Tedy. Rekapitulace:
- 2016 - Vznikl prenositelnejsi a rychlejsi Yarn jako alternativa k NPM
- 2017 - NPM dotahuje prenositelnost
- 2020 - NPM dotahuje vsecko ostatni
Jak se na to divame dneska?
Od pouziti Yarnu se globalne ustupuje a vetsina novych projektu se vraci k NPM. Na tech Internetech se rozjizdi pomerne zasadni vlna hatu na Yarn. A to, prekvapive, kvuli jeho samotnemu vzniku. Hlavni argument dnesnich odpurcu je, ze Facebook nespolupracoval na posunu samotneho NPM, ale misto toho sel, tehdy popularni cestou, Yet Another Anything.
Mel Yarn vubec vzniknout?
Ze zpetneho pohledu je vse strasne jednoduche. Pro Facebook bylo dulezite zavest .lock file a nastroj zrychlit. Vyvojarstvo je drahe a pauza na kafe behem kazdeho buildeni se nascita. Mel tedy prijit do repozitare NPM a poslat pull request.
Az sem je argument neprustrelny. Ale co na to product owner NPM z te doby? Rychlost neni preci vubec dulezita, zvlast za cenu kompromisu. A .lock file? K cemu? Kdyz chcete presnou verzi, jak si ji muzete nastavit. A minor updaty prece nemuzou nic rozbit. A deployuje se prece jednou za pul roku, tak to pred buildem staci zkontrolovat.
Tohle vsecko se nezmenilo diskuzi s product ownerem, jak moc dulezita je rychlost a jak moc dulezita bude v blizke budoucnosti stabilita build pipeline v cloudu. Psal se rok 2016, proboha. Zmenilo se to vytvorenim alternativy. Az kdyz se objevila konkurence, zacal NPM reagovat.
Takze zaver je, ze konkurence je potreba?
Ano. Je to jeden z dulezitych zaveru. Konkurence je potreba. Minimalne to umozni uzivatelum zahlasovat nohama, ne jenom palcem v roadmapovem nastroji.
Je to jediny zaver?
Ne tak docela. Byt odpurce rozdelovani vyvojovych kapacit v OSS je naprosto validni postoj a sdili ho cim dal vetsi rada technologikych celebrit. Debata JavaScript vs TypeScript. Java vs Kotlin. CSS vs Tailwind. Argument je jednoduchy. Je to ztrata casu. Alternativy k dominantni technologii ji ve vysledku mozna obohati, ale ve finale maximalne trochu nasmeruji vyvoj.
Kdyz se bavim s vyvojari, treba v ramci pohovoru, uznavam obe varianty. Striktni variantu drzet se "podkladove" technologie a treba se ji i aktivne snazit vylepsovat. I variantu hledani perfektiniho matche s konkretnim problemem. Ktery teda vyvojari realne maji. Hype vlny moc neuznavam a beru to jako red flag.
Existuje varianta bez nutnosti tlaku konkurenci?
Tezko rict. Zalezi jak velkou vahu prikladate rychlosti. Demokraticke procesy v OSS z principu rychle byt nemuzou. Hledat shodu v byt i mirne diverzni komunite neni snadne. Abych jenom nekritizoval, tak pro me priklad funkcni demokraticke komunity je vyvoj Golang.
https://github.com/orgs/golang/projects/17
Maji jasne dany zaklad a filosofii jazyka. Cti: proc a jak vznikl. A dobry framework, jak posouvat proposal, od rychle popsaneho napadu, odladeneho design dokumentu az po implementaci. A rychlost? Shoda na nutnosti pridani generics trvala 10 let. Stalo to za to? Ano. Mohl to urychlit Yet Another Go fork od Facebooku? Ano. Ale to by bylo zase jenom rozdelovani vyvojovych kapacit.