React Native также позволяет реализовывать нативные решения и интегрировать их в проект, это не преимущество KMM.
Если уж по чесноку, то в преимущество KMM я бы записал возможность реализовать бизнес логику 1 раз в SDK и поставлять этот SDK под разные платформы, вот тут кроется самый его большой плюс, но опять же у нас есть C++, он тоже дает такую возможность.
Сейчас я вижу, что KMM могут себе позволить только большие команды, проекты на старте скорее всего погибнут в веренице интеграций и количестве участников в проекте, в то время, как маркетплэйс может реализовать на Flutter 1 человек для двух платформ.
Итого получается, я, как разработчик, могу взять Flutter или React Native и написать 1 приложение для двух платформ (оговорюсь, что минимальные знания Java и ObjC все же потребуются), скомпилировать его и отправить в сторы, а вот чтобы написать на KMM, мне потребуется написать бизнес логику, потом написать UI для каждой платформы, которую я хочу поддерживать.
1 раз написал - используешь везде в случае KMM работает на пол шишечки, простите.
Они могут предоставлять любое железо в комплекте с тем набором услуг, которые описаны в статье. Если вы скажете — мы абьюзоустойчивый хостинг, но вот вам камни 2006 года и 2гб оперативки за 100 евро в месяц, поверьте мне, от клиентов будет не отбиться.
При этом, железо может стоять с 2006 года, без проблем, никто не будет его менять, если оно исправно работает.
Переезд клиента на новый сервер также очень затратное дело, многие клиенты отказываются переезжать просто потому, что у них «все и так работает».
Expo закрыли возможность делиться приложением через QR код с другими пользователями, теперь это можно сделать только в рамках одного аккаунта, что не лучше чем стандартный Testflight. Кроме того, как было сказано в статье, eject приведет вас к приложению, завязанному на Expo и в какой-то момент вы перепишете все на обычный RN.
По поводу разработки под iOS без симулятора скажу так, поставьте виртуалку и запускайте проверку реализации там, кроме того, есть разные UX паттерны для iOS/Android, тот же свайп влево в почте, в Android для этого используется длительное нажатие с выпадающим контекстым меню.
Здесь были уже статьи про RN, как человек с огромным опытом разработки скажу так — берите Swift/Kotlin, если нет денег на двух разработчиков — берите RN, но закладывайте на перспективу реализацию всего в виде нативных приложений. Рано или поздно вам придется столкнуться с проблемами RN, которые заставят вас отказаться от этого замечательного решения, как бы вам этого не хотелось.
увы да, особенно это было великолепно на стыке RN 0.59 с 0.60 и одновременным обновлением до Xcode 11, в котором они изменили несколько нативных методов. Вы просто не могли запустить RN0.59 на Xcode11, и хотя потом вышла заплатка для RN, вы все равно сделать бы это не смогли XD
Самые сильные Frontend разработчики, с котороыми мне довелось работать, именно те, чьим первым языком были Java или C#. Их код чище, шаги продуманы, ну и в целом они умеют писать весьма приятный код.
Мне вот интересно, долго еще Javascript разработчики будут удивляться, что все работает именно так, как работать должно и именно так, как написано в документации?
С той единственной разницей, что код в статьях синтетический и, как правило, то, что лежит в репозитории проекта на 100% отличается от того, что написано в статьях. Ведь рано или поздно к вам придет бизнес и скажет, мы не учли вот эти критерии. После этой фразы вся красота растворяется в «бизнес логике».
Поймите, Redux тоже брали из рассчета, что он решит все насущные проблемы, однако потом вдруг выяснилось, что в рендер компонентов каждый раз прилетает новый объект (даже если данные не изменились), кто-то не уследил за код-ревью и в рендер упал Array.map и был передан в компонент ниже и так далее, а может код ревью не было вовсе?
Интересно, насколько такой хак легален с точки зрения безопасности компании? Одобрит ли команда internals красивую черную тему, которая тянет что-то из gist?
Заголовок статьи должен звучать так — «Сложность фронтенда возросла настолько, что пора читать Кнута и „Design Patterns“ но я не хочу, мне проще уйти».
В нашей компании мы замечаем, что фронтенд, как достаточно молодое направление разработки, нуждается в людях с классическим академичиским образованием, в тех, кто изучал Java, C#, в тех, кто мыслит типами. К сожалению сейчас засилье Javascript разработчиков, которые знают только и учили только Javascript. Большинство из них даже не будет знать о существовании bigint в вашем PostgreSQL.
Вот только люди с академическим образованием предпочитают держаться в стороне от фротенда, и я их в этом прекрасно понимаю.
у Николаса Галлахера был подход, где он заменил _ на — и выглядит вполне сносно, пока стили не начинают расти и ты такой:
.my-awesome-new-component_element
Ой, но ведь я не пользуюсь нижним подчеркиванием
.my-awesome-new-component-element // не то
.myAwesomeNewComponent-element // и вот тут ты понимаешь, что что-то пошло не так
Спасибо больше, не знал, надо посмотреть
React Native также позволяет реализовывать нативные решения и интегрировать их в проект, это не преимущество KMM.
Если уж по чесноку, то в преимущество KMM я бы записал возможность реализовать бизнес логику 1 раз в SDK и поставлять этот SDK под разные платформы, вот тут кроется самый его большой плюс, но опять же у нас есть C++, он тоже дает такую возможность.
Сейчас я вижу, что KMM могут себе позволить только большие команды, проекты на старте скорее всего погибнут в веренице интеграций и количестве участников в проекте, в то время, как маркетплэйс может реализовать на Flutter 1 человек для двух платформ.
Итого получается, я, как разработчик, могу взять Flutter или React Native и написать 1 приложение для двух платформ (оговорюсь, что минимальные знания Java и ObjC все же потребуются), скомпилировать его и отправить в сторы, а вот чтобы написать на KMM, мне потребуется написать бизнес логику, потом написать UI для каждой платформы, которую я хочу поддерживать.
1 раз написал - используешь везде в случае KMM работает на пол шишечки, простите.
При этом, железо может стоять с 2006 года, без проблем, никто не будет его менять, если оно исправно работает.
Переезд клиента на новый сервер также очень затратное дело, многие клиенты отказываются переезжать просто потому, что у них «все и так работает».
По поводу разработки под iOS без симулятора скажу так, поставьте виртуалку и запускайте проверку реализации там, кроме того, есть разные UX паттерны для iOS/Android, тот же свайп влево в почте, в Android для этого используется длительное нажатие с выпадающим контекстым меню.
Здесь были уже статьи про RN, как человек с огромным опытом разработки скажу так — берите Swift/Kotlin, если нет денег на двух разработчиков — берите RN, но закладывайте на перспективу реализацию всего в виде нативных приложений. Рано или поздно вам придется столкнуться с проблемами RN, которые заставят вас отказаться от этого замечательного решения, как бы вам этого не хотелось.
Поймите, Redux тоже брали из рассчета, что он решит все насущные проблемы, однако потом вдруг выяснилось, что в рендер компонентов каждый раз прилетает новый объект (даже если данные не изменились), кто-то не уследил за код-ревью и в рендер упал Array.map и был передан в компонент ниже и так далее, а может код ревью не было вовсе?
В нашей компании мы замечаем, что фронтенд, как достаточно молодое направление разработки, нуждается в людях с классическим академичиским образованием, в тех, кто изучал Java, C#, в тех, кто мыслит типами. К сожалению сейчас засилье Javascript разработчиков, которые знают только и учили только Javascript. Большинство из них даже не будет знать о существовании bigint в вашем PostgreSQL.
Вот только люди с академическим образованием предпочитают держаться в стороне от фротенда, и я их в этом прекрасно понимаю.
.my-awesome-new-component_element
Ой, но ведь я не пользуюсь нижним подчеркиванием
.my-awesome-new-component-element // не то
.myAwesomeNewComponent-element // и вот тут ты понимаешь, что что-то пошло не так