zrovna v teto dobe delam projekt na php. Lepe receno neni to jenom php, je to propletena kombinace html, css, javascript, php a sql. html mi nedela problemy, css trosku, sql absolutne ne. Jenom ta kombinace javascript-php. Javascript je pekny, dobre se pouziva, ovsem clovek si musi davat pozor, aby to fungovalo na vsech browserech. To uz dnes vetsinou funguje. Ovsem php je proste hruza. Naprosto nekonzistentni knihovny, objektove programovani sice do php dorazilo, ale stringy a array nejsou objekty. Tim padem jsou tady desitky funkci s pomerne nejednotnymi jmeny a dost blbe se to pouziva. Hlavne z duvodu ze v jednom file je kousek php, kousej javascript, nekdy uz ani nevim, ktery kousek je ktery a v kazdem se na stringy pouzivaji jine funkce. Proc se i na serverove strane nepouziva javascript? Vyvijet takovouhle aplikaci by bylo 100 krat jednodussi. Na php se mi ovsem libi, ze se dobre integruje do html stranek. Tohle se jim celkem povedlo.
Pokud děláte PHP doporučil bych určitě jít do nějakého frameworku, ať se dostanete do MVC (např. Nette je velmi dobrá volba). Ušetří to mnoho práce a zajistí to udržitelnost projektu (přehlednost, snadná modifikace atd.). Vyřeší to za Vás i mnoho problémů včetně jednotnosti knihoven atd.
Co se týče js na serveru... poslední dobou je poměrně populární Node.js, ale s tím jsem nepracoval, ale možná vám k tomu řekne někdo jiný.
Frameworky jsou kapitola sama pro sebe. Udržitelnost je s nimi samozřejmě větší, ale musíte opravdu respektovat daná pravidla. Jinak si ho zašprcnete na verzi, ze které se nehnete. Zrovna Nette moc nevyniká ani přechodovými cestami, ani soudržností verzí frameworku a modulů. V tomto ohledu je zajímavější spíš Symfony. Oba zmiňované jsou ale za cenu obrovské ztráty výkonu, jen "Hello World" trvá nesmyslný čas. Symfony to umí aspoň částečně kompenzovat preloadem v PHP 7.4. Ale to všechno jsou obezličky, které kompenzují to, že se PHP používá na úplně něco jiného, než na co by se ve skutečnosti hodilo (psal už někdo výše). Nejpopulárnější a taky nejhorší, co se může potkat je pak kombinace Apache s podporou htaccess, framework (nette, symfony) a ORM. Skvěle se to naprogramuje a běží to do prvního výkonnostního problému. Pak je utrum a nejde to pořadně vyladit.
1) tohle neni zase tak uplne pravda.
2) na hello world si fakt nebudu brat framework
3) kolik programatoru se potka s appkou kde performance opravdu musi resit?
4) i s tim PHP dokazeme na Symfony vykon ktery bohate staci pro bezne zpravodajske servery.
5) ORM je dobry sluha, ale zly pan. tam souhlasim, ze to muze byt bolest. Ale zase proste pocitac vs programator je v nakladech neporovnatelne takze v pripade vyssiho loadu pridame aplikacni server a balancer to poresi :-)
6) jasne, na velín jaderne elektrarny nebo rizeni rakety pouziju neco jinyho
@bez přezdívky
Tyto argumenty slýchávám často a každý jednotlivě platí. Programátoři pak naprogramují appku, která POSTEM posílá megabajty dat a díky ORM je zpracovávají v paměti. Na PHP Vám nezbude než nastavit vysoké limity RAM i POST.
...a v jeden okamžik se Vám server dostane do stavu, kdy "něco" přestane fungovat a nemáte ani jak najít chybu. Server, na kterém by běžela jen jedna apka a FPM pool nebyl sdílený aby člověk pohledal (je to pak drahé na prostředky = vysoká cena). Takže z malých projektů, které nepotřebují výkon, se Vám poskládá velký průser. Zákazník pak ječí, proč to nefunguje a vysvětlujte mu, že místo sdíleného hostingu si má pronajmout managed VPS nebo bare metal, pokud nechce ani čas od času zažívat problémy.
Ale to už jsme na hony daleko od tématu. To bylo, že PHP se dnes používá úplně jinak, než na co by se opravdu hodilo. Vynalejzají se ohejbáky a na ně narovnáváky (viz "přidáme aplikační server a balancer").
Souhlas. Nette (nebo Symfony) jsou dobrá volba. Patří mezi technologickou špičku v PHP ať už co se kvality týče, dokumentace, nebo v tom, že DG je fakt fanatik co se zpětné kompatability a BC týče.
Symfony víc vyniká určitou šíří záběru. Ale IMHO je trochu víc akademickej a prekombinovanej.
JS na serveru v dnešní době není problém - respektive je to už problém jen hostingů. Ekosystím kolem Node.js je obrovskej.
1. miešanie rôznych jazykov v stejných súboroch bol vždy humus.
2. niekedy si nemôžeš dovoliť tým na osobitné riešenie backendu a frontendu a niekedy to ani nie je moc možné.
Ostatne v JavaScripte viem jednoducho spraviť jak front-end tak back-end, s frameworkom Svelte/Sapper je to úplne zábava v tom robiť.
To neni zas tak problem v jednom souboru nebo ve dvou souborech, ale v tom, ze musis paralelne myslet ve dvou jazycich a pak v javascriptu pisu promenne s dolarem na zacatku a v php pristupuju do pole pres tecku.
Nejvic me na php stve prave to, ze se do pole nedostanes pres tecku, jako treba v lua nebo v js. Psat vsechny pristupy jako pole['xxx'] misto pole.xxx je na zblazneni. K tomu ti zadny framework nepomuze.
Navic jsem tady z historickych duvodu nucen to psat tak, aby to bezelo jak na php 4, tak na php 7 nebo ktera je posledni, takze skutecne opruz.
Ze by jeden clovek delal backend a druhy frontend je sice mozna dobra idea v pripade, ze pracujes na velkem projektu ve firme kde je 100 lidi. Ovsem pro tento maly projekt a malou firmu by to nebylo. Mimo jine i kvuli tomu, ze se frontend i backend meni soucasne a dost propletene.
"a v php pristupuju do pole pres tecku.
Nejvic me na php stve prave to, ze se do pole nedostanes pres tecku, jako treba v lua nebo v js. Psat vsechny pristupy jako pole['xxx'] misto pole.xxx je na zblazneni. K tomu ti zadny framework nepomuze."
??? ak viem, nie je tečka prístup do objektu? zrovna nikde som nevidel používať pole.2 ako aby som načítal hodnotu z pola na indexe 2... to ešte častejšie vidím obj["property"]...
Není. Pro přístup k property používá šipku.
A naopak, PHP to má vymyšlené chytře, protože v objektu jsou dva kontexty: jeden pro property, druhý pro klíče pole, takže v něm můžeš používat oboje. Někdo by se mohl pozastavit nad tím, proč to mít - potud ok, ale IMHO Javascript to má s možností přistupovat přes tečku i přes index špatně.
> Navic jsem tady z historickych duvodu nucen to psat tak, aby to bezelo jak na php 4, tak na php 7 nebo ktera je posledni, takze skutecne opruz.
Pokud Vás za tohle neplatí naprosto královsky, tak bych doporučoval se poohlédnout po jiném zaměstnání, kde Vás nikdo nebude nutit prasit místo programovat.
Vis, ono to neni tak jednoduche. On se hrozne jednoduse programuje nejaky web system, ktery pojede nekde na hostingu, kde si muzes nainstalovat co chces. Tohle co delam musi bezet na systemech, ktere jsou u klientu a nektere z techto systemu bezi na strojich, ktere maji 10+ let. S operacnim systemem, ktery ma 15 let. Zkus na tom rozjet neco novejsiho. A zkus presvedcit nekolik stovek klientu, ze si maji koupit lepsi hardware a dostat na to lepsi software. Ja budu jenom rad, kdyz se ti to povede, nebudu muset delat eskamontaze s kompatibilitou.
Takze mi nezbyva, nez se smirit s tim, ze musim psat tak, aby to bezelo i na php4 a mysql 3.23
> Takze mi nezbyva, nez se smirit s tim, ze musim psat tak, aby to bezelo i na php4 a mysql 3.23
Tak to je to, co jsem se snažil naznačit - těch možností máte rozhodně více než se s tím smířit. Prostě se taky můžete rozhodnout to už dále nedělat. Nebo to dělat, ale stanovit si podmínky takové, aby to nebyla jen rezignace, ale aktivní rozhodnutí - "fajn, chcete to mít na 10+ let starém stroji, tak to bude stát 5x tolik", protože Vás to nakonec 5x tolik (možná i více) stojí na vývoji.
"fajn, chcete to mít na 10+ let starém stroji, tak to bude stát 5x tolik", protože Vás to nakonec 5x tolik (možná i více) stojí na vývoji.
To je jediná aspoň trochu fungující cesta. Plus zákazníkům posílat informace o životních cyklech technologií a další podklady, aby rozuměli tomu, proč se to projeví na ceně (jinak mají pocit, že je jen "trestáte" bez důvodu).
V praxi se ale vždycky najde aktivní blbec, který neví, že to je problém, přijde a udělá to. Sice si možná po pár měsících, letech nabije ústa, ale to v té době jste už bez zákazníka a zakázky.
Naprosty souhlas. Presne tohle mame v umyslu. Sice to nebude stat 5x tolik, ale rozhodne ti, co maji system postaveny na OS z roku 2004 bud upgradnou na novejsi os, ve vetsine pripadu i zelezo, na tom starem zeleze nic noveho nejede a kdyz jo, tak silene pomalu. Nebo budou platit o kus vic za upgrady. A kazdy rok o vetsi kus vic, ono je to prestane bavit. Protoze ja si tady musim psat jak blbec i funkce jako json_encode - podle manualu php4 by tam sice mela byt, ale neni nebo xml parser. Taky neexistuje. Proste silenost. Nehlede na potencialni bezpecnostni problemy celeho systemu, jak uz tady taky nekdo zminil.
> Navic jsem tady z historickych duvodu nucen to psat tak, aby to bezelo jak na php 4, tak na php 7
A nepramení tedy váš hejt z toho, že porovnáváte verzi z roku 2004 (!) se současnými jazyky?
> Psat vsechny pristupy jako pole['xxx'] misto pole.xxx je na zblazneni.
Lua neznám, ale teda pole.i ani slovník."klíč" jsem neviděl nikde jinde, ani v tom JS.
Přesně kuli takovejm punkovejm vývojářum, jako jste vy, si lidi o php myslí, že je to kentus jazyk. Nic ve zlym, punkoví vývojáři jsou potřeba ve startupech (ať se jedná o php, python, java), aby se ušetřily peníze a rychle se to rozjelo, ale jak se projekt začne sám platit, mělo by se zainvestovat do refaktoringu a napsat to pořádně, klidně i v jinym jazyce, kterej podle vás "neni příšernej". Samozřejmě to nemusí být tak jednoduchý, ale zažil jsem, když startup prorazil na nějakym wtf kódu a po pár letech to začali přepisovat. Pak třeba Rohlík, jestli se nepletu, přechází/přešel z php na javu.
Jsem víceméně backendový vývojář, ale svého času jsem dělal fullstack a nějak jsem neměl problém mít separé js, php i html. Ono to "separé php a html" neni tak uplně pravda, ať už jsem dělal na custom frameworku, kterej templaty řešil vyloženě phpkem, nebo jsem používal třeba nette s latte, který je víceméně zase zpracovávaný phpkem. Ale tak to funguje všude, i v javě. A zrovna v javě jsem narazil fakt na mixování html a JAVY. Nebo úžasná konstrukce - instance vytvořená anonymní funkcí a přiřazená ihned při inicializaci proměnné. To byl poslední hřebíček do rakve a s javou jsem definitivně rozloučil :)
Prasit a dělat ostudu ste dá v jakymkoli jazyce. Že někdo narazí na hnusnej kód v php, za to sice php částečně může svou jednoduchostí, ale zároveň ta jeho jednoduchost je důvod, proč je tak rozšířenej i přes jeho neduhy.
Laravel mi teda prijde spis jak inspirovany Ruby on Rails, coz kolem a kolem nemam PHPkarum za zle, ze konecne vnesli nejake koncepty a struktury do PHP aplikaci. To je podle mne ten duvod, proc spousta lidi povazuje PHPko za "hnusny", protoze kdyz otevrete Wordpress, Drupal a Joomlu tak v tom, aby se prasatko vyznalo.
Samozrejme prasit se da v kazdym jazyku a spousta lidi zacalo programovat diky "dostupnosti" PHP, coz prineslo i to, ze kazdej si to delal po svem.
Setkal jsem se relativne castokrat s problemem, kde PHP programatori duplikovali z nejakeho duvodu napr. funkcinolitu OS viz pristup k souboru nebo network stack kvuli CDN. Cili naucili se pouzivat kladivo a kazdy problem byl najednou hrebik.
Dalsi vec jsou PHP balicky, composer, jak si pustit neco ala RVM/virtualenv v php bohuzel nenasel jsem nic moc podobneho. To, ze vynechali jednu major verzi, mluvi samo za sebe (kazdej problem byl hrebik).