>> Если же приложение написано сколь-нибудь нормально, оно не лагает( если только на
>> старых бюджетных андройдофонах ).
> Даже на дисплеях 1440p 120гц со сложной вёрсткой? Как только появляется новое
> мощное железо, програмиисты находят, чем его нагрузить.Мы все еще про мобильные устройства говорим ?
Тем более, что не стОит мешать частоту кадров и скорость отрисовки( в том же RN, к примеру, при миниальнейшей оптимизации, перерисовываются лишь компоненты с измененными входными данными. Тут уж хоть с частотой 100 000 000 гц на экран выводи - никакой разницы не будет. В случае с остальным - оптимизированная анимация обычно идет через "натив" - т.е из JS в нативную часть отправляется пачка точек и проч, по которым планируется анимация, далее - сигнал для старта, после чего сама анимация происходит чисто на нативе, без обмена данными с JS-потоком, разве что по окончании ему сообщает. И это уже идет "искаропки" )
В случае с мобильными устройствами, сложная верстка - это обилие списков, в т.ч вложенных, с кучей элементов.
А просто обилие оформления - вообще не проблема, т.к без наличия изменений входных данных, они не изменяются.
Для тех случаев, где требуется что-то особо динамично отрисовывать ИМХО есть игровые движки, которые в т.ч для этого и предполагаются.
> Да, и тут уже выигрыш от удобства разработки на js не так
> очевиден, если приходится больше внимания уделять оптимизации.
Учитывая, что при этом не требуется этот бесконечный цирк с типизациями на фоне огромного обилия RN и JS-пакетов на все случаи жизни и это при наличии пакетного менеджера, все-таки плюсы есть.
Реально серьезные оптимизации требуются крайне редко.
На самом деле, нередко приходится заниматься обратным - черти-какие разрабы начитаются каких-нибудь хренабров, медиумов итд итп и на ровном месте начинают тянуть в проект гору мусора, которая, мало того, что делает код громоздким и добавляет кучу оверхеда( простой и кэповский код на JS размазывается на десяток файлов, появляются абстрактные классы, интерфейсы, публичные-приватные методы. Что, ни разобраться в этой помойке, ни просто взять и сделать правки, практически невозможно, как будто кто-то только начитался этой белиберды про паттерны и заблевал этим весь проект ) , так еще и само приложение делателя тормозным, безумно жрущим ресурсы, а сам проект - малоподдерживаемым.
> Дарт уже готов для прода, компилится сразу в исполняемый код. Библиотек разве
> что меньше и архитектура замороченная, на плюсах и то проще делать
> UI.
Дарт и его инфраструктура почти намертво к гуглу привязаны и их будущее практически полностью зависит от его прихоти - очень с серьезная неопределенность.
Вдобавок, дарт уже даже подыхал разок вроде бы как.
Потому прогеры не очень-то и спешат за него браться.
Нужен не просто исполняемый код, а максимально пережеванный, но не заточенный под конкретную архитектуру, который без серьезных проблем можно оптимально собрать под разные архитектуры( в т.ч те их модификации, которых пока даже нет ).
За подобным будущее ИМХО.
