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

Zdroják » JavaScript » Jak se mění svět JavaScriptu

Jak se mění svět JavaScriptu

Články JavaScript

Před více než 3 roky jsem zde začal psát seriál, jehož ústředním tématem byl především JavaScript a Node.js, ale také Angular a řada dalších technologií. Jak se JavaScript od té doby změnil?

Nálepky:

JavaScript a ES6

JavaScript se výrazně proměnil s příchodem nových verzí ECMAScriptu (ES). Změn je opravdu hodně. Pro mě osobně je nejpříjemnější novinkou arrow funkce, deklarace proměnné přes const, práce s moduly a doplnění async funkcí pro řešení asychronního běhu programu. Pro mnoho jiných bylo nejdůležitější doplnění tříd. Před rokem zde psal Jakub Vrána článek Co se mi nelíbí na JavaScriptu, řada ze zde zmíněných bodů už neplatí.

Abychom nemuseli čekat několik let, než se ES6 dostane do prohlížečů, vznikl projekt Babel, který umí převést kód psaný v ES6+ do ES5, a tedy je možné všechny novinky používat už dnes. Příchod Babelu bude také nejspíš znamenat snižování ochoty vývojářů používat jiné jazyky, které se kompilují do JavaScriptu, protože bude jistější používat něco, co je standardizované a co tady bude i za pár let. JavaScript tady bude určitě i za 5 let, zda tady za 5 let bude i LiveScript, to nikdo neví.

V Node.js 5 je podpora ES6 velmi dobrá a mnohé novinky z ES6 je možné používat i bez transpileru, případně použít preset es2015-node5, který doplní to, co Node.js 5 a V8 zatím nepodporuje.

Změnil se také proces, podle kterého se budou dostávat nové věci do prohlížečů. Na ES6 jsme museli čekat dlouhých 6 let, proto byla změna nutná. Nyní bude vznikat každý rok nová verze, více si o tom můžete přečíst v článku The TC39 process for ECMAScript features.

Já budu používat Babel na serveru ještě chvíli, dokud nebude doplněna podpora pro async funkce přímo do Node.js, což by mohlo být už tento rok (aktuálně jsou ve 3. fázi candidate a do V8 se už implementuje). Další plánované novinky už pro mě nejsou tak významné a raději se jich ještě na nějakou dobu vzdám výměnou za to, že odstraním mezistupeň v podobě Babelu. V případě prohlížečů je to jinak, zde se stane Babel součástí všech projektů na několik dalších let, než uživatelů opustí staré prohlížeče.

Verze ES6 je skvělá a odstranila velké množství problémů, na které si lidé dlouho stěžovali. JavaScript se tím výrazně proměnil a je použitelnější pro širší spektrum uživatelů. Jen mám trochu obavy z toho, aby se díky rychlejšímu procesu zavádění novinek do jazyka nedostávaly věci, které tam být nemusí, a které přinesou spíše více komplikací. Kupříkladu decoratory, bez kterých bych se obešel. Ty jsou však v 1. fázi schvalování (návrh) a nemusí se do jádra dostat, jako to bylo třeba u metody Object.observe(), která byla zavržena, když byla ve 2. fázi schvalování.

Node.js a io.js

Node.js také prošlo řadou velkých změn. Kvůli sílící nespokojenosti s tím, jakým způsobem se Node.js vyvíjí, vytvořila skupina vývojářů Node.js fork pod názvem io.js, kde vývoj probíhal podstatně rychlejším tempem. V květnu minulého roku se k všeobecné radosti oba projekty spojily dohromady pod organizací Node Foundation.

Hlavním důvodem pro vytvoření io.js byl model, v jakém se projekt Node.js řídil, kdy mělo malé množství lidí konečné slovo o tom, jaké úpravy se do jádra dostanou. Proto dva roky trvalo, než se Node.js dostalo z verze 0.10 do 0.12 a Node.js bylo dodáváno se starou verzí V8, která už nebyla podporována, bez novinek z ES6 a bez řady vylepšení, které se týkaly bezpečnosti a výkonu. Nově Node.js vzniká pod otevřeným modelem řízení a Joyent už dále není vlastníkem Node.js.

Od té doby vývoj pokračuje rychle a nyní je Node.js ve verzi 5.5 a má více než 800 přispěvatelů do jádra (těch, co poslali Pull Request). Node.js se stalo superbezpečné a změnil se také způsob, jakým budou vydávány nové verze. Každý rok vyjde nová major verze, vždy v dubnu a říjnu, z nichž jedna bude podporována po dobu 30 měsíců (sudá) a druhá (lichá) jeden rok. Podpora znamená, že zde nebudou žádné breaking changes. Jestliže tedy vyjde v dubnu Node.js 6, tak do konce roku 2018 na ní může váš projekt fungovat a máte jistotu, že budou řešeny všechny bezpečnostní a výkonnostní problémy, které se případně objeví. Tahle změna byla důležitá především kvůli enterprise prostředí. Pro více informací doporučuji přednášku Convergence: Evolving Node.js with Open Governance and an Open Community z nedávné konference Node.js Interactive.

Vzestup popularity Node.js je naprosto nevídaný a pokud se nemýlím, žádný jazyk/prostředí pro vývoj aplikací nikdy nezískal tak rychle tak velkou popularitu. Když jsem před cca 4 roky s Node.js začínal, bylo k dispozici zhruba 2 tis. balíčků a přišlo mi to jako velké číslo. Dnes už jich je téměř čtvrt milionu, což je zdaleka nejvíc ze všech jazyků. Jen za minulý rok bylo staženo 25 miliard balíčků a balíčkovací systém npm spravuje stejnojmenná firma o 27 zaměstnancích. Alespoň jeden npm balíček vytvořilo už 60 tis. lidí a každý den je publikováno přibližně 400 nových balíčků (cca 4x více než třeba u PHP). Tato čísla uvádním proto, aby bylo vidět, jak rychle roste počet vývojářů, kteří Node.js používají. Také je vidět, jak silný argument „jeden jazyk pro všechno“ je. Jazyk se dá upgradovat snadno, mozek nikoliv. Vypadá to, že JavaScript je „good enough“ pro většinu aplikací, které dnes vznikají.

Node.js postupně také proniká do enterprise prostředí. Můžete se podívat na přednášky o tom, jak se Node.js používá v Netflixu, v Uberu nebo třeba v PayPalu.

Na začátku ledna zveřejnil Microsoft ChakraCore, zdrojové kódy js enginu, který je součástí MS Edge, a krátce na to od něj přišel pull request na přidání ChakraCore do Node.js. V8 by byl stále výchozí, ale uživatelé by si mohli vybrat, který z obou enginů chtějí použít.

Izomorfní a univerzální aplikace

V době, kdy oba seriály vznikaly, začaly vznikat single-page aplikace, které mohly přinést množství výhod, ale také dva problémy: aplikace byly špatně indexované a problematické byly na mobilních telefonech, protože trvalo dlouho, než se aplikace načetla. Tohle z velké části vyřešily izomorfní aplikace pracující s virtuálním DOMem, který umožňuje stránku snadno vygenerovat na serveru a poslat ji do prohlížeče. Tak vidí crawler bez JavaScriptu stejnou stránku jako uživatel s JavaScriptem. Výhoda je také v tom, že uživatel ihned může se stránkou pracovat, zatímco se na pozadí vytváří instance frameworku.

V letošním roce se místo pojmu„izomorfní“ začalo říkat „univerzální“. Díky React Native je možné psát aplikace v JavaScriptu i pro mobily tak, že využívají jejich nativní API. Populární je také Electron, přes který jde psát pomocí Node.js klasické desktopové aplikace a je v něm napsaný třeba editor Atom.io nebo klient pro Slack.

Isomorfní aplikace začínají být velice populární. Příkladem je třeba AirbnbNetflix nebo nová verze Uber, která kombinuje Node.js a React podobně jako Netflix.

Express

Framework Express byl v době psaní seriálů zdaleka nejpoužívanějším frameworkem pro psaní Node.js aplikací a nejinak to je i dnes. Na Expressu se mi velmi líbí jeho minimalistické pojetí, celý framework bez middleware tvoří jen 12 krátkých souborů v JavaScriptu, které jsou velice dobře dokumentované, takže když potřebuji něco vědět, je pro mě rychlejší podívat se přímo do zdrojového kódu než do dokumentace.

Express je už nějakou dobu spravován firmou StrongLoop, která nad ním staví framework LoopBack. Zajímavé je, že StrongLoop nedávno koupila firma IBM. O tom, proč se rozhodla známá IBM investovat do Node.js, byla přednáška The World is being Reinvented in Code.

Kromě Expressu stojí za zmínku framework Koa, kterou vytvořil a spravuje v Node.js komunitě velmi známý TJ Holowaychuk. Koa framework je stejný jako Express, liší se jen tím, že používá ES6 generátory. Já se velmi těším na vydání Koa 2, která bude pracovat s async funkcemi. Nyní je v alfě, jakmile budou async funkce i v Node.js, bude Koa 2 i v Este.js.

Ještě by bylo dobré zmínit framework Restify, který si pro API vybral Netflix.

Další nástroje

Na konec zmíním ještě některé nástroje, které jsem v seriálu používal.

Dnes už bych nepoužil task runner Grunt, misto toho bych si vybral Gulp. Rozdíl mezi nimi je v tom, že první preferuje konfiguraci nad kódem, u druhého je to naopak. Gulp si tedy budou vybírat spíše programátoři, Grunt se hodí více třeba pro CSS kodéry.

Pro kontrolu kódu jsem používal JSHint, dnes už se všude používá ESlint, který se dá výborně upravit podle potřeb každého projektu.

V seriálu jsem pro správu klientského kódu používal Bower, protože řada javascriptových knihoven pro client-side nebyla v npm. Dnes už je situace jiná, kód se píše úplně stejně jak pro klienta, tak pro server a snad všechny knihovny kódu jsou i v npm, takže už stačí npm na všechno a Bower už není potřeba.

Dnes bych do projektu doplnil ještě Webpack, module bundler, který umí dohromady poskládat celý projekt (nejen JavaScript) a stal se dnes už standardem.

Problémy současného vývoje

Zatímco na serveru mi Node.js dělá velkou radost a cítím se s ním mimořádně produktivní, v případě vývoje klientské části webu to tak úplně neplatí. Příště, v druhé části shrnutí, se budu věnovat problémům (a možným řešením), které souvisí s vývojem SPA a izomorfních aplikací.

Komentáře

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

Díky Jakube za skvělý článek. Možná bych doplnil, že i Microsoft ve velkém sází na Node.js. Jeho Visual Studio Code je postavené na Electron-u a taky „zbrusu nové“ ASP.NET 5 se vidatně inspiruje u Node.js a open source. Nově se používá Yeoman pro generování kódu, Gulp pro bundling CSS a JS, npm a Bower pro balíčky a přichází také s podporou middleware.

zajca

Výborný článek vidím to podobně, jen bych určitě zmínil TypeScript, ten má před sebů zdárnou budoucnost a verze 2.0 s async/await až do es3 bude velká věc, dnes používat Typescript+babel je takové těžkopádné.
NodeJS po spojení s iojs chytil taky druhý dech, jediné co ve světě javascriptu v poslední době není tolerováno je zdrženlivost a pomalý vývoj.
Ještě si myslím, že do node frameworků má co mluvit HapiJS, Walmart u nás sice nefrčí, ale hapi evidentně věří.
+ v nástrojích stojí za zmínky rollup.js a fly.js a webpacku pořád zdatně konkuruje browserify.

Radek Miček

ten má před sebů zdárnou budoucnost a verze 2.0 s async/await

Bohužel se async/await uchytil a mnoho jazyků jej přidává, i když je to často na úkor znovupoužitelnosti kódu.

Frontstart

TypeScript se s čím dál větší podporou ES6 na indexech popularity propadá čím dál níž. Osobně bych mu nějakou zářivou budoucnost nevěštil, jako mnohem pravděpodobnější vidím vzestup popularity kombinace ES6/Flow. Ale to uvidíme až za pár let.

uetoyo

Kupříkladu decoratory, bez kterých bych se obešel.
Můžeš prosím uvést důvody? Moje zkušenost z Pythonu je, že dost zpřehledňují kód.
Díky za článek.

.

Srigi

Tu je trocha iny pohlad na tento obor: The Sad State of Web Development.

Srigi
Marek Feuermann

Pevně doufám, že se v dalším díle rozebereš Meteor.JS :)

Josef Polymer Ninja

Google veri Polymeru, pres 300 google projektu na nem bezi, viz video…
https://youtu.be/jVn8tlnwAEs?t=4m37s

Kouknete treba na moji praci Polymer Starter Kit Plus, viz link…
https://github.com/StartPolymer/polymer-starter-kit-plus

Martin Jurča

Možno by stálo za to zmieniť IMA.js od Seznamu na izomorfné webové aplikácie:
https://github.com/seznam/IMA.js-skeleton

Setup chvíľu trvá, ale aplikácie sa v tom píšu pekne.

Miroslav Jančařík

Už nám na tom běží dvě služby
https://www.hry.cz/ a https://www.seznam.cz/vychytavky. Další se teprve píší a vyjdou během roku.

Petr Toman

Aplikace all-in-javascript jsou IMHO stále v první fázi „hype křivky“ a navíc je tu jistá podobnost s očekáváními u Javy (kdysi). Nabízí se otázka, jestli se JS stane „assemblerem“ pro web… každopádně má tentokrát na své straně podporu „operačního systému“ dneška, tj. prohlížeče.

Nicméně jsem se chtěl především zeptat, jak udržujete kód velkých JS aplikací. Umím si to představit za použití TypeScriptu nebo Kotlinu, ale u čistě dynamických jazyků mě nenapadá jiný/lepší způsob než vysoké pokrytí (unit) testy. Každopádně refactoring kvůli absenci typové kontroly bych viděl jako potencionální problém… Jsou nějaké vyzkoušené „best practices“?

Jan Kovář

Jediná výhoda JavaScripu oproti Jave apod. je že běží všude. Díky tomu odsune do zapomění všechny UI toolkity jako WPF, Swingy nebo sotva narozenou JavaFx. Nicméně tím z mého pohledu výhody končí. Programovat velký projekt na kterém za jeho životnost pracuje třeba 30 programátorů ve slabě typovém jazyku je podle mě sebevražda. Reps. vražda těch co budou můj kód číst. Rychlý refaktoring je nemožný. Copy&Paste nemožný a psát unit testy kvůli kontrole překlepů nehodlám.

Nicméně HTML/JS se při psaní frontendů za chvíli nebude možné prakticky vyhnout. Ale než transpilovat kus tady a kus tam, tak proč už netranspilovat všechno? Z nějakého rozumného jazyku s rozumnou podporou a vyhlídkou. Já aspoň na pár let vsázím svoji kariéru na Kotlin. I když doufám, že se neseknu jako s Adobe Flexem :)

Navíc JavaScript tady sice za pár let bude, ale už není tak jisté že tu bude i JavaScriptový framework který si dnes vybereme.

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.