×Закрыть

Nativescript + Angular 2 vs React Native? Где вакансии?

Всем привет, немножко о себе, значит я учу активно Angular 2\4 + Typscript, и вот для добавления красок в свое обучение, решил я значит сделать мобильное приложение.

Был выбор смотреть React Native?но так как мне и сам react не нравится, в силу того что для успешного начала проекта нужно подключать кучу разных библиотек, не нравятся темплейты, и организация проекта в целом, я искал что то с Angular 2.

Нашел Ionic, но как я понял это не совсем native app получится.

И вот я дошел к Nativescript, и пройдя туториал, я в недоумении, почему такой фреймворк, с отличной, вот серьезно документация просто отличная, они помимо того что хорошо описывают каждый шаг касаемо templates, они так же дают базовые знания о Angular 2, что мне как начинающему в Angular 2, просто огромный плюс, так как я помимо того что учу новую технологию, еще и повторяю все по Angular, так вот собственно вопрос, где вакансии?

Почему вообще нету вакансий на Nativescript?

Почему фреймворк настолько не популярен?

Он же ведь должен быть на равне с React Native, ведь зная хорошо Angular 2, ты с минимальными усилиями сможешь делать мобильные приложения с помощью Nativescript.

Может я чего не понимаю?

Поделитесь кто использовал \ использует в чем подвох?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

ха, тот же вопрос
ну вобщем есть рест веб сервис, есть кое-какая вебморда и нужен мобильный клиент, в котором будут грабить корованы
в кратце что нужно на мобильном клиенте:
— поддержка айос и андроида. только нейтив, без всяких там эмуляторов
— авторизация по номеру мобильного телефона
— примитивный crud через рест
— интеграция с гугл-мапс. ну чтоб можно было виджет (или как оно там)с гуглмапсом показать, поверх поля для ввода инфы и красиво все забиндить. ну чтоб например жпс координаты ввел в текстбокс, а оно красиво тебя на карте по тем координатах спозиционировало
— грабить корованы. куда ж без них

пока что вижу двп лидера: реакт нейтив и нейтивскрипт
душа лежит больше к нейтивскрипту, ибо нравятся мне энгулары и все тут. Но както непонятно оно там и все. Да и умных мыслей хочется послушать, ибо опыта в этом всем нету.
Вобщем, покритикуйте)

В Январе 16-ого NativeScript не заводился были глюки при сборке, чуваки в суппорте сказали — это норм, React тоже не понравился, но ReactNative тогда оказался красавчик, невероятно быстро и удобно разрабатывать.

Год назад делал мобильное приложение на NativeScript/Angular. Не знаю как сейчас, но тогда он был сыроват(NativeScript а не Angular). Сделать что-то не по туториалу было очень тяжело. Плюс не хватало сторонних компонентов. Пришлось перейти на ReactNative. С ним дело пошло быстрее.

я не ангуляный знаток, но, черт возьми, объяните мне почему:
angular 1 — js;
angular 2 — ts и js, но документации по js — на оффсайте нормальной нету;
angular 3 — де он ваще? шо тут праесходет?
angular 4 — dart ?
angular 4+ — ts, опять ts? а зачем вы dart трогали?
angular 5 — зачем?

Автором с момента выпуска версии 4 в конце марта было выпушено 50 релизов (ПЯТЬДЕСЯТ, КАРЛ!). Да он релизы делает чаще чем с женщину уестествляет.
Через два месяца после 4ой версии выпустили пятую.
Как по мне, процессом заведуют какие-то буквально наркоманы. Барыга подвез — будет релиз. Не подвез — будет депрессняк и попытки переписать все на другом языке.

angular 3 — де он ваще? шо тут праесходет?

Для 2 ангуляра Випустили роутер з версією № 3, і щоб підігнати всі модулі під 1 цифру — вирішили 3 версію перескочити.

angular 5 — зачем?

На реакті взагалі зараз 15.6.1!

Через два месяца после 4ой версии выпустили пятую.

WHAT!? Зараз по ангуляру чіткий графік — мажорна версія кожні 6 місяців.

но ведь дичь же. Я не могу аргументированно поддержать дискуссию, почему именно ангуляр плохо (ниже парень объъясняет почему), но пот такая пляска вокруг версий — это дичь, я так думаю.

Минулого руку з реліз-кандидатами отоооо була дич! Після виходу релізу 2.0 жодних революційних потрясінь, все працює, графік виходу нових версій відомий.

react вообщето даже до первой версии не дошел

Это потому, что шли 0.13, 0.14 а потом плюнули и поставили 15.0.0, сейчас 16.2.2 и ничего: народ обновляется, api не расходится, все совместимо вплоть до 13-14, если классы поменять на ES6 и простые функциональные компоненты на лямбды. Фейсбуку, Нетфликсу и другим нафиг не надо переписывать тысячи компонентов, обратная совместимость затребована. А интересно где Google у себя использует Angular 2-4,5?)

YouTube Player написан на Angular 2+

angular 3

У AngularDart есть версия 3. И он еще более наркоманский.

angular 4 — dart ?
angular 4+ — ts, опять ts? а зачем вы dart трогали?

может они спецом решили разные версии под разные языки ваять, в зависимости от того фанаты какого языка попросят? ну т.е. 4-ю версию заказали фанаты дарта — написали на дарте, 4+ — фанаты тайпскрипта) 6-ю версию закажут адепты Elm’а — напишут на Elm’е)))

Автором с момента выпуска версии 4 в конце марта было выпушено 50 релизов (ПЯТЬДЕСЯТ, КАРЛ!). Да он релизы делает чаще чем с женщину уестествляет.

и не говори)))

норм всё ) они чуть более года назад на semver решили перейти плюс всякая возня, как Іван Пащенко уже описывал...
как помню после NG2 beta4 -> beta5/6 куча воя было, и я сам чуть не решил гневным высером на гитхабе разрадиться и назад в духовный React убежать... (ну имея 2 года на Angular 1 и после этого, ешё года ожиданий и перманентно fail апдейдов, нервы слегка сдавать начинали ;)

ts, опять ts? а зачем вы dart трогали?

вот же!

Барыга подвез — будет релиз. Не подвез — будет депрессняк и попытки переписать все на другом языке

возможно что-то похожее и было, когда мы все альфу ng2 только тестить начинали, но щас имхо норм всё ) ну относительно...

ionic есть на рынке и используется. За последние два месяца получил три оффера в линкеде на ionic. Просто берут под точечный проект и ищут сами очевидно.

Ionic, всё-таки, совсем не то. Я его ковырял — в нём очень мало смысла. Разве что написать какую-либо простую морду. Сильно лимитирован, очень тормознутый. Тот же React Native сравнивать с Ionic-ом просто нельзя — из разной весовой категории (Nativescript не пробовал, не могу ничего сказать).

Я не говорю , что он классный, я говорю, что на него есть все таки спрос.

Потому, что когда выбирают реакт нейтив, за ним стоят fb, linkedin, airbnb и куча других приложений. Потому что они смогли в оптимизацию. Потому что банально технология старше, чем «наш ответ чемберлену». Потому что дебажить реакт — это одно, а дебажить ангулар, умноженный на нейтив — это вообще не представляю во сколько раз сложнее

Если не принципиально в ИТ-компанию, то есть такая вакансия, изучайте. — career.pumb.ua/ru/vacancy/it/371

Я заметил там Angular 2 (TypeScript) в списке. У автора статьи он тоже фигурирует. ) Правда не знаю, вакансия актуальна или нет.

натив на жабаскрипте...натив на жабаскрипте...чувствую, гдето тут подвох, но не могу понять где

Потому что никому не нужны мобильные аппликации на джаваскрипте

Как самостоятельный продукт — да. Но например у нас сейчас есть сайт на реакте, параллельно теми же разрабами пилится апликуха на реакт нейтиве. Вроде нормально работает

Ну на этот счет разные мнения. Я как пользователь предпочел бы опциональный (потому что они часто жутко урезаны в функциях) мобильный сайт, чем для каждого сайта качать аппликуху. Но да, для такого сценария конечно имеет смысл.

Да я честно говоря вообще не понимаю зачем эта апликуха нужна. Сайт на том же реакте, мобильная версия сделана максимально приближенной к нативным апликухам, разницы в функциональности и внешнем виде почти никакой нет.

Ну, если все начнут хотя бы следовать гугло-гайду по Progressive Web App-ам, необходимость в отдельных мордо-аппах вообще отпадет. Всё не могу дождаться, когда же это произойдёт.

Недавно писал проект для заказчика из Дании. Проект совершенно нетривиальный (не морда для веб-аппа), с кучей логики по взаимодействию с другими девайсами (принтерами, кассовыми аппаратами и т.д. и т.п.), с необходимостью нередко ковырнуть «внутрь» или самостоятельно написать либу. Реакт Нейтив был требованием клиента, не моим.

Получилось, кстати, на удивление хорошо. Перформанс отличный, сделать можно всё, что угодно, код читабельный.
Не знаю, насколько это единичный случай, но опыт был приятный.

Перформанс отличный

Вот это интересно, потому что по идее должен быть похуже чем у нейтив-приложения на java. На бюджетных устройствах тестировали?

Аппа заточена под бюджетные девайсы — клиент высылал всю технику, на которой оно должно запускаться и работать (бла-бла, аппа будет крутиться только на девайсах конкретного заведения). Мой личный девайс 4-летней давности оказался по железу сильнее того, на чем это работает у клиента.
В процессе написания появлялись скрины, которые работали хуже, но там уже была лажа в коде, а не вина Реакта, её удавалось успешно исправить.

Сравнивать с нативным Джава-приложением не возьмусь (перед глазами не было идентичного приложения на Джаве) — возможно, таки похуже, но глаз воспринимает всё хорошо, юзер-икспириенс в плане скорости работы приятный.

Сергей, могли бы рассказать в чём был плюс использования Реакт Нейтив на данном проекте? И был ли он вообще или это просто такой заказчик попался (мол, хочу и это не обсуждается)?

Вообще, тут две причины, почему использовался Реакт:

1. Клиент так твердо решил и шел в компанию с четко сформулированными хотелками (он сам технически подкован со своей командой в другой сфере).

2. Он же — основной плюс использования Реакта. Бюджет и время. Клиент хотел нанять одного девелопера, который захендлит и Андроид, и айОс. айОс потребовал дополнительного внимания и даже внесения некоторых не совсем удобных изменений в приложение. Но в целом — тоже всё прошло хорошо.
В итоге удалось успеть сделать и одно, и другое, и даже помочь фронтэнд-команде клепать веб-приложение (тоже на Реакте).

Я не являюсь проповедником универсальных «нативных приложений» в ущерб логике и здравому смыслу, когда-то в начале своего айти-пути я даже побыл полноценным Андроид-девом. Я все еще считаю, что в немалом количестве ситуаций приложение на Java/Swift наверняка будет оптимальнее и лучше.
Но тут Реакт позволил быстро и качественно дэливернуть нетривиальный результат c хорошей производительностью для двух платформ сразу. При этом всём выполнял это фулл-стэк разработчик (python + js), а не дедикейтед специалист по мобайл-разработке.

Интересный опыт. Не смотря на возможность экономии времени/бюджета, думаю эта технология слабо взлетает у нас по неск причинам:

1. Может так получиться, что вместо двух разработчиков (одного Android и одного iOS) при стандартной дедикейтед разработке, потребуется три (те два + web full-stack), а не один. Ведь вцелом, когда проект только начинается, не всегда его можно надежно и четко оценить (заказчик может и сам не знать что ему нужно, а дозреет только когда получит какую-то часть), часто всё выясняется по ходу проекта.

2. И чтобы потом саппортить код, то также может потребоваться не по одному на платформу, а по паре.

Иными словами существует риск не получить экономию времени/бюджета, а наоборот потратить больше. При этом, конечно, есть случаи, в которых всё достаточно прогнозируемо, где не требуется тяжеловесных операций на клиенте либо доступа к каким-то нативным клиентским API, и там возможна экономия времени/бюджета. С другой стороны, мне, как Android разработчику, за последние годы такие простые проекты не попадались (везде требовалось глубокое понимание своей платформы, которого бы у меня не было будь я web разработчиком).

а я вообще не видел на галерах спрос на hybrid-аппликухи (для наших локаций), только фриланс... там да, большая часть возможно именно React Native, Ionic, Nativescript,- и примерно с такой частотой востребованности.

согласен с тем, что Nativescript+NG2 весьма рулит, однако, здешний заказчик скорее-всего просто не осведомлен о наличии онного... думаю, и при поиске вакансий, вам следует обращать внимание скорее на формулировку Hybrid (не смотря на то, что он генерит нэйтив, их всё-равно к гибридным причисляют), чем какой-либо конкретный фреймверк/платформа, но опять же, здесь, в основном только Native (Java), а на гибридные больше на фрилансах спрос, имхо.

с другой стороны, для энтерпрайза и по причине весьма геморной отладки не взлетает... и вообще, оно всё только в теории такое кроссплатформенное, и типа безглючное.

зы: Телерик вообще для разрабов всегда всё писали, посему и документация всегда в адеквате и т.д., но вот продажники они фиговые... лично я как любитель ангуляра, только с их (ангуляра) блога когда-то о нём (Nativescript) узнал, и больше вообще никаких эннаунсментов или пиара... хз канешна

а реакт(вставить сюда любой другой фреймворк) разумеется куда круче, верно понимаю?

Дело не в кручести других а в нормальности ангуляра

Извините, можно вопрос — что не ДНО? Без троллинга, чтобы для себя (да и других, задающих вопросы по сабжу, разобраться — что учить-то, что требуется?) Вы Senior Frontend Developer, каков Ваш стек технологий? Заранее благодарю за ответ.

Антон скажет React, но я бы ответил Ember.js :)

А разве Ember не похож на Angular? В том плане что там тоже желательно использовать свой CLI, следовать рекомендуемой структуре проекта, и т. д. Опять же, почти своя, довольно сложная шаблонизация (хорошо хоть что используют handlebars). То есть ты должен следовать ember way для того чтобы с ним работать, прямо как с ангуларом.

А разве Ember не похож на Angular

Вот сложно сказать. Я не работал с ангуларом никогда. Когда я выбирал между фреймворками — я читал обзорные статьи и ember мне приглянулся больше предлагаемой структурой проекта. Cli тогда еще не был рекомендуемым, я использовал поначалу require.js.

О современном ангуларе я слышал что он использует TypeScript. Для меня это недостаток — я не знаю TS и не понимаю зачем он мне нужен. В Ember используется ES6, с которым привычно и приятно работать.

То есть ты должен следовать ember way для того чтобы с ним работать

Это с любым фреймворком так. Но не обязательно следовать какому-то пути буква в букву, как считают многие разработчики. Отступления от официального гайда на самом деле возможны и нужны, имхо. А то все прочли в гайде «Observers are often over-used by new Ember developers. Observers are used heavily within the Ember framework itself, but for most problems Ember app developers face, computed properties are the appropriate solution» и суют CP туда, куда они не суются, чтобы потом радоваться что не использовали observer (и пофиг что создали CP, которая нигде не нужна и где-то к ней обращаются просто чтоб работало).

Если без тролинга то стек зависит от поставленной задачи и условий, а насчет того что учить, учите то что вам нравится.

И да, ангуляр иногда можно тоже выбрать.

Кстати, то что иногда следует выбирать ангуляр не отменяет того что он ДНО

Так почему он дно таки?

не контролируемый на прямую change detection или digest loop, shared state (проблема возникает как только у вас чуть более менее выростает приложение, и вы будете передавать целые объекты в компоненты) хренова туча тулзов для построения (это про ангуляр 2 и AOT в основном) проект, ввиду чего каждое обновление огромный страх что все сломается — а так часто и бывает. DI который в большинстве случаев излишен и больше усложняет чем дает преймуществ. ну и сам по себе концепция универсального ножа, которой пытаются следовать ребята из ангуляр весьма ущербна

Проблема ангуляра в том, чтоб на нем хорошо писать надо много знать. Посмотрите на ChangeDetectionStrategy, Zone, ChangeDetectuinRef, а для state ngrx, или прсто используйте сервисы для их хранения и передавайте потоки. AOT не работает если кто то наплохокодил, что не так уж и плохо.

Проблема ангуляра в том, чтоб на нем хорошо писать надо много знать.

Вот это самый лучший критерий того можно ли инструментом пользоваться. Если инструмент нельзя освоить за 3 дня, то работать с ним не стоит.

ChangeDetectionStrategy,
ChangeDetectuinRef

По одним названиям уже ясно, сколько проблем создает инструмент

Вот это самый лучший критерий того можно ли инструментом пользоваться. Если инструмент нельзя освоить за 3 дня, то работать с ним не стоит

Смелое утверждение.
Вы из тех кто предлагает писать ентерпрайз на нод джс, а мобильные приложения на 6000+ человекочасов на реактНейтив?

Ну, я за два дня освоил на уровне, достаточном чтобы уверенно им пользоваться. И дальше прокачивается с опытом как и все остальное.

ChangeDetectionStrategy, Zone, ChangeDetectuinRef

и они не решают проблему не контролируемого ChangeDetection — скорее тут речь о включение в change detection чего-то чего ангуляр не охватил.

а для state ngrx, или прсто используйте сервисы для их хранения и передавайте потоки
а для state ngrx, или прсто используйте сервисы для их хранения и передавайте потоки

мм, когда приложение становится чуть более менее большим, вы скорее всего прийдете к тому что структуры будут приобретать все большую вложенность, сервисы эту проблему не решают, как и ngrx/store ибо это тоже является как раз shared state.

AOT не работает если кто то наплохокодил

нет, сам ngc часто релизится с багами, посмотрите github issues там почти на каждый мажор заведена бага что АОТ перестал работать

мм, когда приложение становится чуть более менее большим, вы скорее всего прийдете к тому что структуры будут приобретать все большую вложенность, сервисы эту проблему не решают, как и ngrx/store ибо это тоже является как раз shared state.

Да проблема была, была из-за неправильного построения приложения изначально, если следовать модульной системе то все ок. А в чем проблема большой вложенности? Если получаются перекрестные связи, то это не проблема фреймворка

Проблема большой вложенности тесно связано с мутабельностью. Иначе один и тот же объект может изменятся в нескольких местах одновременно, а это корень зла почти везде

почему не хранить все объекты в сервисах?

вам прийдется дофига дублировать и усложнять взаимодействия делая стейтфул сервисы — а в ангуляре не стал бы этого делать после того как они где то с версии 2.3 начали плодить куча сервисов для каждего лейзи лоадед модуля, они вроде обещали пофиксить это к 4 версии, но я не проверял, да и не хочу. в целом стейтфул сервисы не самая лучшая идея, единственный стейт который следует хранить в сервисе это кеш — ибо его не страшно похерить

так и есть, общий кеш-сервис, и стайт-сервис для каждого модуля. Дублирования нету, есть абстрактные классы которые расширяются.

я кажется понял. вы считаете что переопределение всех компонент как OnPush + Immutables или Observables (с пометкой о том что изменение произошло) это удобный метод борьбы с неконтролируемым change detection?
я вас разочарую, в react есть один метод — setState — конец истории, это удобно, это понятно, никто за вас change detection не запускает на каждый чих

я кажется понял. вы считаете что переопределение всех компонент как OnPush + Immutables или Observables

Это занимает одну строчку при создании компоненты. А Immutables или Observables — хороший тон изначально.

Одно строчка в аннотации, поменяй типы входных параметров, поменяй то как с ними работаешь, а да, в начале это никто не сделает в 90 процентах случаев, ведь большинство библиотек этого не используют, а когда начнешь сам, получишь проект который использует разные подходы, перевести все на эти рельсы сразу может быть затруднительно, а тут еще какойто джун наклепал компонент по старому пока был в отпуске. А ведь всего бы этого не было если бы ангуляр изначально по умолчанию не полагался на мутабельность данных, здорово что есть опция писать нормально, только почему не по дефолту включена?

А ведь всего бы этого не было если бы ангуляр изначально по умолчанию не полагался на мутабельность данных, здорово что есть опция писать нормально, только почему не по дефолту включена?

Потому что тогда бы, порог вхождения на который все жалуются, был бы еще больше.

правильно, ибо этот воркераунд выглядит как самый обычный оверинжениринг — то что они не смогли это сделать просто — это их проблема, в то время как существуют решения где это сделано просто.

Мне кажется проблема скорее в том, что туториалы не охватывают эту область совершенно, в том числе их официальный. И на курсах по ангуляру не изучают rxjs. Это все не так сложно если бы было много информации с доступным изложением. А сам фреймворк для больших ентерпрайз приложений и это нормально, что он сложный.

Сделали бы они это опцией бай дефолт не было бы проблем, причем они могли сделать это правильно, то есть не усложняя — они не захотели а может просто и не умеют. В этом собственно и искусство — делать сложные вещи просто.

Подписаться на комментарии