Чтобы разобраться в том, как работает механизм обработки кода (иначе говоря, движок JavaScript), надо понять, что происходит при выполнении кода. Такие знания помогают программистам писать лучший, более быстрый и умный код.
Движки JavaScript — это не что иное, как программы, преобразующие код на JavaScript в код более низкого уровня, который компьютер сможет понять. Эти движки встроены в браузеры и веб-серверы (Node.js), что даёт возможность выполнять код и осуществлять компиляцию во время выполнения.
Разве JavaScript — это не интерпретируемый язык?
Краткий ответ: это зависит от реализации. Обычно JavaScript относят к интерпретируемым языкам, хотя вообще-то он компилируется. Современные компиляторы JavaScript фактически выполняют JIT-компиляцию, т.е. компиляцию «на лету», которая осуществляется во время работы программы.
Движок
Существует множество разных движков. У каждого из них внутри есть что-то вроде конвейера с интерпретатором и конвейера с оптимизатором и компилятором. Интерпретатор генерирует байт-код, а оптимизатор выдаёт оптимизированный машинный код. Далее в статье в качестве примера будет использоваться движок V8.
Для чего нужен язык JavaScript
V8 — это высокопроизводительный движок от Google с открытым исходным кодом JavaScript и WebAssembly, написанный на языке C++. Он используется в Chrome, Node.js и других платформах и реализует ECMAScript и WebAssembly (см. v8.dev).
Что внутри движка
Всякий раз, когда JavaScript-код отправляется в движок V8, он проходит ряд этапов для отображения console.log:
Парсер
Движок выполняет то, что мы называем лексическим анализом. Это первое, что происходит с файлом JavaScript при попадании в движок. Код разбивается на части, называемые токенами, для выявления их назначения, после чего мы узнаём, что код пытается сделать.
Абстрактное синтаксическое дерево (AST)
На основе этих токенов создаётся то, что мы называем AST. Синтаксическое дерево — это древовидное представление синтаксической структуры кода JavaScript, и мы можем использовать этот инструмент для анализа преобразования кода AST.
Интерпретатор
Интерпретатор читает файлы JavaScript построчно и преобразовывает их на ходу (во время работы программы, не прерывая её выполнение). На основе сгенерированного кода AST интерпретатор начинает быстро создавать байт-код. Никаких оптимизаций здесь не выполняется, так что байт-код этот неоптимизированный.
Байт-код не является таким низкоуровневым, как машинный код, но всё же может быть интерпретирован движком JavaScript для выполнения кода.
Профайлер
Профайлер отвечает за проверку кода. Он вызывает специальное средство контроля, которое отслеживает код и наблюдает за ходом его выполнения, обращая наше внимание на то, как можно оптимизировать код. Выдаёт, например, информацию о том, сколько раз код запускался, какие типы используются и как мы можем его оптимизировать?
Так что, если профайлер находит часть кода, которую можно оптимизировать, он передаёт этот код JIT-компилятору, чтобы он мог быть скомпилирован и выполнялся быстрее. Рассмотрим эти конвейеры с интерпретатором и компилятором более подробно.
Зачем нужен JavaScript?
Оптимизирующий компилятор
Задача оптимизирующего компилятора — определить, что делает программа, подлежащая оптимизации, и создать из неё оптимизированную программу, выполняющую всё то же самое, только быстрее.
Он не преобразует файлы на лету. Он делает свою работу заранее, создавая преобразование только что написанного кода и компилируя его в язык, понятный для компьютера.
Деоптимизация
Оптимизирующий компилятор на основе имеющихся у него данных профилирования делает определённые предположения, а затем выдаёт высокооптимизированный машинный код. Но вполне возможно, что в какой-то момент одно из предположений окажется неверным. И тогда оптимизирующий компилятор может деоптимизировать код.
Объектная модель JavaScript
JavaScript — это динамический язык программирования, а это подразумевает, что свойства могут легко добавляться или удаляться из объекта после его создания. Для написания более лучшего кода надо понимать, как JavaScript определяет объекты и как движок работает с объектами и свойствами.
- Enumerable → определяет, перечисляется ли свойство в циклах for — in .
- Value → само значение.
- Writable → определяет, можно ли свойство изменить.
- Configurable → определяет, можно ли удалить свойство.
Оптимизация доступа к свойству
В динамических языках, таких как JavaScript, для доступа к свойствам требуется ряд инструкций. Поэтому почти в каждом движке имеется оптимизация для ускорения этого доступа. Такая оптимизация в V8 реализуется скрытыми классами: V8 присоединяет скрытый класс к каждому отдельному объекту. Целью скрытых классов является оптимизация времени доступа к свойствам.
Скрытые классы работают аналогично фиксированным макетам (классам) объектов, используемым в таких языках, как Java (за исключением того, что они создаются во время выполнения). Магия здесь в том, что несколько объектов могут иметь один и тот же скрытый класс, поэтому необходимы только минимальные ресурсы, а код становится быстрее:
Выгода становится очевидной, когда объектов много. Ведь пока у них один и тот же скрытый класс, информацию приходится сохранять только один раз независимо от того, сколько всего имеется объектов!
Тема оптимизации очень обширна и может стать предметом обсуждения отдельной статьи.
Встроенные кэши
Цель встроенного кэширования в том, чтобы ускорить привязку метода времени выполнения. Происходит это за счёт запоминания результатов поиска предыдущего метода непосредственно в месте вызова. Встроенное кэширование особенно полезно для динамически типизированных языков, где большинство, если не все привязки методов происходят во время выполнения и где виртуальные таблицы методов часто не могут быть использованы.
Основная причина существования скрытых классов — концепция встроенных кэшей. Движки JavaScript используют встроенные кэши для запоминания информации о том, где найти свойства в объектах. Поэтому нет необходимости повторять дорогостоящий поиск свойств при каждом доступе к ним. Зачем каждый раз искать свойства, когда со встроенными кэшами это значительно быстрее?
Выводы
- инициализировать объекты лучше всегда одним и тем же способом, чтобы скрытые классы у них не были разными;
- с атрибутами свойств элементов массива надо быть осторожным, чтобы они могли аккуратно сохраняться, а работа с ними была эффективной.
- Как работает новый await верхнего уровня в JavaScript
- Чистый код JavaScript — Вертикальное форматирование
- Что значит this в JavaSсript?
Источник: medium.com
JavaScript QA — делаем все правильно с самого начала
JavaScript — это широчайшая функциональность, незаменимый user experience, и ты всегда на волне последних трендов веб-дизайна. Есть и минусы, за удобство и красоту надо платить: большой объем кода в проекте, и да — все написанное на JS приходится очень много тестировать. Выход — в автоматизации, так быстрее, проще, надежнее.
У автоматизации, однако, есть свои узкие места: нестабильные тесты, проблемы с расширяемостью. Бывают ситуации, когда лучше вообще отказаться от автоматизации. В целом, если JS-код хорошо читаемый и удобно расширяемый, это даст хорошее покрытие, минимум багов, отлаженные процессы в команде.
JavaScript все еще первый и главный язык тестировщика, а Python пока не очень серьезный конкурент. Чтобы оценить мощь JS, надо овладеть лучшими практиками JavaScript для QA; далее — попытка систематизировать эти практики.
Правильное поведенческое тестирование
Наверное, пункт первый это behavioral testing, то есть поведенческое тестирование. Старайся смотреть на код с точки зрения именно тестировщика, а не разработчика. Это сэкономит время, по крайней мере за счет пропуска неприоритетных тестов. Быстрый пример: можно, ничего не теряя, пропустить тесты внутренних переменных:
it(‘should login with valid credentials, () => < userManager.login(‘UserId’, ‘Password’); expect(userManager._usersList[0].name).toBe(‘UserId’); expect(userManager._usersList[0].password).toBe(‘Password’); >);
Здесь пользователь пытается залогиниться в веб-приложение с логином/паролем, взятыми из соответствующего списка. Такой тест лучше переписать вот так:
it(‘should login with valid credentials’, () => < userManager.login(‘UserId’, ‘Password’); expect(userManager.login(‘John’, ‘Password’)).toBe(true); >);
Мы не проверяли значения внутренних переменных — и все равно получили нужный результат.
Такая практика улучшает расширяемость тестов, а также позволяет команде лучше понимать свои тест-кейсы. Она считается, вероятно, одной из лучших, помогающих избежать “рандомно падающих”, то есть нестабильных flaky-тестов на JS.
Когда нужно юнит-тестирование
С этим делом существует недопонимание. Перед тем как тестировать, надо усвоить, что далеко не каждый тест должен выглядеть как юнит-тест. Например когда считывается файл с диска, или добавляются таблицы в базу — для этого не нужно юнит-тестирование.
Юнит-тесты не касаются внешних систем, они находятся на уровне “юнитов”. Если тест “красный” при запуске в системе неправильной конфигурации, такой тест не считается юнит-тестом.
В случае необходимости тестирования сложного высокоуровневого функционала рекомендуется писать end-to-end-тесты, функциональные тесты, и интеграционные. Это позволяет протестировать функции и их интеграцию. Обычно здесь применяют Selenium.
Сдвиг влево
Концепция “Test-driven development”, как гласит классическое определение, разработана для улучшения качества кода и ускорения сдвига влево. Эта практика позволяет раньше находить дефекты.
Однако, написание тест-кейсов до написания кода — само по себе еще не гарантирует полное отсутствие багов, а просто максимизирует тестовое покрытие, и лучше удовлетворяет бизнес-требования.
Как внедряется TDD применительно к JavaScript? Например, мы пишем тест валидации:
- Считываем значения из полей
- Применяем правила обработки цифр/букв
- Если что-то не так, возвращаем ошибку
В форме проверяем только поля имени и контакта. Скрипт:
it(‘should validate a form with all possible data types’, function () < const name = form.querySelector(‘input[name=»first-name»]’); const contact = form.querySelector(‘input[name=»contact»]’); name.value = ‘John’; age.value = ‘9051513622’; const result = validateForm(form); expect(result.isValid).to.be.true; expect(result.errors.length).to.equal(0); >);
form >
Так как мы не написали код валидации формы, тест упадет. Чтобы он прошел, надо написать код, который будет валидировать форму.
Когда нужно остановиться
Упомянутый выше TDD-подход ориентирован на повышение тестового покрытия. Это любят проджект-менеджеры. А иногда нужно не перегнуть палку с покрытием, понимая разницу между покрытием кода и тестовым покрытием.
Если спросишь кого-то, а какое должно быть идеальное тестовое покрытие, скорее всего скажут — 100%, или как минимум 80%. Если такая цель дана команде, они будут “вытягивать покрытие”. И есть вероятность, что из-за спешки не протестируют некую важную функцию.
Что такое идеальное покрытие? Невозможно сказать точно. Если в проекте автоматизация в Selenium, бывает трудно добиться высокого покрытия — очень много времени уйдет на написание правильных тестов. Это скажется, когда в проекте кроссбраузерные и кроссплатформенные тесты.
Работа с такими тестами бывает монотонной, и нужны специалисты в Selenium. Каждое изменение в коде должно пройти тестирование, то есть тогда лучше ограничиться тестированием ветвлений.
“Портативный” фреймворк автоматизации
Тестировщики тратят много времени на конфигурацию. Это вредит на больших проектах. Скрипт, отлично работающий на машине, где фреймворк создавался, может плохо работать на других.
А если тесты запускаются на CI-сервере? Если фреймворк автоматизации не “портативный”, тестирование становится проблемным.
Для начала, избавься от привычки хранить файлы автоматизации на локальной машине. Вместо этого отправляй их в фреймворк. Если файлы большие, можно подумать о хранилище на Amazon S3, например. Если работаешь в Selenium, можно избежать проблем с конфигурацией, используя облачную платформу. Можно применять POM-модель, отделяя веб-локаторы от логики, чтобы изменения в UI включали модификации в репозитории веб-локаторов (а не в коде теста).
Давай осмысленные имена тестам
Это одна из недооцененных практик тестирования на JavaScript. Правильное и понятное именование функций, переменных и тестов — хорошая практика.
Имена тестов должны быть понятными и “объявлять” их предназначение. Имена тестов должны:
- Обозначать цель теста
- Легко найти “место поломки” в функции
- Улучшить реюзабельность тест-кейсов и сэкономить время
Так называть не рекомендуется:
Плохо, потому что название ничего не говорит о сценарии. Лучше так:
BDD-подход
Behavior-driven development, как и TDD-методика, направлена на повышение покрытия кода и тестового покрытия. BDD опирается на постоянную коммуникацию и общее понимание продукта тестировщиками и разработчиками. Это достигается созданием сценариев “желаемого поведения” продукта.
BDD особенно подходит для автоматизации UI. Например:
HomePage homePage = new HomePage(); homePage.open(); homePage.waitUntilPageLoaded(); Assert.assertEquals(homePage.getTitle(), «FlightBookingDemo»); Assert.assertEquals(homePage.getTitle(), «Welcome to the Flight Booking Demo Site!»); FlightsPage flightsPage = homePage.findFlights(«Bangalore»,»Mumbai»); List foundFlights = flightsPage.getFlights(); Assert.assertTrue(foundFlights.size() > 0);
Опытный тестировщик должен уметь делать такие скрипты. А для бизнес-менеджеров они “вне контекста”. Представим скрипт, написанный на специфическом языке типа Gherkin:
Given that a user opens the home page The user should view a homepage with title «FlighBookingDemo» and heading «Welcome to the Flight Booking Demo Site!»/ When the user searches for flights from Bangalore to Mumbai Then the user should find some flights
Так BDD-подход реализуется в Cucumber. Он позволяет снизить дублирование кода, улучшить читаемость, и упростить правки. Люди в команде, не владеющие ЯП, таким образом смогут участвовать в создании сценариев. Если можно, применяй BDD вместо TDD, чтобы привлекать к сценариям специалистов, не владеющих ЯП.
Не надо делать mock’и везде
Такая привычка есть у разработчиков, обычно они это делают, когда пишут свои юнит-тесты. Далее им приходится тестировать if…else. Такие тесты не имеют большой ценности, потому что тесты if…else можно писать на любом ЯП.
Делать моки есть смысл только для самых низкоуровневых зависимостей, или других I/O-операций (API, вызовы из базы данных и подобное). Тестируется корректность имплементации private-методов.
Например, нужно написать код на страницы магазине, чтобы пользователь мог вычислить цену товара с НДС. В следующей функции мы берем цену продукта, вычисляя НДС. Функция вызывает внутренний метод calculateVATAddition, который вызывает API getVATRate. Здесь не надо делать мок функции calculateVATAddition. Нужен только мок функции getVATRate, потому что у тебя нет доступа к результату вызова этого API.
class ProductService < // Internal method calculateVATAddition(priceWithoutVAT) < const vatPercentage = getVATRate(); // external API call ->Mock const finalprice = priceWithoutVAT * vatPercentage; return finalprice; > //public method getPrice(productId) < const desiredProduct = DB.getProduct(productId); finalPrice = this.calculateVATAddition(desiredProduct.price); // Don’t mock this method return finalPrice; >>
Избегай повторения
Понятно, что дублирование кода усложняет читабельность и обслуживание. Плохой пример:
if($.browser.chrome) < console.log(“Browser is Chrome”); >else if ($.browser.mozilla) < console.log(“Browser is Firefox”); >else if ($.browser.msie) < console.log(“Browser is IE”); >else
- Проверить браузер, в котором открыта страница
- Вывести имя браузера в Консоль
- Если имени браузера нет в списке, выдать сообщение “Неизвестный браузер”
escribe(«Browser», function()< it(«should print Browser is Chrome», function()< expect($.browser.chrome) is true; >); it(«should print Browser is Firefox», function()< expect($.browser.mozilla) is true; >); it(«should print Browser is IE», function()< expect($.browser.msie) is true; >); it(«should print Browser is Unknown», function()< expect($.browser.chrome) is false; >); it(«should print Browser is Unknown», function()< expect($.browser.mozilla) is false; >); it(«should print Browser is Unknown», function()< expect($.browser.msie) is false; >); >);
Много продублированного кода. Код — фактически копия имплементации, и нет правильной логики.
Например, если ($browser.chrome) равно false, но ($browser.msie) равно true, тест все равно выдаст ложный негативный результат.
А у нас все будет хорошо, если просто напишем:
it(«should return the correct browser», function()< var browsers= ‘chrome,mozilla,msie’; expect($.browser.browsers).toEqual(true); >);
Эффективное кроссбраузерное тестирование
Понятно, что в 2022 году сайт должен идеально выглядеть и быть доступным с любых устройств и браузеров. Это делает кроссбраузерное тестирование обязательным, по крайней мере что касается пользовательских продуктов. Хорошее кроссбраузерное тестирование это одна из лучших практик в JS QA.
Чтобы правильно протестировать все варианты браузеров и ОС, надо следующее:
- Присваивай категории багам “по браузерам”, поскольку некоторые баги являются “браузерно-специфическими”. Таким образом, необязательно тестировать все (не)возможные сочетания ОС/браузер, это уйма времени. Надо бы создать матрицу, где будут хорошо видно приоритеты.
- Надо хорошо знать требования насчет браузеров и устройств от своих клиентов. Далее определиться, нужно ли тестировать сайт на старых версиях браузеров. Например IE почти мертв, но все-таки его надо протестить, если предполагаемые клиенты все еще “сидят в експлорере”. В таком случае есть смысл сделать отдельный stylesheet для старых браузеров.
- Вместо долгой настройки локальной инфраструктуры лучше сэкономить время, деньги, и усилия, и тестировать на облаке.
Сделай сьют управления тестами
Если работаешь в большом проекте, бывает большой объем тестовых данных и скриптов. Тогда понадобится специальный инструмент управления ими, который:
- Уменьшает затраты времени на написание и выполнение скриптов. В некоторых инструментах AI-мозг подскажет, как писать эти скрипты.
- Упорядочивает всю информацию в едином дашборде, куда имеют (настраиваемый) доступ члены команды. Лид проверяет прогресс по отдельным тестировщикам, мониторит эффективность команды.
- Расширяемое окружение — а значит тесты выполняются быстрее
- Экономит время, уменьшая лишние действия присвоения статуса бага и обновления процесса
- Предполагает интеграцию с Jira, Github, Slack
Соблюдай законы о личных данных
Эти законы зависят от места жительства заказчиков и клиентов. Соответствующий закон Евросоюза — GDPR, в США это CCPA.
Эти законы гласят, что нельзя работать с пользовательскими данными в целях тестирования или маркетинга. Несоблюдение грозит большим штрафом и потерей репутации.
Во избежание, нужно часто проводить аудит тестовых данных, пользоваться комплайенс-сьютом для тестовых данных, или маскировать данные, или работать с “синтетическими” тестовыми данными.
Слишком много хелперов и хуков
Библиотеки-хелперы упрощают работу, но иногда вредны. Особенно когда у разработчиков/тестировщиков не хватает компетенции разобраться с тест-сьютом. Например нужно много времени на разбирательства, что случилось с хуком beforeAll, или beforeEach.
Можно оценить сложность, задав кому-то из новичков пару вопросов о сьюте. Если он с трудом объяснит, то сьют надо упростить. Кроме того, внимание на хуки. Пользуйся ими, только если действительно надо добавить что-то на все тест-кейсы.
Если коротко
JS издалека кажется простой вещью, позволяющей сделать тестирование эффективным и даже приятным. Как можно видеть, многое из Лучших Практик касается удобочитаемости кода, и легкости обслуживания.
И еще: нужно избегать сложных сетапов и многоуровневой абстракции. Также, неплохо бы освоить паттерн ААА (Arrange, Act, Assert), и трехуровневую архитектуру.
Источник: testengineer.ru
Зачем учить JavaScript и где он пригодится
Аспирант Нетологии Максим Пименов рассказывает про JavaScript — невероятно популярный язык программирования, который учит сайты реагировать на поведение посетителей.
JavaScript — это лучший друг HTML и CSS. HTML задает разметку сайта, CSS отвечает за внешний вид, а JavaScript все это оживляет. С помощью кода на JavaScript программист определяет, как страница отреагирует на действия пользователя.
Сейчас JavaScript — единственный язык программирования для браузеров. Он работает под Windows, macOS, Linux и на мобильных платформах, то есть везде. Если не знаешь JavaScript, делать в программировании интерактивных сайтов нечего.
В 2009 году появился Node. js, который вывел JavaScript за пределы браузеров. Теперь его можно запустить хоть на стиральной машине. О том, что такое Node. js и зачем он нужен, мы уже писали, поэтому не буду рассказывать о нем подробно.
Без JavaScript делать в программировании интерактивных сайтов нечего
Максим Пименов
Профессия
Frontend-разработчик с нуля
Узнать больше
- Получите востребованную профессию frontend-разработчика
- Реализуйте жизнеспособные проекты уже во время обучения
- Соберите крутое портфолио для получения работы своей мечты
- Научитесь работать с HTML, CSS, JavaScript, JSX, XHR и AJAX, React, VirtualDOM, Flexbox, React Router
Как работает JavaScript
Любое действие пользователя на странице порождает событие. Программирование на JavaScript — это обработка событий. Вот как выглядит обычный сценарий:
Пользователь что-то сделал на странице
↓
В браузере сработало событие
↓
Запустился JavaScript-код, который назначен на событие
↓
JavaScript изменил что-то на странице.
Программист пишет обработчик только для тех событий, на которые стоит реагировать:
Пользователь кликнул мышью
↓
Сработало событие onclick
↓
Запустилась функция changePhoto
↓
В галерее сменилось фото
Пользователь нажал клавишу
↓
Сработало событие onkeydown
↓
Программист не назначил обработчик события
↓
Ничего не произошло
JavaScript — это, прежде всего, реакция на события
Чем хорош JavaScript
JavaScript полностью интегрирован с HTML, он способен как угодно менять веб-страницу. В ответ на событие программист может:
- на лету вставить в HTML-код любые теги;
- задать внешний вид элементов через класс и атрибуты HTML;
- переместить любой элемент;
- запросить у пользователя данные;
- отправить запрос на сервер (технология AJAX).
Это только то, что сразу пришло в голову. JavaScript может намного больше, в пределах своей страницы он Бог.
JavaScript — подходящий язык для изучения программирования. Он достаточно прост, но содержит все фундаментальные вещи: алгоритмы, объектно-ориентированную модель, структуры данных. Если традиционные языки для обучения — Pascal и Basic — несут мало практической пользы, то JavaScript — рабочая лошадка.
Начинать с JavaScript хорошо и потому, что синтаксически он похож на великий и ужасный язык С. Изучив JavaScript, получишь базовое представление обо всех «сиобразных» языках: С++, C#, Java, PHP. Они задают тренд в своих областях и весьма популярны, поэтому для новичка важно познакомиться с синтаксисом С.
Программа на JavaScript — это простой текст. Писать на JavaScript можно в любом текстовом редакторе.
В пределах своей страницы JavaScript — Бог
Ограничения
Классический JavaScript — это язык программирования для интернета, он бессилен за пределами браузера. С помощью JavaScript нельзя запустить программу на компьютере или записать файл в нужную папку.
Из-за правил безопасности браузеры ограничивают мощь JavaScript и за пределами «родной» страницы. Управлять вкладками можно при определенных условиях или же вовсе нельзя. Например, JavaScript может закрыть только ту вкладку, которую создал сам.
Год-два назад появились платформы Node.js и React Native, с ними на JavaScript пишут не только для браузера, но и для компьютеров со смартфонами. Это модные и трендовые технологии, но глобально JavaScript — язык программирования для интернета.
На JavaScript пишут для интернета и браузеров
Конкуренты
Сейчас в веб-программировании нет ничего, что способно пошатнуть позиции JavaScript. Язык настолько удачен, что нет причин изобретать что-то другое.
С чистым JavaScript конкурируют только надстройки над ним: CoffeeScript, TypeScript, Dart. Код надстроек порой компактнее, его легче читать и отлавливать ошибки, но перед выполнением он все равно преобразуется в JavaScript.
Главная сила JavaScript — вечная молодость. Он вышел 21 год назад, но не устарел, а развивался и развивается вслед за HTML.
Серьезных конкурентов у JavaScript нет
Что изучать до JavaScript
Можно приступать к JavaScript, вообще не имея представления о программировании. JavaScript — удачный выбор для первого языка, особенно если связываешь будущее с веб-разработкой. При этом любые знания в сфере программирования будет плюсом.
Если есть опыт HTML и CSS, совсем хорошо. Создание сайта логично начать со статичных страниц на HTML и CSS, а потом оживить их при помощи JavaScript. Плюс HTML и CSS дают базовое понимание того, как устроен интернет и работают сайты.
JavaScript — подходящий первый язык, если связываешь будущее с веб-разработкой
Куда развиваться JavaScript-программисту
Изучив основы JavaScript, можно копать так глубоко, как хочется.
Хорошо освоить библиотеки и фреймворки для JavaScript — наборы готовых классов с функциями. Некоторые из них настолько мощные, что полностью меняют сценарии программирования. Для JavaScript самые популярные фреймворки и библиотеки — React, jQuery и Angular2.
Кроме фреймворков полезно изучить надстройки над JavaScript: CoffeeScript, TypeScript и Dart. Одни надстройки сделают ваш код чище и компактнее, другие — строже.
Наконец, можно взяться за серверное программирование и Node.js. Это трендовая технология, которую используют BMW, Amazon, Apple и другие серьезные компании. Так вы расширите область своих знаний JavaScript за пределы управления веб-страницей.
Для JavaScript-программиста нет потолка развития
Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии
Бесплатный курс
Источник: netology.ru