Framework je přežitek

Očesaný sandbox, jupí! :) Díky!

Dneska hodně moderní pojem Full Stack Developer… Jak to vidím kolem sebe, tak frameworkům jako takovým asi odzvonilo. (Určitě odzvonilo…) Osobně už asi nerozumím ani tomu, jak někdo může říct: „Já jsem PHP/Python/Ruby programátor.“

Tohle je super, ale ještě dál jde asi NodeJS, spolu s jeho NPM.
Na vše je nějaký balíček. Balíčků přibývá neuvěřitelným tempem.
V balíčcích jsou i věci jako Express, včetně Bootstrapu, template enginů a já nevím co všechno. Opravdu VŠECHNO.
Skvěle jsou vyřešené závislosti, testování a vše s tím souviející. Instalace probíhá jediným příkazem…

Když vidím kam se posouvá JavaScript, nemyslím si, že o PHP bude někdo ještě za pár roků/měsíců stát…

Prosím, neberte to jako jako kopání do PHP, ale zkuste se odpoutat od svých knihoven, podívat se na to co řešíte a nahlédněte na to nesvázaným pohledem, jestli by se to co programujete, nemělo řešit/programovat jinak…

Ano, JavaScriptová platforma prochází překotným vývojem, neboť dotahuje konkurenci. Zatím prochází telecími léty, věci rychle vznikají a zanikají, komfort zdaleka nedosahuje toho, na co je člověk zvyklý u jiných platforem. Ale jde to rychle kupředu a výsledkem bude nějaká symbióza se současnými serverovými jazyky a technologiemi. Což je fajn, těším se na to.

#2 Pepo, „Use the right thing on the right part of your business.“

Úplně nejlepší je použít PHP tam, kde to dává smysl, použít JavaScript tam, kde to dává smysl, použít Clojure tam, kde to dává smysl, použít <whatever>, kde to dává smysl.

Oblastí, kde PHP + Nette komponenty + Symfony komponenty dávají smysl, je požehnaně.

[…] rozdělení do samostatných repozitářů (namísto náhražky v podobě Git subtree split)

Nemyslím si, že subtree split je náhražka, ale naopak dobře vypočítaný krok. I když by bylo fajn a všechny komponenty frameworku byly naprosto decoupled, i tak se najdou věci, které přesahují hranice jednotlivých komponent (hlavně různé utilities). Refactoring přes X repozitářů je pak docela porod.

Poslední zkušenost s ReactPHP, kdy framework rozdělili na více repo, každé si začalo žít vlastním životem a rozjelo se jim číslování verzí, některé komponenty zaostávaly za ostatními… Hrůza s tím pracovat.

Mít jedno velké repo má svoje výhody – viz zkušenosti FB https://web.archive.org/…book-s-scale

#5 Jakube Kulhane, Jedno repo, jednotné verzování = monolit.

Monolit s možností nainstalovat výřez – všechny ostatní výhody uvedené v článku padají. Dochází i k absurdním situacím, kdy vycházejí nové verze komponent, které se od těch předchozích neliší ani komitem navíc, jen prostě v rámci monolitu vyšla nová verze něčeho jiného.

Co popisuješ je situace, kdy se rozdělení frameworku do komponent prostě nepovedlo. Důvod může být ten, že framework ještě nebyl dostatečně zralý (dělit Nette před 2.0 bych si netroufl). Nebo se řez vedl špatným směrem.

Subtree split je pak způsob, jak rozdělení emulovat, jak si ho vyzkoušet nanečisto. Což je naprosto ok, ale je to provizorium.

#3 Davide Grudle, …JavaScriptová platforma …dotahuje konkurenci…komfort zdaleka nedosahuje toho, na co je člověk zvyklý u jiných platforem…

No – ne že by to nebyla v některých ohledech pravda. Ale pod článkem, který má v pozadí to, jak se php snaží dotáhnout komfortem konkurenci (včetně javascriptové platformy a npm) to působí trochu legračně ;)

Líbí se mi, jak PHP ekosystém jako celek postupuje kupředu. Skalarní datové typy + zrychlení očekáváne v PHP 7, rozšíření používání Composeru (ústup PEARu), HHVM a kvalitní IDE jako je PhpStorm.

#2 Pepo, Tak nějak mě baví sledovat ty názory, že PHP má už odzvoněno 🙂 David jako pamětník se mnou zavzpomíná na vlny, kdy se objevila platforma .NET, JSP. Pak bylo chvíli ticho a přišel boom Djanga následovaný RoR, ale tak nějak mi pořád přijde, že v globálu se PHP vedle Javy profiluje jako jedna z nejsilnějších platforem v komerčním vývoji…

#5 Jakube Kulhane, #6 David Grudl Keď som videl to video od FB, tak som si hneď spomenul na Nette ako sa rozbilo do niekoľkých Git repo a vďaka tomu vznikli nové problémy, napr. ako sledovať zmeny zo všetkych repo na jednom mieste, viac administratívnej práce na spravovanie, a pod…

FB vyriešil ten jeden veľký „monolitický“ repo tak, že zavrhol pomalý Git a použili rýchly Mercurial a jeho Sparse checkouts a Shallow history, čo mu umožnilo lepšie narabať s jednotlivými projektami v jednom repo. Odporúčam to video pozrieť. Zaujímavé veci sa človek dozvie, napr. ako musí FB už inak pristupovať k vývoji pri jeho veľkosti.

Jsem rád že se to hejbe tímto směrem, Jeden čas jsem chtěl používat PEAR jako repozitář ale bylo to nepoužitelné, ovládaní a obsah PEARu byl pod psa.

Skládat si aplikaci z jednotlivých komponent je bezva věc, sám to dlouhé roky prohlašuji za ideál, ale má to i své proti. A myslím si, že za to proti může Composser. Tedy nepřímo.

Že hlídání závislostí řeší nějaký nástroj je dobrá věc, ale pak se stane, že člověk závislosti neřeší vůbec. A tak když si stáhnu pár balíčků řešících různé věci, stáhnu si s nimi, kvůli závislostem, ještě komponenty pro práci s databází, request/response, případně nějakou cool vychytávku co třeba dělá nějaké debugovatelnější exceptions. A legrační na tom je, že každá komponenta používá na ten který úkon jinou komponentu.

Takže ve výsledku mám s 6 cizími komponentami 5 databázových vrstev, 4 request/response handlery a 3 cool vychytávky, které dělají nevím co. Zbytečně. Z „hlídat závislosti není problém“, (což je pravda) se vyklubalo „závislosti nejsou problém“ (což je průser).

#12 OnGe, Problém bych viděl spíš ve vývojářích konkrétních balíčků. Composer podporuje suggest (pro doporučení, co dál k balíčku nainstalovat), které bohužel spostu vývojářů nepoužívá. Co si budeme nalhávat, je jednoduší udělat knihovnu, která má napevno zadrátované závislosti, než knihovnu modulární. :)