Comments 13
Вчера смотрел вот этот видос про dioxus - https://www.youtube.com/watch?v=rzzwa9qiLj0
Там примерно теже самые аргументы за и против его конкурентов как и у автора статьи.
Но мне больше интересно мнение тех кто попробовал и отказался по каким-то причинам (то есть не пытается мне его продать). Кто пробовал? Стоит с ним связываться вообще?
Интересное видео. спасибо. Обязательно посмотрю. А какой у вас кейс? Если расскажете подробнее можем порассуждать над лучшим решением для вашего кейса)
Отказались от React-Native внутри компании. Причина в больших накладных расходах на maintenance и крайне низком качестве экосистемы - значительная часть библиотек не работает со свежими версиями RN, приходятся патчить нативным кодом. In-App payments для android и ios реализуются по-разному порождая platform-specific код. Перфоманс всех текущих решений для интеграции карт тоже требует нативный код
В итоге разработка обходится примерно на 20% дешевле, но сложности при дальнейшей поддержке полностью нивелируют эту экономию
Имхо mvp можно и на pwa протестировать…
Ещё один любитель делать оформление через LLM)
И где-то с середины пошла вода, бросил
Flutter использует свой движок (Skia)
Может Impeller? И я цепляюсь не потому, что заподозрил отставшую от жизни нейронку, а потому, что жизнь меняется. А раз так, то вопрос
Какой фреймворк выбрать
просто вредный - ни будущего вообще, ни будущего проекта, не угадаешь. Особенно если хорошо обосновано, что
Но в любом случае — не строй собор на болоте. Сделай MVP, получи метрики, и тогда строй храм.
а оно очень похоже на правду. И метрики, кстати, перпендикулярны фреймворку. А вот то, что в необходимости храма стоит убедиться - с этим не поспоришь.
Обосновать можно всё что угодно.
Не знаю из кого, но точно цитата. Обоснование подкреплённое историей - survivor bias.
Когда решают нерешаемую задачу, цепляться можно через слово. Например:
Подходит, если у вас уже есть веб-команда,
Это про React Native. Но позвольте, тогда тут же находим
Часто нужно писать бриджи для работы с нативом. Производительность хуже Flutter. UI-компоненты могут лагать или вести себя не так, как в нативе.
А производительность Flutter уже не беспроблемна, ибо
Иногда страдает производительность (особенно в сложной графике или при тяжелом скролле).
То есть React Native, выбранный строго на основании наличия команды - путь не к MVP, а к провалу.
Или так:
Нужно писать два приложения = выше бюджет и сроки
Не обязательно для бюджета. Скорее неверно для сроков. А шансы на то, что ко Христову Дню вожделенное Яичко будет хотя бы на одной платформе - много, где-то втрое, выше... Ниже тоже точно цитата, откуда - тоже не помню,
Дублирование и резервирование - основа повышения надёжности.
Кроме того, мне не нравится логика статьи вообще. Автор в плену и мерзавцы заставляют его выбирать из натива, Flutter, React Native и KMM? А при попытке потянуться к чему-то другому - смерть? На свободе то MVP можно сделать на чём угодно, хоть на Python, хоть на Rust, хоть на Go, хоть на C#... и вариантов слишком много для перебора. Поэтому перед перебором полезно структурировать.
Типа - Web View берём? Если да, то какой - свой или системный? Если нет - компоненты рисуем сами или поручаем это системе? Вопросы, вроде, логичные - ответами легко получаем Flutter, натив, неупомянутый но модный Tauri... и с большим трудом логически неочевидный React Native.
И на этом уровне шансов как-то угадать больше в разы, но беда в том, что на что ни умножай ноль...
И ещё раз не нравится логика - из того. что Переслегин называет балансом (задача - фреймворк - разработчик), выброшен разработчик. А ведь более чем вероятна ситуация, когда плохой выбор фреймворка для конкретной задачи (а ведь автор понимает - если собрал метрики и увидел что говно, то всё равно никто не погибнет) окажется наилучшим для того, что Переслегин называет стратегией.
Вывод комментирующего, но решать Вам!
Не заморачивайтесь выбором фреймворка вообще. Если проект выстрелит - перепишите на чём угодно хоть тысячу раз. Просто не пишите говнокод который невозможно понять - это плохо и если будете периписывать, и если не будете.
Как руководство к действию - ещё одна цитата, возможно, искажённая:
Делай что хочешь, таков и будет весь закон.
Спасибо за ваше мнение, я старался поделиться своим. Классно что выстраивается диалог, много поинтов где с вами согласен
Так и по React Native уже устаревшая информация, как-будто из 2021
Нет уже никакого бриджа, уже давно в стейбле новая архитектура, JSI, Hermes который поправили перфоманс и не используют уже бридж.
Плюс вообще ни слова про Expo не сказано тоже
Надо делать на веб-стеке. PWA/TWA и меньше играться с нативом. Почти за бесплатно получается веб-версия которую можно оперативно тестировать и которая плюс-минус будет одинаково работать на всех девайсах.
Конечно же VUE наше все.
А если приложению уж очень надо нативные API, их можно сделать в обёртке и мокнуть в Web-версии. Но опять-таки Web-api настолько мощное, что на нём можно делать драйвера (WebHid, WebUsb).
Я, конечно, не специалист в мобильных фреймворках, но единственное, что реально интересует инвесторов стартапах, – это, как быстро ты сможешь выйти на окупаемость. И тут важнейшую роль играют не технологические особенности фреймворка, а то, насколько быстро ты сможешь собрать команду и насколько дёшево у тебя будет, а также то, насколько легко будет найти замену ушедшим разработчикам. Таким образом, брать нужно тот фреймворк, на котором банально больше разработчиков
Adonis + Edge + Alpine + HTMX
Мой топчик для собственных новых проектов
Какой фреймворк выбрать для MVP стартапа: опыт разработчика и фаундера