Přejít k navigační liště

Zdroják » Webdesign » Posuňme Definici “Front-End Developera”

Posuňme Definici “Front-End Developera”

Články Webdesign

Jak se kód přesouvá ze serveru do prohlížeče, role vývojářů se mění. Platí stále, že veškerý kód běžící v prohlížeči je front-end? Nad tím se zamýšlel Matthew Gertner. Překlad jeho článku vám dnes přinášíme.

Nálepky:

V anglickém originále zveřejněno na blog.salsitasoft.com.

Jak se kód přesouvá ze serveru do prohlížeče, role vývojářů se mění. Před nástupem webu nebyl vývoj rozdělen na front-end a back-end. Byli zde C programátoři, Pascal programátoři a FORTRAN programátoři, ale jazyk, který používali, byl spíše detail než podstata jejich kariéry.

Pak přišel web a s ním nová komunita vývojářů, kteří již nepsali tradiční imperativní kód. Zpočátku to byly šablony v jazycích jako PHP a ColdFusion (a poté JSP a ASP.net) pro generování HTML, které bylo následně renderováno prohlížečem. Přestože web developeři technicky vzato kódovali na serveru, rozdělení front-endu a back-endu bylo na obzoru.

V dalším století, dvě významné inovace zrychlily tento trend: Ajax a CSS. Ajax umožnil přesunout velkou část logiky do prohlížeče, zatímco server se stará o předávání a updatování dat skrz SOAP nebo REST. Toto nové paradigma dalo vzniknout jQuery, což je v podstatě nový jazyk nahrazující vanilla JavaScript, vytvořený zejména pro potřeby frontendistů. Nekompatibilita prohlížečů už nebyla takovým problémem, mizerné DOM API (včetně prapodivného XMLHttpRequest) bylo nahrazeno něčím rozumným a built-in funkce umožnovali lehce vytvářet poutavé animace a přechody.

Následující verze CSS zase umožnily vytvářet ješte více sofistikované layouty, ale také zvýšily laťku pro frontendisty. To vedlo k ještě větší specializaci a najednou formální vzdělání v informatice a přehled v algoritmech, system designu a imperativních jazycích už nebylo potřeba k tomu být profesionální vývojář. Pro tyto pozice bylo naopak důležité znát základy user experience a dobře ovládat HTML a CSS. Schizma mezi front-endem a back-endem bylo kompletní.

V posledních letech je situace ještě více nepřehledná. Již neplatí, že veškerá práce s tězkými břemeny se děje na serveru. Trend single-page aplikací dal vzniknout knihovnám jako Angular a Ember, jejichž rozsah a ambice se spíše podobají back-end frameworkům. Společnosti, které nezaměstnávají kvalifikované frontendisty, najednou zjišťují, že nejsou sto zvládnout veškeré spletitosti nejnovějších front-end frameworků. Tito vývojáři mezitím z frustace prskají, že Angular má „problém“, protože byl navrhnut lidmi od back-endu, kteří prostě „nechápou“, jak se dělá front-end.

Tím nechci říct, že hackování Angularu je mimo schopnosti každého frontendisty. Vývojářské schopnosti nejsou diskrétní, ale dali by se zhruba načrtnout na následující kontinuum. (Toto není workflow diagram – v takovém případě by například UX předcházelo graphic design – ale spíše diagram zobrazující blízkost dvou schopností. Čím jsou blíže, tím spíše jednotlivec ovládá oba dva.)

Software-Development-Continuum-2

(Jen z téhle ilustrace asi dokážete odvodit, kde se na spektru nacházím já.) Z mojí zkušenosti téměr všichni vývojáři zabírají nějaký spojitý segment tohoto spektra. Samozřejmě existují vývojáři, ktěří ovládají široké pásy. A já je naprosto obdivuji. Taky jsem si jistý, že někdo vytváří světovou grafiku a zároveň kóduje ovladače pro Unix. Nicméně většina frontendistů, které jsem potkal, ovládá zhruba rozpětí mezi UX a jQuery, možná s kapkou designu nebo (non-jQuery) JavaScriptu. Vzestup webu výrazně zvetšil množinu potencionálních develperů tím, že otevřel dveře lidem s tímto profilem.

Front-End-Developers-3

Spousta práce, která se dříve děla na backendu, je nyní tlačena do single-page aplikací v prohlížeči. Najednou se od UX-až-jQuery vývojářú očekává hardcore programování. Mezitím to, co se děje na serveru, se stalo povětšinou nudné: autorizace API volání a poskytování dat z databáze skrz REST. Přístupy jako CouchApps se dokonce snaží zbavit serveru úplně a není nepravděpodobné, že se něco takového stane mainstreamem v příštích pár letech.

Takže problém není Angular. Samozřejmě, v rychle se měnícím světě JavaScriptu je trochu staromódní, ale myšlenka single-page aplikací s většinou logiky v prohlížeči je v zásadě zdravá. A problémem nejsou ani frontendtisti. Svět stále potřebuje vývojáře, kteří zvládnou uchopit požadavky zákazníka, pracovat s grafikou a orientovat se ve spletitých CSS standardech k vytvoření nádherných, responsivních a funkčních uživatelských rozhraní.

Opravdový problém je dojem, že veškerý kód běžící v prohlížeči je front-end. To již zřejmě neplatí. Buď najdeme jiný výraz pro UX₋až-jQuery, nebo předefinujme to, čemu říkáme „front-end“.

Nǎse společnost si vybrala to druhé. Rozdělujeme vývojáře do dvou skupin: front-end a full-stack. Front-end zahrnuje stejné dovednosti jako kdy předtím: UX, HTML, CSS a jQuery se špetkou Angular direktiv. Mistrovství v CSS je obzvláště důležité, jelikož modulární responsivní stylesheety se stali životně důležitými v moderních aplikacích. Full-stack inženýři pracují na všem ostatním, což často znamená vybudování komplexních architektur využívajících Angular nebo jiný „front-end“ framework s Node.js backendem, který nedělá o mnoho více než prosté poskytování dat.

Angular a další velké frameworky nejsou nepřátelé frontendistů. Jsou pouze posledním projevem dlouhotrvajícího trendu: kód se stěhuje ze serveru do prohlížeče. Definujme tedy „front-end“ jako části aplikace vztahující se k uživatelskému rozhraní místo prostého „kód, který běží v JavaScript VM“. Pokud našim developerům přidělíme úkoly takto, uvidíme, že nový svět sigle-page aplikací je velmi podobný tomu starému. Nic nového pod sluncem.

Salsita Software

Salsita Software je softwarová společnost, která se specializuje na vývoj komplexních moderních webových a mobilních aplikací. Sponzorujeme JavaScripting.com, komunitní portál, který pomáhá vývojářům hledat knihovny a frameworky pro JavaScript.

Autor: Matthew Gertner
Překlad: Luboš Turek

Komentáře

Subscribe
Upozornit na
guest
16 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
pp

Pořád mám pocit, že „frontend“ je víceméně „jen“ GUI. V nejjednodušší aplikaci stačí frontend, ve složitější s primitivním backendem pro storage dat.

S tím, jak se do prohlížeče se stěhuje i storage a náročnější operace (např operace v graphics editoru), nevidím smysl v tom, nazývat toto ještě frontendem. Naopak, dělení toho co uložit v prohlížeči a co už poslat na server beru jako backend.

Můj závěr tedy je, že backend se roztahuje do prohlížeče, který se stává jeho další platformou či komponentou, se kterou může a nemusí pracovat. I složitější operace prováděné v prohlížeči podle mne jsou spíše backendem. Frontend je pořád o GUI, jeho uživatelské přívětivosti a jeho reakcích na uživatele. Jinými slovy, souhlasím s autorem, je třeba zúžit definici frontendisty.

standakaluza

Až na to, že správně je UX → GD, ne naopak, je to zajímavá hypotéza.

standakaluza

Odpovím si sám, blbě jsem to pochopil…

Matthew Gertner

Proto jsem napsal explicitne „Toto není workflow diagram – v takovém případě by například UX předcházelo graphic design – ale spíše diagram zobrazující blízkost dvou schopností. Čím jsou blíže, tím spíše jednotlivec ovládá oba dva.“

Ten diagram je ale asi trochu zavadejici.

Aleš Roubíček

Aneb, kdo chce hledat konce, ten si je vždycky najde. Dělení po vrstvách bylo vždycky chybou a neustále děláme jako že ne a pokračujeme ve vytváření nových…

vire

Ahoj, celkom by ma zaujimal aj iny (tvoj) pohlad na vec. Ja som rozdelenie v clanku nevnimal ako urcite vrstvy, skor ako spektrum skillov potrebnych pre vyrobu sw, s cielom plnit urcity zmysel (resp prinasat hodnotu).

EdaCZ

Ahoj, pěkný článek, díky. Jen dvě drobnosti:
„…built-in funkce umožnoval*i*…“
„Vývojářské schopnosti nejsou diskrétní, ale dal*i* by se…“

EdaCZ

A opravte si tučné zvýraznění v komentech, nefunguje… :-)

Pavel

Aniž bych chtěl znít jako jeden z těch co tvrdí že všechno už tu bylo (protože to není pravda), pamatuji tyhle souboje tenkého vs. tlustého klienta ještě z dob kdy webový browser nebyl typickým, a nebo vůbec prakticky uvažovatelným, běhovým prostředím pro klienskou část aplikace :-) .

K tématu snad tolik že pokud dělení na front-end (= tuze tenký klient) vs. back-end („tlustý“ server, který totiž u webových stránek nadlouho přebíral i ty části business logiky které bývaly součástí nativních tenkých klientů) přestává mít smysl, protože implicitní rozdělení rolí které označoval nadále neplatí, je lepší přejít k explicitnějšímu rozdělení vývojářských rolí – už proto aby se to nepletlo je-li myšlen frontend postaru a nebo ponovu (i když chápu že vývoj pro web je specifický tím že se všechno, včetně obsahu pojmů, rychle a synchronně pro všechny mění).

karel

jj a pak prisly prvni mobili co zvladly zobrazit web, nemyslim wap ale opravdu http
a vse se zaclo zas davat na server protoze mobil mel dost prace vykreslit tabulku v html natoz aby mu ji javascript tvoril dinamicky. Ted kdyz uz kazdej mobil ma dvojadro to muzeme skusit znova, pak nas spatky zas zatlaci pomale proxesory v hodinkach, ale nevadi oni taky casem zrychlej a napotreti uz to vyjde.
Take je nutne si pripomenout proc se to poprve tlacilo do ke klientovi a to aby se odlehcilo serverum, dnesni hracky sou na tom radove jinak, ale diky vpskam je to zas treba.

Pavel

… no a pak se ukáže že to sice osmijádrové procesory na mobilech upočítají i s tím overheradem browseru ale zase to neutáhle baterka a že mobilní sítě jsou vlastně tak rychlý že se vyplatí spíš to počítat a zpracovávat v cloudu a sem-tam si posílat jen požadavky a výsledky atd.

Navíc, ne pro všechny typy aplikací je takové či makové rozložení business logiky mezi klientem a serverem vlastně jedno. Prostě nakonec je (nebo by měla být) architektura a zvolené řešení výsledkem optimalizace a rozvahy v mnoha směrech, a v čase se s rozvojem technologií a požadavků může přelévat… I proto trvat na „frontend“ a „backend“ může být spíš zavádějící.

Dor

Několikrát jsem se setkal i s interpretací, že frontend je rozhraní pro uživatele a backend je rozhraní pro administátory. Od té doby se radši výrazům frontend a backend vyhýbám úplně a používám osvědčené server, client, GUI. Zvykl jsem si na rozdělení programátor – imperativní jazyky / kodér – deklarativní jazyky. S tím jsem zatím nenarazil a všichni mě pochopili. Ale možná jsem měl jenom štěstí. :)

Marek Sirkovský

A co kdyz pisu v jednom jazyce jak imperativne tak deklarativne? To sem pak vyvojar? :)

Jerry7x

Joooo, PL/SQL a T-SQL. To byly casy, kdyz jsme vazne museli kvuli vykonu zavirat peknou cast aplikacni logiky do DBMS.

Mar

Všechno co je momentálně v Javascriptu v prohlížeči je frontend. Generování HTML/CSS není backend ale taky frontend, z důvodu nedokonalosti tenkých klientů vykonávaný na serveru. Situace se vrací zpět do tlustých klientů, kdy aplikace u klienta bude řešit frontend kompletně celý a server bude poskytovat data a výkonné funkce z business logiky.

Robert

Každá aplikace má (nebo alespoň by měla mít) Model, který má nějaké rozhraní (API). To co je schované za tímto API je backend, naopak to, co toto API využívá je frontend. Tak to bylo, je a bude.

Toto API je sada metod / funkcí pracujících s čistými daty (nikoliv s HTML). Toto API může být zveřejněno i přes URI (SOAP, REST, XML-PRC atd…). Ale tímto API rozhodně nejsou běžná „aplikační URL“ typu xxx.cz?page=prehledClanku která vracejí HTML.

Definovat někoho kdo generuje HTML na serveru jako backend pracovníka je naprostý omyl. Z toho pak plyne celá řada rozporů které autor řeší pokud se toto generování přesune na ze serveru na klienta.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.