Chat, živé notifikace, společná úprava dokumentu nebo průběžně aktualizované kurzy. Uživatelé dnes čekají, že se webová aplikace změní ve chvíli, kdy se změní data, a ne až po stisknutí klávesy F5. Protokol WebSocket je nejrozšířenější způsob, jak mezi prohlížečem a serverem vytvořit trvalý obousměrný kanál. V článku se podíváme, jak funguje pod kapotou, jak ho použít v prohlížeči i na serveru a na co si dát pozor při nasazení do produkce.
Rozbalovací menu, tooltip, modální okno a plynulý přechod mezi stránkami. Ještě nedávno čtyři důvody, proč do projektu přidat několik knihoven a desítky kilobajtů JavaScriptu. V roce 2026 už to všechno zvládne prohlížeč sám. Ukážeme si, jak na to s Popover API, CSS anchor positioningem a View Transitions, a také kde mají své limity.
Před rokem začal registrem npm procházet samošířící červ Shai-Hulud. Od té doby se útoky na dodavatelský řetězec JavaScriptu staly pravidelnou záležitostí a npm postupně přepisuje pravidla publikování. Projdeme, co se za ten rok stalo, jak dnes bezpečně publikovat balíček, co musíte stihnout do ledna 2027 a jak se bránit jako uživatel balíčků.
Je dobře, že kvůli věcem bez velkých nároků na výkon (grafy, reklamy, …) se už nemusí startovat plugin. Ale má-li Canvas nahradit Flash ve všech aplikacích, včetně her, musí vyřešit tohle:
„Probably the biggest difference between Canvas and Flash is the level of abstraction available. Canvas is really just a low-level 2D graphics API. There are no objects or layers or groups…“.
To, co Flash řeší nativně (příp. i s HW akcelerací, což je aktuální priorita na mobilech), se musí v Canvasu řešit JS knihovnami, což logicky vede k: http://zdrojak.root.cz/zpravicky/porovnani-rychlosti-animacnich-technik/.
Zatím mi není jasné, jestli má Canvas vůbec takové ambice nebo chce náročnější aplikace navždy přenechat pluginům…
Ambice canvasu jsou „docela velké“, viz například (neúplný) port Processing do JS: http://processingjs.org. (Např. port generativního Substrate od Jareda Tarbella: http://processingjs.org/learning/custom/substrate)
Největší zádrhel z praktického hlediska je skutečně v tom, že na rozdíl od Flashe (anebo SVG, …) vytvořený grafický prvek není žádný objekt, k němuž lze přistupovat, věšet na něj handlery událostí, příp. ho z canvasu odstranit, atd.
To je hezky vidět i v diskusi na blogu Githubu, kde se mnoho lidí ptá, proč @mojombo nepoužil SVG, resp. Raphael.js. Ten umožňuje daleko smysluplnější práci s grafickými objekty, viz např. http://raphaeljs.com/github/impact.html, výkonnostně ale za Flashem a canvasem (zatím?) strašně pokulhává: http://www.themaninblue.com/writing/perspective/2010/03/22/ (linkováno v diskusi na Githubu). Pro mně osobně (=subjektivně) je práce s Raphael.js balzám. Je to snesitelně rychlé, je to „normální JS programování“ s využitím jQuery/Prototype/Underscore/etc, Firebug funguje jako debugger, …
Jo, jo. V tomto světle se i to, co se zdálo na první pohled jako úsměvná kuriozita – Flash runtime implementovaný v JS (http://ajaxian.com/archives/gordon-flash-runtime-implemented-in-javascript) přestává zdát kuriozitou, protože to je vlastně nejefektivnější způsob (v tom smyslu, že je prakticky stejně efektivní jako jakýkoliv jiný), jak přejít od Flashe ke Canvasu (s výhodou setrvání u osvědčených nástrojů a pokročilého jazyka).
To, co se Flashi po celá léta vytýkalo, buď zůstává (nepoučený tvůrce bude všechno „malovat“ místo aby strukturoval dokument) nebo se dokonce ještě zhoršuje (další mezivrstvy interpretovaného kódu, další nenažranost).
Ještě pro upřesnění – výše odkazovaný projekt Gordon nerenderuje do Canvasu, ale do SVG, výše uvedená úvaha platí pro potenciální obdobu takové knihovny, která by pracovala s Canvasem (což by bylo v jejím případě asi smysluplnější).