Pregătește-te să codezi: software pentru Front End

Vrei să-nveți HTML, CSS, JavaScript și să prinzi un job de Front End Developer. Dar ai tot ce-ți trebuie ca să te apuci de front end development?

Ți-ai instalat toate soft-urile necesare ca să poți coda fără probleme? Ai un IDE, un editor grafic, un soft de optimizare de imagini, un editor media, un client de FTP, hosting gratuit și așa mai departe? Dacă nu, atunci în articolul de azi trecem împreună, pas cu pas, prin tot ce ai nevoie ca să te pregătești pentru următorul modul al Cursului de Front End Development în Română în care înveți, în sfârșit, să codezi în HTML!

Dacă vrei să fii Front End Developer, ai nevoie de niște unelte care să te ajute. Așa cum vânătorul poate folosi arcul sau pușca cu lunetă, pescarul poate folosi undița sau lanseta, zidarul poate folosi trafaletul sau aerograful și așa mai departe, și Front End Developer-ul poate folosi unelte mai simple sau mai complexe care să-l ajute să-și facă treaba bine. Uneltele simple de obicei rezolvă probleme în situații generice, unde nu te grăbești sau unde poți lucra singur sau singură, pe când uneltele mai complexe te ajută în orice context, inclusiv singur sau singură sau în echipe de orice dimensiuni. Din acest motiv, voi încerca să limitez uneltele „simple” pe care ți le voi prezenta azi, ca să ți le instalezi, și mă voi concentra pe uneltele care te pregătesc cel mai bine pentru a fi un developer bun.

În spiritul acestui tutorial, TOATE uneltele prezentate vor fi unele GRATUITE. Incidental, uneltele gratuite pe care ți le voi prezenta sunt și printre cele mai bune din lume la ce fac, deci nu trebuie să ai mustrări de conștiință că nu investești în ceva „mai bun” pentru că în puține cazuri există ceva cu adevărat „mai bun” care chiar merită banii.

În plus, ca să știi de la-nceput, mă voi concentra pe unelte cât se poate de universale ca sistem de operare, dar voi prezenta procesul de instalare caracteristic Windows-ului, pentru că majoritatea dintre voi folosesc Windows, nu Mac sau Linux – cel puțin acum, la început de carieră. 🙂

Așadar, ca să parcurgi mai departe acest curs, vei avea nevoie de:

Editorul, sau IDE-ul – VSCode

Începem cu zona de cod, mai precis cu IDE-ul.

IDE înseamnă Integrated Development Environment. Cel mai simplu editor pe care-l poți folosi pe Windows este Notepad. În Notepad poți edita fișiere de tip text, care sunt exact fișierele pe care le vom folosi ca să construim site-uri împreună. Notepad vine preinstalat cu Windows-ul de fiecare dată, însă există multe alternative net superioare Notepad-ului din toate punctele de vedere.

Cel mai simplu de instalat și ușor de folosit IDE pe care îți recomand să ți-l instalezi acum este Visual Studio Code, sau VSCode cum mai e numit. E făcut de Microsoft și e unul din cele mai bune și mai iubite editoare de developerii din toată lumea.

Ca să-l instalezi, mergi pe https://code.visualstudio.com/ și dă click pe butonul mare și albastru de download.

Apoi vei vedea niște ecrane de instalare destul de standard, prin care te voi trece și eu pas cu pas, pe Windows (deși e similar pe toate platformele).

1. După ce-ai dat click pe buton, vei vedea o pagină similară cu asta și ar trebui să-ți pornească download-ul de fișier instalabil pentru VSCode.
2. Odată ce s-a downloadat, dă click pe el în browser sau deschide folder-ul unde l-ai downloadat și apasă click dreapta -> Run as Administrator, ca în imagine. Eu am Windows 11 și Dark Mode activ, imaginea asta s-ar putea să arate diferit la voi, dar opțiunea de Run as Administrator sigur e disponibilă pe undeva dacă ești logat ca user cu drepturi de Admin pe PC-ul tău.
3. Apoi, dacă Windows îți cere permisiunea să editeze fișiere ca Administrator, apasă Accept sau Allow, ca în poză.
4. Selectează „I accept the agreement” și apasă Next.
5. Bifează tot din ecranul următor și apasă Next.
6. În acest ultim ecran, apasă Install.
7. Apoi vei vedea un progress bar care ar trebui să dureze câteva secunde.
8. În final, în ecranul ăsta, ar trebui să lași bifat checkbox-ul și să apeși Finish, și ți se va deschide IDE-ul automat. Dacă se întâmplă asta, înseamnă că instalarea a funcționat.

Extensii pentru IDE

Acum că ai editorul de text instalat și deschis, e momentul să instalăm niște extensii de care în mod sigur vom avea nevoie în călătoria noastră prin minunata lume a front end development-ului profesionist. Extensiile astea se instalează în interiorul VSCode și îl fac un editor mai bun, din multe puncte de vedere.

Pentru a căuta aceste extensii, ai două modalități pe care le-ai putea încerca. Prima este să cauți direct în VSCode (ceea ce vom și face împreună), a doua e să intri pe marketplace-ul VisualStudio și să le cauți acolo. Pentru fiecare extensie, voi pune și un link pe ecran, care te va duce în acest marketplace, dar nu e musai să accesezi link-ul respectiv dacă reușești să găsești extensia direct în VSCode, cum îți voi arăta imediat.

Așadar, iată ce trebuie să faci:

1. Asigură-te că ai deschis VSCode. Dacă ai urmat pașii de mai devreme, e deja deschis. Dacă nu îl ai deschis, găsește-l dând un search în Windows taskbar și rulează-l ca Administrator (click dreapta -> Run as Administrator).
2. Odată ce ai VSCode deschis, dă click în stânga pe butonul de Extensions, și apoi dă click pe bara de căutare pentru a începe să cauți extensii.
3. Prima extensie pe care o instalăm este Auto Rename Tag, care în momentul în care editezi un tag existent, editează automat și tag-ul de închidere. E ceva ce VSCode n-are ca funcționalitate implicită, și e destul de simplu, dar necesar, ca să ai mai puține dureri de cap. Apasă pe Install și Enable odată ce extensia s-a instalat. Link: Auto Rename Tag – Visual Studio Marketplace
4. A doua extensie de care ai nevoie se numește ESLint și îți va evalua corectitudinea codului scris odată ce-o configurezi corect. Vom face asta împreună într-un articol viitor, dar până una-alta, hai s-o instalăm. Link: VS Code ESLint extension
5. A treia extensie se numește Prettier+ și îți va formata corect codul pe care-l scrii odată ce-o configurezi corect. La fel ca ESLint, vom face configurările într-un articol viitor, pentru moment hai doar s-o instalăm. Link: Prettier+ – Visual Studio Marketplace
6. Dacă dai search după Jock SVG, ar trebui să găsești următoarea extensie de care avem nevoie, ca să ne faciliteze vizualizarea și manipularea fișierelor de tip SVG, foarte utile pentru a fi folosite ca iconițe în site-urile noastre viitoare. Link: SVG – Visual Studio Marketplace
7. Acum voi menționa două extensii opționale. Una este pur estetică, și schimbă felul cum arată VSCode. Dacă vrei ca editorul tău să arate la fel ca al meu, deci, caută extensia freeCodeCamp Dark Theme și instaleaz-o. E posibil ca VSCode să-ți ceară să restartezi editorul pentru a intra în funcțiune, și poți face asta fără probleme. Link: freeCodeCamp Dark Theme – Visual Studio Marketplace (opțional)
8. A doua extensie opțională se ocupă de ceva mai exotic. O listă de lucruri de făcut, pe care n-ar trebui să le uiți. Un fel de to do list pentru proiectele tale. Și e o listă scrisă chiar de tine. Vom folosi extensia activ în câteva din articolele viitoare, pentru moment, dacă vrei să îți amintești și să găsești mai ușor lucrurile pe care le ai de făcut în proiectele tale, instalează extensia opțională Todo Tree. Link: Todo Tree – Visual Studio Marketplace (opțional)

Și cu asta am terminat cu extensiile de Visual Studio Code.

Manager de pachete – NPM

Orice web developer care se respectă a lucrat până acum cu Node Packet Manager sau NPM. Acest NPM vine la pachet în momentul în care instalezi serverul local de NodeJS, care e un limbaj de programare derivat din JavaScript, pentru a fi folosit server-side. Noi n-o să avem de-a face prea mult cu Node în acest curs, însă vom avea cu siguranță lucruri de făcut folosind NPM, din diverse motive. Spre exemplu, ne vom autocompila SCSS-ul și vom face auto-refresh la browser în momentul când dai Save în VSCode după ce-ai editat un fișier SASS sau SCSS. Știu că momentan poate nu-nțelegi ce-nseamnă asta, și va trebui să mă crezi pe cuvânt că e ceva foarte mișto.

Ca să putem face asta împreună, însă, va trebui să-ți instalezi ultima variantă de NodeJS. Așdar:

1. Intră pe site-ul NodeJS, la: https://nodejs.org/en/
2. Descarcă varianta curentă (butonul verde din dreapta)
3. Deschide fișierul și apasă Next.
4. Acceptă condițiile din ecranul ăsta și apasă din nou Next.
5. Alege unde să se instaleze Node-ul (opțional – eu îl las de obicei în Program Files) și apasă din nou Next.
6. Asigură-te că toate opțiunile din listă au fundal alb (deci vor fi instalate integral) și apasă Next.
7. Eu aici de obicei bifez opțiunea de instalare automată a tuturor uneltelor adiționale necesare ca să n-am probleme, și te sfătuiesc și pe tine să faci la fel. Apasă din nou Next.
8. În sfârșit, apasă Install.
9. Windows te va întreba dacă-l lași să facă modificări substanțiale în sistemul tău de operare, și evident că ar trebui să accepți.
10. Apoi instalarea va decurge normal și va dura câteva secunde. În final, vei ajunge la un ecran de concluzii.
11. Imediat după, dacă ai bifat opțiunea de mai devreme care se referă la unelte adiționale, ți se va deschide o fereastră de terminal și te sfătuiesc să apeși Enter de două ori când se întâmplă asta.
12. Apoi va trebui să dai din nou drepturi de instalare în sistem din Windows, de data asta Power Shell-ului (un terminal mai puternic din Windows).
13. PowerShell-ul, un terminal care e mai… albastru și mai puternic, și care instalează Python 3, Chocolatey și alte lucruri utile pentru tine. La final, îți va cere un Enter să se închidă fereastra.

Bun, am reușit să instalăm NodeJS și niște software conex, dar n-am intrat deloc în NPM, adică în manager-ul de pachete pentru aplicații web. Și nici n-o să facem asta chiar acum. Dacă însă ești nerăbdător sau nerăbdătoare, are Kevin Powell un video excelent despre ce-ai putea să faci folosind NPM într-un proiect web, și am și eu un LIVE cu Tică în care explic cum poți folosi un template de proiect care folosește niște pachete de Node utile ca să îți pornești propriul proiect cu niște superputeri.

Până ajungem să folosim NPM în curs, însă, mai avem niște software de instalat…

Editor de imagini – GIMP

Continuăm cu zona vizuală și multimedia, și pornim de la poze.

Dacă vei avea nevoie vreodată să editezi imagini, Photoshop este și rămâne regele. Dar Photoshop-ul celor de la Adobe nu e gratuit, vine la pachet cu un abonament lunar destul de mare. Așa că alternativa gratuită și destul de bună este: GNU Image Manipulation Program, sau GIMP. Îl găsești spre download gratuit pe: https://www.gimp.org/ 

Editor de design și UX – Figma

Cu un pas mai departe, dacă vei avea nevoie să faci design de interfață, UI și UX, Figma e de departe cel mai bun din industrie din multe puncte de vedere. Și are și variantă gratuită! Există alternative cum este Adobe XD, însă mie mi se pare că Figma e cel mai bun și mai ușor de învățat software de design de la ora actuală. Și merge direct din browser! 🙂 Fă-ți cont în Figma aici: https://www.figma.com/ 

Optimizator de imagini – Squoosh

Odată ce ai design-ul gata și imaginile pregătite, nu e OK să le folosești fix așa cum le-ai exportat din GIMP sau Figma. E nevoie să le treci printr-un software de optimizare. Și fiindcă inițial nu vom avea nevoie de editare „industrială” de mii sau zeci de mii de imagini, ci vom avea doar câteva pe ici, pe colo, o unealtă gratuită cum e Squoosh e mai mult decât suficientă. Squoosh e construit de echipa de la Google care lucrează la Chrome.

Folosind Squoosh poți exporta imaginile pe care vrei să le folosești în site-ul tău în format WEBP (care e cel mai eficient format de imagini modern fiindcă reușește să combine eficiența JPEG-ului cu prezența transparenței ca-n PNG-uri). Ca fallback, sau variantă de siguranță, ideal este să exporți aceeași imagine și în format JPG sau PNG pentru browsere mai vechi sau useri care nu și-au făcut update-uri la sistemul de operare și browser.

Așadar, folosește Squoosh gratuit de aici: https://squoosh.app/ 

Editor video / multimedia – DaVinci

Dacă ai nevoi mai complexe și vrei să creezi sau să editezi video-uri sau audio-uri pentru site-ul pe care-l construiești, ideal ar fi să ai acces la suita plătită Adobe – Premiere, After Effects, Media Encoder, Audition și așa mai departe. Asta folosesc și eu să creez video-urile de pe canalul meu. Dar ne lovim de aceeași problemă: soft-urile astea nu sunt gratuite.

Alternativa gratuită este suita DaVinci de la BlackMagicDesign. Mai exact, DaVinci Resolve. Poți să descarci software-ul de aici: https://www.blackmagicdesign.com/products/davinciresolve/ 

Client FTP – FileZilla

Acum hai să intrăm în zona operațională, de deploy.

Vom începe cu un tip de software util în variantele simpliste de deploy, care nu folosesc un funnel de Continuous Intergration și Continuous Delivery, adică CI/CD. Mai exact, cu un software capabil să facă transferuri prin File Transfer Protocol, sau FTP. Acest FTP este un protocol special la care ai acces dacă folosești un serviciu de hosting tradițional, cum e SiteGround.

Un asftel de software gratuit și destul de bun este FileZilla, mai exact FileZilla Client, pe care-l găsești aici: https://filezilla-project.org/ 

Hosting – GitHub, Netlify, Vercel, Heroku sau DigitalOcean

Vei avea nevoie și de conturi la servicii de hosting gratuite. Oricare din variante de mai jos e OK, voi face un video în care le compar pe toate, dar varianta gratuită e oricum foarte similară pentru toate, și unele sunt deja integrate direct cu GitHub, ceea ce se va dovedi un avantaj, așa cum veți vedea în curând.

Așadar, astea sunt variantele de hosting gratuit de aplicații simple de front end, pe care le vom folosi și noi în acest curs:

• GitHub Pages: https://pages.github.com/
• Netlify: https://www.netlify.com/
• Vercel: https://vercel.com/
• Heroku: https://www.heroku.com/home
• DigitalOcean: https://www.digitalocean.com/ 
• InfinityFree: https://www.infinityfree.net/ (hosting gratuit de PHP)

Browser – Chrome sau Firefox

Așa cum am discutat deja într-un articol anterior din curs, browserele cele mai bune pentru development din punctul meu de vedere sunt Chrome sau Firefox. Poți descărca Firefox de aici: https://www.mozilla.org/en-US/firefox/new/ și Chrome de aici: https://www.google.com/chrome/ 

Mai sunt și browsere care nu mai sunt OK deloc și recomand să le schimbi dacă le folosești acum: Opera, Safari, Internet Explorer și așa mai departe. Alte browsere cum sunt Edge sau Brave sunt OK, dar au niște mici probleme (lipsa plugin-urilor specializate pe Edge spre exemplu, sau găuri de securitate în Brave) și de-aia nu le recomand pentru acest curs.

Voi menționa și câteva plugin-uri de Chrome și Firefox când vom avansa pe anumite subiecte din curs (accesibilitate, viteză și așa mai departe), dar pentru moment, browserul e suficient.

Mai poți vedea detalii în engleză despre ce software să folosești în articolul ăsta foarte bun de pe Mozilla Developer Network.

Cum să-ți organizezi proiectele și fișierele?

Nu în ultimul rând, aș vrea să vorbim puțin despre cum îți vei organiza proiectele și fișierele în proiecte astfel încât să n-ai probleme pe viitor. Asta necesită să fii familiarizat sau familiarizată cu management-ul simplu de fișiere din sistemul de operare pe care-l folosești acum.

Spre exemplu, pe Windows ar trebui să știi ce este un Folder, adică un director, și ce este un fișier simplu, eventual ce e aia o extensie. Nu voi intra în detalii în cursul ăsta (pentru că partea asta ține mai degrabă de alfabetizarea digitală pentru care sunt multe alte cursuri mult mai bune decât aș putea eu să fac). Dacă ce-am spus mai devreme nu îți este familiar, consultă companii care îți pot oferi cursuri de tip ECDL pentru toți, măcar primele două niveluri: cel de conștientizare digitală și cel de alfabetizare digitală.

Odată ce le stăpânești, ar trebui să-ți fie ușor să înțelegi ce urmează să facem împreună mai departe în acest articol și în tot acest curs.

Primii pași în organizarea proiectelor de Front End

Așadar, cum e cel mai simplu și cum e indicat să-ți organizezi proiectele de front end development la care vom lucra împreună?

Păi în primul rând ar trebui să ai un folder undeva pe calculator unde-ți ții toate proiectele. Aici am niște sugestii: dacă ai un hard disk de tip SSD și unul sau mai multe hard disk-uri clasice, recomandarea mea pentru ca experiența ta de development să fie cât mai ușoară ar fi să faci un folder dedicat proiectelor în root-ul SSD-ului. Asta va permite multitudinii de fișiere cu care vom lucra să se încarce cât se poate de repede și va evita orice fel de întârzieri cauzate de felul cum se comportă (mai ales la pornire – cold start – sau acces repetat de mai multe fișiere – multi-access) hard disk-ul tău clasic. Dacă n-ai un SSD, atunci nu-ți face griji, n-ar trebui să ai probleme majore.

Apoi, acest folder, ca să nu pierzi nimic din ce faci, ar trebui să fie încărcat automat într-un sistem de backup cum este Dropbox sau Google Drive, pentru ca orice s-ar întâmpla cu calculatorul, să ai un backup în cloud la munca ta. Recomand backup-uri asincrone la final de zi, nu să ții folder-ul de lucru în Dropbox sau Drive direct, pentru că asta va îngreuna accesul la unele fișiere și vei avea probleme de locking pe fișiere care sunt simultan citite și scrise de Dropbox sau Drive și IDE-ul tău.

Cu toate astea, Dropbox și Drive sunt al doilea nivel de backup. Primul este întotdeauna GIT. Dar despre GIT vom vorbi în articolul imediat următor.

Apoi, în interiorul folder-ului principal cu proiecte, va trebui să îți creezi câte un folder pentru fiecare din proiectele tale. În interiorul acelui folder ar trebui să organizezi lucrurile similare în câte un folder, cam asta e regula generală.

În cazul proiectelor super-mici, poți ignora regula asta, însă dacă vrei să te obișnuiești să o folosești pentru toate proiectele tale, există niște convenții de nume de foldere și fișiere pe care e bine să le ai în vedere pe viitor când lucrezi la proiectul tău. Nu trebuie să le ții minte acum, pentru că pe măsură ce pornim cursul practic în Modulul 2 și începem să învățăm HTML și apoi CSS, eu voi demonstra practic felul cum organizez proiectele în timpul cursului, și voi explica logica organizării.

Dar ca să nu te ia asta prin surprindere, voi face un mic rezumat și acum.

Arhitectura fișierelor într-un proiect de Front End

Fiecare proiect are nevoie de un fișier index, pentru că pe majoritatea serverelor de hosting cu Linux (practic, majoritatea serverelor de hosting din lume, cu excepția celor care folosesc arhitectura Windows și servere caracteristice – .NET, ASP, etc) fișierul standard care e accesat automat când încerci să încarci un folder sau un site este index.htm sau index.html. Așadar, acesta va fi tot timpul primul fișier pe care-l facem în orice proiect de-ale noastre.

În majoritatea proiectelor vei avea nevoie de resurse statice. Acestea se numesc așa pentru că nu se schimbă pe parcursul procesului de „construire” a site-ului și pregătire a acestuia pentru a ajunge live pe un server pe Internet. De obicei, în categoria asta intră imaginile (cu extensia jpg, png, gif, webp și așa mai departe), typeface-urile (cu extensia woff, woff2, otf, ttf și așa mai departe), grafica vectorială (de obicei în format svg, folosită pentru iconițe de sine stătătoare), și lista poate continua. Categoriile speciale de fișiere statice sunt fișierele generate ca urmare a compilării stilurilor din fișierele SASS sau SCSS folosite, ceea ce rezultă într-unul sau mai multe fișiere CSS. Dacă nu folosești preprocesoare de CSS deloc, cum e SASS sau LESS, fișierele CSS sunt prin definiție fișiere statice. De obicei, dacă sunt mai mari și mai complexe, ele sunt însoțite de fișiere cu extensia .css.map care sunt niște „hărți” care trimit persoana care inspectează pagina direct la linia de SCSS care a generat stilurile inspectate, dar din nou, vom discuta despre asta mai în detaliu în curs. Nu în ultimul rând, fișierele statice JS sunt fie folosite așa cum sunt, fie generate prin script-uri de JavaScript și de Node care rulează în procesul de construire a site-ului, dar și ele fac parte din resursele statice în momentul în care site-ul se încarcă în browser-ul vizitatorului.

Toate resursele statice – și cele „naturale” și cele „generate” sunt plasate de obicei într-un folder care se numește fie /assets fie /resources fie /static – iar în interior, dacă sunt multe imagini spre exemplu, se mai adaugă un subfolder de tipul /img sau /images. La fel și dacă sunt mai multe fișiere CSS sau JS, se face câte un folder de tipul /styles sau /scripts – deși eu unul nu recomand să aveți situația asta decât în situații bine determinate. Observați convenția de denumire în engleză, pe care eu aș vrea s-o păstrăm, deși cursul e în 🇷🇴 Română, din motivul că în felul ăsta vă veți obișnui cu convențiile folosite și în proiecte mai mari sau care folosesc framework-uri care au la rândul lor convenții similare.

Există, însă, niște excepții. Spre exemplu, favicon-urile cross-platform, care sunt în mai multe formate și cu mai multe convenții în spate, ar trebui păstrate în root-ul proiectului, lângă index.htm. Și nu doar ele, ci și: browserconfig.xml, humans.txt, security.txt, robots.txt, service-worker.js, sitemap.xml sau site.webmanifest. Depinzând de complexitatea proiectului, o parte din fișierele astea pot fi autogenerate de către proiect și deci n-are sens să păstrați variante statice în root. În plus, e posibil ca root-ul proiectului vostru să nu fie replicat 1:1 în construcția finală a variantei deployabile a proiectului, și deci va trebui să mutați fișierele astea statice în /resources sau /static sau /assets, care va deveni root-ul variantei care se copiază și se deployază pe serverul live. Puteți vedea o astfel de structură în proiectul DeDeDe.ro de pe GitHub, de aici, unde am pus toate fișierele statice în /assets.

Că tot vorbim de procesul de construire și deploy (CI/CD sau Continuous Integration & Continuous Delivery în terminologie de specialitate), există niște foldere standard și aici. În 99% din proiectele voastre „reale” veți avea nevoie de module de Node, care vor fi instalate automat în /node_modules. La pachet cu aceste fișiere veți avea cu siguranță încă niște fișiere în root-ul proiectului: package.json, package-lock.json, .gitignore, .env și așa mai departe. Din nou, nu intrăm în detalii legat de ele încă, le vom explica atunci când le și folosim, dar vă spun de ele să nu vă speriați că vă apar fișiere ciudate în proiect în momentul în care instalați pachete de Node sau în care folosiți GitHub pe viitor.

Pe lângă /node_modules, procesul de construire a site-ului de obicei exportă toate fișierele gata de a fi uploadate pe server într-un folder de tipul /dist de la Distribution sau /public. Acesta e folderul pe care trebuie să-l selectați ca root pentru deploy în GitHub Pages, spre exemplu.

Nu în ultimul rând, dacă lucrați cu Node și cu un framework, de obicei sursele JavaScript ale proiectului se pun în folder-ul /src.

Exemple de organizare de proiecte de Front End

Cam așa arată un proiect simpluț care folosește SvelteJS, cam așa arată un proiect simpluț care e 100% static și deja poți observa că în general când ai mai multe lucruri de același fel, e bine să le grupezi într-un folder, fără să exagerezi cu nivelul de detaliu și cu adâncimea arborelui format din foldere. Cu cât e mai ușor de înțeles pentru cineva nou care se uită la proiect din afară pentru prima dată, cu atât mai bine. Ăsta e scopul organizării, să existe o convenție ușor de urmărit de toată lumea. Chestia asta e critică dacă vrei vreodată să contribui și tu la vreun proiect open source.

Încă ceva: fișierele pe care tu alegi cum să le numești ar trebui să aibă tot timpul numai litere mici și numai caractere alfanumerice în nume (deci de la a la z mic și de la zero la 9), cu liniuțe simple (simbolul „minus”: „-”) în loc de spațiu și omisiuni în loc de caractere speciale. Asta va ajuta proiectul tău să nu dea niciodată peste probleme de configurare de servere. La ce mă refer? Pe serverele de Linux, poți crea două fișiere cu același nume, dacă scrii una din litere invers față de celălalt fișier – spre exemplu a1.txt e diferit de A1.txt sau de a1.Txt doar pentru că „a” mic e diferit de „A” mare și „t” mic e diferit de „T” mare. Pe Windows nu avem luxul ăsta, deci fișierele sunt identice și vor fi interpretate ca atare de sistemul de operare, lucru care va crea probleme dacă vrei să lucrezi pe un proiect deployat pe Linux, tu având Windows.

În plus, când scrii în bara de adresă a browserului un spațiu într-un URL, acesta îl transformă de obicei în simbolul %20 – care arată urât în URL-ul, deci de-aia nu vrei să ai fișiere cu spații în nume. În plus, simbolul minus e mai lizibil decât underscore-ul – „_” și e mai standard folosit peste tot de toată lumea, deci de-aia recomand să eviți alte simboluri echivalente spațiului și să folosești exclusiv minus.

Codarea caracterelor din fișierele tale ar trebui tot timpul să fie UTF-8 indiferent de ce limbă folosești în interiorul fișierelor. Caracterele terminale ale rândurilor ar trebui să folosească standardul de Unix / Linux, adică „LF” (line feed sau /n), fără „CR” (carriage return sau /r). Asta se configurează ușor din VSCode și din alte editoare, și vom face asta în prima lecție a Modulului 2.

Link-uri relative vs absolute

Mai trebuie să vorbim de link-uri relative și absolute. Un link relativ ia ca bază folder-ul curent al fișierului care-l accesează. Spre exemplu, dacă am un folder cu index.htm și un fișier CSS aflat în subfolder-ul /resources/style.css, link-ul relativ ar fi: resources/style.css. Dacă sunt într-un alt HTML din folder-ul /pages/page2.htm și vreau să accesez același fișier, trebuie să „navighez” în folder-ul corect când declar link-ul relativ, adică: ./resources/style.css – dacă observi, se adaugă un ./ la început, care semnifică „ieși cu un nivel din folderul curent”. Aș putea, însă, ca să nu mai am problema diferențelor dintre cele două link-uri, să creez o referință relativă la rădăcina site-ului, adică: ../resources/style.css – care dacă e folosit într-un web server va funcționa din ambele locații, însă dacă e folosit din Windows direct, nu va funcționa, pentru că rădăcina se schimbă, nu mai e domeniul (folder-ul public_html din hosting-ul domeniului mai exact), ci drive-ul curent (e.g. C:\ sau D:\ și așa mai departe).

În momentul în care referențiezi un fișier în HTML, browserul interpretează ca folder „rădăcină” folder-ul pe care îl identifică la nivel de server pentru fișierul curent HTML. Dacă accesezi direct un HTML în Windows, Chrome ți-l va deschide folosind structura de foldere de pe calculatorul tău. Dacă accesezi un HTML pe un server web dintr-un hosting, de pe un domeniu, structura fișierelor se schimbă dramatic. De-aia e bine, în general, să folosești referințe relative la fișierul curent, nu referințe absolute.

Referințele absolute includ tot path-ul către fișier, inclusiv root-ul. Spre exemplu: https://dedede.ro/images/dedede-hero.svg e un link absolut către această imagine, pentru că include și protocolul și root-ul, adică domeniul dedede.ro – în felul ăsta indiferent unde pui link-ul, va referenția tot timpul aceeași resursă. Care poate fi ceva bun sau nu, depinde de context. De obicei însă, link-urile relative ușurează procesele de deploy, și sunt puține locuri unde e imperativ să ai link-uri absolute (spre exemplu, în meta canonical). Regula de bază aici e să testezi fișierele proiectului tău folosind un web server tot timpul, ca să reproduci contextul în care se află când vor fi puse live pe un site, și să eviți să le accesezi direct din sistemul de operare. Vom vedea exact cum să facem asta în curând.

Mai poți citi detalii în engleză despre cum să-ți organizezi fișierele în articolul ăsta de pe Mozilla Development Network.

De ce n-am vorbit de GIT, GitHub și consolă?

Probabil ai văzut că n-am menționat nimic de GIT, GitHub sau consolă. Am făcut asta intenționat, pentru că articolul viitor din acest curs se va ocupa exclusiv de asta. Te voi învăța cum să lucrezi cu GIT și GitHub la nivel foarte simplist, pentru că odată ce ajungem în Modulul 2, temele pentru acasă vor putea fi făcute și în GitHub-ul tău personal, și voi putea (eu sau oricine altcineva din comunitatea de pe Discord) să îți dea feedback pe temele ținute pe GitHub, unde îți vei uploada munca folosind cunoștințele de GIT pe care le vei dobândi articolul următor. Articol care urmează să apară foarte curând!

Recapitulare și temă

Felicitări, ai mai parcurs un articol din curs! Azi am învățat despre ce e un IDE, ce IDE și ce extensii să folosești pentru el, ce alte unelte gratuite ai la dispoziție pentru imagini, design și multimedia, ce variante de hosting gratuit ai și cum să-ți organizezi fișierele în viitoarele tale proiecte.

Ăsta e momentul perfect să îți dau o temă pentru acasă.

• Era previzibil, nu? Tema pentru tine este să treci prin toți pașii pe care i-am descris în articolul ăsta și să-ți instalezi sau să-ți faci cont peste tot, pentru a putea intra în pâine cât mai repede odată ce începem să codăm.
• Dacă ai dificultăți cu vreun pas de instalare sau înregistrare de la vreo unealtă de mai sus, scrie-mi mai jos în comentarii și voi încerca să te ajut.

Concluzii

Tocmai am terminat a cincea lecție din cursul de Front End Development în Română. Dacă sunt lucruri pe care nu le-ai înțeles și vrei să îmi adresezi o întrebare, scrie mai jos în comentarii și îți răspund cât pot de repede! Poate chiar fac un articol dedicat răspunsului pe care-l cauți, fiindcă mi-am propus ca acest curs să fie interactiv în felul ăsta.

În cazul în care ți-a plăcut acest articol, dă un share tuturor prietenilor tăi care ar putea învăța ceva nou din lecția de azi. Dacă nu ești încă abonat la canalul meu de YouTube, intră aici și apasă pe Subscribe, clopoțel și alege Toate Notificările, ca să primești tot ce urmează să public în viitor.