La evenimentul de lansare din luna martie am povestit despre provocările programatorilor de front-end și bineînțeles despre JavaScript. Invitații noștri la panel au fost:
Andrei Miron - Front-end Competence Lead @ Accesa,
Ovidiu Mățan: Salut! Ce faceți voi zi de zi la job-ul vostru?
Andrei Miron: Momentan, sunt React developer. Lucrez la o aplicație de management de contracte și condiții. Fiecare contract poate avea 10000 de condiții care trebuie exemplificate, pe care oamenii să le poată alege sau ajusta. Reactul face acest lucru posibil. Acum, rescriem aplicația datorită regulilor din Germania. În acest proiect se caută seniori, oameni care să învețe rapid și să lucreze independent. Avem o echipă de trei persoane, pe care clienții doresc să o extindem, dar cerințele lor sunt destul de greu de îndeplinit.
Florin Tomozei: Lucrez la Wolfpack Digital de doi ani. Lucrez cu tehnologii web de vreo doisprezece ani și mă axez pe Angular. De doi ani, am prilejul să lucrez în ecosistemul Vue și Next sau Vue și Ruby on Rails în zona de full stack. Momentan, s-a trecut la o nouă versiune.
Andrei Miron: Eu am mers pe React, deoarece, spre deosebire de Angular, este o simplă librărie. Pot folosi orice doresc. Ultima versiune de React este 18 care scoate foarte multe dependințe de back-end.
Cum faceți designul? Lucrați cu mock-upuri?
Andrei Miron: Nu există așa ceva. Trebuie să funcționeze totul cât mai bine prin designul componentelor. Dacă scriem CSS e rău.
Trebuie să vă definiți componentele de dinainte, iar apoi să vă jucați cu ele?
Andrei Miron: Da. Folosim librării care ne oferă niște componente. Nu trebuie să reinventăm roata, ci să folosim ceea ce avem cât mai eficient. Noi ne facem componentele extinzând ceva existent cu designul nostru.
Florin Tomozei: Noi avem chestii de tip web apps care sunt destul de custom. Eu nu știu să fac design, dar în front-end intru mai mult pe CSS, pe animation. La nivel de divizie, avem o echipă specială axată pe mobile, însă noi, prin librăriile pe care le folosim, creăm pagini web de tip responsive, așa cum se creează lucrurile de la Bootstrap încoace. Librăriile sunt mobile-first, iar când crești, dai valorile noi și spui cum ar trebui să fie comportamentul pentru web.
Andrei Miron: În proiectul la care lucrăm nu avem secțiune mobile. Fiind o aplicație cu foarte multe date, este imposibil să afișezi toate datele într-un ecran atât de mic. Am avut în schimb aplicații unde am început cu partea de mobile, deoarece am dorit să funcționeze de oriunde, oricând.
Ce folosiți în partea de arhitectură? Aveți și front-end în microservicii, Andrei?
Andrei Miron: Buildul îl folosește toată lumea. E vorba de acele pachete MPM. În ceea ce privește server-side sau server injection, folosim componentele aferente dacă vrem să modificăm niște campanii, promoții ori un banner în aplicație. Direcția înspre care încercăm să mergem este cea mai dificilă și durează. E vorba de un monolit pe care încercăm să îl facem bucăți. Vom trece la micro aplicații, dar în același timp vom avea un monorepo.
Față de core side, front-endul poate rula la client.
Andrei Miron: Da, este frumusețea front-endului. Nu compilezi nimic, doar dai Run. Ai niște resurse relativ statice, nu încarci memoria foarte mult. În schimb, browserul duce tot. La un moment dat, va crăpa.
Florin Tomozei: Am avut și proiecte cu orchestrări de micro front-enduri. Sunt mare fan al conceptului de monorepo ca loc unde să ții codul pentru organizația respectivă, așa cum face Google cu sistemul lor de miliarde de linii de cod. Beneficiul TypeScript este că poți extrage logica, care este oricum foarte comună, de exemplu autentificarea, pe care o pun într-o librărie cu același repository, ceea ce înseamnă că am tot sistemul tipizat. Ai un singur config, ai tipizări, modele. Se simplifică lucrurile. Frameworkurile front-end care devin full stack facilitează ca și back-endul să fie acolo, dacă dorești. Prin tipizare, poți avea aceeași structură de date, aceeași modelare cu back-endul care se transmite și la front-end.
Cum testați aplicațiile?
Andrei Miron: Cum spuneam, acum avem un monolit cu back-endul și front-endul împreună, lucru pe care vrem să îl modificăm. Rulăm testele cu Cypress care se bazează pe jQuery, dar vrem să schimbăm asta, pentru că jQuery este pe ducă. Alternativa la Cypress ar fi Playwright. Avem baze de date, avem și mock server, dar și server integrat. Avem GitHub actions și rulăm testele la orice commit. La cât de mare e aplicația, nu ne permitem să treacă ceva netestat.
Florin Tomozei: Cel mai rapid mod de a trece toate testele este să nu ai teste. Fluxul ideal e cel cu unit tests scrise de programator, apoi cu testare la QA și eventual automation. Vedem acum trecerea la automatizarea de happy flows. Playwright aduce un recorder. Tu intri în aplicație, dai record, înregistrezi pașii, iar apoi se generează scriptul de JavaScript cu pathuri, cu asserturi. Playwright este gratuit. Poate face screenshots. Le generează pe XPath și îți spune care este calea spre element.
(întrebare din sală): Aș dori o discuție. Bundleul meu este mai bun - webpack vs Vite?
Andrei Miron: Folosind cu precădere webpack, aș merge pe webpack. Nu aș putea face o comparație 100%. Știu că webpackul a fost destul de dificil de folosit până la versiunea 5. Acum cu versiunea 5, webpackul este ceva pur front-end, fără librăriile back-end care ne dădeau de furcă. Sunt însă și multe lucruri care nu mai merg. Prin urmare, deși nu cunosc celălalt configurator, l-aș încerca pe acela.
Florin Tomozei: Cred că Reactul va începe să folosească Vite. Ambele sunt bune, deoarece ambele sunt independente de librărie, de framework. Vite e scris de la zero, e mai rapid și nu are toată greutatea lui webpack. Există o adopție foarte mare de Vite.
(întrebare din sală): În afară de taburile uzuale din DevTools, ce altceva folosiți pentru măsurarea performanței?
Andrei Miron: Nu folosesc altceva în afară de Profiling. Nu folosesc ceva doar de dragul de a folosi acel lucru, ci doar dacă aduce valoare adăugată. Profiling are posibilitatea de recorder, poți vedea stările și partea de latency.
Florin Tomozei: Folosim Lighthouse, chiar dacă avem server de CI pentru el și rulează automat. Folosesc taburile avansate de stage management. Analizez mult network requests. Dacă ții Shift pe un network request îți spune la ce a făcut trigger mai jos.
Dacă vine cineva la voi la interviu, ce întrebare grea îi puneți?
Andrei Miron: Încerc să aflu raționamentul oamenilor. Dacă îmi vorbesc, de exemplu, de un spread operator, vreau să aflu cum se face copia, ce presupune deep clone. Vreau să văd dacă se înțelege procedeul din spate.
Florin Tomozei: Am fost la un interviu de JavaScript în 2014. Era primul meu interviu, iar eu nu mai scrisesem în JavaScript decât o săptămână. Mi s-a cerut să fac o sortare și am făcut cel mai frumos FOR in FOR pe care îl știam. Doar apoi mi-am dat seama că JavaScript are SORT. Nu m-au mai sunat. Eu am avut parte de mentori foarte buni. Eu încerc să găsesc chestii comune cu cel pe care îl am în față la interviu. Vreau să aflu cum a rezolvat o problemă și de ce a ales acea cale de rezolvare. Referitor la partea tehnică, pun întrebări din TypeScript, tipizare, modelare.
(întrebare din sală): Acel tool de testare automată pe care l-ați menționat seamănă cu Selenium?
Andrei Miron: Am stat pe lângă oameni care au folosit Selenium și din ce am înțeles de la ei, Selenium testează și buildul, condițiile în care se face deployment. Selenium testează un ecosistem mai mare decât Cypress sau Playwright.
(întrebare din sală): Cine poate scrie teste cu Playwright? Programatorul sau QA-ul?
Florin Tomozei: Ar fi minunat ca un QA să poată intra în codebase și să își genereze testele automate.
Andrei Miron: Programatorii front-end au această obligație ca la un moment dat să știe și aceste tooluri de testare.
(întrebare din sală): Ați spus că trebuie să faceți modificări din cauza regulilor și legislației germane. Ne puteți da mai multe detalii?
Andrei Miron: Aceste legi ne interzic să lucrăm pe același codebase. Dacă cineva a pus o virgulă sau a reformatat ceva, iar în cod, la commit, apare că s-a produs această modificare, eu nu mai pot face acea modificare. Pentru a evita acest lucru, am decis să schimbăm arhitectura. Folosim această oportunitate pentru a nu mai lucra în sistem monolit.
(întrebare din sală): Mă ocup de partea de back-end și am încercat să țin pasul cu toolurile de pe front-end. Se modifică frecvent și am renunțat să mai încerc să fiu la zi. Se va continua tot în ritmul acesta cu frameworkurile front-end în care ești la zi vreo șase luni, apoi ceva iar se schimbă? Cât va mai dura schimbarea?
Florin Tomozei: Există o vorbă în comunitatea JavaScript, anume "the ages of JavaScript". Nu ne-au plăcut 1 și 2, deci acum suntem la 3. Direcția spre care ne îndreptăm din 2015 încoace merge către o standardizare. Mie îmi place să văd o standardizare de tip web, mai mult. Observ o standardizare înspre o abordare state management mai comună. Contează mult ce decidem noi, comunitatea, să adoptăm. Adopția de lucruri noi este sănătoasă. Este bine să adăugăm ceva nou la lista de abilități.
Mi se pare mie sau sunt puțini oameni în front-end în Cluj?
Andrei Miron: Eu sunt din București, iar acolo colegii specializați pe front-end erau destul de numeroși.
Florin Tomozei: Avem o comunitate de JavaScript destul de mare în Cluj. Avem chiar și o listă de așteptare. Cred că este important să găsești locul unde se întâmplă lucruri.
(întrebare din sală): Am o întrebare legată de Next.js. Una din problemele React, față de Angular, este că este doar o librărie și că are nevoie de mult mai multe elemente pentru a putea funcționa. Angular este susținut de Google, de un ecosistem, iar Reactul mai puțin încă de când a fost introdus de Facebook. Cum vedeți evoluția Next.js din această perspectivă a unui ecosistem întreținut de o firmă mare?
Andrei Miron: Și noi avem în vedere trecerea spre Next.js. Dorim să profităm de server-side rendering în continuare.
Florin Tomozei: Vedem un trend de open-source care devine funded. S-ar putea să fie o problemă, dar este bine să ai librării open-source care au și bani în spate. Ne permite să dezvoltăm mai repede.