{full-post-img}
Перш за все слід сказати, що ця стаття лише ІМХО, не слід сприймати її надто серйозно. Тут я описав перше враження про сучасний веб, котре склалося в мене після декількох років роботи на бекенді. Під час написання (і перекладу) не було написано ні одного JavaScript-фреймворку.
Привіт, мені потрібно написати один веб-проект, але, чесно кажучи, я не займався вебом вже декілька років і не знаю що тут до чого. Ти найпрогресивніший розробник в окрузі, чи не так?
— Правильно казати фронтенд-розробник. Але так, ти звернувся до потрібної тобі людини. Я роблю веб в 2016. Візуалізація, музичні плеєри, літаючі дрони, що грають в футбол, називай як хочеш. Я тільки повернувся з JsConf та ReactConf, я знаю що таке останні технології.
Круто. Мені потрібно створити сторінку, що буде відображати останню активність користувачів. Мені просто потрібно отримувати дані від REST API і показувати їх в таблиці з можливістю фільтрації. Ну і оновлювати її, якщо на сервері щось змінилось. Я думаю використовувати jQuery для цього.
— Заради Бога, ні, ні, і ще раз ні. Хлопче, на дворі 2016 рік, ніхто не використовує jQuery, тобі потрібен React.
Добре, а що таке React?
— Це дуже крута бібліотека від чуваків з Facebook. Вона дозволяє створювати швидкі додатки, які приємно писати. Ти можеш відловлювати будь-які події в інтерфейсі та реагувати на них.
Звучить круто. Я можу використовувати React для отримання даних від серверу?
— Так, але спочатку потрібно підключити бібліотеки React та React DOM.
А чому бібліотеки дві?
— Одна головна, а друга дозволяє виконувати маніпуляції з DOM, який ти тепер можеш описувати на JSX.
JSX? Що це?
— JSX — це розширення синтаксису JavaScript, що дозволяє додавати в нього XML. Це ще один спосіб розширити можливості DOM, можеш вважати його покращеним HTML.
А що не так з HTML?
— Це 2016. Ніхто вже не кодить на HTML безпосередньо.
Нехай так. Після додання цих двох бібліотек я зможу використовувати React?
— Майже. Потрібно ще додати Babel, тоді ти зможеш використовувати React.
Ще одна бібліотека?
— Ох, ні. Babel — це транспілятор, що дозволяє писати на новому JavaScript, котрий скомпілюється в старий, який добре підтримують браузери. Взагалі, це не обов'язково, але без нього тобі доведеться писати на ES5. А хто в 2016 пише на ES5? Тобі слід використовувати ES2016 або новіше.
ES5? ES2016? Чекай, я заплутався. Що це?
— ES5 це скорочення від ECMAScript 5. Це версія, яку використовують більшість розробників, так як вона має найкращу підтримку в браузерах.
ECMAScript?
— Так. Знаєш, стандарт JavaScript було затвержено тільки в 1999 році, тоді як сам JS з'явився в 1995 році. Тоді він називався Livescript і працював лише в Netscape Navigator. Тоді його використовувати було боляче, але зараз в нас вже є сім редакцій цього стандарту, що роблять JS кращим та зручнішим.
Хм, тобто ES5 та ES2016+ одні з них?
— Так, пята і сьома редакції.
Чекай, а що сталося з шостою?
— Ти маєш на увазі ES6? Кожна редакція це надбудова над минулою, тобто використовуючи ES2016+ ти вже маєш всі фічі минулих версій.
Добре, а нащо використовувати ES2016+ поверх ES6?
— Ну, ти можеш використовувати ES6, але тоді ти не зможеш використовувати такі круті фічі як async & await.
Я не розумію що ти тільки що сказав. Стільки назв, я заплутався. Мені просто потрібно підключити jQuery з CDN і отримувати дані через AJAX. Чому б мені просто не зробити так?
— Це 2016, хлопче. Ніхто не використовує jQuery більше. Він лишився в ері спагеті-коду, всі це знають.
Тобто ти пропонуєш завантажувати 3 бібліотеки щоб просто відобразити дані в таблиці?
— Ти можеш використовувати менеджер модулів, котрий з'єднає їх в один файл.
Що таке менеджер модулів?
— Це залежить від оточення. В вебі ми зазвичай використовуємо щось, що підтримує AMD або CommonJS модулі.
Ох, а що таке AMD та CommonJS?
— Це спосіб описати, з якими бібліотеками взаємодіє твій код. Знайомий з export та require? Ти можеш написати декілька файлів з AMD- або CommonJS-оголошеннями, а потім поєднати їх за допомогою Browserify.
Ну, це логічно... Напевно. А що таке Browserify?
— Це інструмент, що дозволяє впакувати описані залежності до файлів, що можуть запускатися в браузері. Його створили тому що багато людей публікує ці залежності на реєстрі npm.
Npm?
— Це великий публічний репозитарій, де розробники зберігають свій код та його залежності в вигляді модулів.
Як на CDN?
— Схоже, але ні. Це більше схоже на централізовану базу даних, де кожен може публікувати та завантажувати бібліотеки так, що ви можете використовувати їх для локальної розробки, а потім завантажити на CDN.
О, прямо як Bower!
— 2 0 1 6. Забудь це слово.
Добре-добре. Тепер я повинен завантажувати бібліотеки з npm?
— Так. Якщо ти хочеш використовувати React, то ти завантажуєш його і імпортуєш до свого коду. Так можна робити з більшістю популярних бібліотек.
Схоже на Angular.
— Angular лишився в 2015, чувак. Але так, з Angular теж так можна. Як і з VueJS, RxJS чи іншими сучасними бібліотеками. Хочеш послухати про них?
Ні, давай залишимося на React, дуже багато речей я дізнався за цей час. Тобто щоб використовувати React мені потрібно завантажити його з npm, а потім використовувати Browserify?
— Так.
Для простого отримання та конкатенації залежностей це виглядає якось перевантажено.
— Саме тому ти повинен використовувати менеджер задач, як ось Grunt, Gulp чи Broccoli. Можеш ще подивитися в сторону Mimosa.
Grunt? Gulp? Broccoli? Mimosa? Про що ми взагалі говоримо?
— Менеджери задач. Але вони вже не актуальні. Ми використовували їх в 2015, потім були Makefiles, але зараз ми використовуємо для всього цього Webpack.
Makefiles? Я думав це більше для проектів на C чи C++.
— Так. Знаєш, в вебі ми любимо спочатку зробити все складним, а потім повертатися до основ. Ми робимо так кожен рік, можеш почекати трохи і в вебі з'явиться і ассемблер.
Досить. Ти казав щось про Webpack?
— Це ще один менеджер модулів для браузера. Це як Browserify, тільки краще.
А чим краще?
— Ну добре, може й не краще. Він більш гнучкий і дає обирати що використовувати як менеджер модулів: як CommonJS, так і нативні модулі в ES6.
Я вже не розумію про що ми говоримо.
— Так мало хто розуміє. І це я ще не розказував про SystemJS.
Святий Ісусе, ще один <іменник>-js. Для чого воно?
— На відміну від Browserify та Webpack 1.x, цей інструмент збирає бібліотеки не в один великий файл, а в багато маленьких.
Я думав нам навпаки потрібно збирати все в один файл.
— Так, але тепер, коли з'явився HTTP/2, декілька http-запитів краще.
Тоді чому я не можу просто підключити 3 бібліотеки для React?
— Ну, тобі все ж треба додати Babel.
Це погано?
— Так, ти можеш підключити babel-core, але вона не для продакшену. Перед запуском коду на бойовому сервері його потрібно мініфікувати, зжати ресурси і все таке.
Добре, добре. А як би ти додав бібліотеки до проекту?
— Я б зібрав їх з TypeScript за допомогою Webpack + SystemJS + Babel.
Я думав ми пишемо на JavaScript.
— TypeScript - це JavaScript. Хоча точніше сказати, що це надбудова над JavaScript. Він базується на ES6, пам'ятаєш, ми про нього говорили?
Я думав що ES2016+ це надбудова над ES6. Чому нам потрібно використовувати якийсь TypeScript? ЧОМУ?
— Зараз рулить статична типізація. Знаєш, тобі потрібно трішки статичної типізації в своєму коді.
І TypeScript робить це?
— Так, як і Flow, але він лише перевіряє типи, а TypeScript потрібно компілювати в JavaScript.
Чорт. Щ О Т А К Е F L O W?
— Це чекер для типів, зроблений чуваками з Facebook. Він написаний на OCaml, адже функціональне програмування - це прекрасно.
OCaml? Функціональне програмування?
— Це те, що використовують круті розробники в 2016. Функції найвищого порядку, каруваня, чисті функції і все таке.
Я не розумію.
— Спочатку ніхто не розуміє. Тобі просто слід знати, що функціональне програмування краще OOП, і саме його будуть використовувати в 2016.
Хм, я вчив ООП в коледжі. Мені здавалося, це дуже навіть зручно.
— Так було доки Java не викупила Oracle. Я маю на увазі, ООП був зручним раніше, але зараз всі зрозуміли, що зміна станів це зайве. Тому зараз всі використовують незмінювані об'єкти і функціональне програмування. Раніше так можна було писати лише на Haskell чи Elm, але завдяки таким бібліотекам як Ramda, ФП можна використовувати і в JavaScript.
Ти зараз просто називаєш випадкові імена? Що за Аманда?
— Ні, рамбда. Як лямбда, тільки рамбда. До речі, це бібліотека від Девіда Чамберса.
Кого?
— Девід Чамберс. Крутий чувак. Один з розробників Ramda. Тобі також слід почитати про Еріка Мейджера, якщо ти хочеш познайомитися з функціональним програмуванням.
А Ерік Мейджер це...?
— Теж крутий чувак. Дуже. В нього є купа виступів, де він в прикольній футболці змішує з брудом Agile. Також почитай про Tj, Jash Kenas, Sindre Sorhus, Paul Irish, Addy Osmani-
От тут я тебе переб'ю. Все це, звісно, класно, але для простого отримання та відображення даних це зайве. Я впевнений, що мені для цього не потрібно знати цих людей та всі ці бібліотеки. Давай повернемося до React. Як я можу отримати дані від сервера за допомогою React?
— Ти не отримуєш дані за допомогою React. З ним ти їх відображаєш.
Чорт візьми. Що мені потрібно використовувати щоб отримати ці кляті дані?
— Можеш використати Fetch. Це нативна реалізація XMLHttpRequests.
Тобто AJAX?
— AJAX - просто використання XMLHttpRequests. Fetch дозволяє робити запити, що повертають проміси. Це допомагає оминути callback hell.
Callback hell?
— Так. При кожному запиті потрібно перервати функцію, що обробить результат. І от так, раз за разом, а в тебе в коді 20 функцій, вкладених одна в одну. Ось це і є Піраміда коллбеків прямо з пекла.
А проміси дозволяють оминути це?
— Так. Вони дозволяють більш елегантно керувати твоїми колбеками, легше інтегрувати тести, чи групове керування запитами.
І Fetch дозволяє це використовувати?
— Так, але тільки якщо користувач використовує сучасний браузер. Інакше слід додати поліфіл, або використовувати Request, Bluebird чи Axios.
Боже, чому так багато бібліотек для однієї і тієї ж задачі?
— Це JavaScript, так було завжди. В нас тисячі і тисячі бібліотек для одного й того ж.
Досить. Хіба AJAX-методи jQuery не повертають проміси?
— Ми не використовуємо j-бібліотеки в 2016. Тобі слід використовувати нормальні бібліотеки. Просто отримуєш проміс, і керуєш ним за допомогою await в async-функції. Ось це я називаю контроль виконання.
Ти поїхавший.
— Ні, самий сік, це коли тобі потрібно транспілювати TypeScript в JavaScript, а потім використовувати Babel, що async & await запрацювали.
Що? Вони не вбудовані в TypeScript?
— В наступній версії буде. А поки він компілюється в ES6, а потім Babel збирає його в ES5-код.
Навіть не знаю що сказати.
— Все просто. Пишеш весь код на TypeScript. Компілюєш його в ES6, потім за допомогою Babel компілюєш в ES5. І завантажуєш за допомогою SystemJS.
Здається, ти не розумієш що таке "просто". Після всіх цих ритуалів з отриманням даних, я вже можу їх показати?
— Твій додаток повинен відстежувати зміни стану?
Думаю, що ні.
— Дякувати Богу. А то мені слід би було розказати про Flux і його реалізації, наприклад Flummox, Alt чи Fluxible. Але ти все ж повинен використовувати ще й Redux.
Досить. Д О С И Т Ь. Мені просто потрібно показувати деякі дані.
— Ну, якщо тільки відображати деякі дані, то ти можеш обійтися і без React. Вистачить шаблонізатору.
Ти знущаєшся? Думаєш це весело? Я що, настільки тобі не подобаюсь?
— Я просто розказав що ти можеш використовувати.
Припини.
— Якщо ти і використовуєш сам шаблонізатор, то все одно потрібен і TypeScript, і SystemJS, і Babel.
Мені потрібно просто показувати дані, а не робити фаталіті Саб-Зіро на JavaScript.
— TypeScript.
Досить. Просто розкажи, що мені слід використовувати.
— Тут є багато варіантів, ти з чимось знайомий?
Хм, так просто і не згадаю назв.
— jTemplates? jQote? PURE?
Ні, не те. Є ще варіанти?
— Transparency? JSRender? MarkupJS? KnockoutJS? Ще щось, що має двостороннє зв'язування?
Ні.
— PlatesJS? jQuery-tmpl? Handlebars? Дехто все ще використовує їх.
Можливо, є ще щось схоже на останнє?
— Mustache, underscore?
Ні, не знаю.
— Jade? DustJS?
Ні.
— DotJS? EJS?
Ні.
— Nunjucks? ECT?
Ні.
— Все одно ніхто не любить синтаксис CoffeeScript. Jade?
Ні, ти вже називав Jade.
— Я мав на увазі Pug. І Jade. Я мав на увазі, що Jade тепер Pug.
Не пам'ятаю. А що б використав ти?
— Нативні ES6 шаблони стрічок.
Дай здогадаюсь, вони потребують ES6?
— Ага.
І для його використання потрібен Babel?
— Так.
Котрий мені потрібно завантажувати з NPM?
— Правильно.
І це все потребує Browserify, чи Wepback, або SystemJS.
— Абсолютно вірно.
І, якщо це не Webpack, то слід використовувати ще й менеджер задач?
— Так.
А ще, мені потрібно компілювати TypeScript або додати Flow, так як я тепер пишу з статичною типізацією?
— Так.
А потім все це відправити до Babel, якщо я хочу використовувати await?
— Правильно.
І тільки тепер я зможу використовувати Fetch, проміси і контролювати всю цю магію?
— Не забудь додати поліфіл. Safari до цих пір не підтримує його.
Знаєш, тут ми і закінчимо. Досить з мене фронтенду.
— Це нормально, через декілька років ми всі будемо писати на Elm або WebAssembly.
Ні, я повертаюсь до бекенду. Я не можу працювати в такому шаленому темпі змін версій, фрейморків і підходів. Спільнота JavaScript божевільна, якщо думає що хтось може встигнути за всім цим.
— Я зрозумів тебе. Спільнота Python 3 як раз для тебе.
Чому?
— Ніколи не чув про Python 3?
Ще немає коментарів