Всем привет. Очень часто перед разработчиками стоит выбор. Это может быть выбор библиотеки, выбор алгоритма, выбор архитектуры. Рассмотрим выбор между Angular или React
Читая о плюсах React, авторы приводят в пример небольшой размер библиотеки. Тогда как у Angular больше. Для маленького, возможно для среднего приложения это важно. Крупные проекты достигают несколько мегабайт. Разница в 100 или 200 килобайт большой роли не играют.
React прост в освоении. Angular напротив сложнее. Angular предоставляет множество функциональности. Это полноценный framework. Если вам нужен widget на сайте или простой сайт, такие сложности излишне. Чаще такие задачи ставят перед новичками. В этой ситуации выбор очевиден в пользу React. Большие приложения не бывают простыми. Не важно React или Angular, придется тщательно продумывать архитектуру, вспомогательные библиотеки. Angular из коробки обладает большим набором инструментов, которые разработчики Angular тестируют как единое целое. При выборе React, придется самостоятельно выбирать библиотеки для работы с ajax, маршрутом. Каждое обновление может сопровождаться болью и страданиями. Angular предлагает, где-то диктует свои правила, для больших команд это плюс. React напротив. В итоге все равно придумывают свои правила
Сколько восторженных авторов про virtual DOM. Сколько примеров высоких показателей производительности virtual DOM. Так ли на самом деле в реальных проектах? Сначала определим почему DOM медленный. Ответ — геометрия. После каждого изменения ширины элемента, экрана, браузер вычисляет расположение элементов и готовит отображение. Частые геометрические манипуляции приводят к тормозам. Пусть браузеры и улучшаются с каждым годом, но кардинально не стоит ожидать чуда. Вместо того, чтобы менять элементы поштучно, выгоднее обновлять html оптом. Что и делает virtual DOM. Кажется, что Incremental DOM проиграл, но не совсем так. Изменение состояния в компоненте Reac вызывает функцию render. Если есть дочерние компоненты, то идет вызов render по цепочке вниз. Насколько производительно будет приложение, если вложенность компонентов будет достигать 100 или 1000 уровней? У меня ответа нет, думаю будет ухудшаться с увеличением уровней. Angular, при первом вызове render, также работает с virtual DOM. Лишь второй и последующие вызовы работаю с DOM. Не все вызовы обновления представления компонента Angular приводят к изменению DOM компонента. Значит и нет падения производительности. Как писал выше, геометрия является источником тормозов. Значит, изменение цвета элемента браузер выполнит быстро. Только React не делит изменения геометрии или цвета, он просто запустить render. Еще одним аргументом выбора Incremental DOM Google — экономия оперативной памяти. Не секрет, что virtual DOM требует копию DOM приложения
React и Angular имеют свои плюсы и минусы. React хорошо подходит для небольших и не сложных проектов, где больше статичного контента и вовлечены в основном молодые разработчики. Angular требует основательности и позволяет решать сложные задачи, с большим количеством динамического контента. При решении простых задач выглядит монстром
Размер конечного приложения
Читая о плюсах React, авторы приводят в пример небольшой размер библиотеки. Тогда как у Angular больше. Для маленького, возможно для среднего приложения это важно. Крупные проекты достигают несколько мегабайт. Разница в 100 или 200 килобайт большой роли не играют.
Простота или сложность
React прост в освоении. Angular напротив сложнее. Angular предоставляет множество функциональности. Это полноценный framework. Если вам нужен widget на сайте или простой сайт, такие сложности излишне. Чаще такие задачи ставят перед новичками. В этой ситуации выбор очевиден в пользу React. Большие приложения не бывают простыми. Не важно React или Angular, придется тщательно продумывать архитектуру, вспомогательные библиотеки. Angular из коробки обладает большим набором инструментов, которые разработчики Angular тестируют как единое целое. При выборе React, придется самостоятельно выбирать библиотеки для работы с ajax, маршрутом. Каждое обновление может сопровождаться болью и страданиями. Angular предлагает, где-то диктует свои правила, для больших команд это плюс. React напротив. В итоге все равно придумывают свои правила
Incremental DOM и Virtual DOM
Сколько восторженных авторов про virtual DOM. Сколько примеров высоких показателей производительности virtual DOM. Так ли на самом деле в реальных проектах? Сначала определим почему DOM медленный. Ответ — геометрия. После каждого изменения ширины элемента, экрана, браузер вычисляет расположение элементов и готовит отображение. Частые геометрические манипуляции приводят к тормозам. Пусть браузеры и улучшаются с каждым годом, но кардинально не стоит ожидать чуда. Вместо того, чтобы менять элементы поштучно, выгоднее обновлять html оптом. Что и делает virtual DOM. Кажется, что Incremental DOM проиграл, но не совсем так. Изменение состояния в компоненте Reac вызывает функцию render. Если есть дочерние компоненты, то идет вызов render по цепочке вниз. Насколько производительно будет приложение, если вложенность компонентов будет достигать 100 или 1000 уровней? У меня ответа нет, думаю будет ухудшаться с увеличением уровней. Angular, при первом вызове render, также работает с virtual DOM. Лишь второй и последующие вызовы работаю с DOM. Не все вызовы обновления представления компонента Angular приводят к изменению DOM компонента. Значит и нет падения производительности. Как писал выше, геометрия является источником тормозов. Значит, изменение цвета элемента браузер выполнит быстро. Только React не делит изменения геометрии или цвета, он просто запустить render. Еще одним аргументом выбора Incremental DOM Google — экономия оперативной памяти. Не секрет, что virtual DOM требует копию DOM приложения
Вывод
React и Angular имеют свои плюсы и минусы. React хорошо подходит для небольших и не сложных проектов, где больше статичного контента и вовлечены в основном молодые разработчики. Angular требует основательности и позволяет решать сложные задачи, с большим количеством динамического контента. При решении простых задач выглядит монстром