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

Zdroják » Webdesign » Webdesigne, kam směřuješ?

Webdesigne, kam směřuješ?

Články Webdesign

Web se neustále vyvíjí. Nabobtnává, přidává novou funkcionalitu a zároveň zjednodušuje stávající technologie. Právě se nacházíme na dalším evolučním kroku webu, a tím je zjednodušování. V čem je ale háček?

Vývoj na webu se vždycky snažil vyřešit nějaký problém. Tak jak rostl, řešil problémy předchozích řešení problémů. A dnes tomu není nikterak jinak.

Aby bylo možno jednotlivé kroky porovnat, je třeba podívat se zpětně, jak se uživatelská očekávání od webdesignu vyvíjela v průběhu věků a hlavně, co tehdy na daných technologiích a technikách nevyhovovalo a proč vznikaly jiné.

Vývoj webdesignu v čase

Začněme úplně od počátku. Od času, kdy se samotný internet zrodil.

Temná éra

Pro svět to začalo v  roce 1989. Ačkoli svět už tehdy téměř 8 let měl jasného vítěze pro standard barevné grafiky, tehdy tvořené webové stránky byly převážně monochromatické. V úplných začátcích pak stránky vypadaly dost temně, tvořeny černým pozadím s jednou převažující monochromatickou barvou. Design spíše upravoval webový prohlížeč než samotný tvůrce webových stránek. Na nejstarší dostupné stránce, která byla vytvořena 13. listopadu 1990, lze vidět, že tehdejší web obsahoval jen minimum zdrojového kódu tak, jak jej známe dnes. Byl docela nahý, bez <body>, bez tagu <title>.

Problém: nemožnost tvorby menu, nebo přesněji layoutů oddělujících části navigační od obsahových. Stránky obsahovaly jen text a jakékoli pokusy o odlišení částí textů musely být řešeny pomocí tabulátorů a symbolů.

Tabulková éra

V roce 1995 se začaly rodit webové prohlížeče, které dokázaly zobrazit obrázky, což byl jeden z prvních kroků k designu, který známe dnes. Nejbližší technika, jak strukturalizovat informace, byl koncept tabulek, který dávno v HTML existoval. A tak tvůrci umísťovali tabulky do tabulek a tímto způsobem stránku dělili do sekcí, ačkoli každý v hloubi duše tušil, že tabulka by měla zůstat pro zobrazování tabulárních dat. V těchto letech zároveň začal být internet veřejně dostupný i u nás. Pokud vás zajímá, jak v letech 1995-1999 webové stránky vypadaly, doporučuji projekt muzeum internetu Jiřího Peterky.

Problém: narůstající složitost kódu. S rostoucí komplexitou webových stránek bylo čím dál obtížnější je aktualizovat. Problém byl v prohlížeči (tehdy také vznikly termíny jako front-end a back-end) částečně řešen pomocí iframe, kdy se stránky skládaly z několika jiných stránek v prohlížeči poskládaných do sebe, což ale zároveň přinášelo jiné problémy.

Kdo mohl, obvykle problémy řešil na pozadí, tj. už na serveru. Rok 1995 je spojen s rozvojem skriptovacích programovacích jazyků, a to zejména jednoho ze stále nejpoužívanějších, jazyka PHP, v původní zkratce Personal Home Page.

S tabulkami se rovněž pojí problém pomalého zobrazování webu – prohlížeč čekal, až najde koncový tag </table>, aby mohl tabulku vyrenderovat. Při načítání dlouhých webů tvořených tabulkami měl návštěvník pocit, že trvá věčnost.

Éra flashová

Dnes se mu smějeme, ale v roce 1996 byl Flash darem z nebe. A vlastně i mnoho let poté. Designérům poskytoval volnou ruku, protože vše, co vytvořili, se v identické podobě zobrazilo i jejich návštěvníkům. Tedy… pokud měli v počítači nainstalovaný Flash Player. A pokud měli stejnou verzi. Flash se svým příchodem zničil všechny tehdy existující limity webového designu. Přinesl layouty stránek, rozvinul animace, rozjel video na webu, přinesl dodatečné sady písem a návštěvníkovi nevídanou možnost interakce s webem. A celé to fungovalo bez sebemenších potíží. V té době bylo moderní mít na webu animované, postupně se načítající úvodní uvítací obrazovky. Vznikaly také internetové hry.

Problém: uzavřená platforma. Ačkoli byl Flash vyvíjen velmi silnou společností, ani ta nedokázala ustát zrychlující se vývoj a zvyšující se požadavky uživatelů. Problém uzavřenosti se projevil na nemožnosti flashové stránky procházet crawlery a jinými roboty, což majitele stránek znevýhodňovalo ve vyhledávačích. Zároveň se u něj často objevovaly různé bezpečnostní problémy. Hřebík na hlavičku udeřil Flashi Apple, když se jej rozhodl ve svém prvním iPhonu (2007) nepodporovat s tím, že Flash potřebuje příliš mnoho výpočetního výkonu. A tak Flash začal pomalu umírat. Steva Jobse to asi ještě dlouhou dobu mrzelo, protože se v roce 2010 rozhodl vydat svůj článek Thoughts on Flash.

Éra JavaScriptu a CSS

Nelze říct, že by éra JavaScriptu a kaskádových stylů začala až po éře Flashe, neboť všechny tři technologie vznikly v podobný čas (JavaScript v roce 1995, CSS roku 1998). Vliv trojice byl identický, ale postupem času vždycky tam kde Flash ztrácel, začaly jej nahrazovat JavaScript a CSS.

Základním konceptem CSS bylo oddělit obsah od prezentace. Technologie to ale neměla lehké. Trvalo několik let, než ji začaly prohlížeče plně podporovat. A pak ještě několik let, než ji začaly podporovat správně, tj. tak, aby se všude zobrazovala stejně anebo bez chyb. CSS vděčíme za odstranění tabulkových layoutů a celkově v lepším přístupu ke strukturalizaci a návrhu designu. Jednou z událostí na poli CSS, které je nutno zmínit, byl příchod obrovsky populárního frameworku Twitter Bootstrap (2011), který nárazově přeformátoval řadu webů do použitelnější, méně chaotické podoby.

Ačkoli byl JavaScript navržen jako jazyk, který umožňuje dynamicky měnit stránku po jejím načtení, dlouhou dobu jej neuměli vývojáři uchopit za správný konec. A tak byl dlouhou dobu zneužíván jako možnost, jak vytvořit popup okno nebo alert zprávu „opravdu chcete opustit tuto stránku?“.

Největší rozmach JavaScriptu lze přisoudit knihovně jQuery (2006), u které je vidět jistá podobnost s CSS. Zatímco kaskádové styly oddělují „zobrazovací“ charakteristiky od struktury HTML, jQuery od struktury HTML odděluje „chování“. Nejlépe je to znát na příkladu tlačítek, u kterých se dříve častěji specifikovala událost „onclick“ přímo v HTML kódu, jQuery tuto techniku oddělilo do samostatného skriptu, který tak nejprv daný element nalezne a poté mu onclick událost přiřadí. jQuery, kromě jiných funkcí, se svým příchodem zjednodušilo volání AJAXu, což jej pomohlo výrazněji rozšířit.

Problém: narůstající složitost a mrtvý kód. Ačkoli tato éra rozhodně nelze označit za ukončenou, lze zde pozorovat podobné problémy, jaké mělo HTML před příchodem CSS. Složitost stránek se zvyšuje, což je přirozený vývoj. Se vzrůstající složitostí ale narůstá tzv. mrtvý kód.

Css frameworky a javascriptové knihovny obsahují desítky pravidel a funkcí, které pak webdesignér vůbec nepoužije. V klasickém programování aplikací, mimo vody internetu, mrtvý kód natolik nevadí. Zabírá místo, ale nijak výrazně to nikoho neohrozí. Web je ale v tomto jiný, stále je třeba řešit každý zbytečně přenášený kilobajt navíc. Ano, už dávno nemusíme říkat, že pokud má stránka více než 120 kB, je mrtvá, jak to učinil v prvním vydání své populární knihy Jeffrey Zeldman.

Aktuálně možným řešením tohoto problému je diffing kódu, čili kontrola který kód se změní při přechodu na novou stránku a nahrazení jen tohoto kódu, nikoliv celé stránky, což asi nejefektivněji v současnosti řeší knihovna React. Dalším možným řešením může být příchod nového HTTP2 protokolu a následný přechod na jiné způsoby předávání dodatečných zdrojových kódu – čili jen těch, co jsou aktuálně třeba. A nebo tento problém může vyřešit jiná technologie. Napadá vás nějaká? Prosím napište o ní do komentářů.

Éra mobilních zařízení

Je lehké a zároveň těžké definovat počátek éry mobilních zařízení přistupujících k internetu. Jako etalon se používá uvedení iPhonu (2007) a tím vznik nového trhu smartphonů, chytrých telefonů schopných používat internet.

Nedá se však říci, že by mobilní internet před tímto bodem neexistoval. Existovaly statisíce zařízení schopných přistupovat ke klasickému velkému internetu a zcela určitě miliony mobilních zařízení, které byly schopné používat WAP. Kdo někdy zkoušel vytvářet stránky ve WML, značkovacím jazyce založeném na XML, zcela jistě ví, že je to tuna práce navíc a že pokud uživatel může, stejně raději využije klasické zobrazení.

Samotné smartphony od jejich počátku narážejí na webu na řadu problémů.

Problém: weby nejsou pro mobily připravené.

Weby, původně dělané pro počítače, se zobrazovaly příliš malé. Bylo nutno stránku zvětšovat a složitě se ve výřezu zorientovávat. Některá menu byla závislá na hover událostech myši, a tak se v mobilu špatně ovládala.

Řešení tohoto problému rozdělilo webové vývojáře na tři skupiny.

Řešení prvé: mobilní verze

První část se rozhodla vytvořit oddělenou, jednodušší osekanou verzi stránky, která je dělaná speciálně pro mobilní zařízení. Mobilní verze obvykle leží na poddoméně, obvykle „m“ nebo „mobile“. Vytvořit takovéto řešení není výrazně pracné, nicméně je to práce navíc a tento speciální oddělený web může časem tvůrci přerůst přes hlavu.

Řešení druhé: mobilní aplikace

Jedná se o časově nejpracnější řešení. Je třeba začínat na zelené louce a zároveň je vhodné tvořit tyto aplikace pro více platforem. Výsledek pak je ale znát, aplikace je svižná a nabízí řadu možností, o kterých se klasickému či mobilnímu webu ani nesnilo, jako například zobrazování notifikací.

Řešení třetí: responzivní design

Třetí část vývojářů zvolila řešení nejjednodušší. A to návrh webu tak, aby se mobilním zařízením přizpůsoboval. Přestože od roku 2001 existoval working draft pro Media Queries, technologii umožňující v CSS oddělit zobrazení stránek pro jiné velikosti obrazovek, teprve v roce 2012 byl dokončen a označen jako doporučená technika. Klasické webové stránky tak bylo možné zobrazit na malých zařízeních bez větších zásahů do stávajícího systému, což se samozřejmě negativně projevilo na rychlosti nejen renderování stránek, ale i načítání.

V této chvíli budu částečně předjímat budoucnost, neboť ještě nejsme v situaci, kdy to je možné stoprocentně zhodnotit. Nicméně vypadá to, že právě řešení responzivního designu se dlouhodobě uchytí. U výkonnějších smartphonů a rychlejších mobilních sítí bude speciální mobilní verze často zbytečná. A mobilní aplikace jsou příliš velkým kanónem na vrabce. Ne každý uživatel si chce při návštěvě každého webu instalovat speciálně vytvořenou aplikaci.

Éra zjednodušování

A tady se právě nacházíme. Máme komplexní aplikace, které jsou plné mrtvého kódu (viz výše), a tak často řešíme to, že web přenáší nedůležitá data. Ač se dá problém nyní řešit optimalizacemi, není to dlouhodobě udržitelné řešení, protože to potřebuje dodatečné úsilí. Jako všude, řešením budou nové technologie, ať http2 protokol nebo jiné techniky. Zároveň tento problém může vyřešit rozvoj rychlejších mobilních a jiných sítí, kdy prostě bude najednou zbytečné řešit nějaký ten kB nebo dokonce MB navíc. Podobně jako to dnes neřešíme u velkých, desktopových aplikací.

Je zde ale problém zjednodušení, který nová technologie nevyřeší. A s tím se setkáváme i dnes. Stránky se staly komplexní i na poli grafického designu a samotných prvků, které se zobrazují uživateli. Na desktopu či velkém monitoru  to tolik nevadí. Některé prvky jsme se naučili nevnímat, viz např. bannerová slepota. Ale na menších zařízeních je řada prvků na obtíž a „věci navíc“ jsou tak více viditelné.

Jinými slovy řečeno, s nástupem responzivního designu přichází další problém, kterým je prioritizace obsahu. Web se začal stávat neúměrně komplexním nejen na pozadí zdrojového kódu, ale postupně se tenhle problém přelil i na jeho vizuální část, kterou vidí samotný návštěvník.

Tlak na zjednodušování designu je rovněž vyvolán samotnými potřebami uživatelů. Souvisí s rozšiřujícím se počtem uživatelů a jejich zkušenostmi. Již dnes téměř každý druhý obyvatel této planety má přístup k internetu (3,2 ze 7,2 mld) a i celkový přístup k informacím se za několik málo let rapidně změnil.

Uživatelé webových stránek jsou náročnější

Prohlížejí stránky rychleji a jsou náročnější na rozvržení dat. Pokud se vaše stránka nenačte do 4 sekund, 25 % návštěvníků si ji nikdy neprohlédne. Nenačte-li se do 10 sekund, už to může být každý druhý. A mimochodem, i Google vás hodnotí a posouvá níže ve svém vyhledávání v závislosti na tom, jak rychle se vaše stránky načítají.

To ale není všechno, uživatelé webových stránek se každou novou webovou stránku naučili posuzovat vzhledově. U webů, které vypadají staře, se rapidně začala zvyšovat míra opuštění. Většinu času lidé nečtou, ale text pouze skenují, prohlížejí si obrázky, přeskakují nadpisy, hledají záchytné body. Úkolem dobrého designéra je jim toto skákání obsahem co nejvíce zjednodušit.

Designové styly

Na webu existuje řada designových stylů. Ovšem málokteré styly korelují s potřebou po zjednodušování. Největší halo v této oblasti mají dva velmi podobné designové styly. Jeden založen na druhém. Jeden je horkou novinkou. Druhý možná utichající buzzword. Jeden je spontánně vzniknuvším designovým trendem. Druhý je založen na pevně vytvořených designových vzorech.

Jsou mezi nimi rozdíly? Je jeden podstatně lepší než druhý? Lepší pro některá užití?

Flat design

Flat design pomáhá řešit vizuální zjednodušení stránek. Je to design, který se vrací zpět k základům. Odstraňuje všechny stylistické prvky, které vytvářejí iluzi třetí dimenze, jako jsou stíny, barevné přechody (gradienty) a nebo dodatečné textury.

Flat design je vlastně takový bratr minimalizmu, designového stylu, který ale nelze použít všude. Vzhled není pro flat design prvořadý, zaměřuje se primárně na funkcionalitu. Nový druh designu používá jednoduchých grafických prvků, tj. ikonek a základních barev namísto obrázků na pozadí. Flat design rovněž pomohl rozšířit fonticony, neboli jednoduché ikonky, které jsou uloženy do samotného písma, kde každý znak představuje jednotlivou ikonku. Protože písma jsou vektorová a zároveň se jich přenáší vyšší počet, výrazně tato technika napomáhá v optimalizaci.

Tím se nejenže výrazně sníží doba načítání, ale zároveň grafika vypadá dobře na různých zařízeních, což pak má ve výsledku velký dopad na uživatelský zážitek.

Výhody

  • Zjednodušuje návrh webu, zbavuje se zbytečných grafických prvků, snižuje dobu načítání.
  • Odstranění nepotřebných částí podporuje rychlejší člení.
  • Je velmi adaptibilní pro různá zařízení a je s ním jednoduché vytvářet responzivní weby.

Nevýhody

  • Omezení jednoduchými barvami, tvary a ikonami může být limitující.
  • Pokud se to přežene, je snadné omylem vytvořit nevýrazný generický web.
  • Některé stránky potřebují komplexnější vizuální podněty k tomu, aby vedly uživatele tam, kam chtějí. Pokud uživatel nepozná, že tlačítko je tlačítko, je to problém.

Material design

Material design využívá chyby, které kritikové flat designu vytýkali, a to je radikální odstranění všech grafických elementů. Nový návrhový vzor od Google tak znova objevuje třetí dimenzi. Jednotlivé elementy skládá na sebe dle důležitosti v Z-ose, takže uživatel se dokáže snadněji orientovat, které části stránky mají větší prioritu podle toho, jestli daný box leží nad druhým.

Zároveň přidává řadu smysluplných animací, takže návštěvníkovi tak může být jasnější, odkud se objevil nový prvek, jak jej potenciálně nechá zmizet a kde jej případně zase nalezne. Také se snaží předefinovat nešťastné placeholdery uvnitř formulářů, což by mohlo vyřešit nekonečný problém s inputem, do kterého začnete psát a najednou nevíte, co vyplňujete, protože nápovědný placeholder zmizel.

O Material designu se již dlouhou dobu mluví, vznikla řada nezávislých frameworků, ale teprve nedávno, před pár dny, Google představil ten svůj, Material Design Lite, který je volně dostupný a může jej kdokoli použít. Na Githubu získal obrovskou popularitu. A vypadá to, že jej třeba ho brát se vší vážností, že to není jen srandapokus Googlu, ale potenciální další vývojový krok.

Výhody

  • 3D uspořádání prvků dělá interakci se stránkami snazší, kupříkladu vržený stín vrstev zjedodušuje orientaci, na které úrovni důležitosti obsahu se návštěvník právě nachází.
  • Oproti Flat designu nenechává nic na pochybách, přichází s velmi detailní a specifickou sadou návrhových vzorů, kde je přesně definováno, co a jak se má chovat.
  • Pokud plánujete vytvářet pro více platforem, jako kupříkladu pro webovou stránku a zároveň Android app, Material design přináší pro uživatele unifikovanou zkušenost napříč všemi zařízeními nebo použité technologie (web vs. nativní aplikace).

Nevýhody

  • Může se nám to líbit či ne, Material design je neoddělitelně připoután ke Googlu. Pokud budete chtít vytvořit unikátní identitu stránky, bude nemožné ji byť částečně vystavět na guidelines Googlu a zároveň tvrdit, že s ním nemáte nic společného, protože návštěvníci si ji s Googlem vždy spojí. V nynější situaci je obtížné hodnotit, jestli dopadne jako kdysi Twitter Bootstrap a „bude všude“. Ostatně se domnívám, že TB se bude Googlem inspirovat ve zmiňovaném grafickém skládání obsahu na sebe a rovněž půjde směrem k smysluplným animacím.
  • Material Design cílí hlavně na mobilní zařízení, ovládání na počítači ustupuje do pozadí. Některé prvky se stávají na desktopu v rámci UX hůře použitelnými, čili stojí za zmínku si na tohle dát pozor, pokud je stránka primárně pro desktop a nezapomenout tak na UX testování.
  • Ačkoli si Google striktně vynucuje návrhový vzor, sám se jej stoprocentně nedrží. Striktní vzory ničí kreativitu tím, že potlačují vývoj dodatečných nápadů, animací či dekorativních částí, právě proto, že neodpovídají původnímu návrhu.
  • Tohle je minoritní problém, nicméně čím častěji se boudou používat animace na webu, tím vyšší to bude mít vliv na baterii mobilních zařízení, což může jednou paradoxně vést k programovému zpomalování či zastavování animací, podobně jako býval řízeně blokován Flash.

Závěr

Material design není tak velký skok od Flat designu, oba jsou minimalistické a jednoduché. Jsou velmi praktické, zjednodušují stránku, snižují rychlost načítání, zvyšují uživatelskou přívětivost a zkušenost, je možné je použít na velké množství zařízení. Pokud chcete jednoduchou a použitelnou stránku, Flat design je pro vás. Pokud však pátráte po něčem komplexnějším v tomto jednoduchém stylu, Material design by mohl být zajímavou volbou.

Trend zjednodušování zcela určitě nepostihne pouze designovou část stránky. V nejbližších letech nastoupí novější technologie, bylo by však okázalé snažit se předpovědět, které uspějí. Možná CSS a dnes používané preprocessory nahradí PostCSS éra. Možná budou weby navrženy jako offline & mobile first. Možná weby přejdou na izomorfní model, tzn. nebudou se již programovat ve dvou jazycích a JavaScript převezme servery. Uvidíme, určitě je nač se těšit.

Názory odborníků v oboru

Zeptal jsem se několika odborníků na českém internetu, jak si představují webové stránky za pár let, co by uvítali, aby bylo běžnou praxí, standardem:

Petr Pixy Staníček

Budu zcela upřímný, já si webové stránky za pár let nepředstavuji. Vkus i technologie se mění rychle a oba tyhle faktory ovlivňují podobu webu největší měrou. Asi lze očekávat, že trend méně čtení, více multimédií bude pokračovat a posilovat, dál budou nabírat na síle mobilní zařízení a klesat používání desktopu (aspoň do doby, než někdo vymyslí zase nějakou převratnou technologii), bude se dál zjednodušovat technická forma (větší používání univerzálních frameworků, hotových šablon a standardních patternů) ve prospěch sofistikovanějších forem obsahu ve smyslu uměleckém.

Koukám na trendy a všemožné pokusy a posouvám se v práci s hlavním proudem, pokud to dává smysl a vypadá to jako trvalý posun (v opačném na hlavní proud kašlu) a přizpůsobuji se aktuální situaci. Snění o budoucí podobě webu laskavě přenechám věštcům a podobným sociologům.

Jan Brbla Bažant

V prvé řadě je třeba konečně pohřbít IE 7, 8 a 9 v korporátech :-) Dále lepší responze, vektorová grafika a hodily by se nástroje k optimalizaci požadavků pro mobilní zařízení (grafika, fonty).

Daniel Steigerwald

Nejlepší způsob jak předpovědět budoucnost, je vytvořit ji. Co se týká webu, jednu takovou právě vytváří Facebook. Budoucnost patří univerzálnímu JavaScriptu v podání Reactu a univerzálním aplikacím v podání Este.js. Pro webdesignéra to znamená, learn once write anywhere. Pokud se kodér naučí JavaScript, React a související technologie, může psát serverové appky i klientskou logiku jedním jazykem a jedním dev stackem. A díky React Native i aplikace pro iOS a Android.

Vidím to tak, že hodně PHP a Ruby programátorů přijde o práci, nebo spíše, bude mít novou a zajímavější :-) Rozjet projekt pro prohlížeč, server a mobil bude možné i pro jednoho osamoceného kodéra. Z tohoto důvodu je už pojem izomorfní aplikace nepřesný a místo něj se preferuje „universal JavaScript“.

Jednotný JavaScript povede k reaktivnějším aplikacím a k novému buzzwordu příštích let, developer experience (DX). Bez dobrého DX není dobré UX. Dělat interaktivní aplikace díky React programming modelu bude mnohem snažší a nutné. Představte si, kdybyste programovali drona pomocí jQuery a Angularu — asi byste měli velkou spotřebu dronů. Celé to souvisí s funkcionálním programováním, a tady bych předal slovo Guillermu Rauchovi a jeho Pure UI.

Martin Michálek

Kam půjde webdesign si netroufám říct, protože nic jako „jeden webdesign” už dlouho neexistuje. Máme tu prezentační weby, eshopy, mikrosajty, webové aplikace, mnoho platforem a způsobů tvorby. Zjednodušování dává ve spoustě segmentů smysl. Stejně jako v některých segmentech dává smysl použít Bootstrap nebo – nedejbože – tabulkový layout nebo – ach né! – Flash. Je to jako u natáčení kamerou, webdesign je plný žánrů. Příští érů tedy vidím jako „Éru současné platnosti všech ér”.

Richard Fridrich

Netrúfam si tipnúť, ako bude web vyzerať za pár rokov. Dúfam, že ostane rovnako rôznorodý ako dnes.

Čo by som ja osobne uvítal, by bola lepšia sémantika stránok, aby bolo ľahšie oddeliť obsah od formy. Zvykol som si čítať obsah z webu vo vlastnej čítačke, na zariadení ktoré mám práve po ruke, kde je text naformátovaný tak, ako to vyhovuje mne. Niektoré weby sa mi to snažia komplikovať, nútia ma ísť priamo na ich web, kde čakajú, že budem konzumovať nečitateľný text obalený reklamou. Pevne verím, že je to slepá vývojová vetva.

Úplne ideálne by podľa mňa bolo, keby existovali dve veci: Na jednej strane zdroje obsahu rôznych typov (texty, galérie, videá, čo ja viem to ešte), kde by sa vôbec nepárali s tým, ako ten obsah bude naformátovaný. Dôležité by bolo, aby to bol obsah kvalitný. Na druhej strane by boli rôzne čítačky a prehliadačky obsahu. A tie by zas nezaujímalo, aký obsah v nich zobrazujem, dôležité by pre nich bolo, že sa mi ten obsah konzumuje, prechádza a vyhľadáva dobre. Jedno aj druhé by kľudne mohlo byť platené.

A co si myslíte vy?

Komentáře

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

Nevím, řekl bych, že Material design je jeden z mnoha pohledů na design, nepřijde mi to jako nějaký „vývoj“ natožpak něco co vydrží léta než se to okouká.

Jo a ten Steigerwald zní tak nějak…jak to říct…omezeně. Ale tak v IT není sám…

Oldis

Jestli se realitou stane vyvoj webu ciste v JS, prejdu do jine oblasti. JS je účinný právě tam kde je, stejně tak php. Zde je sjednocení kontraproduktivní.
(upozorňuji že jde o můj názor, nikoliv že si myslím že je to absolutní pravda)

Oldis

Myslím účinnost při programovaní, efektivita běhu moje zákazníky příliš nezajímá, zajímá je kolik je bude stát vývoj. Čili to kolik hodin vývojem strávím.
A rozvedu to dál, v JS se napíše hodně omáčky, zvlášť když má být problém/úkol zabalen, být modulární.
V php rozložím, zpracuju, a poskládám pole snáž než v JS. Ještě si stím můžu pomoct implementací rozhraní pro práci s polem, které tedy ještě není dokonalé ale pro přístup při procházení stačí.
A u toho výkonu se pak můžeme bavit o tom že php zpracujeme na bytekód a provádět budeme ten.
Ale tak záleží na koho je článek zaměřen, na lidi co dělají pár velkých projektů celou karieru, a tedy jim a jejich zákazníkům u velké applikace záleží i na spotřebě a nebo na lidi kteří sekají malé a střední projekty, které si pak žijí vlastním životem?

Oldis

Ano jsem již trochu nemoderní, používám eclipsu, zatímco celý svět přešel na netbeans. Spíš jsem myslel že php vývojář toho v jistých specifických úlohách, a hlavně v serverové části nemusí psát tolik.
foreach(item as key => val){
}
pole.forEach(function(item){
}, context);
v php je toho o torchu min a je tu zasadni rozdil, key muze byt cokoliv cili mam mapu a ne automaticky indexovane pole, coz je docela benefit.
ale jako oboje je pokrok proti c++, v tom by se člověk upsal.

Oldis

O tom se tu i psalo ze? Tak ano znám CoffeeScript. Nemám dvaceti členný tým kde bych ho půlku mohl dislokovat na migraci na novější hype technologie, a sám na to nemám čas. Už jen proto že sem dice freelancer ale to ve svém volnu, jinak jsem zaměstnanec, a tam co dělám děláme ještě v 10 let starém prostředí :)
Ale řekněme si to na rovinu, rozpitvavame Steigerwalda, protoze placnul dogmatickej blábol.
Vraťme se k designu. na Flatu je sice hezka myslenka a pokus o radikalni reseni ale informace splývají, material je podle mne lepsi, momentalne ho implementuji :D

Matto

Osobne by som dal tym izomorfnim aplikaciam (IMA) viac priestoru a viac sanci. Nevidel by som to teda tak, ze niekto strati ci ziska pracu. Myslim si akurat ze je to zaujimava cesta, ktora riesi mnoho problemov, a samozrejme i prinasa. Ale to je na inu diskusiu. Preto vznikaju rozne nastroje, ktore tieto problemy riesia. My v tyme sa momentalne hrajeme s IMA.js ( https://github.com/seznam/IMA.js-skeleton ), co je jeden takyto nastroj ceskej vyroby (od Seznamu). A myslim si ze stoji za zmienku i za vyskusanie.

Vojtěch Mikšů

Blízká budoucnost bude asi patřit univerzálnímu JavaScriptu, už minimálně proto, že má v prohlížečích totální monopol a 100% neinteraktivní stránky se už moc nenosí. Už i vizitkové weby bývají plné různých animací a jiných srandiček.

Zásadním problémem je ale současná komplexnost JS nástrojů, kvůli které většina vývojářů nedošla dál než k jQuery, což je velká škoda. Doufám a věřím, že se tohle v příštím roce až dvou razantně zlepší (je vidět spousta aktivity v tomhle směru). Skvělé nástroje už máme, jen je potřeba je udělat více dev-friendly. Jakmile vývojář jednou přeskočí vstupní bariéru knihoven jako Webpack, Babel či React, tak se už zpět jentak neohlédne. Je to totiž těžce návykové, zábavné a i produktivní.

Oldis

Rekneme si za rok, či za dva.

Já

Pockat a jak dlouho uz ten monopol v prohlizecich ma? Ten javascriptovej hype je jako s flashem, driv kazdej potreboval hejbaci prezentaci nejlepe s hudbou v pozadi, dneska zase kazdej potrebuje appku, ktera se stahuje pul minuty protoze je napsana ve frameworku kterej je zrovna cool (a za rok nebude).

Jaroslav Bereza

Měl by někdo odkaz na jednoduchý a srozumitelný článek, jak funguje diffing kódu pomocí ract.js viz zmínka ve článku?

Jinak můj pohled na budoucnost je, že by se Microsoftu mohlo podařit rozšířit co nejvíce win10 s prohlížečem Edge a bude se držet politiky, častých updatů na pozadí bez možnosti odmítnout. A pokud bude chrlit verze stejně rychle jako Chrome a Firefox, tak se budeme mít skvěle a výrazně se zkrátí čas, kdy budeme moci použít nové technologie na webu.

Jsem také zvědavý, jestli se prosadí javascriptový bytecode. Myslím, že svoje místo by si našel. https://en.wikipedia.org/wiki/WebAssembly

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.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.