Як воно вчити JavaScript в 2016



— Гей, я отримав новий веб-проект, але, якщо чесно, я не займався веб-кодингом протягом декількох років, і я чув, все трохи змінилося. Ти самий сучасний веб-розробник, правда?

— Це тепер називається Front-End інженер, але так, я — саме він. Я працюю з вебом в 2016. Візуалізації, музичні плеєри, літаючі дрони, які грають у футбол, все що завгодно. Я тільки що повернувся з JsConf і ReactConf, так що я знаю новітні технології для створення веб-додатків.

— Круто. Мені потрібно створити сторінку, яка відображає останні дії з боку користувачів, так що мені просто потрібно отримати дані від REST і відобразити їх в якийсь фільтрованої таблиці, ну і оновлювати її, якщо щось зміниться на сервері. Я думав, може бути, використовувати JQuery для отримання та відображення даних?

— О, Мій Бог! Ні! Ніхто більше не використовує JQuery. Ти повинен спробувати React: це — 2016!

— Цікаво. Що таке React?

— Це — дуже крута бібліотека, зроблена хлопцями з Facebook. Вона реально дає повний контроль і підвищує продуктивність програми, дозволяючи дуже легко обробляти будь-які зміни уявлень.

— Звучить заманливо. Чи можу я використовувати React для відображення даних з сервера?

— Ага, але спочатку потрібно додати React і React DOM у вигляді бібліотек.

— Почекай, чому дві бібліотеки?

— Ну, одна — це сама бібліотека, а друга — для маніпулювання DOM, який ти тепер можеш описати в JSX.

— JSX? Що таке JSX?

— JSX — це просто розширення синтаксису JavaScript, який виглядає дуже схоже на XML. Це свого роду ще один спосіб описати DOM. Думай про нього, як про покращеному HTML.

— Що сталося з HTML?

— Це 2016. Ніхто більше не пише на сирому HTML.

— Ну добре. Якщо я додаю ці дві бібліотеки, то я можу використовувати React?

— Не зовсім. Потрібно додати Babel, а потім можна використовувати React.

— Інша бібліотека? Що за Babel?

— О, Babel — це транспайлер, він дозволяє орієнтуватися на конкретні версії JavaScript, у той час як пишеш код в будь-яку версію JavaScript. Тобі не обов'язково додавати Babel для того, щоб писати на ReactJS, але якщо ти цього не зробиш, то ти застряг з ES5, ну а це 2016, ти повинен кодити в ES2016+ як і всі круті чуваки.

— ES5? ES2016+? Я загубився. Що за ES5 і ES2016+?

— ES5 означає ECMAScript 5. Це версія, на яку орієнтується більшість, оскільки вона реалізована в більшості браузерів на сьогоднішній день.

— ECMAScript?

— Так, знаєш стандарт JavaScript, який був заснований в 1999 році після його початкового випуску в 1995 році? Тоді, коли JavaScript був названий LiveScript і працював тільки в Netscape Navigator. Це було дуже заплутано тоді, але, на щастя, тепер все ясно, і у нас є 7 версій цієї реалізації.

— 7 версій. Серйозно. А ES5 і ES2016+ це?..

— П'яте і сьоме видання відповідно.

— Зачекай, а що сталося з шостим?

— ES6? Так, кожне видання є надбудовою попереднього, так що якщо ти використовуєш ES2016+, то ти використовуєш всі функції попередніх версій.

— Добре. А навіщо використовувати ES2016+ над ES6 тоді?

— Ну, ти можеш використовувати ES6, але для цікавих штук, типу async і await, тобі потрібно використовувати ES2016+. В іншому випадку ти застряг з ES6 генераторами і сопрограммами для блокування асинхронних викликів і нормального управління потоком.

— Я поняття не маю, що ти тільки що сказав, і всі ці імена заплутані. Слухай, я просто хочу завантажити купу даних з сервера, просто підключити JQuery з CDN і просто отримати дані за допомогою AJAX. Чому я не можу зробити це?

— Чувак, це 2016. Ніхто не використовує JQuery більше, це закінчується купою заплутаного коду. Всі це знають.

— Ясно. Так що моя альтернатива — це завантажити три бібліотеки для вилучення даних і відображення таблиці HTML.

— Ну, ти вмикаєш ці три бібліотеки, але пов'язуєш їх з менеджером модулів, щоб завантажити один файл.

— Зрозуміло. А що за менеджер модулів?

— Визначення залежить від навколишнього середовища, але для веба ми зазвичай маємо на увазі все, що підтримує модулі AMD або CommonJS.

— Хорошооооо. А AMD і CommonJS це?..

— Визначення. Є купа способів, щоб описати, як кілька бібліотек і класів JavaScript повинні взаємодіяти. Ти можеш написати кілька файлів JavaScript, визначають API AMD або CommonJS, і використовувати що-то на кшталт Browserify, щоб пов'язувати їх.

— Добре, має сенс… напевно. А що таке Browserify?

— Це інструмент, який дозволяє зв'язати CommonJS описанния залежностей для файлів, які можуть бути запущені у браузері. Він був створений, тому що більшість людей публікують ці залежності в NPM.

— NPM?

— Це дуже велике суспільне сховище, де розумні люди постять код і залежності у вигляді модулів.

— Як CDN?

— Насправді, ні. Це більше схоже на централізовану базу даних, де кожен бажаючий може опублікувати скачати бібліотеки, так що ти можеш використовувати їх локально для розробки, а потім завантажити їх на CDN, якщо захочеш.

— О, як Bower!

— Так, але це 2016, зараз ніхто більше не використовує Bower.

— Хм, ясно… так мені потрібно завантажити бібліотеки з NPM?

— Так. Наприклад, якщо ти хочеш використовувати React, то завантажуєш модуль React і импортируешь його в коді. Це можна зробити для майже кожної популярної бібліотеки JavaScript.

— О, це як в Angular!

— Angular це занадто 2015. Але так. Angular теж там є, поряд з VueJS, RxJS та іншими цікавими бібліотеками 2016. Хочеш дізнатися про них?

— Давай дотримуватися React, я вже дізнався дуже багато про нього. Так що, якщо мені потрібно використовувати React, я витягну його з цього NPM, а потім використовую Browserify?

— Так.

— Це здається занадто складним, щоб просто взяти купу залежностей і зв'язати їх разом.

— Ага, саме тому ти використовуєш менеджер завдань, типу як Grunt або Gulp, або Broccoli для автоматизації запуску Browserify. Ти навіть можеш використовувати Mimosa.

— Grunt? Gulp? Broccoli? Mimosa? Чорт візьми, про що ми говоримо зараз?

— Task менеджери. Але вони вже не такі круті. Ми використовували їх у стилі 2015 з Makefiles, але тепер ми перейшли на Webpack.

— Makefiles? Я думав, що в основному це використовується для C або C++ проектів.

— Ага, але, мабуть, в вебі ми любимо робити речі складними, а потім повернутися до основ. Ми робимо це типу щороку. Ти почекай, через рік чи два ми ще запилим збірки (assemblies) у вебі.

— Пффф. Ти згадав щось під назвою Webpack?

— Це інший менеджер модулів для браузера, в той же час він і свого роду Task менеджер. Це поліпшена версія Browserify.

— ГАРАЗД. А чому він краще?

— Ну, може бути не краще, але більш гнучкий в плані того, як залежно пов'язані. Webpack дозволяє використовувати різні менеджери модулів, а не тільки CommonJS. Наприклад, рідні модулі ES6.

— Я дуже заплутався в цих CommonJS/ES6.

— Та все в цьому заплуталися, але можеш більше не паритися, тому що є SystemJS.

— О, Боже, знову щось-JS. Добре, а що це за SystemJS?

— Ну, на відміну від Browserify і WebPack 1.x, SystemJS являє собою динамічний модуль завантажувача, який дозволяє зв'язати кілька модулів у декількох файлах, а не пов'язуючи їх в один великий файл.

— Почекай, я думав, що ми хотіли об'єднати наші бібліотеки в один великий файл і завантажити його!

— Так, але через HTTP/2 HTTP запитів насправді краще.

— Стояти! Так чого ж ми не можемо просто додати три оригінальні бібліотеки для React?

— Ти, звичайно, можеш додати їх в якості зовнішніх скриптів з CDN, але все одно потрібно буде додати Babel.

— Ех. І це погано, чи не так?

— Так, доведеться включити повністю Babel-core, а це не буде ефективним для production. На production необхідно виконати ряд попередніх завдань, щоб проект був повністю готовий, а це ритуал, в порівнянні з яким викликати диявола — це рецепт як зварити яйце. Треба буде мінімізувати файли, зробити uglify, погратися зі стилями, подумати про завантаження скриптів…

— Зрозумів, зрозумів. Але якщо не завантажувати бібліотеки безпосередньо з CDN, то як інакше?

— Я б зробив транспайл з TypeScript з допомогою комбо Webpack + SystemJS + Babel.

— TypeScript? Я думав, що ми пишемо код на JavaScript!

— Typescript — це і є JavaScript, або, краще сказати, надмножество JavaScript. Більш конкретно — JavaScript на версії ES6. Ну, та шоста версія, про яку ми говорили.

— Я думав, що ES2016+ — вже надмножество ES6! Чому нам зараз потрібен ще й TypeScript?

— Тому що це дозволяє нам використовувати JavaScript як типізований мова та зменшити кількість помилок під час виконання. Це 2016, треба додати деякі типи код на JavaScript.

— І TypeScript, очевидно, робить це.

— Flow і, хоча він перевіряє тільки типи, в той час як TypeScript є надбудовою JavaScript, який потрібно скомпілювати.

— Еее… та Flow?

— Це — інструмент для перевірки статичної типізації, зроблений хлопцями з Facebook. Вони написали його на OCaml, так як функціональне програмування є дивно крутим.

— OCaml? Функціональне програмування?

— Ну це те, що сьогодні юзають круті пацани, ну типу, знаєш, 2016. Функціональне програмування. Функції високого порядку. Currying. Pure функції.

— Я поняття не маю, що це.

— Ніхто не розуміє, на початку. Треба просто знати, що функціональне програмування краще, ніж об'єктно-орієнтоване програмування, і це те, що ми повинні використовувати в 2016 році.

— Почекай, я вчив ООП в універі, я думав, що це круто?

— Ну так було поки Oracle не купив Java. Я маю на увазі, що ООП був хороший раніше, і його використовують досі, але тепер кожен розуміє, що маніпулювати станами еквівалентно пинанню немовлят, так що тепер все рухається до immutable об'єктів і функціонального програмування. Хлопці з Haskell вже 100 років кричать про це, і це я ще не згадував Elm. Але, на щастя, в мережі тепер у нас є такі бібліотеки, як Ramda, які дозволяють нам використовувати функціональне програмування на простому JavaScript.

— Ти що, просто придумуєш імена? Що ще за Ramnda?

— Ні. Ramda. Як і Lambda. Ну, знаєш, бібліотека Девіда Чембера?

— Девіда кого?

— Девіда Чембера. Крутий чол. Один з авторів Ramda. Глянь ще роботи Еріка Мейєра, якщо серйозно ставишся до вивчення функціонального програмування.

— А Ерік Мейер це?..

— Теж функциональщик. Крутий чол. У нього є купа презентацій, де він в дивній кольоровий футболці громить Agile. Ще глянь що роблять Tj, Jash Kenas, Sindre Sorhus, Paul Irish, Addy Osmani…

— ГАРАЗД. Пригальмуй. Все це добре і чудово, але я думаю, що все це дуже складно і не потрібно для простої вибірки даних і їх відображення. Я впевнений, що я не повинен знати цих людей або всі ці речі, щоб створити таблицю з динамічними даними. Давай повернемося до React. Як я можу витягти дані з сервера в React?

— Ну, насправді для вибірки даних не треба React, він відображає дані.

— О, чорт. Так а що використовується для вибірки даних?

— Використовуй Fetch для отримання даних з сервера.

— Використовувати Fetch для вибірки даних? Той, хто називаючи ті речі, потребує тезаурус.

— О, так. Fetch це ім'я нативної реалізації для виконання XMLHttpRequests.

— О, AJAX.

— AJAX це просто запити XMLHttpRequest. А Fetch дозволяє робити AJAX на основі промисов, які потім можна резолвить, щоб уникнути callback hell.

— Callback hell?

— Так. Кожен раз, коли виконується асинхронний запит, ти повинен чекати його відповіді, який змушує тебе додати функцію всередині функції, яка називається піраміда callback hell.

— О, добре. А ці промисы вирішує цю проблему?

— Ще б. Маніпулюючи коллбеками через промисы, ти можеш писати більш зрозумілий код, тестувати його, а також виконувати кілька одночасних запитів відразу і чекати, поки всі вони відпрацюють.

— І це можна зробити за допомогою Fetch?

— Так, але тільки в деяких браузерах, в іншому випадку необхідно включити Fetch polyfill або використовувати Request, Bluebird або Axios.

— Скільки бібліотек мені потрібно знати, заради бога? Скільки з них?

— Це JavaScript. Тут тисячі бібліотек, які роблять те ж саме. Ми знаємо ці бібліотеки. Наші бібліотеки огрооооомные, а іноді ми включаємо картинки з Guy Fieri в них.

— Guy Fieri? Давай покінчимо з цим. Що ці Bluebird, Request і Axios роблять?

— Це бібліотеки для виконання XMLHttpRequests, які повертають промисы.

— А методи AJAX JQuery не повертають промисы?

— Ми більше не використовуємо «J» до 2016. Просто використовуйте Fetch polyfill або Bluebird, Request або Axios. Потім керуй промисами з async, await і Бац!, в тебе правильний потік управління.

— Це третій раз, коли ти говориш про await, але я поняття не маю, що це таке.

— Await дозволяє блокувати асинхронний виклик, що дозволяє краще контролювати під час отримання даних і збільшує читаність коду. Це приголомшливо, просто потрібно, щоб переконатися, що ти додав stage-3 в Babel, або використовувати синтаксис асинхронних функцій і плагін transform-async-to-generator.

— Це божевілля.

— Ні, божевілля, що потрібно перекомпілювати код TypeScript, а потім транспайлить його з Babel, щоб використовувати await.

— Шта!? Це не входить в TypeScript?

— Входить в наступній версії, але у версії 1.7 він тільки ES6, так що якщо хочеш використовувати await в браузері, спочатку потрібно скомпілювати код TypeScript в ES6, а потім транспайлить з Babel в ES5.

— Я не знаю, що сказати.

— Слухай, це легко. Пиши весь код в TypeScript. Всі модулі, що використовують Fetch компилируй в ES6, транспайль їх з Babel з stage-3, та завантажуй з SystemJS. Якщо у тебе немає Fetch, використовуй polyfill, або Bluebird, Request або Axios, і обробляй промисы з await.

— У нас дуже різні визначення легко. Так, з цим ритуалом я, нарешті, отримав дані і тепер я можу показати їх за допомогою React правильно?

— А додаток буде обробляти будь-які зміни стану?

— Грр, я не думаю. Мені просто потрібно відобразити дані.

— О, слава богу. В іншому випадку я повинен був пояснити Flux і реалізації, такі як Flummox, Alt, Fluxible. Хоча, якщо бути чесним ти повинен використовувати Redux.

— Як же дістали ці імена. Знову ж таки, мені просто потрібно відобразити дані.

— А якщо просто відобразити дані, не треба починати з React. Можна взяти движок шаблонів.

— Ти жартуєш, чи що? Вважаєш, що це смішно?

— Та я просто пояснив, що ти міг би використовувати.

— Стоп. Просто зупинись.

— Я маю на увазі, навіть якщо просто використовувати шаблонизатор, я б все одно використовував комбо TypeScript + SystemJS + Babel на твоєму місці.

— Мені потрібно відобразити дані на сторінці, а не виконати оригінальний фаталіті Sub Zero з Мортал Комбат. Просто скажи мені, який движок шаблонів використовувати.

— Їх багато, з яким ти знайомий?

— Уф, не можу згадати назву. Це було давно.

— jTemplates? jQote? PURE?

— Не те. Ще один?

— Transparency? JSRender? MarkupJS? KnockoutJS?

— Інший

— PlatesJS? JQuery-tmpl? Handlebars? Деякі люди до сих пір використовують його.

— Може бути. А є щось схоже на що останній?

— Mustache, underscore? Я думаю, що тепер навіть у lodash є шаблонизатор, але це свого роду 2014.

— Грр… можливо він був новіші.

— Jade? DustJS?

— Ні.

— DotJS? EJS?

— Ні.

— Nunjucks? ЇСТЬ?

— Ні.

— Чувак, ніхто не любить синтаксис CoffeeScript в будь-якому випадку. Jade?

— Ні, ти вже сказав Jade.

— Ну я мав на увазі Pug. Я мав на увазі Jade. Я маю на увазі, Jade тепер Pug.

— Пф. Немає. Не пам'ятаю. Якій з них ти б використав?

— Напевно нативний ES6 template strings.

— Дай вгадаю. Це вимагає ES6.

— Так.

— Який, в залежності від того, який браузер я використовую вимагає Babel.

— Так.

— Який, якщо я хочу включити без додавання всієї бібліотеки, потрібно завантажити в якості модуля NPM.

— Так.

— Який, вимагає Browserify або Wepback, або, швидше за все, SystemJS.

— Так.

— Що, якщо це не Webpack, в ідеалі повинен управлятися Task runner-ом.

— Так.

— Але, так як я повинен використовувати функціональне програмування і типізовані мови, я в першу чергу повинен попередньо зібрати TypeScript або додати цей Flow.

— Так.

— А потім надіслати це на обробку в Babel, якщо я хочу використовувати await.

— Так.

— Так що я можу використовувати Fetch, промисы і управління потоком і всю цю магію.

— Тільки не забудь polyfill Fetch, якщо він не підтримується, Safari досі не може впоратися з цим.

— Знаєш що. Я думаю, ми закінчимо тут. Насправді, я думаю, я закінчив. Я закінчив з цим вебом і з JavaScript в цілому.

— Добре, через кілька років ми всі будемо кодити в Elm або WebAssembly.

— Я просто хочу повернутися до бэкэнду. Я не можу впоратися з усіма цими змінами, версіями, виданнями, компіляторами і транспайлерами. Спільнота JavaScript шалено, якщо воно думає, що хтось може йти в ногу з цим.

— Зрозуміло. Тоді ти повинен спробувати співтовариство Python.

— Чому?

— Чув про Python 3?
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.