phpFashion

Na navigaci | Klávesové zkratky

Rubrika Web

Psát isomorfní webové aplikace?

Isomorfní webové aplikace jsou takové, které sdílejí kód mezi serverovou a klientskou stranou. Jinými slovy, jsou obě strany psané v JavaScriptu. I když tak to vůbec nemuselo být, historie je zajímavější.

Úplně poprvé jsem se s touto koncepcí setkal před (fíha, to je neuvěřitelné) takřka 20 lety. Vlastně JavaScript přímo vznikl jako client-side i server-side jazyk, serverové prostředí se jmenovalo Netscape LiveWire a kód vypadal nějak takto. Šlo tedy o mix HTML a JavaScriptu, jen s tím rozdílem, že skript se vykonával na serveru. JavaScript byl zamýšlený jako jazyk pro amatérské programátory, jako konkurent tehdejšího PHP a Microsoftího ASP, zatímco pro profesionály tu byla client-side a server-side Java.

Nic nedopadlo podle očekávání. Kvůli soudním sporům Java z prohlížečů zmizela, ke konci se držela už jen v porno chatech a bankovnictví, a dnes je z ní jeden velký bezpečnostní kráter distribuovaný jako adware, který je nutno v prohlížečích vypínat. Neuspěl ani JavaScript na serveru, protože byl příliš nezralý a nevhodný na takové nasazení a serverové řešení upadajícího Netscape nezískalo popularitu.

Vývoj webů na mnoho let zbrzdilo šílenství okolo specifikací začínajících na X a monopol Internet Exploreru, ale pak došlo k jejich svržení a máme tu hromadu nových technologií. A s tím se pochopitelně vrací i otázka jednoho jazyka na obou stranách. Odstartoval to zejména výkonnostně nadupaný interpret JavaScriptu z Google Chrome a platforma Node.js.

Situace je dosti jiná, než před 20 lety:

  • server-side technologie ušly obrovský kus cesty a vyzrály
  • client-side prožívá pubertu
  • v průniku jazyků je pouze JavaScript

Tvorba webů pomocí serverových frameworků se stává komoditou, na řadu složitých otázek odpovídají zažité návrhové vzory. Na straně klienta to naopak bují, dnešní novinky nejspíš brzy nahradí novinky jiné, a to se ještě několikrát zopakuje. Tenhle stav je fajn, dohání se dlouhé zpoždění a máte šanci se zapojit a odvětvím pohnout.

Dohání také JavaScript, leč jeho skutečnou pozici nejlépe charakterizuje potřeba a popularita nejrůznějších nadstaveb, ať už jde o CoffeeScript, Google Closure Compiler nebo TypeScript. Pomocí nich už dnes lze z JavaScriptu udělat něco celkem robustního, což ale ve skutečnosti stále není. Přičemž jazyky s ambicí jej nahradit existují.

Osobně mi cesta k izomorfním aplikacím připadá přirozená a správná. U klientského skriptování jsem začínal a stále hledal různé spojnice, například Nette má dosud poměrně ojedinělou vlastnost, že pravidla pro validaci formulářů zapsaná na straně serveru vám automaticky překlopí na stranu prohlížeče. Isomorfní validace formulářů od roku 2008.

Ale v žádném případě bych si isomorfně nenechal naprogramovat třeba e-shop. Zatím.

Příliš mladé prostředí znamená absenci zažitých návrhových vzorů a různá rizika. Když si Dan Steigerwald, který pro mě částečně pochopitelně odmítá jakékoliv problémy této technologie připouštět, si tuhle posteskl, že čeští vývojáři jsou pozadu za frikulíny ze San Francisca a stále se drží serverových technologií, rozjela se diskuse o výhodách a nevýhodách jednotlivých přístupů a Dan jako odpověď na jednu námitku poslal příklad webu (tuším jeho kolegů) iodine.com psaný v React.js. Čímž poskytl pěkný příklad neduhů SPA/isomorfních aplikací:

  • na webu nefunguje správně tlačítko zpět
  • na mnoha různých URL se nachází identický obsah
  • jeho výroba byla násobně dražší

Zdůrazňuji, že z jeho stany nešlo o ukázkový příklad, nicméně tím lépe demonstruje hlavní problém SPA/isomorfních aplikací: udělat je dobře je stále velmi těžké a potažmo drahé. Přičemž tentýž web za použití server-side frameworku, jako je například Nette, zvládne napsat i průměrný a levný programátor. A podobných hrubek se přitom nedopustí.

Izomorfním aplikacím se nevyhýbejte, zkoušejte si novinky, zavčasu odhalujte slepé cesty, rozšiřujte si obzory. Ale s ostrým nasazením se držte jen u typů aplikací, kde je to skutečně nutné a výhodné. Není jich zase tolik.

Navíc nemáte v žádné žhavé technologii jistotu. Tvrdit opak, třeba proto, že za nějakou z nich stojí obří firma, znamená být slepý k historii posledních 20 let.


Kdy používat preprocesory a kdy ne?

Složitá otázka, těžké kodérovo dilema, které se pokusím rozseknout: používejte preprocesory vždy!

Jak se Internet přesunul do mobilů, staly se největší zabijáci rychlosti načítání stránek tyhlety úhledné sloupečky:

<link rel="stylesheet" href="/css/reset.css">
<link rel="stylesheet" href="/css/content.css">
<link rel="stylesheet" href="/css/layout.css">
<link rel="stylesheet" href="/css/screen.css" media=screen>
<link rel="stylesheet" href="/css/fancybox/jquery.fancybox.css" media=screen>
<link rel="stylesheet" href="/css/print.css" media=print>
<script src="/js/jquery.js"></script>
<script src="/js/jquery.autocomplete.js"></script>
<script src="/js/fancybox/jquery.fancybox.js"></script>
<script src="/js/tooltips/jquery.tooltips.js"></script>
<script src="/js/jquery.scrollspy.js"></script>
<script src="/js/main.js"></script>

To nechceš! Chceš tohle:

<head><link rel="stylesheet" href="/assets/combined.css"></head>

<body>
...
<script src="/assets/combined.js"></script>
</body>

Taky chceš, aby se ti všechny soubory posílaly zazipované a vypadaly hutně: combined.css a hustě: combined.js.

Byly doby, kdy se komprimované skripty psaly ručně. Vynechávaly se komentáře, v JavaScriptu používaly jednopísmenné proměnné atd.

Nedělejte to. Vaším úkolem je psát čitelný kód a komprimování JavaScriptu nechte na bedrech Google Closure Compiler, který to dokáže řádově lépe než vy a navíc upozorní na chyby, o minifikaci stylů se postará například Less.

Ten dokonce zvládá vychytávku, kdy u všech miniobrázků můžete nahradit:

textarea {
    background: #fff url("img/input.gif") repeat-x;
}

za

textarea {
    background: #fff data-uri("img/input.gif") repeat-x;
}

a preprocesor je přímo vloží do combined.css, čímž odpadne hromada HTTP requestů na 100bajtové drobky.

Preprocesory prostě a jednoduše chcete!


SASS, LESS, Stylus or pure CSS? (3)

Journey into the heart of the three most known CSS preprocessors continues, though not in the way I originally planned.

CSS preprocessor is a tool that take code written in their own syntax and generates the CSS for the browser. The most popular preprocessors are SASS, LESS and Stylus. We have talked about installation and syntax + mixins. All three preprocessors have a fundamentally different way of mixins conception.

Each of them have gallery of finished mixins: For SASS there is a comprehensive Compass, the LESS has framework Twitter Bootstrap or small Elements a Stylus NIB.

… this was opening sentences of article I started write year and quarter ago and never finished. I came to the conclusion that all three preprocessors are useless. They required to do so many compromises that potential benefits seemed insignificant. Today I will explain it.

…pokračování


SASS, LESS, Stylus nebo čisté CSS? (3)

Cesta do nitra tří nejznámějších CSS preprocesorů pokračuje, i když ne tak, jak jsem původně plánoval.

CSS preprocesor je nástroj, který vám ze zdrojového kódu zapsaného ve vlastní syntaxi vygeneruje CSS pro prohlížeč. Mezi nejznámější patří SASS, LESS a Stylus. Ukázali jsme si, jak je nainstalovat a naťukli téma syntaxe a mixinů. Všechny tři preprocesory nabízejí fundamentálně rozdílný způsob, jak programovat s mixiny. Každý je v tom jinak konzistentní a každý umí být jinak matoucí.

Pro každý preprocesor existuje galerie hotových mixinů, do kterých nahlédněte přinejmenším k posouzení jejich srozumitelnosti. Pro SASS existuje komplexní Compass, LESS má framework Twitter Bootstrap nebo drobné Elements a Stylus NIB.

…tak takhle začínal článek, který jsem rozepsal před rokem a čtvrt a nikdy nedokončil. Přišel jsem totiž k závěru, že všechny tři preprocesory jsou, alespoň zatím, nepoužitelné. Jejich nasazení by představovalo tolik ústupků, že by se vedle nich potenciální výhody dočista ztrácely. Dnes to vysvětlím.

…pokračování


Objeví Rails Dependency Injection?

Málokdo má takovou potřebu zdůrazňovat svou domnělou nadřazenost, jako právě Railisti. Abyste mě nechápali špatně, jde o dobrou marketingovou strategii. Nepříjemné je, když jí podlehnete do té míry, že zbytek světa vnímáte jen jako upachtěné kopírovače bez šance se vám někdy přiblížit. Svět takový totiž není.

Příkladem je Dependency Injection. Zatímco lidé kolem PHP nebo JavaScriptu objevili DI se zpožděním, Ruby on Rails zůstávají dosud nepolíbené. Bylo mi záhadou, proč framework s tak pokrokovou image zůstává kdesi pozadu a začal v tom pátrat. Odpověď mi dala řada zdrojů na Google nebo karmiq a zní:

Ruby je tak dobrý jazyk, že vůbec Dependency Injection nepotřebuje.

Fascinující argument, který je navíc v elitářském prostředí sebepotvrzující. A je skutečně pravdivý? Nebo jde jen o zaslepení pýchou, stejné zaslepení, jaké způsobilo nedávno přetřásané bezpečnostní díry v Rails?

Říkal jsem si, že je možné, že Ruby znám natolik málo, aby mi nějaký klíčový aspekt unikl, a že skutečně jde o jazyk, který DI nepotřebuje. Jenže primárním smyslem Dependency Injection je zřejmé předávání závislostí, aby byl kód srozumitelný a předvídatelný (a je pak i lépe testovatelný). Jenže když se podívám do dokumentace Rails na tutoriál „blog za pár minut“, vidím tam třeba:

def index
  @posts = Post.all
end

Tedy pro získání blogpostů používají statickou metodu Post.all, která odněkud (!) vrátí seznam článků. Z databáze? Ze souboru? Vyčaruje je? Nevím, protože se tu nepoužívá DI. Místo toho se tu vaří nějaké statické peklo. Ruby je bezesporu šikovný jazyk, ale DI nenahrazuje.

V Ruby lze za běhu přepisovat metody (Monkey patch; obdobně jako v JavaScriptu), což je forma Inversion of control (IoC), která třeba pro potřeby testů dovolí podstrčit jinou implementaci statické metody Post.all. Tohle ale nenahrazuje DI, kód to zřejmější neudělá, spíše naopak.

Mimochodem, zaujala mě i třída Post tím, že reprezentuje jak jeden článek na blogu, tak funguje jako repozitář (metoda all), což je porušení Single Responsibility Principle jako vyšité.

Jako odůvodnění, proč Ruby nepotřebují DI, se často odkazuje na článek LEGOs, Play-Doh, and Programming. Důkladně jsem ho pročetl, sledoval, jak autor párkrát zaměňuje „DI“ s „DI frameworkem“ (tedy něco jako zaměňovat „Ruby“ s „Ruby on Rails“) a nakonec zjistil, že k závěru, že Ruby Dependency Injection nepotřebují, vůbec nepřišel. Psal, že nepotřebují DI frameworky, jaké zná z Javy.

Jeden mylně interpretovaný závěr, pokud pohladí ego, dokáže zcela pobláznit obrovskou skupinu inteligentních lidí. Nakonec mýtus, že špenát obsahuje neobyčejné množství železa, se taky drží od roku 1870.

Ruby je velmi zajímavý jazyk, vyplatí se v něm jako v každém jiném používat DI a existují pro něj i DI frameworky. Rails je zajímavý framework, který zatím neobjevil DI. Až ho objeví, půjde o velké téma některé z příštích verzí.

(Po pokusu diskutovat o DI s Karmim, kterého pokládám za nejinteligentnějšího Railistu, nechávám komentáře uzavřené, omlouvám se.)

Viz také: Dependency injection není pouze o jednoduším testování

před 2 lety v rubrice Web | shlédnuto 15298×