exact asta e si parerea mea.
si adaug la asta si ca in domeniu se folosesc foarte multi termeni care nu au definitii foarte exacte (lucru care nu e musai rau, insa e bine sa fim constienti de asta cand ii folosim intr-o discutie).
argumentul meu (pentru impartirea dupa insemnatate si nu dupa locul executiei) vine din faptul ca locul executiei e de cele mai multe ori relativ, iar tehnologia cu executie la client a evoluat destul de recent.
si inainte de asta existau aplicatii si in loc de front-end obisnuiam sa folosim “interfata utilizator”.
cel asa imi amintesc eu din laboratoarele de info din liceu in care foloseam turbo-pascal si niste "unit"uri (librarii) pentru lucrul cu mouseul in msdos.
atunci interfata utilizator era limitata la niste intrebari la care tastai efectiv raspunsul si la niste elemente simple accesibile cu mouseul.
backendul era evident algoritmul in sine.
concluzie:
definitiile sunt destul de fuzzy, chiar si pt programatori, deci folositi lamuriri suplimentare oricand e necesar.
impartirea in functie de sens are mai multa logica pentru mine (interfata e front, motorul e back)
later edit:
termenul de “programator front-end” se refera totusi la un programator, iar un pic de php chiar n-ar trebui sa incurce pe nimeni care se numeste asa.
Problema e că acel html nu apare prin magie, cineva trebuie să programeze php-ul în aşa fel încât acesta să genereze acel html (sau orice alt output avem nevoie). De exemplu, dacă vreau să generez o factură în pdf am nevoie de un developer de frontend sau de backend?
pe vremea mea se chemau programatori. si trebuiau sa stie si partea de backend si html si css si js. si ceva linux. si alte chestii pe langa. multe alte chestii pe langa. pe ideea ca daca tot mananci macar sa ai tot tacamul necesar.
@serghei.
echo “html la gramada” nu necesita prea multe cunostinte de programare. ca sa nu mai spun ca daca folosesti un mvc nici macar nu te atingi de php. daca-i gandit cum trebuie tot ce o sa fie nevoie e un if/else/foreach. ceea ce exista si in js.
ps: eu, ca programator back end, nu am nici cea mai mica problema sa ma bag in front end (am lucrat si cu angular, react, vue si alte librarii js aparute ca ciupercile dupa ploaie). consider ca daca stii js nu ai nici o scuza sa nu te poti baga in php. (si invers) inteleg ca s-ar putea sa te lovesti cand e vb de baze de date da in rest ar trebui sa te descurci destul de usor,
No offence to anyone, dar imi este scarba de cum a ajuns acest thread. Ma asteptam sa fie ceva mai construcitv pe aici nu atacuri la persoana si jgniri mai mult sau mai putin nuantate.
Hai ca inteleg ca poate unii dintre noi au ego, ocazionalul trolling care se mai face (pe thread, pe forum) etc, dar totusi…
Păi aşa şi trebuie, în template să ai toate datele pregătite de controller şi doar să iterezi prin ele. Dar tot programare php se cheamă. Şi nu e neapărat să fie simplu, e posibil să ai niveluri adânci de imbricare şi să-ţi scrânteşti mintea să înţelegi ce-i acolo.
nu stiu cum functioneaza la tine vremea si de ce esti asa de enervat, dar mie vremea mi-a adus intelepciunea de a ii asculta si intelege pe ceilalti (si asta are un beneficiu semnificativ pozitiv asupra sanatatii mele).
nu trebuie sa fiu de acord cu ei (cum nu sunt cu tine), dar daca ofereai mai multe argumente si mai putine atacuri era mai simplu pentru toata lumea.
(inclusiv pentru cosmin )
ps. @Cosmin_Popescu, eu as spune ca in ciuda atacurilor topicul a evoluat cu suficiente argumente (chiar daca nu mereu clar exprimate), iar asta e cu siguranta un lucru pozitiv, nu crezi?
strict pe exemplul tau, cred ca cel care lucreaza pe backend ar trebui sa o poata face fara probleme. intr-o lume in care nenea ala care se considera web developer stie si html. dar, daca web dev-ul nu stie html atunci el doar pregateste datele si restul face altcineva.
nu te-am jignit cu nimic. am atacat ideea ca php-ul e front end. la fel cum as ataca ideea ca pamanul e plat. si am tras si niste concluzii.nu te-am facut analfabet (sau ma rog, nu ti-am spus ca esti). daca tu vrei sa te simti jignit pt ca ti-am spus ca nu ai treba cu programarea (am presupus ca asta-i domeniul in care activezi) atunci asta-i fix problema ta.
Graniţa e fuzzy. Eu ştiu html, ştiu css, ştiu js. Într-o oarecare măsură. Şi frontend developerul ştie php, dar tot într-o oarecare măsură. Ne întâlnim undeva la mijloc, unde suntem mediocri amândoi.
Cum poate sa existe o discutie despre PHP ca tehnologie de frontend? Poate Firefox/Chrome/Opera/IE/Edge sa execute cod PHP?
Nu am urmarit toata discutia dar reiese o problema de care vorbeam mai demult. Nu te poti apuca de programare sarind pasi. Nu merge sa inveti Javascript/Java/PHP/etc. fara sa inveti C/C++ inainte. Pur si simplu vor fi lipsuri care vor genera probleme la un moment dat.
Nu poti invata de MVC inainte de a intelege si scrie o gramada de clase de la zero cum nu poti invata direct Laravel, Codeigniter sau CakePHP fara sa stii PHP inainte.
Corect, faptul ca stii unde e inima nu te face doctor. Trebuie sa stii domeniul si har Cerului ca in domeniul programarii totul e gratuit (la medicina te usuca de bani cartile lor).
Ca sa clarificam:
front-end: tot ce este executat de browser. Practic poti scrie fisierului .html local si cand il deschizi in browser-ul favorit -> se executa corect. Aici intra cod Javascript, tag-uri HTML sau reguli CSS;
back-end: tot ce este executat in fundal de un proces/interpretor si al carui rezultat e dat browser-ului (sau aplicatiei care il cere, de exemplu cURL). Aici intra tot de la C/C++, Java, Ruby, Python, PHP, Perl, etc.
deci tu spui ca pentru a aplica o grafica intr-o theme de wordpress (indiferent cat de simpla este ea) ai nevoie de un designer (pentru grafica efectiva), de un programator front-end (pentru html, css, js) si de un programator back-end pentru partea de php?
de ce atunci cand ne referim la front (practic interfata) nu intelegem tot ce inseamna acea intervata, inclusiv partea de php din view (daca ne referim la mvc)?
cum tie ti se pare evident intr-un fel, mie mi se pare evident in alt fel… si intreb tocmai din motivul asta.
Model - View - Controller reprezinta o strategie de a-ti imparti o aplicatie. Rolul ei e de a structura codul astfel incat sa ne putem orienta un pic mai usor. Nu este deloc necesar ca o aplicatie sa fie construita pe arhitectura MVC.
Faptul ca avem cuvintul View in aceasta (sau interfata) nu are nimic de-a face cu browser-ul sau front-end-ul. View-ul din MVC e total altceva fata de front-end-ul parsat de aplicatia de navigare pe internet.
Cand ne referim la front-end, ne referim la front-end. Si atat. La urma urmei codul acela HTML/CSS/JS (generat in View) poate fi folosit de un proces cURL si modificat/trimis in alta parte, nu intr-un browser.
Ca sa intelegem mai usor evolutia unei aplicatii:
HTML (pagini statice)
HTML + CSS (pagini statice + ceva formatare/design)
HTML + CSS + Javascript (pagini statice cu unele rutine ce pot modifica elementele HTML/CSS)
backend + (HTML + CSS + JS) - aplicatii dinamice unde aceeasi pagina poate avea continut diferit in functie de utilizator
Folosing Vue, Angular, React ce se intampla e ca sunt scrise sabloanele (HTML + CSS) in fisiere Javascript iar datele (ceea ce se schimba de la utilizator la utilizator) sunt luate din back-end (via API-uri). Mergand mai departe, aplicatiile Single Page reconstruiesc DOM-ul (tot codul HTML) fara ca pagina sa mai fie “reincarcata”.
Folosing o aplicatie Angular + un API (care poate sa fie facut sub arhitectura MVC - si chiar e recomandat), acel API de fapt trimite datele sub diferite formate, sa zicem JSON. Acel API e o aplicatie de sine statatoare careia ii lipseste codul HTML si CSS. La o adica acel API poate fi apelat din browser si-ti va returna doar text JSON.
Partea de front-end poate fi responsabila de pilda de autentificarea utilizatorului, dar doar partial, ca tot backend-ul va valida utilizatorul.
Avantajul unui SPA este ca timpul de afisare a unei pagini noi e data de: timpul executarii apelului catre API + timpul de reconstruire totala sau partiala a DOM-ului.
Pentru o aplicatie clasica avem:
timpul cererii (GET hostname.ext/myDashboard.php)
DNS resolve-ul (who is hostname.ext?)
procesarea datelor in backend
downloading the data (HTML, CSS, JS)
HTML/CSS/JS parsing + afisarea in browser
Anyhoo, ne-am luat cu vorba. Faptul ca PHP genereaza cod HTML, tot limbaj de back-end ramane.
da, e foarte frumoasa explicatia si sunt in mare parte de acord cu ea.
cu diferenta ca atunci cand ne referim la front… intelegem lucruri diferite (si nu ma refer numai la noi doi, din mesajele de mai sus din topic si din viata reala in care interactionez cu destula lume din domeniu).
care este front-ul unei aplicatii php rulata in linie de comanda?
dar a unei aplicatii turbo pascal rulata in msdos?
acea interfata in care raspunzi la intrebari prin tastarea raspunsul e un frontend?
codul care genereaza intrebarile respective e de front?
folosim front si back exclusiv pentru web?
si cand spui ca prin front intelegem front (client ca sa fiu mai exact, conform mesajului tau)… e strict intelegerea ta? sau exista o referinta universal valabila pentru asta?
cand spunem front end ne referim strict la conceptul de aplicatii web. ca daca ne ducem pana la line de comanda nu exista nici front nici back end.
ps: ala-i layerul de prezentare.
macar sa ai tot tacamul necesar.
