Як стати full stack розробником, знаючи back-end. Покрокова інструкція

Всім привіт, мене звати Влад, і я вже більше семи років займаюся комерційною розробкою. Раніше я писав, як знайти першу роботу , як готуватися до співбесід і як вчити .NET .

Зараз я працюю в компанії DataArt. Мій основний стек технологій — екосистема .NET, але майже у всіх проектах я займався також і front-end частиною. У цій статті я спробую сформувати загальне розуміння сучасної front-end екосистеми для людей, які вже мають досвід в розробці, неважливо, на яких back-end технологіях. І дам базові рекомендації тим, хто хотів би розширити свою область компетенцій.

Навіщо це потрібно

Зараз на ринку є якийсь тренд на full stack фахівців, здатних реалізовувати всі частини проекту, а не тільки якусь одну. Цьому є багато пояснень:

Синхронізація між front-end і back-end командами вимагає часу і деяких технічних засобів (swagger, версирование API). Чим більше людей потрібно синхронізувати, тим вище ймовірність помилки через людського фактора. Дуже часто люди стикаються з проблемою, що хтось забув оновити эндпоинты або відправляє дані в неправильному форматі. Це все можна вирішити, але з'ясування причин та усунення таких помилок вимагає часу.
Дуже часто в промисловій розробці клієнт не має до кінця сформованих вимог або вимоги змінюються, що зумовлює процес розробки до невеликим итерациям і змін «на ходу». Якщо в таких умовах складно розділяти завдання, домовлятися про «контракти» між частинами програми, то це буде значна втрата часу та продуктивності.

Загалом, якщо порівняти pros & cons поділу відповідальності, я прийшов до такого порівнянні:

Поділ розробки між front-end і back-end командами/людьми	Full stack
Мінуси: Більш дорого для невеликих проектів. Слабо підходить для ситуацій невизначеності, необхідні чіткі вимоги. Ймовірність помилок зростає нелінійно з необхідністю синхронізації.	Мінуси: Якість реалізації front-end-частини, швидше за все, буде страждати. Для складних проектів люди будуть працювати повільніше, розпорошуючись.
Плюси: Більш компетентна front-end-розробка, кращу якість коду і більш правильне рішення складних завдань. При наявності чітких вимог і паралельної розробки — більш швидка реалізація.	Плюси: Більш гнучка розробка. Більш дешево для невеликих проектів. Більш ефективна розробка в ситуаціях невизначеності. Крос-функціональність і взаємозамінність членів команди.

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

Перші кроки

Якщо ви все-таки зважилися, будьте готові до того, що сучасна front-end екосистема дуже мінлива, постійно виходять нові версії фреймворків, ламаючи зворотну сумісність. Те, що вчора було стандартом, сьогодні вже застаріло. Це має свою логіку: сам веб розвивається досить швидко разом з самими браузерами, змінюються і вимоги до розробки. Також ви відразу ж зіштовхнетеся зі шквалом незрозумілих помилок — на всіх рівнях. Будьте готові багато гуглити або питати у колег. Не дарма front-end ком'юніті найактивнішу в плані конференцій і контрибуції open source, інакше просто не вижити.

Наприклад, ось таблиця підтримки різними версіями і виробниками браузерів різних версій JavaScript. Про те, як долається така плутанина, — далі у статті.

Трохи про те, що таке сучасна front-end-розробка. Якщо ви писали на JQuery, це не зовсім то, це скоріше веб-мастеринг, додає динаміку сторінкам. Якщо вам потрібно додати прості ефекти на landing page або реалізувати нескладну логіку спливаючих вікон, це вірний шлях, але якщо ви пишете повноцінне одностраничное веб-додаток (Single Page Application), то це явно шлях в нікуди. Можете залишити свій попередній досвід з JQuery і навчатися заново, інакше розробка справить величезний технічний борг, який поглине ваш проект, і кожне наступне зміна буде майже неможливим без переписування значної частини.

Також трохи про базові поняття. Правильна назва JavaScript — ECMAScript (ES), JS — це маркетингова назва. Другий важливий момент: Angular і AngularJS — це різні фреймворки. AngularJS — це все, що до версії 2.0, Angular — це все, що після другої версії. Це абсолютно різні паралельні гілки. Angular версій 2 і 7 відрізняються не так сильно, просто політика версирования. Кажучи «front-end-фреймворк», ми також для простоти маємо на увазі бібліотеки зразок React.js і Vue.js разом з їх екосистемою.

Загальна структура знань і технологій

Наступна ілюстрація показує, на мою думку, поступовий підхід до вивчення front-end інфраструктури. Освоївши нижні рівні на базовому рівні, можете рухатися далі.

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

Інфраструктура та складання проекту

Пакетний менеджер

За аналогією з будь-якої іншої середовищем розробки — gems в Ruby або packages з Nuget — в .NET для front-end є системи керування пакунками:

NPM (Node Package Manager ) — напевно, найпопулярніша система управління пакетами. Її основне завдання — віднімати назви та версії пакетів з package.json і розгортати їх разом з залежностями в папку node_modules. Має глобальний кеш пакунків (за аналогією з GAC.NET ). Пакети можуть бути службовими (devDependencies) і звичайними, включаються у production-складання. Посилання на офіційний репозиторій пакетів.

Yarn — встановлюється за допомогою NPM, що дозволяє прискорити процес установки, а також забезпечити інші корисні функції, недоступні в NPM, за замовчуванням дивитися на дзеркало npmjs від Facebook.

Bower — вже неактуальний менеджер пакетів, сенсу розбиратися з ним немає. Встановлюється за допомогою NPM, але має свою базу пакетів. Раніше мав фічі, не реалізовані в NPM, проте вже застарів, на сайті Bower є рекомендація переходити на Yarn або NPM.

CLI

Кожен фреймворк має свій Command Line Interface (CLI) для виконання різної чорнової роботи: скаффолдинга проектів із заздалегідь заданими параметрами, додавання компонентів, запуску тестів, деплоя, аналізу продуктивності.

Angular — Angular CLI
React — Create React App
Vue — Vue CLI

Модульна архітектура проекту

Для того щоб система складання модулів могла ці самі модулі зібрати, вони повинні розуміти, хто кого імпортує і на яких умовах. Існує кілька видів модульної організації:

ES-модулі — самий популярний стандарт, той самий import {classname} from.
CommonJS — вбудована в NodeJS система організації модулів.
AMD (asynchronous module definition) — стандарт, який реалізований в системі RequireJS, вважається застарілим.

Більш докладно можна почитати тут .

Система складання модулів та таск-раннеры

По суті, це той же NPM-пакет, який запускається інфраструктурним кодом для перетворення ваших вихідних у веб-додаток, готове до запуску. Найпопулярніші системи складання:

Webpack , Browserify — системи збирання з безліччю функцій з коробки. Для більшості випадків цілком прийнятно використовувати Webpack.
Gulp , Grunt — є, по суті, таск-раннери, мають екосистеми з великої кількості плагінів. З їх допомогою можна відтворити ту ж ланцюжок обробки і зборки і навіть запустити Webpack як окрему задачу.
NPM scripts — альтернатива Gulp/Grunt. Пропонується робити цю роботу суто на менеджері пакетів NPM з його можливістю підключати залежності для розробки, додавати складні команди в розділ scripts у package.json.

Однозначно сказати, який підхід краще, не можна. Таск-раннеры дають більше гнучкості, але мають більший час конфігурування. Webpack дає нам веб-сервер з коробки плюс готову інфраструктуру для складання програми.

Якщо взяти, приміром, Webpack, то доведеться трохи повозитися , щоб налаштувати всі необхідні параметри і пакети з нуля, для зборки/минификации скриптів, транспайлинга/полифила, складання і перетворення CSS, HOT loading (оновлення програми після збереження без необхідності оновлювати сторінку).

Для цього має сенс скористатися CLI для скаффолдинга (генерації основи програми/модулів) готових налаштувань і пакетів для файлу webpack.config.js.

Транспайлеры/полифилы

Як я писав раніше, існує цілий зоопарк сумісних між браузерами і версіями мови ECMAScript. Щоб мати змогу написати наш код на самій останній версії мови, але виконати його на будь-якій платформі, необхідно імітувати відсутні фічі на вже реалізовані.

Тут нам на допомогу приходять:

транспайлеры— спеціальні службові пакети, які транслюють фічі більш високих версій ES у нижчі;
полифилы— додають старими браузерами нове API, імплементоване на JS, як емуляцію стандартного.

Наприклад, найпопулярніший пакет Babel є і транспайлером, і полілфілом. Підтримує ES6/TypeScript, JSX, Flow, переводячи код, написаний на цих мовах, у ES5, зрозумілий для всіх браузерів.

Транспайлеры/полифилы — зазвичай одні з кроків обробки вихідного коду з допомогою складальників/таск-раннери.

Линтеры

Статичні аналізатори коду, які допомагають знаходити і усувати проблеми форматування, робити висновки про потенційно небезпечних місцях без компіляції. Самий часто використовуваний лінтер — ES Lint .

Форматеры коду

Pret-рівня — справа особистого смаку, використовувати такі кошти чи ні, але вони допомагають витримувати єдиний стиль оформлення коду при колективній роботі.

Unit/UI-тести

Аналогічно з back-end час від часу існує необхідність у написанні тестів. Але види тестів трохи відрізняються.

Тести в BDD підході / Unit тести— це три в одному: і тести, і документація та приклади використання. Тут вам допоможуть Jasmine/Mocha.
Інтеграційні тести — перевіряються окремі елементи верстки на коректність і працездатність.
End-to-end-тестування — через обгортку над Selenium Web Driver, наприклад, реалізується в Mocha . Перевіряється весь флоу взаємодії, де покриваються тільки позитивні сценарії.
Візуальне тестування — тестування на відповідність верстки заданому увазі, наприклад: PhantomCSS , Wraith , більш просунуті засоби, начебто Applitools .

Розуміти, що це таке, для загального розвитку варто, але не думаю, що вам слід сильно заглиблюватися в цю тему: частіше пишуть тести профільні front-end розробники.

Розробка

Для розробки можна використовувати як більш важкі IDE начебто NetBeans/Visual Studio, так і більш легкі. Не настільки важливо, яку IDE або текстовий редактор, ви будете використовувати, скільки те, які плагіни ви поставите туди. Всі ці IDE/редактори мають вбудовану систему установки плагінів для навігації/налагодження/підсвічування синтаксису та генерації коду. Різниця між IDE і текстовим редактором полягає в тому, що текстовий редактор більш вільний від зайвої функціональності, і тільки вам вирішувати, які плагіни туди поставити. З часом його складність може стати не менше, ніж IDE.

WebStorm — досить популярна і потужна, але платна IDE.
Visual Studio Code — більше текстовий редактор, ніж IDE.
Sublime Text — чимось схожий на VS Code.

Що вам використовувати — справа смаку, особисто я використовую Visual Studio Code, але багато професійні front-end розробники хвалять WebStorm. Full stack розробники часто люблять використовувати ту ж IDE, де вони пишуть і back-end. Наприклад, в ASP.NET Core є мидлвар для запуску front-end частини синхронно з back-end.

Також необхідно освоїти Chrome DevTools (F12 Tools) — дуже потужний засіб налагодження та діагностики. У найважчих випадках вам може знадобиться Fiddler — сніффер трафіку, що дозволяє виробляти дебаг взаємодії з сервером.

Розуміння клієнт-серверної та мережевої архітектури

Для початку з'ясуйте базові речі на рівні концепцій протоколів транспортного рівня моделі OSI.

Як працює DNS-сервер.
Що таке доменне ім'я.
Як, як і чому виділяється IP-адресу.
Що таке протоколи TCP/IP, UDP.

Далі візьміться за базове розуміння протоколу HTTP. Сам по собі HTTP або його спадкоємець HTTP/2 з мережевою точки зору — це протокол прикладного рівня. По суті, це передача тексту по протоколу TCP/IP. HTTP реалізований на папері , у вигляді деякої характеристики-рекомендації, як веб-сервер повинен реагувати на певне поєднання надходить до нього тексту. Ми можемо послати, наприклад, GET-запит дані тіла запиту, як в POST, а сервер їх просто проігнорує.

І в якому вигляді веб-сервер повинен віддавати браузеру відповідь? Різні веб-сервери (IIS, Nginx, Apache) можуть по-різному реагувати на HTTP-запити, однак тут відхилення від рекомендацій і відмінності дуже незначні.

Особливу увагу слід приділити наступним розділам:

HTTP статуси, основні .
HTTP-заголовки і реакція браузера на них.
Методи HTTP-запитів GET/POST/PUT/DELETE та інші, хоча на практиці часто обходяться GET і POST.
Що таке Cookies, JWT/Bearer-токени.
Local storage — браузерне сховище, як з ним працювати і навіщо.
Види взаємодії браузера і сервера — технічні та логічні техніки:
- AJAX/Polling;
- Long polling;
- Comet;
- SSE;
- WebSocket.

Більш докладно можна почитати (пости 2012-2013 років, тим не менш інформативно):

Після того як браузери стали підтримувати WebSocket нативно, необхідність в інших техніках стала відпадати, але тим не менш є випадки, коли, наприклад, використання SSE більш доречно.

Наприклад, обмін повідомленнями в реальному часі ASP.NET реалізований у вигляді фреймворку SignalR. Він сам вибирає транспортний рівень в залежності від сумісності, тим самим приховуючи ці подробиці від вас. При використанні front-end фреймворків вам лише потрібно інсталювати пакет для роботи з SignalR.

XSS, CSRF — найпопулярніші уразливості і методи боротьби з ними.
CORS — політика міжсайтових запитів, як зробити так, щоб з одного домену можна було надсилати запит на ресурс в іншому домені.
JSON — найпопулярніший формат передачі даних в мережі.

Мова

Зараз найпопулярніший мова для front-end — це ECMAScript 6/TypeScript. Якщо розглянути можливості мов з точки зору множин, то вийде так:

ES5.1 — фактично стандарт, підтримуваний майже на 100% усіма сучасними браузерами однаково. Про нього є чудова книга з носорогом під назвою «Докладне керівництво», яку я вам не раджу читати: дуже вже там багато води. Базові речі досить глибоко розібрані тут: javascript.ru/tutorial , learn.javascript.ru .

Критичні речі для розуміння самої мови:

Області видимості змінних var.
Типи даних, включаючи функціональні.
Механіка роботи об'єктів і прототипів — досить загального розуміння, при написанні коду на ES6/TS ви навряд чи зіткнетеся з цим.
Механіка роботи замикань.
Приведення типів (без фанатизму!).
Робота з об'єктами браузера — window, document, HTML element.
Спливання подій, робота з подіями.
Маніпулювання DOM і селектори.
Як працює асинхронність в V8.

Якщо ви знайомі з ООП-мовами, то JavaScript — мова теж об'єктно-орієнтований, зі специфічною механікою спадкування за прототипи. Тим не менше я думаю, що JS цілком собі поділяє концепції ООП:

Інкапсуляція — ми в праві зберігати мінливу, захопивши її в замиканні, зробивши недоступною зовні.
Спадкування — ми можемо будувати ланцюжки прототипів, розширюючи їх.
Поліморфізм — ми можемо інтерпретувати функцію як об'єкт, все є об'єкт.

Бути професіоналом в ES5 необов'язково, але базове розуміння не завадить.

ES6 — є розширенням ES6, відмінна довідка з нововведень за нього тут . У ньому з'являється багато синтаксичного цукру, більш передбачувані області видимості, класи, модулі. Цю специфікацію потрібно знати дуже добре.

TypeScript — є розширенням ES6 і мовою за замовчуванням в інфраструктурі Angular. Рекомендую читати офіційну довідку . Тут з'являються інтерфейси, generic, сувора типізація, помилки часу компіляції. TS найбільше схожий на C# і, мабуть, є самим зрозумілим підмножиною JS для back-end розробників.

Інші мови екосистеми JavaScript:

NativeScript — є мовою написання гібридних мобільних додатків.
CoffeeScript — діалект, відрізняється своєю лаконічністю і читаністю, однак не має великої популярності зараз.
ELM — функціональний мову, має обмежену сферу застосування.
Dart — не зовсім мова екосистеми JS, швидше, окремий мову зі своїм інтерпретатором, який вбудований в Google Chrome.

Вони зовсім не обов'язкові до розгляду, зараз сенсу в них немає. Звичайно, є, наприклад вузька ніша, де, можливо, написати на ELM буде лаконічніше. Але я вважаю, що, використовуючи настільки рідкісні технології, ризикуєш залишитися без фахівців, здатних це підтримувати.

Фреймворк і бібліотеки

Angular/AngularJS

Я вже згадував, Angular — це все, що після другої версії, а AngularJS — все, що до неї. Архітектурний патерн, пропонований Angular, — це MV*/MVVM. Єдиної думки немає, але в цілому архітектура дуже схожа на ASP.NET Web Forms — є компоненти з вкладеними компонентами і наскрізний функціональністю — вбудований IoC-контейнер для ін'єкцій сервісів компоненти, управління scope. Обробка асинхронних операцій зазвичай пишеться на RxJS. Однак можливо використовувати Angular спільно з контейнером станів Redux.

Для освоєння базових речей я рекомендую курс «Angular 7 (formerly Angular 2) — The Complete Guide» . Також непоганий гайд для старту .

Працюючи з front-end, потрібно розуміти природу завдань, розв'язуваних програмно. Взаємодія з браузером можна представити у вигляді потоку подій та реакції на них, а також синхронізації різних ланцюжків подій і їх перетворення. Для вирішення таких завдань застосовують парадигми реактивного програмування. Ці парадигми реалізовані в бібліотеках Reactive Extensions для багатьох мов програмування. Для JS це RxJS. Довідка за RxJS . За RxJS можу порадити доповідь мого колеги .

З точки зору движка шаблонізації, Angular цілком нагадує той же Silverlight з прив'язками даних.

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

React.js

Менш звичний підхід для back-end розробників, з орієнтацією на верстку і подієвий потік. React.js, по суті, є бібліотекою/template-движком, на якій цілком можна розробляти без додаткових коштів, однак це не настільки зручно при зростанні проекту та його складності.

Кажучи «React», ми маємо на увазі React + React DOM для веб-розробки. Якщо взяти React і React Native, ми зможемо в схожому синтаксисі розробляти крос-платформні мобільні додатки. Для спрощення такий підхід називають React Native. Докладніше тут .

Таким чином, сформувалася ціла екосистема React:

Axios — для HTTP-запитів.
React Router — для підтримки більш зручного роутінга.
Redux — для централізованого керування станами.
React Router Redux — для зв'язку роутера і контейнера станів.
Redux-Thunk/Redux-Saga/MobX — різні підходи для синхронізації асинхронних операцій.

Найпопулярніший архітектурний патерн в React.js — це Redux, еволюція ідеї Flux. По суті, ідея Flux — це той самий знайомий CQRS для back-end-розробників.

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

Підхід до розробки в React.js суперечить «класичному» — відділення коду розмітки. React має свій движок шаблонізації — JSX, який спрощує змішування верстки і коду. Верстка вставляється прямо в код.

З перших питань, які варто розібрати, я виділив такі:

JSX;
Components, lifecycle;
State/props;
Virtual DOM;
Synthetic events;
Unidirectional data flow;
HOC/Pure components;
Flux/Redux.

В якості підручника цілком підійде офіційна довідка .

Vue.js

Ще один популярний движок шаблонізації, побудований на архітектурі MVVM (з використанням VueX — це Flux). Він має кілька варіантів організації шаблонів:

Single File Components — концепція, в якій шаблон, логіка і стилі інкапсулюються всередині єдиного файлу.
JSX — суміш верстки і коду, те ж, що і в React.js.

Сам по собі Vue.js схожий на React в тому, що це лише движок для шаблонізації, має свою екосистему:

Axios — HTTP-запити;
Vue Router — роутинг;
VueX — контейнер станів.

Суб'єктивно, Vue.js набагато простіше для старту, ніж Angular або React. Він має відмінну довідку-керівництво, в тому числі російськомовну .

Коротко про концепції потоку даних в VueX:

Ідея схожа на той самий CQRS:

Код з нашої верстки диспатчит Action.
Action робить асинхронний запит на сервер.
Після отримання відповіді викликається Mutation, яка вирішує, як їй міняти State.
Зміна State робить повторний рендер верстки.

Awesome Vue — тут ви знайдете вичерпний список всього, що відноситься до екосистемі Vue.js: пакети, гайди, UI-бібліотеки, статті.

Інші фреймворки та бібліотеки

Backbone/Marionette, Ember, Knockout, MeteorJS, ExtJS, Aurelia — є ще дуже багато різних фреймворків/бібліотек, але:

Вони не користуються таким попитом, як раніше, хоча можуть бути цілком придатними для вирішення завдань, покладених на них. Я знаю людей, які досі хвалять Ember/Backbone+Marionette і будуть використовувати їх у нових проектах зважаючи хорошого їх знання.
Їх підхід застарів.
Вони мають деяку надмірність порівняно з трійкою лідерів.

Окремо слід відзначити наступні бібліотеки:

InfernoJS — дуже схожий на React.js, може використовувати JSX, але дає екстремальну швидкість роботи, коли це необхідно.
Preact — клон React.js для вебу, що має розмір пакету всього лише 3 КБ (!), реалізує основний API React.

На них цілком можна будувати адекватний front-end, але підтримка ком'юніті не буде такою сильною.

Додам, що розвиток SPA породило іншу проблему: у краулера Google при індексації сайтів, можливо, не вийде нормально проіндексувати сайт, який будується динамічно, або ж нам потрібна підвищена продуктивність. Для цього використовують Server Side Rendering (SSR ), але це тема для окремої статті.

Імплементація аспектів — кращі практики і патерни

Після того як ви вирішили, який фреймворк будете вивчати, реалізуйте на ньому базові речі:

Стандартні речі на зразок роутінга/розбиття на модулі.
Ідентифікація і аутентифікація.
Форми, валідація форм.
Спливаючі вікна.
Завантаження файлів.
Дебаунсинг введення і подій.
Асинхронність програми.
Продуктивність навантажених сторінок.

Список реально розв'язуваних завдань може бути набагато ширше, це я написав для прикладу. На перший погляд це здається простим, але по дорозі ви зіштовхнетеся з десятками проблем, рішення яких буде давати розуміння того, що і як реально працює.

Верстка

Це одна з головних тем у front-end-розробці. За останні 10-15 років верстка дуже сильно просунулася завдяки новим можливостям браузерів. Те, що треба розуміти насамперед, — це базові HTML4/CSS2, далі на їх основі HTML5/CSS3 — з новими тегами, Flexgrіd, змінними, CSS-властивості, що допомагають вирішувати більш складні завдання більш просто. Далі — CSS-препроцессоры начебто SCSS, LESS, Stylus, PostCSS. Вони допомагають уникати дублювання CSS-коду, вводити змінні, додавати домішки і ще багато всього — краще почитати тут .

Більш просунутий рівень:

Адаптивність і крос-браузерность.
Методології верстання типу БЕМ .
Основи SEO і як правильно розробляти веб-сторінку для коректної індексації пошуковими движками.

Але зауважу, що навіть front-end розробники рідко роблять складну верстку. Зазвичай версткою займаються спеціальні люди або зовнішні підрядники. Зараз хороша верстка — це досить непросто, і вона вимагає спеціальної підготовки і досвіду.

UI kits/libs

Дуже часто використовуються готові рішення для побудови додатків. Немає сенсу розробляти те, що вже розробили і протестували.

CSS-фреймворки

Дозволяють вирішити найбільш часті проблеми у верстці і зробити її максимально швидкої і правильної з точки зору пропорцій, валідності, адаптивності та крос-браузерности: Bootstrap , Bulma . Якщо пошукати, існує багато WYSIWYG-конструкторів для Bootstrap.

Паки UI-компонентів

Кожен рік виходять нові версії і паки, досить просто знайти інформацію про них в інтернеті у схожих статтях за запитами на зразок Best React UI Component Libraries . Наприклад, Material реалізований для Angular та інших фреймворків/бібліотек.

UI-бібліотеки

Зазвичай платні, більш просунутий рівень UI-компонентів. Мають інтеграцію один з одним і вирішують практично всі можливі завдання промислової розробки, інтегровані з найпопулярнішими front-end фреймворками: DevExtreme , KendoUI , ExtJs .

Перевага використання таких бібліотек в тому, що, заплативши 1000 доларів за одного користувача на рік, ми отримуємо швидке рішення всіх задач, пов'язаних з типовим промисловим UI: таблиці будь-якої складності, модальні вікна, форми, експорт та завантаження даних та багато іншого.

Висновок

Не бійтеся різноманітності front-end технологій. Для початку визначіться, з яким саме стеком хочете працювати, потім вивчіть його інструментарій на базовому рівні. Виберете середовище розробки під себе, а так само запитуйте своїх колег. Тут без спілкування не обійтися.

Якщо ви маєте якісь питання/побажання, пишіть мені на Facebook . Також для розробників з досвідом: якщо хочете змінити роботу, можу порадити найкращі вакансії, допомогти зі складанням резюме і підготовкою до інтерв'ю.

Опубліковано: 27/03/19 @ 11:00
Розділ Різне

SEO Блог