Frontend er utvikling brukergrensesnitt og funksjonalitet som fungerer på klient side nettside eller applikasjon. Denne typen utvikling inkluderer alt som brukeren ser når han åpner en nettside. En frontend-utvikler samarbeider med designere, programmerere og UX-analytikere for å lage et brukervennlig og etterspurt produkt.

For å tydelig forstå hva frontend-utvikling er, åpne siden til et hvilket som helst nettsted - du vil se grensesnittet foran deg. Klikker Høyreklikk mus, kan du se koden til denne siden i nettleseren din.

Denne koden er et eksempel på arbeidet til en frontend-utvikler, den lastes ned til brukerens nettleser, og du kan se den med dine egne øyne. Sidekoden beskriver alt du ser foran deg: farger, layout, fonter, layout grafiske elementer og så videre.

Frontend-utvikling inkluderer:

• HTML (HyperText Markup Language)- dokumentmarkeringsspråk, ved hjelp av hvilket sidestrukturen dannes: overskrifter, avsnitt, lister og så videre;
• CSS (Cascading Style Sheets)- et språk for å beskrive og stilisere utseendet til et dokument. CSS-koden lar nettleseren din forstå nøyaktig hvordan elementer skal vises. CSS setter farger og fontparametere, bestemmer hvordan forskjellige blokker av nettstedet vil bli plassert, og så videre. Det lar deg også vise det samme dokumentet i forskjellige stiler, for eksempel for utskrift (vanlig eller blindeskrift), visning av et program på en skjerm eller lesing med stemme;
• JavaScript er et språk som ble skapt for å bringe nettsider til live. Dens oppgave er å svare på brukerhandlinger, behandle museklikk, markørbevegelser og tastetrykk. Den sender også forespørsler til serveren og laster inn data uten å laste siden på nytt, lar deg legge inn meldinger og mye mer.

Hva er backend-utvikling?

Backend-utvikling er et sett med maskinvare- og programvareverktøy ved hjelp av hvilke logikken til nettstedet implementeres. Enkelt sagt er dette noe som er skjult for brukerens øyne og skjer utenfor nettleseren og datamaskinen hans.

For eksempel når du skriver inn et søk på en søkemotorside og trykker på tasten Tast inn, frontend slutter og backend begynner. Din forespørsel sendes til serveren Google eller Yandex, hvor søkealgoritmene er plassert. Det er her all "magien" skjer. Så snart informasjonen du lette etter vises på skjermen, går du tilbake til frontend-sonen igjen.

I det store og hele er en server den samme datamaskinen, bare kraftigere. Den lagrer data og svarer på brukerforespørsler.

Backend er prosessen med å koble serveren til brukeren.

En backend-utvikler kan bruke alle tilgjengelige verktøy på serveren hans. Han har rett til å velge hvilket som helst av de universelle programmeringsspråkene, for eksempel Ruby, PHP, Python, Java.

Brukes også til backend-utvikling ulike systemer database ledelse:

1. MySQL;
2. PostgreSQL;
3. SQLite;
4. MongoDB.

Avhengig av type produkt, kan ansvaret til en backend-utvikler variere sterkt. En slik spesialist kan lage og integrere databaser, sørge for sikkerhet, lage teknologier Reserver eksemplar og bedring.

Hvordan samhandler frontend og backend?

Interaksjonen mellom frontend og backend skjer i en sirkel: frontend sender brukerinformasjon til backend, hvor den behandles og returneres tilbake i en forståelig form.

Som regel utføres denne typen arbeid ulike spesialister, men det er tilrådelig for hver av dem å forstå prinsippene som kollegene deres arbeider etter. For eksempel er det viktig for en grensesnittdesigner å minst generell disposisjon vet hva bakenden av prosjektet han jobber med er. Dette vil hjelpe ham med å vurdere hva tekniske evner kan være på et nettsted eller en applikasjon.

Det er flere alternativer for interaksjon mellom frontend og backend:

• En HTTP-forespørsel sendes direkte til serveren, serveren ser etter informasjon, legger den inn i en mal og returnerer den som en HTML-side;
• Alternativ ved hjelp av verktøy AJAX (asynkron JavaScript og XML). I dette tilfellet sendes forespørselen JavaScript, lastet inn i nettleseren, og svaret kommer inn XML-format eller JSON;
• Enkeltsideapplikasjoner som laster inn data uten å oppdatere siden. Dette gjøres også når AJAX hjelp eller rammer Angular og Ember;
• Glør eller bibliotek Reagere hjelp til å bruke applikasjonen både på serveren og i klienten. Frontend og backend kommuniserer gjennom AJAX og HTML-kode, som behandles på serveren.

Som vi kan se, er moderne utvikling en kompleks prosess på flere nivåer, som er delt inn i to deler: klient og server. Frontend- og backend-programmerere har mange verktøy til disposisjon, valget av disse avhenger av oppgavene som er tildelt og kompleksiteten til prosjektet. Begge typer utvikling inkluderer tekniske og kreative komponenter.

Ansvaret til frontend- og backend-utviklere er vanligvis atskilt, men det er tider når en programmerer må løse problemer som oppstår både på serversiden og på klientsiden. Du kan ofte finne spesialister på markedet som føler seg trygge på både frontend og backend og kan kombinere to typer arbeid.

Du kan starte reisen din i frontend- og backend-utvikling med det 12-måneders Skillbox-kurset. Den passer for nybegynnere og programmerere med liten erfaring. I løpet av et år vil kursdeltakerne lære grunnleggende programmeringsspråk i praksis og lage sin egen portefølje, som vil hjelpe dem med å finne en lovende og godt betalt jobb.

webutvikler

Du har sikkert allerede hørt disse fasjonable ordene innen programmering av "frontend" og "backend", men hva ligger bak dem? Jeg foreslår at du ser nærmere på dette.

La oss starte med definisjoner.

Frontend- alt som nettleseren kan lese, vise og/eller kjøre. Det vil si at det er HTML, CSS og JavaScript.

HTML ( H yper T ext M arkup L språk) forteller nettleseren hva innholdet på siden er, for eksempel "overskrift", "avsnitt", "liste", "listeelement".

CSS ( C stigende S stil S ark) forteller nettleseren hvordan den skal vise elementer, for eksempel "etter første avsnitt, innrykk 20 piksler" eller "all tekst i brødtekstelementet skal være mørkegrå og i Verdana-font."

JavaScript forteller nettleseren hvordan den skal svare på visse interaksjoner ved hjelp av lett språk programmering. De fleste nettsteder bruker faktisk ikke mye JavaScript, men hvis du klikker på noe og sideinnholdet endres uten at skjermen blinker hvitt, ble JavaScript brukt et sted.

Baksiden- alt som kjører på en server, det vil si "ikke i en nettleser" eller "på en datamaskin koblet til et nettverk (vanligvis Internett) som svarer på meldinger fra andre datamaskiner."

For backend kan du bruke alle verktøyene som er tilgjengelige på serveren din (som egentlig bare er en datamaskin satt opp for å svare på meldinger). Dette betyr at du kan bruke et hvilket som helst universelt programmeringsspråk: Ruby, PHP, Python, Java, JavaScript/Node, bash. Dette betyr også at du kan bruke databasebehandlingssystemer som MySQL, PostgreSQL, MongoDB, Cassandra, Redis, Memcached.

Struktur av interaksjon mellom backend og frontend

I dag er det flere grunnleggende arkitekturer som bestemmer hvordan backend og frontend vil samhandle.

Serverapplikasjoner

I dette tilfellet sendes HTTP-forespørsler direkte til applikasjonsserveren, og serveren svarer med en HTML-side.

Mellom mottak av en forespørsel og svar, ser serveren vanligvis opp informasjonen i databasen for forespørselen og legger den inn i en mal (ERB, Blade, EJS, Handlebars).

Når en side lastes inn i nettleseren, bestemmer HTML hva som skal vises, CSS bestemmer hvordan den vil se ut, og JS bestemmer eventuelle spesielle interaksjoner.

Kommunikasjon ved hjelp av AJAX

En annen type arkitektur bruker AJAX for kommunikasjon ( EN synkron J ava S krypt og X ML). Dette betyr at JavaScript lastet i nettleseren sender en HTTP-forespørsel (XHR, XML HTTP Request) fra innsiden side og (historisk) mottar et XML-svar. Nå kan du også bruke JSON-format for svar.

Dette betyr at serveren din må ha sluttpunkt, som svarer på forespørsler med JSON- eller XML-kode. To eksempler på protokoller som brukes for dette er REST og SOAP.

Klientapplikasjoner (enkeltside).

AJAX lar deg laste inn data uten å oppdatere siden. Dette er mest brukt i rammeverk som Angular og Ember. Når de er bygget, sendes slike applikasjoner til nettleseren, og eventuell påfølgende gjengivelse gjøres på klientsiden (i nettleseren).

Denne frontenden kommuniserer med backend via HTTP ved hjelp av JSON- eller XML-svar.

Universelle/isomorfe applikasjoner

Noen biblioteker og rammeverk, som React og Ember, lar deg kjøre applikasjoner på både serveren og klienten.

I dette tilfellet bruker applikasjonen både AJAX og servergjengitt HTML for å kommunisere frontend med backend.

Utover frontend og backend

Autonom frontend

Nettapplikasjonene du skal lage vil kreve mindre og mindre Internett-tilkobling.

Progressive nettapper lastes bare én gang og fungerer (nesten) alltid. Du kan lagre databasen i nettleseren. I noen tilfeller trenger applikasjonene dine bare en backend første gang de lastes, og da kun for datasynkronisering/beskyttelse. Dette nivået av utholdenhet betyr at det meste av applikasjonslogikken ligger direkte i klienten.

Lett backend

Backend blir på sin side lettere og lettere. Teknologier som dokumentlagre og grafdatabaser resulterer i færre turer til backend for å samle data på nytt. Klientens jobb er å avklare hvilke data den trenger (grafdatabaser) eller å hente alle de forskjellige dataene den trenger (REST API).

Det er nå mulig å lage backend-tjenester som ikke kjører hele tiden, men bare når de trengs, takket være serverløse arkitekturer som AWS Lambda.

Uklare grenser

Databehandlingsoppgaver kan nå flyttes mellom frontend og backend. Avhengig av type applikasjon kan du gjøre beregningene utført enten i klienten eller på serveren.

Hvert alternativ har sine fordeler og ulemper. Serveren er et mer stabilt miljø, har færre ukjente, men den trenger hele tiden en tilkobling til Internett. Noen brukere bruker siste versjoner nettlesere, og det er mer lønnsomt for dem å bruke klientapplikasjoner, som gjør det meste av jobben og har et vakkert grensesnitt, men da vil du fremmedgjøre brukere som ikke bruker nyeste nettlesere Og høyhastighetsforbindelse til Internett.

Uansett er det bra at det er mye å velge mellom. Det viktigste er å velge akkurat det som passer best for spesifikk oppgave. Jeg håper du har en bedre forståelse av hvor webutvikling står i dag.

Nettleseren viser alt den mottar fra serveren og "forstår". Dette gir grunnlag for å definere kartleggingsprosessen og datagenereringsprosessen i to komponenter. Den besøkende som ser på siden, tar handling, noe som gir sidefunksjonaliteten grunnlaget for å "administrere" serveren.

Serveren genererer den første siden når nettleseren "går inn" på nettstedet. Serveren venter deretter på "instruksjoner". I denne situasjonen: front-end og back end-utvikling er virkelig en grunn til å gi arbeid til to kategorier av utviklere parallelt.

Nettstedet er et enkelt system

Det har alltid vært en ting og det har det vært generell oppfatning om hvordan du gjør dette. Frontlinjen har alltid vært dynamisk og bakdelen har vært stabil. Det var alltid slik, i alle retninger teknisk fremgang, og hvis ikke teorier, så dukket det opp universelt aksepterte regler. I området informasjonsteknologier Det er fortsatt ingenting universelt akseptert, men det er mange gode ideer som brukes etter behov.

Infosfæren er ennå ikke i stand til vitenskap. "Konstruksjonsstadiet" for programmer og nettsteder er allerede bak oss. Feltet informasjonsteknologi utvikler seg stille, og utviklere handler på egen risiko og respekterer kollegenes meninger, kritiserer ikke spesielt alles arbeidsalternativer, aksepterer det som skjer som det er, i alt dets mangfold.

Statiske sider hører fortiden til; innholdsstyringssystemer har allerede blitt vanlig. En betydelig del av utviklerne fortsetter å skrive «for hånd», og alle de andre som bruker maler, CMS, rammeverk og lignende verktøy for å fremskynde arbeidet på nettsteder, legger fra tid til annen til koder på serverside- eller nettleserspråk for å produktene deres.

Hva du skal gjøre, det er ingen perfekte verktøy innen nettstedbygging ennå, du må bruke alt som er tilgjengelig.

Om front-end-funksjoner

Boken "Front-end. Klientutvikling for profesjonelle" er et slags konsentrat av høy kvalitet og praktisk beskrivelse av JavaScript, HTML5 og CSS3, rettet mot en kvalifisert utvikler som ønsker å utvikle "klient"-kode av høy kvalitet.

Node.js, ES6, REST, praktiske eksempler og flott stil. Uten tvil er "Front end: Client Development for Professionals" en utmerket og nyttig publikasjon, grunnleggende for utvikleren - en bibel med kunnskap og prosesser for effektiv anvendelse.

Det er vanskelig å argumentere med det faktum at en spesialist innen informasjonsteknologi ikke er forskjellig fra spesialister i andre yrker. Som andre steder er det også en mening her: en spesialist er som en gumboil - fullstendigheten av kunnskapen hans er ensidig. Du kan ikke være JavaScript-ekspert og mestre CSS3 samtidig.

Det er en oppfatning at det finnes selvstendige kvalifikasjoner i hypertekst (HTML), iht XML-språk, Cascading Style Sheets (CSS) og andre områder. Naturligvis er det vanskelig å ikke dele opp arbeidet:

• nettlesermiljø;
• "filosofi" til serveren.

Så å si er det åpenbart at frontend-utvikling er hva det er: det er grunnleggende viktig, men det fungerer ikke på serveren i det hele tatt.

Om backend-funksjoner

Internett-verdenen betjenes av et stort utvalg av servere og teknologier. Her er Apache, i alle sine nåværende versjoner, fortsatt en trendsetter. Til i dag har ikke Unixoid-familien mistet håndflaten i serverbransjen til noen andre plattformer.

Fra utviklerens synspunkt, enkelhet, pålitelighet og ønsket om å lage systemer som ikke er utsatt for Blå skjerm og "panikk", men trygt gir en adekvat vei ut av enhver uforutsett situasjon.

Dette er nivået serverteknologier, det vil si at dette ikke er frontend-utvikling, hva dette betyr er på en måte klart: det er ingen nettleser her, men det er PHP eller et annet serversidespråk.

HTTP (eller annen) protokollen lar nettleseren be serveren om å hente en side, og nettleseren gjengjelder. Språket på serversiden behandler funksjonaliteten som er opprettet av "back-end"-utvikleren og sender "front-end" til nettleseren. Dette kan være den første siden, en sideoppdatering eller en overgang til en annen side, inkludert å følge en kobling til et annet nettsted, det vil si til en annen server.

Å kombinere back-end + front-end utvikling: hva er det, er det mulig?

Enhver anstendig konfigurert server tilbyr utvikleren mye moderne språk og verktøy for ethvert svar på nettleseren. Klienten har ingenting med det å gjøre, den handler kun gjennom nettleseren. Selv om klienten kan være:

• Internett-robot;
• "edderkopp" er et fasjonabelt merke innen parsing;
• annet programvareprodukt.

Det er mange nettlesere, men DOM-logikken og JavaScript er i 99,9 % av tilfellene grunnlaget for å vise serverresponsen. Nettleseren prøver å transformere enhver strøm av informasjon fra serveren til DOM og forventer å finne i den:

• HTML.
• JavaScript.

Denne hellige treenigheten utgjør front-end og utvikling: hva det er og hvordan det skal brukes ser ut til å være krystallklart.

DOM er et tre, det høres så kjent og tradisjonelt ut. Faktisk er DOM et godt designet system, og JavaScript er morsmålet. I denne sammenheng er kunnskap - Front-end: klientutvikling for fagfolk i pdf-format veldig bra, men ideelt sett i formatet en oppslagsbok som alltid er i sikte.

Viktig: Når en nettleser åpner et nettsted, bygger den DOM-en og avgrenser den mens klienten er innenfor rammen av siden den åpnet. Flytte klienten mellom sider, både interne og eksterne Eksterne linker, endrer innholdet i DOM- og JavaScript-funksjonaliteten. En front-end-utvikler har all grunn og mulighet til å bli omfattende administrert i nettleseren, uten å miste kontrollen over administrasjonen.

Serveren har en annen filosofi. Det er mange kunder her, du kan ikke holde styr på alle. Men dette er ikke viktig, men det faktum at det er umulig å bygge et permanent system av objekter for alle. åpen forbindelse. Faktisk kan en kvalifisert utvikler gjøre dette, men dette punktet er ikke legalisert verken av serveren eller av noe språk på serversiden.

Klient + serversystem

Hvis vi snakker om en nettleser, er det alltid et ferdig produkt, det har sin egen aura, og det må utføre spesifikk funksjonalitet, ellers er det ikke en nettleser. En server er også et ferdig produkt, hvis funksjonalitet er mye bredere, og ansvaret er mye høyere.

Både nettleseren og serveren er helt uavhengige og uavhengige systemer. Nettsteder er forresten ikke det eneste som både nettlesere og servere er i stand til. Disse er bare flotte programvaresystemer, som tilfredsstiller spesifikke bruksområder.

En nettressurs er grunnen til at nettleseren og serveren begynner å kommunisere og fortsetter til klienten drar til et annet nettsted.

Du kan dele alle byggherrer inn i murere, snekkere, gipsere og malere, men huset de bygger er ett. Denne faktoren er helt uavhengig av stiftelsen, selv om den alltid tar hensyn til dens egenskaper, territoriets spesifikasjoner, klimasonen og innbyggernes mentalitet.

En nettside kan lages av flere utviklere, men den må være et team. Laget er kvalifisert og nært knyttet. Den ene kan lage CSS-regler, den andre kan bare layout HTML-tagger, den tredje er inspirert til å beskrive funksjonalitet i JavaScript ved å bruke tagger, regler og hendelser. Men det bør være et sammenkoblet team som tar hensyn til serversiden, uten å skille den fra nettleseren.

Det er umulig å skrive PHP-kode som ikke vet hva CSS-utvikleren skrev, HTML-spesialisten satt sammen og JavaScript-programmereren utpekt. Ellers vil nettstedet ikke bli et system, og hvis nettstedet ikke er et system, er det ikke et nettsted, men bortkastet krefter og tid på å lage front-end-sider som gjenspeiler det de kan analysere i det de mottar fra baksiden. Sistnevnte gjengjelder, og forstår hvordan det blir, alt som kommer fra nettleseren.

World Wide Web-punkt: nettsted = system

Internett er allerede så stabilt og kjent at det har begynt å leve etter sine egne lover, og disse lovene kontrolleres ikke lenger av utviklere, for eksempel skapere... De som har laget det har lenge vært borte på Internett, men de aktive Det aktive potensialet til alle utviklere som jobber på Internett forblir front-end, back-end, og generelt fungerer de rett og slett uten å bli delt inn i kvalifikasjoner og kunnskapskohorter.

Naturligvis, så snart Internett ble et fullverdig og selvutviklende system, ble det et miljø for eksistensen av nettressurser til ulike formål, men funksjonaliteten til hver ressurs har også blitt et veldig spesifikt spekter av krav.

Hvis en nettressurs oppfyller visse krav, eksisterer den og er tilgjengelig på Internett. Hvis ikke, spiller det ingen rolle hvordan back-end og front-end forholder seg - hva det er vil forbli et mysterium.

Layoutdesigner og programmerer, kunstner og ingeniør rullet sammen. I dette innlegget vil jeg fortelle verden om sverdets helt og magien til stiler og kode, som gjør nettet vakrere og raskere - front-end-utvikleren. Innlegget vil først og fremst være av interesse for alle de som ønsker å forstå hvordan front-end-utviklere skiller seg fra layoutdesignere, back-end-utviklere, UX-spesialister og webdesignere. Hvilke ferdigheter bør han ha, og hvorfor er det en ære å være en front-end-utvikler? Forfatteren utgir seg ikke for å være objektiv, men alle som er interessert i dette er velkomne under katten.

Først, la oss finne ut hva begrepet "frontend" betyr og hvem er en frontend-utvikler?

Dette begrepet er veldig spesifikt og bredt, noe som gjør det vanskelig å gi det en kortfattet og entydig definisjon. Frontend de kaller hele klienten (inkludert programvaredelen som er usynlig for brukeren) en del av nettsteder/webapplikasjoner: grensesnitt, maler, stiler, widgets osv. Alt som skjer på serversiden er følgelig. baksiden.

Jeg skal bringe deg kort liste konsepter og teknologier som oftest assosieres med frontend-utvikling:
HTML, CSS, JavaScript, jQuery, Node.js, AJAX, SPA...

La oss bryte ned hva en typisk front-end-utvikler gjør.

Selvfølgelig er det første ansvaret som dukker opp oppsett. Helten vår vet ideelt sett hvordan man layouter en side av enhver kompleksitet. Overholdelse av standarder (i den grad det er mulig) - nødvendig tilstand.

En front-end-utvikler overvåker kvaliteten på klientkoden i teamet sitt, slår hendene på uforsiktige layoutdesignere og slår designere som er borte i drømmene sine.

Vil du satse på hjemmeside din nettside vakkert galleri"som på den nettsiden"? Spør en front-end-utvikler! Han vil fortelle deg et dusin uten å nøle. ferdige løsninger, vil tilby alternativer for å tilpasse standard plugins, og alt dette umiddelbart under hensyntagen til kompatibilitet med CMS og støttede enheter/nettlesere.

Tenker du på å redesigne og legge til en fasjonabel funksjon på nettstedet ditt? tilpasningsevne, uendelig scrolling, parallaksrulling, etc. Helten vår har allerede regnet ut i tankene hans hvor mye det vil koste deg å implementere en gal idé, og vil fraråde deg i tide hvis hans kunstneriske smak og sunn fornuft tilsier at slike funksjoner i det minste vil være bortkastet penger, og på det meste forårsaker det en forringelse av brukeropplevelsen.

Oppmerksomhet på detaljer og en følelse av skjønnhet - særegne trekk frontend-utvikler.

På dette tidspunktet, la oss skissere linjen som skiller layoutdesigneren og front-end-utvikleren. Vi vil ikke gå inn på detaljer om layoutdesignerens arbeid. Hovedoppgaven er å kutte oppsettet. Hvis han da foretrekker å ta på seg en del av backend-utviklingen (PHP, Python...), så utvikler han seg mot en backend-programmerer. Hvis han legger mer vekt på programmering på klientsiden (JS), så er han kanskje en fremtidig front-end-utvikler. Det kan også skje at en layoutdesigner vil gå mot design, noe som også er ganske bra - praktiske layoutferdigheter vil bli hans betydelige fordel i forhold til klassiske designere "av yrke".

Det andre viktige ansvaret til en front-end-utvikler er å sikre riktig nivå av brukervennlighet og brukeropplevelse(UI og UX). Selvfølgelig bør designeren tenke på disse tingene først. Men en designer alene kan ikke alltid designe et grensesnitt som er oversiktlig å bruke og enkelt å implementere, av samme grunn av uvitenhet om den tekniske delen. En god front-end-utvikler har ferdighetene til en designer og UX-spesialist. Han vet med andre ord hvordan man lager et vakkert og brukervennlig brukergrensesnitt. Men det tar ikke i noe tilfelle brødet fra designere og UX-spesialister. Og hvis noen av dem er fraværende på laget, kan han delvis erstatte dem.

Jeg skal gi deg et eksempel fra det virkelige liv.
Designeren er ikke lenger involvert i prosjektet, og kunden bestemte seg for å gjøre det på nytt utseende og logikken i driften av enhver del av nettbutikken din på Bitrix.
1. Prosjektlederen går til programmereren.
2. Programmereren sier "vi trenger layout, tekniske spesifikasjoner og en betalt løsning fra Marketplace, fordi dette er ikke-standard funksjonalitet for butikken" og sender lederen til layoutdesigneren.
3. Layoutdesigneren sier "vi trenger en layout og en ikke-standard plugin for et slikt galleri, fordi dette ikke er i vår ferdige løsning."
Lederen finner seg selv i vanskelig situasjon. Klienten venter på resultatet, budsjettet er minimalt, det er ingen å tegne. Som praksis viser, hvis du overlater redningen av en slik situasjon til en backend-programmerer, vil klienten på slutten motta noe som ser ut til å fungere, men som er så forferdelig at designeren blir hvit når han så det, og brukeren ville forlate nettstedet og oppfatte det som en stor feil. Layoutdesigneren ville definitivt ikke taklet oppgaven. Lite blod Bare en erfaren front-end-utvikler kan redde situasjonen. Uten unødvendig oppstyr, vil han skrive om en lignende komponent for oppgaven som skal utføres, redesigne standard galleri og vil legge til elementer av interaktivitet slik at løsningen på problemet vil passe klienten og glede brukerne, og lederen vil nok en gang puste lettet ut.

Vår helt er en generalist. Han er interessert i hele spekteret av nettteknologier. Han ignorerer ikke serverutvikling. I tillegg til native JS, kjenner en front-end-utvikler minst ett server-side programmeringsspråk på et mellomnivå og kan utføre en betydelig del av oppgavene som en back-end-programmerer vanligvis utfører. Vet hvordan man håndterer et slikt beist som kommandolinjen (konsoll, terminal), og kan til og med sette opp en webserver. Serverutvikling på Node.js-plattformen er ikke eksotisk, men i det minste en grunn til å svare alle "pehpeshniks" og "python-spesialister" at vi heller ikke er ute av det.

En av hovedoppgavene til en front-end-utvikler er selvfølgelig, JavaScript utvikling, alt fra mini-plugins for gallerier til fullverdige webtjenester. Her er det igjen verdt å nevne Node.js, i i fjor spiller en stor rolle i både utviklingen av klientsiden av webapplikasjoner og serversiden. Hundrevis av klientrammeverk og biblioteker, som jQuery, Angular, Backbone, Knockout, Ember, etc. - uendelige muligheter for å utvikle teknikker for å bygge applikasjonsarkitektur, forbedre kvaliteten og utvide utvalget av oppgaver som løses av applikasjoner.

Med utviklingen av Node.js-plattformen har konseptet "fullstack-utvikler" blitt populært - i vårt tilfelle er dette en JS-utvikler som bruker JavaScript-prosjekter for alle mulige formål. Server, database, klientmaler – alt dette fungerer med data inn JSON-format, som ser veldig fordelaktig ut på bakgrunn av samme PHP, hvor "erfarne programmerere" skriver et rot med PHP/Smarty/JS/CSS, som noen ganger er umulig å ordne opp bare en måned etter at prosjektet er fullført.

Front-end utviklerverktøy er også et eget tema for diskusjon. Mange flotte verktøy er skrevet for Node.js, som fungerer i ånden til "ett program, en oppgave." Automasjon rutineoppgaver ved hjelp av Grunt har blitt en integrert del av arbeidet. Kodesjekking, kjøring av tester, automatisk distribusjon, tilsløring og minifisering, CSS-forbehandling og mange andre oppgaver løses med et smell med bare noen få klikk.

Chrome Dev Tools og Firebug er uovertruffen blant front-end utviklingsverktøy. I i dyktige hender For helten vår lar disse tingene ham utføre mirakler. Er nettsiden din glitchy og treg å laste, og det er derfor den er utsatt for pessimisme i søkemotorer? En god front-end-utvikler vil bruke Firebug til å finne alle svake punkter i et nettsteds ytelse i løpet av et par minutter. Forresten, og ca SEO-optimalisering vår helt glemmer ikke. Det hendte at kolleger i personen til en layoutdesigner og en programmerer introduserte vakre tagger i koden til en side

, og alle bildene hadde attributtet alt="image001.jpg" . Они, безусловно, получат втык и под чутким надзором будут исправлять это.!}

Konklusjon

La oss kort liste, i rekkefølge, ferdighetene til en god front-end-utvikler skissert ovenfor:

1. Gyldig piksel-perfekt layout
2. Grensesnittdesign
3. Arbeid med serverteknologi
4. JavaScript i alle dens avskygninger
5. Optimalisering av nettapplikasjoner

Det viser seg at front-end-utvikleren er en flott fyr. Og han vil korrigere designet og layouten, skrive og feilsøke det som det skal. Med dette innlegget ønsker jeg ikke å sette front-end-utvikleren over resten, men jeg vil at tvilende borgere skal forstå forskjellen mellom en generalist-nettspesialist og høyt spesialiserte spesialister. Det kan være synd når en person som har jobbet i flere år med en lang rekke prosjekter av sine overordnede blir kalt for en enkel layoutdesigner og tenker at de hadde klart det uten ham. På grunn av denne holdningen til ansatte, mister bedrifter ofte svært verdige mennesker.

front-end utvikling er etableringen av klientdelen av nettstedet. En front-end-utvikler er ansvarlig for layout av nettsidemalen og opprettelse av brukergrensesnitt. Vanligvis er en front-end utvikler en jack of all trades. Han må rett og slett ha talentet til en designer, være en dyktig layoutdesigner og en god programmerer.

En moderne front-end-utvikler skal enkelt kunne mestre html5, css3, JavaScript(og minst JQuery). Hver front-end-spesialist har sitt eget arbeid, som han lagrer i form av et rammeverk. Mange utviklere bruker populære rammeverk i arbeidet sitt, som Twitter, Bootstrap, Foundation 3, Compass.

Hva en front-end-utvikler trenger å vite:

For å være en vellykket front-end-utvikler i disse dager, må du ha et sett med grunnleggende grunnleggende ferdigheter. De utviklerne som ikke oppfyller disse kravene vil snart begynne å falle bak den dynamiske fremgangen ettersom informasjonskildene begynner å ta litt kunnskap for gitt.

Her er de viktigste grunnleggende ferdighetene:

• JavaScript

Bare å kjenne til et JavaScript-bibliotek er ikke lenger nok. Det er nødvendig å forstå i hvilke tilfeller bruken av biblioteket egentlig er hensiktsmessig, og å kunne jobbe med god gammel JavaScript, om nødvendig. Du må også forstå hvordan datastrukturer som objekter og matriser fungerer; funksjoner, inkludert hvordan og hvorfor de skal kalles og brukes; kunne arbeide med arv gjennom prototyper; og håndtere asynkroni.

• GIT filversjonssystem

Uten GitHub kan en front-end-utvikler stort sett ikke delta i et stort åpen kildekode-fellesskap. kildekode, som vokste opp rundt front-end utviklingsteknologier. Kloning av et depot for å prøve ut dets evner bør bli vanlig. Det er viktig å forstå hvordan man bruker filialer i fellesprosjekter.

• Modulær organisering, avhengighetsstyring og testbygg

RequireJS-verktøy gjør det mulig å utvikle ved hjelp av små, modulære JS- og CSS-filer, og deretter sette sammen og minifisere dem med optimaliseringsverktøyet for videre bruk.

Hvis alternativet ovenfor ikke er egnet av en eller annen grunn, kan du bruke verktøy som UglifyJS eller Closure Compiler, som intelligent komprimerer den nødvendige koden og deretter sammenkobler disse komprimerte filer før du publiserer resultatet.

Hvis koden er skrevet inn ren CSS- det vil si at en forprosessor som Sass eller Stylus ikke brukes - RequireJS vil også hjelpe med å organisere de nødvendige CSS-filer på modulbasert basis. Du trenger bare å bruke @import på hovedfilen for å laste ned utviklingsavhengighetene og deretter kjøre RequireJS optimizer på hovedfilen for å lage en klar-til-bruk fil.

• Utviklerverktøy innebygd i nettleseren

I løpet av de siste årene har utviklerverktøyene innebygd i nettlesere blitt betydelig forbedret. Hvis du lærer å bruke dem riktig, kan de forbedre utviklingsopplevelsen din betydelig. Det er verdt å velge én nettleser som utviklerverktøyene skal brukes på permanent basis, men ikke forlat verktøyene i andre nettlesere helt, siden nye legges til fra tid til annen basert på tilbakemeldinger fra utviklere nyttige funksjoner. Spesielt Operas Dragonfly har lagt til noen funksjoner som gjør at utviklerverktøyene skiller seg ut fra andre, for eksempel en (eksperimentell) CSS-profiler, tilpassbare hurtigtaster, ekstern feilsøking uten behov for en USB-tilkobling, og muligheten til å lagre og bruke egendefinerte fargepaletter .

• Kommandolinje

Det er flere oppgaver som må gjennomføres kommandolinje uten å nøle:

1. ssh for å koble til en annen maskin eller server
2. scp for å kopiere filer til en annen maskin eller server
3. ack eller grep for å søke etter filer i et prosjekt etter streng eller mønster
4. finne for å oppdage filer hvis navn samsvarer med et gitt mønster
5. gitå fullføre i det minste grunnleggende handlinger som add, commit, status og pull
6. bryggeå bruke Homebrew til å installere pakker
7. npm for å installere Node-pakker
8. perle for å installere Ruby-pakker

Testing

Saken med å skrive modulær, løst koblet kode er at det er mye enklere å teste, og med verktøy som Grynte, har det generelt blitt enklere enn noen gang å forberede et prosjekt med innebygde tester. Grunt integrerer QUnit, men det er mange testrammeverk der ute å velge mellom.

Selv om det er morsomt å teste modulær, løst koblet kode, kan det å teste dårlig organisert kode være et sted mellom vanskelig og umulig. På den annen side vil det å tvinge deg selv til å skrive tester, kanskje til og med før du skriver kode, hjelpe deg med å systematisere din tilnærming og kode. Dette vil også gi deg muligheten til å gjenoppbygge koden din med større selvtillit fremover.

Prosessautomatisering

Muligheten til å bruke Grunt til å sette opp et prosjekt med innebygd støtte for enhetstesting er ett eksempel på prosessautomatisering. Realiteten med frontend-utvikling er at utvikleren må gjøre mye repeterende arbeid, men som de sier: god utvikler- lat utvikler. Hvis noen handling utføres mer enn tre tid, det er på tide å automatisere det.