Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: lukan 11. 12. 2018, 06:50:03
-
V čem má dnes význam psát webové aplikace? Přijde mi, že PHP je již zcela mrtvé.
-
V čem má dnes význam psát webové aplikace? Přijde mi, že PHP je již zcela mrtvé.
Áno, PHP používajú len také mŕtve projekty ako google.com či facebook.com:
https://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites (https://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites)
a 90% všetkých ostatných firiem:
https://idatalabs.com/tech/programming-languages (https://idatalabs.com/tech/programming-languages)
-
No ty si kladeš blbě otázku. Přeci zvolený jazyk se určí podle toho co ta aplikace má umět, jsou aplikace na které je PHP skvělé, ale jsou i aplikace kde je lepší sáhnout po něčem jiném jako třeba nodejs, go, python, c#.net no a jsou aplikace kde je ideální směs.
Jinak je zajímavé, že se ohledně aplikací nejčastěji řeší jazyk, přitom nejdůležitější je správně zvolit databázi a strukturu dat, protože to proč je aplikace pomalá nemá s tím v čem byla napsána zpravidla nic společného.
-
Avsak tim smerem nebyla moje otazka smerovana. A tou odpovedi jsem chtel rict, ze neexistuje nejlepsi auto, nejlepsi notebook a stejne tak neexistuje nejlepsi programovaci jazyk a cokoliv dalsiho. Vzdy je potreba stanovit vstupni podminky a hodnotici kriteria. Webova aplikace muze mit 10 navstevniku mesicne a pak je jedno v cem ji napises. Pak to muze byt online periodikum s miliony pristupu mesicne a taky muze byt jedno v cem ji napises (protoze budes hodne pouzivat cache). Pak to muze byt burza a tam se prechod z jedne platformy na druhou muze stat problemem kvuli vykonu prestoze jsou obe platformy tzv velke, dospele a "ne pro lepice jako php".
-
Doporučuju projít průzkum ze StackOverflow, například sekci nejoblíbenějších jazyků, se kterými chtějí programátoři pracovat a nejmíň oblíbených jazyků
https://insights.stackoverflow.com/survey/2018/#most-loved-dreaded-and-wanted
Ono to má svoje důvody - ty jazyky asi nabízí to, co jejich uživatele (programátory) baví, umožní jim dosáhnout čeho chtějí snadným způsobem, elegantně apod.
-
Doporučuju projít průzkum ze StackOverflow, například sekci nejoblíbenějších jazyků, se kterými chtějí programátoři pracovat a nejmíň oblíbených jazyků
https://insights.stackoverflow.com/survey/2018/#most-loved-dreaded-and-wanted
Ono to má svoje důvody - ty jazyky asi nabízí to, co jejich uživatele (programátory) baví, umožní jim dosáhnout čeho chtějí snadným způsobem, elegantně apod.
Teď je ještě otázka, kolik toho v těch vysněných jazycích doopravdy napsali a nakolik je to jen wow-efekt z něčeho nového, módního po prvním "hello worldu".
S přibývajícími léty mám čím dál silnější pocit, že čím rozsáhlejší projekt, tím více je jedno, v čem je to vlastně napsané - z hlediska přehlednosti a pohodlnosti vývoje. A že člověk si musel za těch pár desítek let vyzkoušet všechno možné, od BASICu, přes různé objektové a funkcionální přístupy, aby nakonec dospěl k závěru, že z hlediska univerzálnosti není nad klasický strukturovaný přístup, který zná už z prachobyčejného Pascalu od svých 15 let. Všechno ostatní jsou více či méně doménově specifické nástroje a v ambicích, jež se do nich vkládaly, naprosto selhaly. Akorát se dnes málokdo ohlédne těch 20-30 let zpátky, aby si toho všiml.
-
S přibývajícími léty mám čím dál silnější pocit, že čím rozsáhlejší projekt, tím více je jedno, v čem je to vlastně napsané - z hlediska přehlednosti a pohodlnosti vývoje. A že člověk si musel za těch pár desítek let vyzkoušet všechno možné, od BASICu, přes různé objektové a funkcionální přístupy, aby nakonec dospěl k závěru, že z hlediska univerzálnosti není nad klasický strukturovaný přístup, který zná už z prachobyčejného Pascalu od svých 15 let. Všechno ostatní jsou více či méně doménově specifické nástroje a v ambicích, jež se do nich vkládaly, naprosto selhaly. Akorát se dnes málokdo ohlédne těch 20-30 let zpátky, aby si toho všiml.
Objektové a fukcionální přístupy jsou lepší než strukturované, ale bohužel stále převažuje strukturovaný přístup i v jazycích, které jsou označovány za objektové. Možná právě proto jsou tak protežovány funkcionální jazyky, ve kterých se dá alespoň částečně psát strukturovaně. Všichni totiž tíhnou k tomu strukturovanému přístupu, i když vědí, že to úplně správné není.
-
S přibývajícími léty mám čím dál silnější pocit, že čím rozsáhlejší projekt, tím více je jedno, v čem je to vlastně napsané - z hlediska přehlednosti a pohodlnosti vývoje. A že člověk si musel za těch pár desítek let vyzkoušet všechno možné, od BASICu, přes různé objektové a funkcionální přístupy, aby nakonec dospěl k závěru, že z hlediska univerzálnosti není nad klasický strukturovaný přístup, který zná už z prachobyčejného Pascalu od svých 15 let. Všechno ostatní jsou více či méně doménově specifické nástroje a v ambicích, jež se do nich vkládaly, naprosto selhaly. Akorát se dnes málokdo ohlédne těch 20-30 let zpátky, aby si toho všiml.
Objektové a fukcionální přístupy jsou lepší než strukturované, ale bohužel stále převažuje strukturovaný přístup i v jazycích, které jsou označovány za objektové. Možná právě proto jsou tak protežovány funkcionální jazyky, ve kterých se dá alespoň částečně psát strukturovaně. Všichni totiž tíhnou k tomu strukturovanému přístupu, i když vědí, že to úplně správné není.
Nejsem přesvědčen ani o prvém, ani o druhém. Jsou problémy, na něž je objektový přístup lepší, a jiné problémy, jimž více sedí funkcionální. Ale strukturovaný se mi jeví jako ten nejuniverzálnější. Z hlediska návrhu jsou oba zmíněné přístupy náročnější. Objektový přístup měl zjednodušit a zrychlit návrh a umožnit znovupoužitelnost kódu. Selhal ve všech bodech. Objektové programy jsou nepřehledné, zbytečně překombinované, náročné na zdroje. Šlo by to jistě i jednodušeji, ale vymyslet dobrý objektový návrh je prostě mnohem náročnější než u strukturovaného - nutí člověka řešit otázky, které při strukturovaném návrhu řešit není třeba, protože zásadně nesouvisejí s problémem. Navíc jejich chybné vyřešení má závažný dopad na celý projekt. Podělat objektový návrh je zkrátka mnohem jednodušší než u strukturovaného.
-
Jsou problémy, na něž je objektový přístup lepší, a jiné problémy, jimž více sedí funkcionální. Ale strukturovaný se mi jeví jako ten nejuniverzálnější. Z hlediska návrhu jsou oba zmíněné přístupy náročnější. Objektový přístup měl zjednodušit a zrychlit návrh a umožnit znovupoužitelnost kódu. Selhal ve všech bodech. Objektové programy jsou nepřehledné, zbytečně překombinované, náročné na zdroje. Šlo by to jistě i jednodušeji, ale vymyslet dobrý objektový návrh je prostě mnohem náročnější než u strukturovaného - nutí člověka řešit otázky, které při strukturovaném návrhu řešit není třeba, protože zásadně nesouvisejí s problémem. Navíc jejich chybné vyřešení má závažný dopad na celý projekt. Podělat objektový návrh je zkrátka mnohem jednodušší než u strukturovaného.
Strukturovanému přístupu obvykle chybí pozdní a velmi pozdní vazba. Objektové programy nemusí být nutně pomalejší než strukturované. V mém případě bývají objektové dokonce rychlejší, protože u objektového návrhu odpadá velké množství různého větvení programu.
Objektové programy nejsou ani nepřehledné, ani překombinované, ba ani náročné na zdroje. Problém je jen v programátorech, kteří použijí nevhodnou architekturu aplikace, nevhodné návrhové vzory a nevhodné algoritmy.
Souhlasím, že vymyslet dobrý objektový návrh je pro vývojáře náročnější. Je problém ho udělat tak, aby se co nejvíc činností odehrávalo uvnitř objektu a bylo co nejméně vazeb mezi objekty. Proti chybnému řešení se však dá velmi dobře bránit testy, které skvěle vedou k maximální izolaci objektů.
-
Jsou problémy, na něž je objektový přístup lepší, a jiné problémy, jimž více sedí funkcionální. Ale strukturovaný se mi jeví jako ten nejuniverzálnější. Z hlediska návrhu jsou oba zmíněné přístupy náročnější. Objektový přístup měl zjednodušit a zrychlit návrh a umožnit znovupoužitelnost kódu. Selhal ve všech bodech. Objektové programy jsou nepřehledné, zbytečně překombinované, náročné na zdroje. Šlo by to jistě i jednodušeji, ale vymyslet dobrý objektový návrh je prostě mnohem náročnější než u strukturovaného - nutí člověka řešit otázky, které při strukturovaném návrhu řešit není třeba, protože zásadně nesouvisejí s problémem. Navíc jejich chybné vyřešení má závažný dopad na celý projekt. Podělat objektový návrh je zkrátka mnohem jednodušší než u strukturovaného.
Strukturovanému přístupu obvykle chybí pozdní a velmi pozdní vazba. Objektové programy nemusí být nutně pomalejší než strukturované. V mém případě bývají objektové dokonce rychlejší, protože u objektového návrhu odpadá velké množství různého větvení programu.
Objektové programy nejsou ani nepřehledné, ani překombinované, ba ani náročné na zdroje. Problém je jen v programátorech, kteří použijí nevhodnou architekturu aplikace, nevhodné návrhové vzory a nevhodné algoritmy.
Souhlasím, že vymyslet dobrý objektový návrh je pro vývojáře náročnější. Je problém ho udělat tak, aby se co nejvíc činností odehrávalo uvnitř objektu a bylo co nejméně vazeb mezi objekty. Proti chybnému řešení se však dá velmi dobře bránit testy, které skvěle vedou k maximální izolaci objektů.
Problém všech těch alternativních paradigmat a v jejich rámci dále návrhových vzorů je v tom, že na papíře to vypadá všechno krásně jednoduše a elegantně. Ale v praxi z toho vzniká horor. To rozházení do objektů a řešení rozhraní každého z nich je zkrátka náročné. Vždyť to je problém i na úrovni celého programu, OOP z toho udělalo problém i v jeho jednotlivých vnitřních částech. Když k tomu připočteme, že pro účely OOP se postupně prosadily ty nejméně vhodné jazyky, tak z toho skutečně vzniká katastrofa.
http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end
Jinak pozdní vazba se dá i ve strukturovaném návrhu udělat - tam, kde je opravdu zapotřebí. Ovšem vždy povede k pomalejšímu běhu a náročnějšímu programu, když dopředu nevím, co mi v daném místě může přistát - v případě čistých OO jazyků cokoli. Aby nevznikla mýlka - nejsem úplně proti OOP nebo FP. Ale tvrdím, že to na potřebné úrovni nezvládá skoro nikdo, takže masové nasazení je prostě omyl.
-
Problém všech těch alternativních paradigmat a v jejich rámci dále návrhových vzorů je v tom, že na papíře to vypadá všechno krásně jednoduše a elegantně. Ale v praxi z toho vzniká horor. To rozházení do objektů a řešení rozhraní každého z nich je zkrátka náročné. Vždyť to je problém i na úrovni celého programu, OOP z toho udělalo problém i v jeho jednotlivých vnitřních částech. Když k tomu připočteme, že pro účely OOP se postupně prosadily ty nejméně vhodné jazyky, tak z toho skutečně vzniká katastrofa.
OOP vzniklo právě proto, aby se jeden velký problém rozdělil na více malých problémů, které jdou snadno řešit, resp. se do nich dá recyklovat již hotový kód. Náročné rozhraní? Stačí se jen podívat na zásady SOLID a hned vidíš, jak málo jsou dodržovány. Místo SRP různé god objekty. OCP je ignorováno - každý si přejmenovává metody, kdy se mu zamane a neváhá přitom měnit i signatury v rozhraní. LSP? O zaměnitelnosti potomků s rodiči si fakt můžeme nechat zdát. ISP je pro mnoho vývojářů jen dobrým vtipem. A DIP? Jeho implementace v podobě různých DIC tento princip zcela degradují.
Z toho je vidět, že OOP se v praxi moc nepoužívá. V podstatě se strukturované programování jen převlékne do objektového kabátku a je to. Získáme tím paskvil, který je pomalejší, komplikovanější a méně srozumitelný, než jaký by byl ve strukturovaném zápisu.
A teď do toho přijde FP, který ukazuje, jak elegantně se vše dá řešit pomocí funkcí a monád. Dobrá, začtu se do prvního netriviálního programu a co vidím? Opět strukturovaný paskvil. Moduly ne nepodobné god objektům. Vychvalované namespace neplnící svou funkci, neboť dvacetiznakové neintuitivní názvy funkcí určitě nejsou to, co jsme od toho chtěli. Když se na něco zeptáš, tak jsi místo odpovědi poslán do teorie kategorií. Proč? Protože tomu skoro nikdo pořádně nerozumí.
Když se tedy vrátíme ke strukturovanému programování, tak proč jsme nezůstali u osvědčeného Fortranu?
Jinak pozdní vazba se dá i ve strukturovaném návrhu udělat - tam, kde je opravdu zapotřebí. Ovšem vždy povede k pomalejšímu běhu a náročnějšímu programu, když dopředu nevím, co mi v daném místě může přistát - v případě čistých OO jazyků cokoli. Aby nevznikla mýlka - nejsem úplně proti OOP nebo FP. Ale tvrdím, že to na potřebné úrovni nezvládá skoro nikdo, takže masové nasazení je prostě omyl.
Když jsem kdysi používal pozdní vazbu v Pascalu, tak jsem byl za exota. Přitom to bylo velmi elegantní řešení mnoha problémů, které vůbec nebylo pomalé ani náročné. Naopak se tím dalo zredukovat větvení programu, takže to mohlo být i rychlejší.
-
Tak dobry vtip jsem dlouho neslysel - dobry navrh OOP se da cilit pomci provadenych testu.... To je treba zaramovat :)
-
Tak dobry vtip jsem dlouho neslysel - dobry navrh OOP se da cilit pomci provadenych testu.... To je treba zaramovat :)
Ano, lidem, kteří nerozumí TDD, to připadá směšné.
-
Tak dobry vtip jsem dlouho neslysel - dobry navrh OOP se da cilit pomci provadenych testu.... To je treba zaramovat :)
Ono to neni tak mimo jak by se mohlo zdat. Pokud budes delat TDD by the book... a zakazes si pouziti mocking knihoven...
Tak te to opravdu dovede k lepsimu navrhu.
-
Tak dobry vtip jsem dlouho neslysel - dobry navrh OOP se da cilit pomci provadenych testu.... To je treba zaramovat :)
Možná se nejdřív koukněte do zrcadla, komu že se to vlastně smějete.
Správné uplatňování testů a TDD obecně téměř vždy vede k lepšímu návrhu (nejen u OOP), protože:
1. Nejdříve musíte přemýšlet nad vhodným interfacem a až pak řešíte interní detaily
2. Kvalitu vnějšího interfacu okamžitě podrobujete praktické zkoušce jste nuceni jej předělat, pokud narazíte na problém
Čím méně zkušený programátor, tím více jej TDD vede správným směrem.
-
V čem má dnes význam psát webové aplikace?
V Go.
Přijde mi, že PHP je již zcela mrtvé.
Bohužel není.
-
V čem má dnes význam psát webové aplikace? Přijde mi, že PHP je již zcela mrtvé.
Nie, nie je. Vo verzii 7 a so Symfony či Doctrine je to naprosto použiteľný jazyk. Avšak ak sa len chystáš začať, PHP si už nevyber.
Ak ti ide primárne o vývoj web aplikácií a najčastejšie budeš robiť REST / GraphQL API, tak na to je momentálne najlepšia Java a s jej znalosťou budeš aj na trhu práce najperspektívnejší. Node je fajn, ale neťahal by som ho do Enterprise oblasti, Go je fajn, ale stále je to oproti Jave viac módna ako praktická voľba, atď.
Suma sumárum: ak už PHP vieš, pokojne pri ňom ostaň a prehlbuj si jeho znalosti - ešte dlhé roky budeš mať o prácu postarané. Ale ak ho nevieš, ani s ním už nezačínaj. S Javou dokážeš to isté a bude to ako robustnejšie, tak výkonnejšie, či škálovateľnejšie riešenie, a preto aj platovo vyššie cenené. A Go, Rust a podobne sú na backendoch web aplikácií príliš málo používané, aby si ich riskoval ako hlavný jazyk, vedel len tie. Mal by si s nimi problém nájsť si tu zamestnanie.
-
najčastejšie budeš robiť REST / GraphQL API,
a v cem konkretne ma byt s timhle v PHP problem?
S Javou dokážeš to isté a bude to ako robustnejšie, tak výkonnejšie, či škálovateľnejšie riešenie,
jsou tohle vzdy hlavni hodnotici kriteria?
-
Tak dobry vtip jsem dlouho neslysel - dobry navrh OOP se da cilit pomci provadenych testu.... To je treba zaramovat :)
Možná se nejdřív koukněte do zrcadla, komu že se to vlastně smějete.
Správné uplatňování testů a TDD obecně téměř vždy vede k lepšímu návrhu (nejen u OOP), protože:
1. Nejdříve musíte přemýšlet nad vhodným interfacem a až pak řešíte interní detaily
2. Kvalitu vnějšího interfacu okamžitě podrobujete praktické zkoušce jste nuceni jej předělat, pokud narazíte na problém
Čím méně zkušený programátor, tím více jej TDD vede správným směrem.
Má to v sobě i určitá úskalí, protože takový postup může vést k tomu, že vymyslím vhodná rozhraní pro testování, což ovšem není totéž, jako vhodná rozhraní pro normální běh programu. Pravda, je to určitě lepší než rozhraní nevhodná pro nic, ale optimální to taky není.
Když dám příklad z elektroniky, tak je to jako navrhnout jednotlivé moduly většího celku tak, že k nim půjdou krásně připojit měřící přístroje a každý modul půjde autonomně otestovat (protože každý bude mít např. vlastní generátor hodin), ale vzájemné propojování těch modulů bude nedomyšlené a vzájemná synchronizace bude obtížná (právě protože každý bude mít např. vlastní generátor hodin místo centrálního zdroje).
Jiná typická chyba podobného rázu je "logický" postup při návrhu programu tak, jak se bude program postupně inicializovat, v jakém formátu bude program generovat/přijímat data apod. Společnou chybou je zatížení uvažování od běžného použití směrem k situacím, které nejsou běžné či nejsou podstatné z hlediska funkce.
Zkrátka testování může včas odhalit některé nedostatky navrženého rozhraní, ale určitě bych nespoléhal na to, že požadavek navrhnout nějaké rozhraní alespoň kvůli testům implikuje, že to rozhraní bude ideální i z hlediska normálního běhu a vývoje programu. To mohou být v lepším případě mimoběžné, v horším dokonce protichůdné požadavky.
-
najčastejšie budeš robiť REST / GraphQL API,
a v cem konkretne ma byt s timhle v PHP problem?
S Javou dokážeš to isté a bude to ako robustnejšie, tak výkonnejšie, či škálovateľnejšie riešenie,
jsou tohle vzdy hlavni hodnotici kriteria?
Nepíšem tam, že s tým má PHP nejaký problém. Nepíšem tam ani len o jedinom probléme s PHP, takže nerozumiem na čo sa to vôbec pýtaš. Odporúčam prečítať si znovu moju odpoveď a tentokrát pomaly a pozorne.
A samozrejme, že robustnosť, výkonnosť a škálovateľnosť sú snáď najdôležitejšie kritériá. Ak nesúhlasíš, pokojne napíš ktoré považuješ za dôležitejšie.
-
A samozrejme, že robustnosť, výkonnosť a škálovateľnosť sú snáď najdôležitejšie kritériá. Ak nesúhlasíš, pokojne napíš ktoré považuješ za dôležitejšie.
TCO je daleko nad tim co jsi napsal.
-
A samozrejme, že robustnosť, výkonnosť a škálovateľnosť sú snáď najdôležitejšie kritériá. Ak nesúhlasíš, pokojne napíš ktoré považuješ za dôležitejšie.
TCO je daleko nad tim co jsi napsal.
Aha. No a to sa vylučuje s tým, čo som písal?
-
U drtive vetsiny projektu ano.
-
U drtive vetsiny projektu ano.
Ale tak to si si vyslovene vymyslel.
-
V čem má dnes význam psát webové aplikace? Přijde mi, že PHP je již zcela mrtvé.
To čo vás to v tej škole učia. PHP mŕtvy jazyk? Veď je to jeden z najpopulárnejších jazykov
na tvorbu webových aplikácií. Jazyk sa aktívne vyvíja a s ním aj jeho ekosystém.
Nie, nie je. Vo verzii 7 a so Symfony či Doctrine je to naprosto použiteľný jazyk.
Ja by som pridal aj Laravel a určite aj Yii či CakePHP a ďalšie. V dnešnej dobe už frameworky konvergujú
a inšpirujú sa navzájom. Nedá sa podľa mňa povedať, že ROR je oveľa lepšie ako Django či Symfony alebo naopak.
Ale ak ho nevieš, ani s ním už nezačínaj.
Čo ja viem, naučiť sa Symfony a PHP a potom prejsť k Jave/Springu mi prijde znesiteľnejšia cesta, ako
priamo skočiť na Javu a Spring. Symfony sa veľmi inšpirovalo práve Springom. Ďalej na menšie a stredne
veľké projekty je oveľa lepšia voľba PHP; ideálne tiež pre mnohé startupy. Java je pre menšie projekty
kanón na vrabce.
Predstavme si, že niekto chce rozbehnúť stredne veľkú aplikáciu na webe. S Linux/FreeBSD, PHP/Laravel/Symfony, nginx, PostgreSQL/MariaDB, Cloudways zrejme nemá konkurenciu, čo sa týka rýchlosti, pohodlnosti vývoja a nasadenia.
Na Cloudways máte bezkonkurenčne najlacnejší plán začínajúci od 10$ za mesiac.
Existuje x skvelých frameworkov ako Python/Django, C#/.Net Core, JavaScript/Express.js, ale s možnosťami nasadenia
a cene sa PHPčku nemôžu rovnať.
-
Symfony sa veľmi inšpirovalo práve Springom.
To považuji za chybu. Dost mi vadí, jaké nesmysly si tyto frameworky tahají z Javy. PHP je jiným jazykem a inspirace Javou vede k tragickému kódu.
-
Symfony sa veľmi inšpirovalo práve Springom.
To považuji za chybu. Dost mi vadí, jaké nesmysly si tyto frameworky tahají z Javy. PHP je jiným jazykem a inspirace Javou vede k tragickému kódu.
Čo konkrétne máš na mysli? Moje primárne jazyky sú Java/Python a len nedávno som začal koketovať s PHP.
Symfony a Laravel mi prijdú kompaktné, veľmi dobre organizované. Ako prvé ma zaujal workflow; ten je oproti
Jave oveľa jednoduchší. Symfony ma validáciu kompletne prebratú z Java špecifikácie, sú tam pre Javistu známe pojmy ako Repository, Dependency Injection, Services atď, akurát to nie je tak komplexné a komplikované. Počul som už nariekať nad tým, že PHP preberá z Javy (CodeIgniter používatelia), ale neviem, čo presne im vadí.
JavaScript je odlišný, tam napr. v tom Express.js nie sú triedy, všetko ide cez funkcie -- middleware, cesty, modely.
-
Symfony sa veľmi inšpirovalo práve Springom.
To považuji za chybu. Dost mi vadí, jaké nesmysly si tyto frameworky tahají z Javy. PHP je jiným jazykem a inspirace Javou vede k tragickému kódu.
Čo konkrétne máš na mysli? Moje primárne jazyky sú Java/Python a len nedávno som začal koketovať s PHP.
Symfony a Laravel mi prijdú kompaktné, veľmi dobre organizované. Ako prvé ma zaujal workflow; ten je oproti
Jave oveľa jednoduchší. Symfony ma validáciu kompletne prebratú z Java špecifikácie, sú tam pre Javistu známe pojmy ako Repository, Dependency Injection, Services atď, akurát to nie je tak komplexné a komplikované. Počul som už nariekať nad tým, že PHP preberá z Javy (CodeIgniter používatelia), ale neviem, čo presne im vadí.
JavaScript je odlišný, tam napr. v tom Express.js nie sú triedy, všetko ide cez funkcie -- middleware, cesty, modely.
Konkrétně mi vadí, že tyto frameworky používají například přístupové metody k datovým objektům. Proč, když PHP má immutable kolekce, se kterými umí pracovat mnohem efektivněji a přehledněji? Ostatní objekty mám také immutable. K čemu statické metody, když je PHP také nepotřebuje? Proč se v těch frameworcích nevyužívají vestavěné funkce a funkcionální přístupy?
PHP je vyspělým programovacím jazykem, který žádné frameworky nepotřebuje. Vše potřebné má již v základu nebo v modulech.
-
U drtive vetsiny projektu ano.
Ale tak to si si vyslovene vymyslel.
Zkus si dat do pomeru pocet projektu ktere potrebuji resit skalovatelnost apod s temi, kde je to buřt. Ne vsechno co se programuje jsou banky a telco.