11 Best PHP Frameworks for Modern Web Developers in 2017

Mi-a placut acest articol si cine stie poate mai e cineva interesat. Pe mine ma surprinde placut pozitia 3 Codeigniter…

2 Likes

Nici macar nu are un autor acel articol, e scris de cine?

1 Like

La Laravel zice:

Does NOT work on Shared hosting plans

Say whaaat ? De ce sa nu mearga ? Merge pe shared hosting atat timp cat indeplineste Server Requirements (PHP >= 5.6.4 si ceva extensii uzuale). Ai nevoie de access ssh in productie doar daca folosesti Queues, si in development pentru Queues, composer, database migrations (dar se poate si fara). Sunt destule hosturi shared care ofera ssh.

Packages can be easily added with the robust Composer built in to Laravel.

Composer e o unealta pe care o instalezi pe sistemul de development. Instalezi laravel (si pluginuri) prin composer, la fel cum poti instala si alte frameworkuri (ex. cakephp), dar nu e “built in to Laravel”.

La Phalcon cum adica “Not as open source as Laravel” ? Cum compari daca ceva este mai putin/mult open-source decat altceva ?

1 Like

Probabil e o licență diferită de ce acceptă autorul ca fiind open source. (de exemplu, prin open source eu înțeleg că ești liber să faci ce vrei cu softul - e.g. MIT - dar Stallman înțelege că ești liber să faci ce vrei cât timp ce rezultă este open source - e.g. GPL).

E un fel

Toți suntem egali, dar unii sunt mai egali decât alții

:slight_smile:

3 Likes

Framework-uri, bleah.

Tot ce fac e să-mi mărească cu 50% orele lucrate. Bine că-s plătit pe oră.

1 Like

Cum pățești asta? Eu credeam că toată treaba cu framework-urile este că accelerează development-ul…

Oh, da, chestiile simple care oricum le făceam repede, sunt „accelerate”, dar când ai nevoie, de exemplu, să faci un query mai sofisticat, atunci tot cauți cum poți să le scrii de mână decât să folosești ce îți oferă cadrul de lucru.

1 Like

Daca nu te superi ca te intreb…
Cati ani de develeopment ai, faci programare pe vrun fel de mvc, librarie ajutatoare facuta de tine?

2 Likes

Deci… mai bine reinventezi roata de fiecare dată decât să folosești ceva foarte bine documentat? Și că veni vorba despre documentație, ce se întâmplă cu cei care lucrează cu/după tine? Cum se descurcă?

1 Like
  1. Toate framework-urile suprascriu SQL-ul. Dacă vrei să faci un select banal, merge. Dacă vrei să iei date și să faci calcule, e mai rapid să scrii query-ul de mână decât să folosești „ajutorul” framework-ului.

  2. Lucram în CakePHP și trebuia să iau niște date din POST. $this->request->data returna un array gol. După o zi de cercetări am găsit o cale alternativă: $this->request->input(‘json_decode’, true);

  3. Toate au problema asta comună: Ce faci când datele dintr-un tabel modifică comportamentul unui alt model (de obicei un model = un tabel)? Trebuie să inițializezi primul model într-al doilea și să faci astfel de artificii. În funcție de framework, alt artificiu.

  4. Vreau să scriu o clasă independentă, trebuie să văd cum/unde o plasez. Dacă nu e nici controller nici helper nici componentă, nici model, nici behavior, nici nimic, unde trebuie să o pun? Și cum o instanțiez?

  5. Unele framework-uri nu te lasă/nu e documentat cum faci un model fără un tabel. Efectiv am o aplicație cu un tabel gol ca să pot face modelul.

  6. Am un API care trebuie să fie rapid. Asta nu e doar framework-ul, dar și framework-ul strică. La fiecare apel, am un timp diferit. Acum 30 ms, apoi 50 ms, apoi 80 ms, apoi 40. Timpul de execuție diferă în PHP, dar faptul că trebuie inițializate x clase de care nu am nevoie nu ajută.

  7. Un programator prost îți face praf codul orice ai folosi. Toți cer framework-uri că poate-poate dezvoltatorii vor scrie cod inteligil ei între ei. Ași! Când am început să lucrez, codul era imposibil de urmat. De fapt cel care m-a angajat a spus exact asta: încearcă să rezolvi tu. Eu nu am putut urmări logica codului. Și dacă reușești, rescrie-l.

  8. Un framework are mii de fișiere. Lucrez cu phpStorm, via WebDrive. Până parsează un proiect stau 30 minute - 2 ore, în funcție de conexiunea la internet.

  9. Dacă trebuie să fac o pagină simplă: „Mentenanță. Reveniți în 5 minute”, trebuie să: scriu o nouă rută, creez controller-ul, adaug o metodă, să creez view-ul, să leg cu șablonul împlicit (sau să fac un alt șablon fără meniuri), să le leg între ele, să verific că totul merge. Asta în loc de a face un fișier index.html cu h1: Revin-o, frate, mai târziu.

  10. Documentația. După cum probabil ați realizat lucrez mai mult cu CakePHP. Documentația este cel puțin lacunară. Sunt unele lucruri simple ce nu le găsesc explicate în documentație. Și sunt unele standarde care trebuie scrise exact. Uneori e cu literă mare, alteori e cu underscore, alteori e la singular, etc. Din nou pierzi ceva timp până cauți care e problema. Și uneori problema e un typo.

  11. Permisiunea fișierelor. În Cake sunt niște elemente cache-uite. Nu știu de ce, când execut un cronjob, unele fișiere sunt atribuite utilizatorului root (da, lucrez direct cu root). Dar când cer o pagină via browser îmi dă o grămadă de avertizări că nu poate scrie fișierele (că serverul web lucrează cu utilizatorul apache).

  12. În Laravel nu mi se actualizează view-urile. Dacă fac o modificare în codul HTML, trebuie să merg în /storage/views și să șterg ce e acolo să-mi apară schimbările.

  13. Ca să nu mai zic de toate momentele când a trebuit să fac depanare pe framework fiindcă ceva nu mergea. Atât în Laravel cât și în CakePHP.

Până la urmă totul se rezolvă, dar costă timp. Mie nu-mi pasă că sunt plătit pe oră, dar mă gândesc la toți fraierii care dau bani și care mai dau bani și programatorilor proști care nu știu PHP, darămite extinderea unor clase și alte concepte de OOP.

Vorbeam cu cineva din echipă, cică să ne gândim cum să îmbunătățim aplicația. Zic: Ok, la ce anume te-ai gândit. Răspunsul: Let’s use design patterns for better application performance. Say what? Ce pattern, unde, pentru ce caz? Nimic, el/ea știa doar că trebuie să folosim design patterns. Atât, doar expresia. Puteam să-l/să o întreb ce e un singleton că habar n-avea.

4 Likes

Ceva îmi spune că ai înțeles greșit unele chestii și ești supărat pe (unele) frameworkuri din această cauză.

De exemplu:

Un model, prin definiție, este responsabil de datele (din… db?). Ce vrei să ții într-un model gol?

Cum procedezi cu versionarea? Cum te împaci cu colegii pe webdrive?

1 Like

Este un model care procesează datele din mai multe tabele ca să obțină cele mai ieftine combinații de zboruri + cazări + alte procesări. În funcție de metodă, lucrează într-un mod diferit și returnează date diferite. Nu e decizia mea, așa a fost făcut proiectul de la început și așa sunt obligat să-l continui.

Versionarea? Colegii? Fiecare are propriul VPS. Eu am VPS-ul meu pe care-l conectez ca un drive local via WebStorm. Când termin ceva, copiez fișierele modificate într-un director local sub GIT și fac commit-ul.

ala nu-i model. n-are nici o treaba cu conceptul de model.

Evident. Are rost discuția? Not really.

Îmi plac framework-urile? Nu. Dacă încep un proiect, voi folosi un framework? Da.

Sunt un rău necesar, sunt un subiect din punctul meu de vedere tacit. Nu are rost să ridici în slăvi vreun framework/conceptul de framework. Îl folosești fără să vorbești despre el și speri să te lovești doar de părțile bune.

2 Likes

Mare parte din ce ai prezentat ca dezavantaje are legura cu programatorii care au scris codul. Dupa 12 ani de experienta (o parte in anii dinainte framework-urilor pe care le urasti), iti zic ca aplicatiile de care te plangi ar fi fost scrise cel putin la fel de prost si fara un framework (sau preferata mea, folosind un framework inventat de un programator care a auzit de MVC, folosit la un singur proiect).

Esti liber sa incepi sa cioplesti o roata de fiecare data cand incepi sa lucrezi un proiect. Eu prefer sa iau una gata facuta din raft (composer/packagist) si sa o folosesc. Stiu cum merge, ca am desfacut-o in bucatele mici atunci cand am avut probleme si acum castig timp, nu pierd.

PS: nu toate framework-urile s-au nascut egale, eu prefer Symfony.

5 Likes

Deci toată lumea folosește framework-uri fără nici o problemă? Must be just me, then.

1 Like

Ai incercat si micro-framework-uri? Nu stiu daca te ajuta “la munca”, unde altcineva face aceste decizii, dar maca pentru proiecte personale sau ca un experiment, pentru edificare. De exemplu, in Python am folosit urmatoarea reteta: Falcon pentru pentru request handling & controllers, SQLAlchemy ca ORM, Cheetah pentru templating etc. In node am folosit express pentru request handling, knex ca ORM, moustache pentru templating etc. Toate cu o doza mare de alte librarii pentru diverse task-uri. Pierzi din integrarile frumoase din framework-urile mari, si sunt mai putine module “de-a gata”, dar ai mai multa flexibilitate in cum construiesti aplicatia, mai multa vizibilitate in ce se intampla si e “oarecum” mai usor de evoluat. E cam ca Angular vs React & it’s ecosystem.

1 Like

Doar un lucru am de zis: query-urile SQL se scriu in uneltele specifice și se folosesc că atare cu nivelul de securitate aferent (PDO).

Nu știu de ce toți încearcă să aducă in alt nivel de abstractizare absolut inutil. Doar că sa ai coloanele că atribute ale unei clase.

2 Likes

Voi încerca să îți argumentez eu cu un caz practic întâlnit acum câteva zile. Lucrez la o aplicație de task management care urmează a fi folosită de o companie. Precizez că este dezvoltată în framework-ul Laravel.

Ideea de bază a aplicației este următoarea: angajații dau task-uri pentru colegii lor iar acestea sunt afișate într-un dashboard după ce sunt prioritizate pe baza mai multor parametri. Pentru că sunt mai multe departamente în companie a apărut nevoia împărțirii task-urilor în “Workplaces” a.î. un angajat al departamentului de HR să vadă doar task-urile specifice departamentului său.

Luând în calcul și alte implicații, pe care nu le-am prezentat mai sus, am decis să fac următoarele modificări la baza de date: am creat o tabelă cu workplace-urile și am adăugat în mai multe tabele (vreo 5) o cheie externă către tabela pentru workplace-uri.

Dacă aș fi folosit query-uri scrise “raw” atunci ar fi trebuit să editez mult mai mult din cod și să adaug o condiție suplimentară în query-uri: WHERE workplace_id = ?.

Abstractizarea tabelelor din baza de date mi-a fost de ajutor pentru că am folosit următoarea soluție (pe care eu o consider mai elegantă): am creat un global scope (vezi documentație) pe care l-am aplicat modelelor asociate celor 5 tabele. Există și câteva secțiuni (cron jobs) unde nu am nevoie de acel global scope și acolo a trebuit doar să aplic metoda withoutGlobalScopes.