React vs Vue vs Angular vs Backbone

В последних версиях разработчики react отменили возможность создания компонентов на es5 без подключения сторонних библиотек на npm. Придумал способ как расширять базовые классы обходным путем. Весь день убил на адаптацию реакта на нормальный js без бабеля, ecmascript 2015, ноды, вебпака и прочей ерунды. Пока не осознал, что у меня весь код - костыль на костыле.

Команда реакта сознательно повысила порог вхождения в веб-разработку, как до этого сделал гугл с ангуляром. Единственная альтернатива для новичков - vue.js. Т.к. бэкбон морально устарел. Единственный минус vue перед backbone - прокидывание пропсов (передача данных между компонентами потомок-родитель). В бэкбоне с его более четкой mv* - архитектурой и коллекциями вопрос не стоит. Бэкбон с marionette js на мой взгляд так же выигрывает в бизнес-логике.

Реакт сосет у вью. Но иерархию компонентов, мне кажется, проще выстраивать. На вью с этим реально надо заморачиваться. ХЗ почему никто не говорит об этом важном недостатке.

Периодически отслеживаю популярность фреймворков у компаний с помощью hh.ru
Кстати, сейчас баланс сильно изменился в сторону реакта, вью так же прибавил в весе. Ангуляр раньше гнался наравне с реактом, свои позиции не потерял, но и не нарастил.
реакт - 565,
вью - 110,
ангуляр - 380.

Upwork по тегам:
AngularJS -  1,998
React.js - 638
React Native - 510
Vue.js - 189
Backbone.js - 33

Upwork без тегов:
angular - 945
react - 1,323

Выдача результатов по тегам и просто слово в поиске - несколько различается. Но видно, что ангуляр на западной бирже рулит. И даже выруливает. Раньше было равенство между ангуляром и реакт+реакт натив.

На superjob и фрилансиме лавры поделены между обоими.

Насколько я знаю, React Native по кросс-платформенной разработке еще никто не победил. И рост популярности на западе можно объяснить только 4 версией ангуляра и закрытием всех недостатков прошлых версий.

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

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

P.S. к чему все это? Буду переписывать фиатлукс с wp на vue+php.
P.S.S. vue.js идеален. Один день мытарств, чтобы познать эту истину.

facepalm

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

можно список пунктов составить, но зачем это здесь

Для тех кто туго понимает зачем это вообще https://www.youtube.com/channel/UCzgtMBarT8AvsGc-Y_8Qexw/videos?disable_polymer=1

raingo пишет:
P.S. к чему все это? Буду переписывать фиатлукс с wp на vue+php.

И сколько же это, позвольте узнать, займёт времени?

мне вью не понравился от слова вообще. хз. все тоже самое, что я неделю мучался на нем одностраничник делал, на Jquery я бы сделал за 2 часа.

Реакт натив буду изучать однозначно. мобильная разработка на нём рулит.

ХЗ, у меня вроде не доисторический комп, но андроид студио медленная, что дополнительно подкрепляет миф о тормазнутости java. И вызывает ненависть к языку. Ну раз я на libgdx тварю, то чутка изучал android api.

Для незамороченных приложений реакт натив рулит опупенски. Родной саблайм, npm, все дела. Но самая крутая фишка - это компиляция на лету. Отвал башки. Андроид студио сосет в сторонке.

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

у меня вроде не доисторический комп, но андроид студио медленная, что дополнительно подкрепляет миф о тормазнутости java. И вызывает ненависть к языку

аналогично. Intel XDK подавал надежды, но сейчас проект завернули. так что если выбирать из двух зол, я выберу Реакт натив

в производительности он все-таки проигрывает нативной разработке

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

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

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

пиро пишет:мне вью не понравился от слова вообще. хз. все тоже самое, что я неделю мучался на нем одностраничник делал, на Jquery я бы сделал за 2 часа.

На реакте и ангуляре время бы еще больше заняло.

Vue.js это программирование внутри программирования. Иная парадигма типа. Иное мышление нужно. Например, когда кодер видит, что нужно создать несколько повторяющихся по функционалу элементов - он пишет класс, создает экземпляры в массиве, возможно циклом. Индексирует. Пишет менеджер объектов (пула), манипулирует объектами через менеджер, а не обращаясь к каждому отдельному элементу и все такое прочее.

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

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

ХЗ к чему этот монолог. Типа мыслей много, выводов всяких.

аналогично. Intel XDK подавал надежды, но сейчас проект завернули. так что если выбирать из двух зол, я выберу Реакт натив

Насколько я знаю, Intel XDK использовал webview - это тормазнутая вьюха на андроиде/ios. Если брать исключительно приложения (без игр), то кросс-платформенные только xamarin и react native. Остальные используют webview.

Не знаю иос, но у андроида есть подобие своего канваса, и у этого канваса подобие контекста для 2d. Еще есть opengl es. Тот самый opengl, который используется для игр, типа драйвер для видеокарты. На hmtl из канваса можно взять не 2d контекст, а webgl. Который является портом opengl es для веба. Они очень одинаковые по функционалу, хоть платформы и разные.

Libgdx или cocos2d и прочие юзают либо канвас, либо opengl es. А затем компилируют язык в машинный код, который управляет тем же канвасом или opengl es (webgl) на других платформах. Получается более-менее нативная разработка. Т.е. это не тормазнутый webview, который юзает phonegap и прочая ерунда.

пиро пишет:у меня есть смутное подозрение, что ненативная разработка всегда проигрывает нативной

С реакт натив чутка сложнее, но на самом деле это считай та же нативная разработка. Хотя конечно "нативная" - растяжимое слово. Реакт натив компилирует js в машинный код, который управляет нативными вьюхами андроида и айфонов.

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

Я пробовал тестовое приложение реакт натив - все летает и поражает скоростью, кроме вьюхи навигации. Смена окошек чутка притормаживает. Заметно, но не болезненно. Айфон возможно даже эти лаги не продемонстрирует (таки ios более совершенный).

Когда-то я искренне считал, что раз знаешь один язык, то другие выучить не составит труда. Походу раньше я не знал ни одного языка.

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

Dessan пишет:

raingo пишет:
P.S. к чему все это? Буду переписывать фиатлукс с wp на vue+php.

И сколько же это, позвольте узнать, займёт времени?

Не так страшен черт, как его малюют. 4 rest скрипта: регистрация, авторизация (через куки и хеш в бд), crud записей, bbcode (я делаю на клиенте, проверку на сервере). Плюс навигация и пагинация на клиенте. А еще это mysql, надо почитать про безопасность и написать доп скрипт. Вроде все.

Авторизация (проверки прав доступа) самая сложная часть. Один и тот же сайт выглядит по разному для хозяина странички, гостя странички, модератора, администратора, незарегистрированного пользователя. По сути, это 5 разных сайтов. Которые из-за безопасности можно объединить в два: пользовательский и администраторский.

Все это уже делал раньше кроме авторизации. Как раньше говорил, была почти полностью реализованная идея. Весь код клиента лежит в localstorage (хранилище браузера). При первом заходе на любую страничку сайта сервер проверяет наличие кода в хранилище и сверяет версию. Если версия подходит, то весь код выгружается с хранилища. Если нет, то весь код целиком загружается в хранилище. Т.о. не надо ждать загрузки сайта.

Это я на даче до такой фигни додумался. Там инет тормазил.

Плюс все сообщения сервер-клиент идут через сокеты, а не http-запросы. Текст передается обычным json. Картинки через base64. Видосы тож, кста, вроде так и делаются плееры. Были еще фишки типа api авторизации (регистрация/аутентификация на другом сервере) и прочее. Мой совершенный сайт.

Суть в том, что сайт не перезагружается после открытия новой странички. Одна загруженная страничка подтягивает все остальные только один раз в жизни (в идеале). Но встает вопрос прав доступа. Клиент должен иметь какие-то кнопки: "удалить сообщение", "редактировать сообщение", и видеть только в нескольких случаях:
- когда он владелец странички (может удалять чужие сообщения, но не может редактировать их)
- когда он владелец своих сообщений на чужой страничке (не может удалять и редактировать чужие сообщения)
- когда он модератор раздела (может и удалять и редактировать все сообщения, но только в назначенном разделе)
и прочее. Чем сложнее сайт, тем больше путаница.

Вопрос, который не смог решить. В теории любой юзер может увидеть вид со стороны модератора. Т.е. клиент то у всех один загружается, а после авторизации клиент подстраивается. Но обойти авторизацию не сложно. Каждый школьник может сделать так, чтобы отображались кнопки "удалить", "редактировать" там, где это не надо.

Конечно, на сервере проверяются права доступа. И удалить все равно никто ничего не сможет. Но это *нецензурная брань* моветон и похабщина. Как решить проблему архитектуры и не запутаться - я так и не придумал.

Как делаю сейчас - так же, как и все. Сайт загружается каждый раз при открытии странички. Т.е. каждый раз сервер проверяет, есть ли нужные права в куках (если кто не знал, куки и прочий мусор приходят вместе с каждым http-запросом, отчего они более медленные). И выдает страничку в соответствии с права (права есть - будут кнопки "удалить" и "редактировать", нет прав - не будут).

Если кто понял суть проблемы и есть идеи, хотя бы абстрактные, с радостью выслушаю.

Разве в localStorage не 5мб объём?Тебе хватит для сайта?И всё зависит от контента. Если у тебя сайт с одной писаниной, которая не обновляется - то ладно, ты сохранил в браузере и потом достал из него же. И хранилище пользователь может редактировать самостоятельно. А если у тебя форум без картинок вот так этот, всё равно же интернет нужен для обновления информации. Так какой смысл хранить пару килобайт в браузере если это скачивается всё за секунды, учитывая современные скорости. Или я что-то не понимаю?
А про права доступа вообще не понял. Вот я зашёл и не вижу никаких кнопок на которые я не могу нажать, никакие панели администрации мне не доступны для просмотра. Если я выйду из учётной записи - я тоже ничего этого не увижу. Но даже если так, почему не сделать по умолчанию отсутствие кнопок и панелей администрации и отдельную страницу для логина администраторов, а потом уже перенаправление на форум и подключение этих всех кнопок и панелей после проверки этих прав на сервере?
А в куках права хранить разве безопасно?Любой может прочитать куки эти и изменить их при необходимости. Сервер ещё и куки проверять должен отдельно тогда.

Да все хранят в куках. Кто в явном виде, кто только хеш (закодированный пароль).

Так какой смысл хранить пару килобайт в браузере если это скачивается всё за секунды, учитывая современные скорости. Или я что-то не понимаю?

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

Кроме локального хранилища есть еще локальные бд (IndexedDB), там вроде неограниченно место.

Если оценить трезво, то все эти идеи с практической стороны нужны типа для "черновиков". Например, делаешь сложный заказ в интернет-магазине. Очень много всяких настроек, опций, информации нужно для заказа. Бац, пропал интернет. Инфа на сервере не сохранилась (да и нафиг загрязнять сервер).

Заходишь на сайт заново, а вся инфа берется из localStorage или IndexedDB.


Еще более частый случай. Пишешь сообщение. Случайно закрыл вкладку. Возвращаешься на страничку, а весь текст более-менее сохранился. Не надо заново писать.

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

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

Так это одной страницы, а ты вроде как про весь сайт говорил. Если текущей активной страницы - то да, это полезно. Если тебе это интересно как "черновик" помимо создания игры, рисования,создания движка и т.д. - добавь это в очередь на реализацию)

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

и vue там практически из коробки