JavaScript

Чем функциональные компоненты React отличаются от компонентов, основанных на классах? Уже довольно давно традиционный ответ на этот вопрос звучит так: «Применение классов позволяет пользоваться большим количеством возможностей компонентов, например — состоянием». Теперь, с появлением хуков, этот ответ больше не отражает истинное положение дел.

Возможно, вы слышали о том, что один из этих видов компонентов отличается лучшей производительностью, чем другой. Но какой именно? Большинство бенчмарков, которыми это проверяют, имеют недостатки, поэтому я делал бы выводы, основываясь на их результатах, с большой осторожностью. Производительность, в основном, зависит от того, что происходит в коде, а не от того, выбраны ли для реализации неких возможностей функциональные компоненты или компоненты, основанные на классах. Наше исследование показало, что разница в производительности между разными видами компонентов незначительна. Однако надо отметить, что применяемые при работе с ними стратегии оптимизации немного различаются.



Я, в любом случае, не рекомендую переписывать существующие компоненты с применением новых технологий если на то нет веских причин, и если вы не против оказаться в числе тех, кто раньше всех начал этими технологиями пользоваться. Хуки — это всё ещё новая технология (такая же, какой была библиотека React в 2014 году), и в руководства по React ещё не попали некоторые «передовые методики» их применения.

Привет, Хабр! Представляю вашему вниманию мой перевод статьи "The Three Big Lies About JavaScript" автора Richard Kenneth. Данная статья была написана в мае 2016 года, однако ее актуальность, на мой взгляд, не исчезла. Я начинающий программист, поэтому возможны ошибки в плане «понимания». Итак…

Три Больших Лжи о JavaScript

Есть два варианта лжи: ложь, которую мы говорим другим, и ложь, которую мы говорим себе, что бы оправдать ее

Есть три больших лжи, которые JavaScript поклонники говорят мне снова и снова.

Ложь#1

JavaScript – это самый неправильно понимаемый язык программирования в мире.
Люди не знают, как правильно им пользоваться, и поэтому они постоянно попадают во всевозможные неприятности. И это ложь, потому что в JavaScript нет ничего непонятного.

Это заурядный императивный / процедурный язык программирования с небольшим количеством функциональных возможностей программирования (ФП) и спорной “объектно-ориентированной” функцией, называемой прототипами объектов. И что же здесь особенного?

В основном, все проблемы, возникающие при использовании JavaScript, являются виной только людей, которые его используют: они невежественны, они ленивы, они привыкли к тому, как программирование выполняется на Java или Python.Чего же они не знают? Функционального программирования?

Почему же тогда люди не ошибаются при использовании других языков ФП, таких как C#, Clojure, Dart, Elm, Erlang, F#, Julia, Haskell, Scala и Scheme? Функциональное программирование является достаточно хорошо понятной парадигмой в IT-индустрии. Так что же тогда делает JavaScript, таким особенно проблематичным в этом отношении?

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

В заметке я расскажу о моем опыте прохождения курсов по web разработка в школах: специалист, loft school, html academy, learn.javascript.ru. Эта заметка будет интересная всем, кто интересуется веб разработкой и всерьез думает сделать это своей работой. Подобные мысли заняли меня 2 года назад. Тогда я работал инженером. Сейчас я работаю frontend разработчиком в банке, поддержка ветхого сайта на битрикс и разработка нового на react, так что обучение не прошло даром. Мне периодически задают вопросы, где можно поучиться веб разработке и с чего начать, по этому я решил систематизировать свой опыт.

Итак, я решил, что курсы с четким планом обучения, заданиями и проверкой со стороны преподавателя (наставника) это самый короткий путь к мой цели, так и вышло. Но пройденные курсы сильно различались, а проходил я их специально в разных школах.

Примечание. Сокращенный перевод, скорее пересказ своими словами.
UPD: как отметили в комментариях, примеры не идеальны. Автор не ищет лучшее решение задачи, его цель объяснить сложность алгоритмов «на пальцах».

Big O нотация нужна для описания сложности алгоритмов. Для этого используется понятие времени. Тема для многих пугающая, программисты избегающие разговоров о «времени порядка N» обычное дело.

Если вы способны оценить код в терминах Big O, скорее всего вас считают «умным парнем». И скорее всего вы пройдете ваше следующее собеседование. Вас не остановит вопрос можно ли уменьшить сложность какого-нибудь куска кода до n log n против n^2.

Структуры данных

Выбор структуры данных зависит от конкретной задачи: от вида данных и алгоритма их обработки. Разнообразные структуры данных (в .NET или Java или Elixir) создавались под определенные типы алгоритмов.

Часто, выбирая ту или иную структуру, мы просто копируем общепринятое решение. В большинстве случаев этого достаточно. Но на самом деле, не разобравшись в сложности алгоритмов, мы не можем сделать осознанный выбор. К теме структур данных можно переходить только после сложности алгоритмов.

Здесь мы будем использовать только массивы чисел (прямо как на собеседовании). Примеры на JavaScript.

Сегодня мы продолжим разговор об использовании форм в React. В прошлый раз мы рассматривали особенности взаимодействия компонентов и текстовых полей. Здесь же мы обсудим работу с другими элементами форм.



→ Часть 1: обзор курса, причины популярности React, ReactDOM и JSX
→ Часть 2: функциональные компоненты
→ Часть 3: файлы компонентов, структура проектов
→ Часть 4: родительские и дочерние компоненты
→ Часть 5: начало работы над TODO-приложением, основы стилизации
→ Часть 6: о некоторых особенностях курса, JSX и JavaScript
→ Часть 7: встроенные стили
→ Часть 8: продолжение работы над TODO-приложением, знакомство со свойствами компонентов
→ Часть 9: свойства компонентов
→ Часть 10: практикум по работе со свойствами компонентов и стилизации
→ Часть 11: динамическое формирование разметки и метод массивов map
→ Часть 12: практикум, третий этап работы над TODO-приложением
→ Часть 13: компоненты, основанные на классах
→ Часть 14: практикум по компонентам, основанным на классах, состояние компонентов
→ Часть 15: практикумы по работе с состоянием компонентов
→ Часть 16: четвёртый этап работы над TODO-приложением, обработка событий
→ Часть 17: пятый этап работы над TODO-приложением, модификация состояния компонентов
→ Часть 18: шестой этап работы над TODO-приложением
→ Часть 19: методы жизненного цикла компонентов
→ Часть 20: первое занятие по условному рендерингу
→ Часть 21: второе занятие и практикум по условному рендерингу
→ Часть 22: седьмой этап работы над TODO-приложением, загрузка данных из внешних источников
→ Часть 23: первое занятие по работе с формами
→ Часть 24: второе занятие по работе с формами

19 апреля в Екатеринбурге пройдет конференция разработчиков DUMP. Традиционно мы публикуем обзоры секций от программных директоров.

Первый наш пост о секции Frontend. Программный директор секции Анастасия Катаева рассказала, что интересного будет в секции и зачем на нее идти.

Андрей Ситник из Злых марсиан — одно из самых известных российских имён во фронтенде: у его проектов PostCSS и Автопрефиксер счёт GitHub-звёзд идёт на десятки тысяч. Но поскольку Андрей живёт в Нью-Йорке, а путешествует по всей планете, застать в России его можно нечасто.

В мае он будет в Петербурге на конференции HolyJS, и по этому поводу его подробно расспросили участники программного комитета HolyJS Дмитрий DmitryMakhnev Махнёв и Максим Юзва. Почему Андрей считает, что фронтенд стагнирует, а код наших проектов излишне разбухший? В чём различия IT-сообществ разных стран? Как учить английский и почему это менее важно, чем кажется? Куда пропал проект Logux, презентованный на HolyJS ещё в 2016-м?

Добрый день!

История данной публикации довольно проста и, возможно, знакома многим. В компании разрабатывается множество продуктов — в нашем случае, в основном, для одного заказчика. В последнее время все решения разрабатываются под web, а существующие desktop-решения на web переносятся.

В связи с этим, при наличии желания увеличить скорость разработки и обеспечить единообразие продуктов, было решено разработать общую компонентную базу. О том, как создавался ui kit, и о долгих боях с дизайнерами мы умолчим, а вот о реализации данной задачи я и хочу поговорить.
На фронте у нас демократия или даже анархия. Люди вольны использовать те решения, с которыми им удобно работать. На данный момент в бою есть проекты на AngularJS, Angular, React, Vanilla, и есть также проекты на Vue для внутреннего использования. Вот на этом моменте наш взор и обратился на web components.

Символьные примитивы — это одно из новшеств стандарта ES6, которое принесло в JavaScript некоторые ценные возможности. Символы, представленные типом данных Symbol, особенно полезны при использовании их в качестве идентификаторов свойств объектов. В связи с таким сценарием их применения напрашивается вопрос о том, что такого они могут, чего не могут строки.



В материале, перевод которого мы сегодня публикуем, речь пойдёт о типе данных Symbol в JavaScript. Начнём мы с обзора некоторых возможностей JavaScript, в которых нужно ориентироваться для того, чтобы разобраться с символами.