Так человек и спрашивает, чем плохи ветвления и циклы. Это же не обязательно бизнес-логика. Невозможно же сделать реально применимый шаблонизатор без циклов и условий, разве не так?
Реакт не более чем инструмент, не понимаю, почему хайп вокруг него так завышает ожидания :)
Не фреймворк, продвинутый темплейтер, оптимизации — именно это и делает его таким удобным (для меня). И еще гладкая и удобная поддержка современного джаваскрипта.
Кроме того он слишком усложняет дело со своим вирруальным DOM деревом, вычисляя что именно патчить в реальном дереве.
А почему он слишком усложняет? Ну я понимаю, что алгоритмы там нетривиальные, но это же все скрыто, с ним не нужно взаимодействовать (за исключением оптимизаций, но там тоже не виртуальный ДОМ).
Почему-то любое обсуждение React быстро переходит на обсуждение производительности, потом выясняется, что нативный DOM быстрее, и делается вывод, что React отстой.
Как по мне, производительность у Реакта достаточная для большинства случаев, кроме того, есть еще запас по оптимизации. Конечно, он медленее идеального обновления ДОМ вручную.
Но, как по мне, он наиболее прямолинейный и предсказуемый, с точки зрения разработки, из всех фреймворков-лидеров. Плюс поддержка IDE у него самая лучшая. Также у Реакта наиболее "дешевое", с точки зрения производительности, дробление на компоненты — каждый компонент — это функция (либо класс), а в Ангуляре, например, это дополнительная куча watcher-ов.
Сам использую похожий самодельный велосипед с бабелем, не идеально конечно, но лучше, чем ничего. Только имя зависимости беру из MyComponentClass.name.
Конечно же, Реакт не может избежать работы с ДОМ. Это очевидно.
Реакт дает оптимизацию сценария интенсивного обновления ДОМ, предоставляя для этого легковесные джаваскрипт объекты, и применяя к ДОМ лишь конечный результат более или менее оптимальным образом.
Это всего лишь один из подходов, и странно видеть в нем решение всех проблем.
В реакте ты исользуешь в файле то, что импортировал в него. В первом ангуляре зависимости регистрируются в модуле, а используются без явного импорта. В результате сложно найти все места, которые ссылаются на определенную зависимость. Второе, зависимости указываются по строковым именам, что неудобно.
Чем лично мне, как программисту (не верстальщику) удобен jsx.
Оговорюсь сразу, что использую тайпскрипт и tsx, но многие вещи справедливы и без тайпскрипта:
Строгая типизация шаблонов и кастомных компонентов. Тайпскрипт подсказывает свойства и события, компилятор показывает ошибки в шаблонах.
Удобная работа с children. Как в ангуляре удобно работать с содержимым компонента? Никак, только через боль и страдания, через парсинг строк, обработку дом-узлов и transclude. В Реакте это просто объекты, можно обрабатывать обычным кодом.
Расширение и декорация компонентов и классов компонентов. Метапрограммирование для бедных. Но лучше, чем в строковых и dom-based шаблонах.
Нормальная работа с новыми возможностями джаваскрипта, в частности с модульностью. Ангуляр 1 бесит в этом плане, хотя без модульности он радовал.
Однако, jsx в чем-то неуловимо раздражает. Постоянно спотыкаешься на className. Зачем это было делать?!
Также теряется преимущество в разделении труда верстальщика и девелопера. Даже если научить писать вестальщика писать jsx, все его привычные методы работы не годятся.
Есть два типа команд: один тип — это команды с четкой специализацией каждого человека, раньше их было много, сейчас они, наверное, только в энтерпрайзе; второй тип — это команды из аджайл, разработчики из таких команд обычно фулл-стек, сейчас в веб деве пре-энтерпрайз таких большинство. Это один из принципов аджайл — взаимозаменяемость разработчиков, поэтому разрабам дают отдельные фичи делать "с низу до верху", от базы до верстки.
Посмотрим с другой стороны. "Специализация" в технологии часто означает то, что человек выучил что-то одно, и считает, что этого достаточно. Я знаю людей, которые за десять лет работы выучили как писать бизнес-логику на C# и MS SQL Server. Ни веба, ни десктопа, ни другой платформы они не знают. Являются ли они классными профи и убеленными сединами гуру? Нет, и более того, те люди довольно посредственные разработчики.
Большинство проектов не требуют глубинных знаний платформы. (И, кстати, шанс их получить у специалиста такой же, как и у фулл-стек разработчика. Платформа, которая требует постоянного вникания в свои тонкости, не выживает). Намного практически полезней для команды и успеха проекта навыки архитектуры и проектирования у разработчика, хотя бы в минимальном их виде.
Но хорошая архитектура — она в первую очередь для разработчиков, это ясный код, который легко использовать правильно, и сложно использовать неправильно. Для хорошего проектирования кода необходимо понимать специфику работы человека, который будет использовать твой код.
Но навыки проектирования (это именно навыки, не знания, теория тут не очень помогает) очень сложно получить, не побывав в роли пользователя своего же, или похожего, кода. Сложно извлечь урок проектирования и архитектуры из проекта, в котором ты можешь понять только часть. Сложно разработать хороший веб-апи, если ты никогда не использовал веб-апи.
Вот и получается бизнес-логика, которая требует целого слоя для адаптации к UI. Веб-апи, к которым нужно делать три запроса вместо одного. Постоянные обсуждения и переделки формата запросов и ответов (т.к. разрабатывают это разные люди, каждый из которых не понимает специфики другой части).
Это было бы так, отличайся они принципиально. Фронтенд фреймворки построены на нескольких базовых идеях, и разобравшись с четырьмя из них, с пятым разберешься с ходу.
К сожалению, не любой. Я думаю, здесь ситуация во многом похожа на спортивные достижения. Благодаря тренировкам можно стать намного сильнее и быстрее нетренированного человека, но невозможно стать, например, олимпийским чемпионом без генетической предрасположенности.
В науке и проще, и сложнее, можно сделать открытие случайно, не являясь лучшим из лучших, можно сильно двинуть область и за счет тяжкого многолетнего труда, не являясь, опять же, гением.
Но вот именно гениальные озарения, в любой области, к сожалению, недоступны середнячкам, я так считаю.
Нет, причем тут react-id. Я об "умном" обновлении ДОМ дерева, том, что, собственно, и делает Реакт реактивным.
В Реакте дерево ДОМ элементов является функцией, или проекцией, состояния приложения. И при изменении этого состояния дерево элементов перестраивается не полностью, а частично, производя минимальные изменения, необходимые для приведения дерева в нужное состояние.
Если не использовать Реакт (и другие virtual DOM библиотеки), то придется либо перестраивать все дерево полностью — и забыть о производительности, либо, как в Ангуляре, оптимизировать перестроение дерева для каждой отдельной директивы.
Я понял, вы имели ввиду без императивных циклов. Я думал, вы имели ввиду без итерации вообще, что, очевидно, бессмысленно.
В XSLT тоже есть включение по условию и итерация по набору, хотя это и не классический императивный цикл, но суть-то одна.
В JSX тоже можно при желании написать нечто вроде:
Только это лишнее усложнение.
Так человек и спрашивает, чем плохи ветвления и циклы. Это же не обязательно бизнес-логика. Невозможно же сделать реально применимый шаблонизатор без циклов и условий, разве не так?
Реакт не более чем инструмент, не понимаю, почему хайп вокруг него так завышает ожидания :)
Не фреймворк, продвинутый темплейтер, оптимизации — именно это и делает его таким удобным (для меня). И еще гладкая и удобная поддержка современного джаваскрипта.
А почему он слишком усложняет? Ну я понимаю, что алгоритмы там нетривиальные, но это же все скрыто, с ним не нужно взаимодействовать (за исключением оптимизаций, но там тоже не виртуальный ДОМ).
Да ладно вам. В соседней теме на Ext JS разрабатывали, и не смущала производительность до поры :)
Почему-то любое обсуждение React быстро переходит на обсуждение производительности, потом выясняется, что нативный DOM быстрее, и делается вывод, что React отстой.
Как по мне, производительность у Реакта достаточная для большинства случаев, кроме того, есть еще запас по оптимизации. Конечно, он медленее идеального обновления ДОМ вручную.
Но, как по мне, он наиболее прямолинейный и предсказуемый, с точки зрения разработки, из всех фреймворков-лидеров. Плюс поддержка IDE у него самая лучшая. Также у Реакта наиболее "дешевое", с точки зрения производительности, дробление на компоненты — каждый компонент — это функция (либо класс), а в Ангуляре, например, это дополнительная куча watcher-ов.
Сам использую похожий самодельный велосипед с бабелем, не идеально конечно, но лучше, чем ничего. Только имя зависимости беру из
MyComponentClass.name.Ну хоть в JSX могли бы разрешить
class. Хотя однообразие, конечно.Конечно же, Реакт не может избежать работы с ДОМ. Это очевидно.
Реакт дает оптимизацию сценария интенсивного обновления ДОМ, предоставляя для этого легковесные джаваскрипт объекты, и применяя к ДОМ лишь конечный результат более или менее оптимальным образом.
Это всего лишь один из подходов, и странно видеть в нем решение всех проблем.
В реакте ты исользуешь в файле то, что импортировал в него. В первом ангуляре зависимости регистрируются в модуле, а используются без явного импорта. В результате сложно найти все места, которые ссылаются на определенную зависимость. Второе, зависимости указываются по строковым именам, что неудобно.
Чем лично мне, как программисту (не верстальщику) удобен jsx.
Оговорюсь сразу, что использую тайпскрипт и tsx, но многие вещи справедливы и без тайпскрипта:
Строгая типизация шаблонов и кастомных компонентов. Тайпскрипт подсказывает свойства и события, компилятор показывает ошибки в шаблонах.
Удобная работа с children. Как в ангуляре удобно работать с содержимым компонента? Никак, только через боль и страдания, через парсинг строк, обработку дом-узлов и transclude. В Реакте это просто объекты, можно обрабатывать обычным кодом.
Расширение и декорация компонентов и классов компонентов. Метапрограммирование для бедных. Но лучше, чем в строковых и dom-based шаблонах.
Однако, jsx в чем-то неуловимо раздражает. Постоянно спотыкаешься на className. Зачем это было делать?!
Также теряется преимущество в разделении труда верстальщика и девелопера. Даже если научить писать вестальщика писать jsx, все его привычные методы работы не годятся.
Спасибо, статья понравилась, понятные и практически применимые правила для написания тестов.
Я думаю, что ничем, кроме масштабируемости отдельных сервисов.
Есть два типа команд: один тип — это команды с четкой специализацией каждого человека, раньше их было много, сейчас они, наверное, только в энтерпрайзе; второй тип — это команды из аджайл, разработчики из таких команд обычно фулл-стек, сейчас в веб деве пре-энтерпрайз таких большинство. Это один из принципов аджайл — взаимозаменяемость разработчиков, поэтому разрабам дают отдельные фичи делать "с низу до верху", от базы до верстки.
Посмотрим с другой стороны. "Специализация" в технологии часто означает то, что человек выучил что-то одно, и считает, что этого достаточно. Я знаю людей, которые за десять лет работы выучили как писать бизнес-логику на C# и MS SQL Server. Ни веба, ни десктопа, ни другой платформы они не знают. Являются ли они классными профи и убеленными сединами гуру? Нет, и более того, те люди довольно посредственные разработчики.
Большинство проектов не требуют глубинных знаний платформы. (И, кстати, шанс их получить у специалиста такой же, как и у фулл-стек разработчика. Платформа, которая требует постоянного вникания в свои тонкости, не выживает). Намного практически полезней для команды и успеха проекта навыки архитектуры и проектирования у разработчика, хотя бы в минимальном их виде.
Но хорошая архитектура — она в первую очередь для разработчиков, это ясный код, который легко использовать правильно, и сложно использовать неправильно. Для хорошего проектирования кода необходимо понимать специфику работы человека, который будет использовать твой код.
Но навыки проектирования (это именно навыки, не знания, теория тут не очень помогает) очень сложно получить, не побывав в роли пользователя своего же, или похожего, кода. Сложно извлечь урок проектирования и архитектуры из проекта, в котором ты можешь понять только часть. Сложно разработать хороший веб-апи, если ты никогда не использовал веб-апи.
Вот и получается бизнес-логика, которая требует целого слоя для адаптации к UI. Веб-апи, к которым нужно делать три запроса вместо одного. Постоянные обсуждения и переделки формата запросов и ответов (т.к. разрабатывают это разные люди, каждый из которых не понимает специфики другой части).
Это было бы так, отличайся они принципиально. Фронтенд фреймворки построены на нескольких базовых идеях, и разобравшись с четырьмя из них, с пятым разберешься с ходу.
К сожалению, не любой. Я думаю, здесь ситуация во многом похожа на спортивные достижения. Благодаря тренировкам можно стать намного сильнее и быстрее нетренированного человека, но невозможно стать, например, олимпийским чемпионом без генетической предрасположенности.
В науке и проще, и сложнее, можно сделать открытие случайно, не являясь лучшим из лучших, можно сильно двинуть область и за счет тяжкого многолетнего труда, не являясь, опять же, гением.
Но вот именно гениальные озарения, в любой области, к сожалению, недоступны середнячкам, я так считаю.
Не будет ли реализация на основе прокси иметь те же ограничения и слабости, что и Нокаут?
Ну а как же реактивность? Реакт — это же не только абстракция для кастомных элементов.
Нет, причем тут react-id. Я об "умном" обновлении ДОМ дерева, том, что, собственно, и делает Реакт реактивным.
В Реакте дерево ДОМ элементов является функцией, или проекцией, состояния приложения. И при изменении этого состояния дерево элементов перестраивается не полностью, а частично, производя минимальные изменения, необходимые для приведения дерева в нужное состояние.
Если не использовать Реакт (и другие virtual DOM библиотеки), то придется либо перестраивать все дерево полностью — и забыть о производительности, либо, как в Ангуляре, оптимизировать перестроение дерева для каждой отдельной директивы.