Pull to refresh

Comments 42

уберите пожайлуста эти ужасные красные заголовки.
Это было просто за гранью добра и зла.
А ещё можно было сделать мигающие заголовки…

ну а с точки зрения "“windows universal apps" там как раз веб вполне может быть одной из платформ. Более того, можно собрать приложение состоящие, по сути, из одного единственного урла. Другой вопрос, что UWP не являются кроссплатформенными.
А ещё можно было сделать мигающие заголовки…
Вспомился тег marquee… чтоб уж для полного погружения в атмосферу веба конца 90-х, начала 00-х
А почему вы один раз упомянули что у Appcelerator есть абсолютно все то же самое, да еще и не один год, а в конкуренты его не записали? У него тоже есть, цитата, «web как одна из платформ, сверхпопулярный JavaScript, не менее популярный тулчейн node.js, бесплатность, поддержка facebook и “hot reloading” из коробки». И сообщество большое. И marketplace
Потому что у него не компонентная модель. Там по старинке, как было в Qt, Gtk, wxWidgets и иже с ними.
Минуточку, там есть виджеты и модули. Это не компоненты в том понимании, в котором они есть в реакте?
Это не компоненты в том понимании, в каком они есть в реакте. Весь реакт построен на том, что вы собираете пользовательский интерфейс из кирпичиков, которые затем дробите и специализируете по необходимости. Каждый кирпичик содержит отрисовку, мининмум логики и immutable модель работы с данными. Фреймворк сделан с расчетом на то, что эти кирпичики будут переиспользованы и в рамках одной аппы, и в рамках разных апп. Вы один раз сделали кнопку "купить" с символом доллара и затем используете ее везде.

В титаниуме тоже так можно! Просто это займет больше усилий :). Вообще, почти на любом фреймворке можно реализовать что угодно, я рассматриваю исключительно на что авторы его "затачивают" и что делать проще всего. Аппселератор — она про "батарейки", бэкенд, аналитику, покупки, инфраструктурыне вопросы — все вот это там очень сильное.
https://github.com/yuchi/react-titanium

По сути, легким движением превращаем Titanium в React Native. Наткнулся прям вот сегодня.
Единственная проблема, что плагин «titaniumify» у меня не собрался, т.к. одна из его зависимостей (вроде, некий nan) не дружит с нодой >= 4, а у меня 5. Временно обошел тем, что собираю проект gulp'ом из ES6 в ES5. А всё остальное, на первый взгляд, работает.
Два года назад надо было сделать win8-приложение. Ничего военного, навороченная читалка и большая база книг. Повелся на золотые горы от MS; поленился въезжать в xaml, и выбрал html5. По прошествии двух лет на Javascript остался только UI, и сейчас готовимся к финальному броску.

Удар по производительности и дичайшее потребление памяти не оправдывает ничто.

Больше бледнолицый на эти грабли наступать не будет.
2 года прошло.

Сравнивал на своём старом пятом яблофоне экзампловые приложения на Ионике и Нативном Реакте. Реакт и правда работает со скоростью нативного, так что я даже не знаю чем вы недовольны.
А скоро, возможно, кроссплатформенный perspex станет подходящим для многих xaml приложений.
При всех плюсах Реакта, довольно раздражает то, что для многих на нем свет клином сошелся. Не Реактом единым решается декомпозиция на компоненты. React хорош когда нужно пре-рендер вида на сервере сделать и в кэш положить, в остальных случаях куда более интересно выглядит Polymer, который также вполне хорош в содружестве с Cordova.
react native — это javascript обвязка вокруг нативных элементов(за счет чего достигается скорость), в случае polymer + cordova, у нас опять старое доброе приложение, которое работает через view, ну и далее все проблемы, тормозит, блокирование главного потока пока ui не отработает, ну и далее по списку.
Критикуя — предлагай. Компания платит мне зарплату, чтобы я мог тратить рабочее время на анализ технологий и писать обзорные статьи на Хабр. За это ожидается, что я буду крафтить привлекательные для широкой аудитории заголовки и писать в стиле, который привлечет максимум внимания.

Полагаю, все хабрапользователи благодарные вам за статьи о ES6. Сам с удовольствием читаю. Если считаете, что мои статьи дискредитируют React Native, что ж — напишите лучше, я буду первый вам за это благодарен. Концепция "либо делать очень хорошо либо не делать вообще" меня не привлекает.
У меня переводы, а не статьи по ES6. Конкретные претензии:

Начиная от Java и заканчивая phonegap разработчики очень хотели, чтобы один раз написал и везде работало. Но не складывалось.

А потом facebook сделал ReactJS. Чтобы чат себе починить. И сложилось.

Но у React есть перед ними ряд преимуществ: web как одна из платформ, сверхпопулярный JavaScript, не менее популярный тулчейн node.js, бесплатность, поддержка facebook и “hot reloading” из коробки.

В итоге статья с одним хайпом. Впрочем, пипл хавает, значит всем пофиг.
Да, мне нравится писать с хайпом. Если посмотреть на любые другие мои статьи, например вот этот цикл — я всегда так пишу. Менять стиль ради одного человека, которому он не нравится… Открою Вам большу тайну — всегда найдется тот, кому не нравится стиль статьи. Любой стиль. Академический — "слишком сухо", эмоциональный с упрощениями и безапелляционными высказываниями — "слишком много хайпа", точный — "ни о чем" и так далее. Жизнь — боль :)
А, извините, не увидел что вы евангелист. Все, вопросов нет.
У меня полностью противоположные впечатления — очень хорошо написано, редко такой уровень текста встречаю.
Дальше "hello world" эта штука не уедет, т.к. основная проблема не в интерфейсе, а в аппаратуре и принципах работы конкретных платформ.

Для мобильного приложения нужно получать mcc, mnc, распознавать пользователя по imei, а при работе с файлами понимать, что приложение работает в виртуальной среде. Для десктопа нужно писать в реестр, параллельно по тихому устанавливать доп. софт и существенно расширять функционал работы с файлами. Для TV — работать с пультом и тщательно продумывать подсказки. Для веба — ещё 100500 своих требований. Разные среды — разный функционал, разные проблемы, решения, задачи и ТЗ.

React Native не решает и в принципе не может решить ни одну из проблем, т.к. проблема в логике, а не инструментах.
P.S.: ну а в целом норм. статья
Для десктопа нужно писать в реестр

Лучше не надо. Ну и МС ведет к тому, что это дело прикроет.
Вы правы, но не полностью, есть очень большой сектор программ, для бизнеса, когда половина функций мобильного не нужно, задача написать сложный в плане бизнес процесса продукт, выполняющий определенный функционал. Писать сложную бизнес логику на 3-4 системы, это ужас… А спецефичных штук чатсо не надо.
А в чём отличия от какой-нибудь кордовы с её WebView и набором platform-specific CSS'ов? Там тоже всё быстро писалось. Service (в понимании android) на reactnative всё так же не напишешь (без нативного кода). Если вы делаете серьёзное приложение, то вы либо "перейдёте на натив" (Java для андроида, ObjC/Swift для яблока), либо сделаете одно для всех. На С++ и opengl (см яндексовский навигатор например).
А почему не что-нибудь типа QML?
Выглядит чужеродно и на android и для ios, нет для веба.
В 5.6 они подготовили новую версию компонентов, специально для мобилок, там теперь есть даже Material стиль. Кроме того, саму систему стилей очень переработали, сделав её гораздо более удобной для изменения.

А под Web действительно нет, но он там и не нужен, C++ всё таки.
Так если веб не нужен и, к примеру, андроид не нужен — то лучше всего нативно писать, swift все-таки. А если веб не нужен и ios не нужен — то лучше всего нативно писать, java все-таки :)
Увы, это пока игрушки от энтузиастов. Но лично я очень надеюсь на фейсбук ^_^
Это да. Но приятно, что osx версию делает российский разработчик из новосиба.
eyeofhell расскажите, пишите ли вы юнит тесты для ваших RN аппов и как именно?
Именно юнит тесты — пишем. Mocha + chai :)
  1. А примеры посмотреть можно где-нибудь?
  2. Почему не jest?
Примеров пока нет, это во внутренних репозиториях. Возможно, в одной из следующих статей расскажу, мы как раз сейчас web sdk переписываем на typescript, можно будет показать как у нас все сделано. Почему не jest? Сам по себе test runner очень маленький относительно тестов, так что по большому счету все равно какой использовать. Мы используем самый популярный :). Если появится что-то, что в jest делается лучше и приносит пользуе — мы без проблем поменяем раннер, бо grep никто не отменял.
Ок, спасибо!
Будет интересно почитать статью про тестирование RN.
А если мы захотим сделать версию для веба, то это займет от силы еще день (...). Все что нужно будет сделать – это заменить элементы пользовательского интерфейса на div’ы...

Ох, не всё так просто.
Таким образом вы получите:
—дублирование копи-пейстом кодовой базы, которая не мержится автоматическими инструментами и придётся поддерживать в два раза больше кода
—кучу инлайновых стилей
—рендер всего приложения на клиенте, что сожрёт слабые машинки и будет крутить им прелоадер по несколько десятков секунд

Да и вся вёрстка в react-native строится на flex, который пока ещё не частый гость в вебе
flex поддерживается уже всеми нормальными браузерами
  • Дублировать ВСЕ не надо — достаточно имплементировать несколько компонент.
  • Если по каким-то причинам инлайновые стили не нравятся, то легким движением конфига вебпака они компилируются в отдельный css
  • Изоморфные приложения же! Все рендерится на сервере и мгновенно отдается CDN
Sign up to leave a comment.