Как стать автором
Обновить

Комментарии 37

Как быть с не-хтмл клиентами и медленным каналом связи?

1. Оставить JSON API дня сторонних клиентов.
2. В этом случае нужно решать задачу, исходя из технических ограничений. Например, не использовать описанный в статье метод. :)
  1. И поддерживать 2 версии АПИ?
  2. Получается его нельзя использовать никогда, так как на любой сайт я могу зайти через ГПРС.
Получается его нельзя использовать никогда, так как на любой сайт я могу зайти через ГПРС.
Мы очень рады за вас, но это не значит что есть много пользователей, кому этот факт интересен.

Я на свой сайт тоже могу зайти по ГПРC, но утверждать вот прямо так сходу, что эта потребность нужна прям всем-всем-всем я не возьмусь. Очень может быть что и нет. Особенно если это корпоративный сайт и заходить на него откуда-нибудь из лесной глуши не нужно.
  1. В пределах МКАД полно такой "глуши".
  2. Находяcь в командировке на корпоративный сайт заходить всё-таки нужно. Да ещё и через VPN.
А пробовали поюзать с пингом ближе к секунде? Приложение не потеряет отзывчивость до уровня раздражающего неудобства?
Наверное, в этом случае и React не сильно поможет? А количество дааных в HTML и JSON представлениях, предположу, что не сильно различается.
React может поможет тем что ответ на действие пользователя будет мгновенным (Откроется нужная страничка, на ней нарисуется loading, по ощущениям такое поведение страницы воспринимается пользователем менее болезненно ). Или все данные могут храниться в каком-нибудь store — и тогда будет только один запрос который получит все нужные данные.
Если нужно полноценное SPA с определёнными техническими требованиями, то да, без фронтенд-фреймворка не обойтись. Если нужно добавить «живости» сайту, то можно сделать проще. Как именно? Об этом и рассказано в статье.
Да я не критиковал подход — я просто спросил как оно выглядит, насколько юзабельно. Секунда, пожалуй, многовато — но 500ms не слишком редкий пинг на мобильном.
Секунда тоже может случиться, когда ближайшая сота вырубилась, а вокруг туман густой (через туман радиосигнал плохо проходит, много пакетов теряется).
Пользуюсь 3G — модемом, и иногда такое наблюдал.

Ничто не мешает показывать loading и в случае server-rendering.


Например, так работает Github (при навигации по папкам репозитория сверху показывается синий прогрессбар).

Такого же эффекта помогает добиться turbolinks
«Другим больным местом при работе с кодом React было тестирование. Так как приложение и клиент были разделены, нужно было быть уверенными, что ответы нашей тестовой имитации сервера всегда актуальны.» Лолшто.
Это проблема всегда есть при разработке SPA приложения.
И они достаточно изящно избавились от этой проблемы. Так можно делать не всегда, но если ситуация позволяет. то почему бы и нет?
Ну, оно и решается, думаю в ситуации описанной автором не нравилось то что при изменении в API все изменения надо было дублировать в моках, и эту проблему решили просто избавившись от всей логики в UI

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


Суть примерно такая: 90% сайта — это обычные статичные страницы, которые генерируются сервером на основе обычных шаблонов. Но некоторые части проекта используют JS компоненты: в основном это Riot.js. По большей части, наша стратегия — это использовать сложную логику на основе js только в конкретных ключевых точках приложения, которые подразумевают большое количество динамических изменений, интерактивное поведение, и так далее.

Как по мне так название статьи «Как Phoenix убивает React» вводит в заблуждение.

У меня к вам пара вопросов:
— чем именно вам мешает React ???
— как Phenix будет его убивать на Node, Ruby и etc???
— вам не кажется что изначально был неверно выбран инструмент или подобрана команда???

После прочтения статьи сложилось впечатление что у вас мало хороших front-end разработчиков и функционал приложения довольно таки посредственный и не предполагает высокой степени активности.

Попробуйте на серверном рендеринге с минимальным js сделать торговую панель для трейдера с 3-5 индикаторами. Я думаю в этом случае React сможет более полно раскрыть свой потенциал.
На картинки для привлечения внимания более точный заголовок. :)

А статья — перевод. Самое главное, что такой подход скорее всего можно применить и на других языках. Не добавлять зависимости, если задачу можно решить из коробки.
Тезис: Авторы описали как переехали с фронта на бэк и стало проще всё тестировать и писать в одном месте, но зачем тогда такое громкое название про React и Phoenix? Возможно, если у них нет мобильных клиентов и приложений, PWA и ограничения по трафику это удобно… но в нынешнее время куда лучше закешировать всё на клиенте и оптимизированно подтягивать данные в готовый интерфейс, а не генерить тонны трафика повторяющегося html.
Вывод: сложилось впечатление, что им просто было лень и они решили всё упростить.

Громкое название придумали переводчики.
Оригинально статья называлась "How We Replaced React with Phoenix", убивать никто никого не собирался

Прошу простить меня за столь громкий заголовок. Примечание по этому поводу в самом конце страницы. :)
Вывод: сложилось впечатление, что им просто было лень и они решили всё упростить
Что в этом плохого-то?
внутренний инструмент для корпоративных анонсов.

React для фронтенда

Дальше пост можно не читать, все и так понятно.

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

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


Вообще, я этот пост читал сразу после написания и мне хотелось разбить себе лицо руками — это просто эталон хипстерства. "Давайте мы сначала сделаем фронтенд на ненужном нам new and shiny реакте, потом удивимся, что так трудно, перепишем на new and shiny фениксе и напишем пост, какой замечательный феникс и как трудно с реактом".

Не верю. Окей, молодцы вкрапляете js маленькими кусочками.
Дальше таких кусочков будет все больше и больше, а давайте ещё комменты можно будет прокручивать, а давайте будет оповещалка о новом комменте, а что-то js не тянет, давайте jquery, а давайте нам галерею, давай, jquery плагином, а ещё это и вот то, и тут классный плагин, а что это сайт превратился в jquery монстра, который парсит куски html с сервера, а давайте перепишем все на ангуляр.
А тот будет тормозить, да и двусторонний биндинг нафиг нужен, давайте обратно на реакт.

Если кто-то и убивает React (чего на самом деле и близко не происходит), так это набирающий популярность Vue.

Vue (v2) содержит virtual dom как элемент оптимизации, а React только этим элементом и является (по сути просто продвинутый шаблонизатор), так что React не нужен от слова совсем.

Подождите убивать React, я на нем еще не ничего не сделал! Вот же ж JavaScript, полгода и библиотека в хайпе, а потом уже сразу considered harmful
Можете уже на vue перебираться ) И да, я тоже не успел…


Там нет драйва. Весь драйв сейчас только на React.

Остальные просто скучноваты монстры. Вымирающие динозавры, пытающиеся хоть как-то противостоять React тем, чтобы дать всё из коробки, тем кто устал и не хочет «париться».

Имхо.

;-)
НЛО прилетело и опубликовало эту надпись здесь

Капец заголовок… один в один новости на канале Россия 1
Я прочитав статью не понял как Ваша навороченная версия PHP может убить Front-end фреймворк? Если Вы такие страшные убийцы фреймворков, что ж не убить и ваш новороченый PhoenHP? Один фиг его изучать тоже надо вашей команде.
ЛАЙК ЗА GITHUB PAGES! — Убьем фреймворки!!! CLEAN HTML!
В общем за статью спасибо, но посыл статьи в чем-то не понятен. Я не понял, толи в вашей компании работают люди которые ни чему не хотят учиться… толи… Слушайте статья не понятная вообще короче. Больше вопросов чем ответов. Почему бы вам не убить Google Chrome таким же способом?

Убили ну и ладно.

Теперь сами убейтесь аб стену. (С)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории