Комментарии 25
Что значит отрендерить страницу на сервере и зачем это может быть нужно? Вопрос без сарказма.
Рендеринг страницы на сервере — это то, что мы делали очень долгое время с помощью Perl, Python, Ruby, PHP и т. д. В одностраничных же приложениях рендеринг часто происходит прямо на клиенте, от сервера поступают только данные через API (чаще всего JSON). Потому что такие интерфейсы работают быстро, и пользователь получает примерно такие же впечатления, как от десктопного приложения. Но с таким подходом появляются две проблемы: 1) скорость первичной загрузки; 2) индексирование поисковиками.
Скорость первичной загрузки теряется от увеличения количества запросов — нужно запросить еще несколько раз данные с сервера через API. А с индексированием у поисковиков тоже проблемы — они еще не научились индексировать js (гугл вот только недавно анонсировал такую фичу.)
Эти две проблемы решаются рендерингом страницы на сервере. Но тогда другая — дублирование кода на клиенте и на сервере, и вот тут решения, умеющие и то, и другое, приходят на помощь. Ведь никому не хочется писать два раза одно и то же =) React позволяет писать один код для сервера и клиента, еще в этом могут помочь фреймворки MeteorJS.
Скорость первичной загрузки теряется от увеличения количества запросов — нужно запросить еще несколько раз данные с сервера через API. А с индексированием у поисковиков тоже проблемы — они еще не научились индексировать js (гугл вот только недавно анонсировал такую фичу.)
Эти две проблемы решаются рендерингом страницы на сервере. Но тогда другая — дублирование кода на клиенте и на сервере, и вот тут решения, умеющие и то, и другое, приходят на помощь. Ведь никому не хочется писать два раза одно и то же =) React позволяет писать один код для сервера и клиента, еще в этом могут помочь фреймворки MeteorJS.
Если я правильно понимаю:
— у вас js на клиенте и node.js на сервере (общий код, общие инструменты)
— для мобилок, первичной отрисовки страницы и т.д., использую jsx трансформер на сервере, можно сгненерировать страничку/компонент клиенту
— у вас js на клиенте и node.js на сервере (общий код, общие инструменты)
— для мобилок, первичной отрисовки страницы и т.д., использую jsx трансформер на сервере, можно сгненерировать страничку/компонент клиенту
именно так. рассчитано на пользователей с медленным интернетом (которых к сожалению в yahoo mail очень много).
ReactJS + все библиотеки и исходный JS код для клиента занимает ~100KB что достаточно много для первого старта приложения. поэтом как только приходит запрос от пользователя, мы возвращаем готовую статическую html страницу с контентом и начинаем грузить весь оставшийся JS. как только JS загрузился, мы наворачиваем клиентское приложение на готовую верстку и оно становится интерактивным (вешаются onclick и т.д.)
ReactJS + все библиотеки и исходный JS код для клиента занимает ~100KB что достаточно много для первого старта приложения. поэтом как только приходит запрос от пользователя, мы возвращаем готовую статическую html страницу с контентом и начинаем грузить весь оставшийся JS. как только JS загрузился, мы наворачиваем клиентское приложение на готовую верстку и оно становится интерактивным (вешаются onclick и т.д.)
100кб даже на медленном интернете — это не так много ведь. Почему не сделать а-ля фейсбук с его «пустышками», которые показываются до загрузки основного контента?
Рендер на сервере все-таки тоже занимает какое-то время, а отдать статику (особенно закэшированную) можно куда быстрее.
Кстати, если не секрет — какое у вас распределение пользователей по браузерам?
Рендер на сервере все-таки тоже занимает какое-то время, а отдать статику (особенно закэшированную) можно куда быстрее.
Кстати, если не секрет — какое у вас распределение пользователей по браузерам?
в будущем размер ветаки вырастет до ~250-300KB. (в данный момент js yahoo mail аж под мегабайт) и для стариков из деревней с очень медленным интернетом это всеже проблема :) так же как и мобильный интернет бывает очень медленным.
и да. о браузерах я забыл. сейчас Yahoo Web Mail это два приложения. одно полностью клиентское на Javascript. и второе полностью серверное request-response (для IE 6, 7, 8). Использование ReactJS дает нам возможность переходить в режим полностью серверсайд рендера (если это один из IE), и на каждый запрос выдавать готовый html. что полностью избавляет от головной боли кросбраузерного javascript и поддержки двух приложений.
и да. о браузерах я забыл. сейчас Yahoo Web Mail это два приложения. одно полностью клиентское на Javascript. и второе полностью серверное request-response (для IE 6, 7, 8). Использование ReactJS дает нам возможность переходить в режим полностью серверсайд рендера (если это один из IE), и на каждый запрос выдавать готовый html. что полностью избавляет от головной боли кросбраузерного javascript и поддержки двух приложений.
если уж извращаться… не думали о компрессии js при помощи png?
А как же deferred loading, неужели и с ним под мегабайт? или так и не перешли на YUI3, ато я давно перестал следить за тем что в яхе происходит? YUI3 был нереально крут на фоне всего бардака, который в жаваскрипте был пару лет назад, да и сейчас практически ничего не изменилось :)
YUI3 был крут на старте, но потом появились AMD и RequireJs в которых можно сделать такой же deffered loading. Во всём остальном YUI3 безнадёжно отстал и его разработку прекратили habrahabr.ru/post/235021/
Ещё до этой новости читал, что какие-то проекты Yahoo! перевёл на Ember.
Ещё до этой новости читал, что какие-то проекты Yahoo! перевёл на Ember.
А можете подробнее рассказать как вы «наворачиваете» клиентское приложение на готовую верстку?
React предоставляет эту функциональность.
в двух словах. есть входные данные (user, mailbox, conversations) они отправляются в реакт компонент на сервере и рендерится в javascript string, после чего отправляется клиенту вместе с исходными данными.
на клиенте после того как все библиотеки загрузились, мы берем те же данные и отправляем в тот же реакт компонент и говорим ему взять готовую верстку которую мы уже получили с сервера. так как конечный html идентичный в обоих случаях, реакт достаточно умный для того чтобы начать работать с имеющейся версткой так как будто он только что отрендерил ее сам (никаких DOM взаимодействий)
в двух словах. есть входные данные (user, mailbox, conversations) они отправляются в реакт компонент на сервере и рендерится в javascript string, после чего отправляется клиенту вместе с исходными данными.
на клиенте после того как все библиотеки загрузились, мы берем те же данные и отправляем в тот же реакт компонент и говорим ему взять готовую верстку которую мы уже получили с сервера. так как конечный html идентичный в обоих случаях, реакт достаточно умный для того чтобы начать работать с имеющейся версткой так как будто он только что отрендерил ее сам (никаких DOM взаимодействий)
Спасибо, это как раз то, что мне сейчас нужно. Постараюсь сам дальше поковыряться.
И еще хотелось бы задать пару вопросов, но уже про server-side, если можно.
Как вы организовали передачу данных между legacy слоем приложения (я так понимаю вы же не все переписали на JavaScript) и собственно node.js?
И какие вы посоветуете посмотреть \ почитать материалы по использованию node.js в highload проектах?
И еще хотелось бы задать пару вопросов, но уже про server-side, если можно.
Как вы организовали передачу данных между legacy слоем приложения (я так понимаю вы же не все переписали на JavaScript) и собственно node.js?
И какие вы посоветуете посмотреть \ почитать материалы по использованию node.js в highload проектах?
Всё это круто при условиях что компоненты не содержат какого-нибудь хитрого внутреннего состояния типа таймера, который будет писать что этот коммент был написан N минут назад, а так же если никак не зависят от чтения дома.
С первой проблемой легко справиться, отказом от состояний в компонентах. И в зависимости от желаемой точности, гонять раз в 30 секунд по всему дереву сверху вниз, делая апдейты на всём пути, тк комменты естественно будут находиться в самом низу, и не получится так легко откидывать большие куски деревяшки с помощью shouldComponentUpdate :)
Ну а вторая проблема никак не решаема.
С первой проблемой легко справиться, отказом от состояний в компонентах. И в зависимости от желаемой точности, гонять раз в 30 секунд по всему дереву сверху вниз, делая апдейты на всём пути, тк комменты естественно будут находиться в самом низу, и не получится так легко откидывать большие куски деревяшки с помощью shouldComponentUpdate :)
Ну а вторая проблема никак не решаема.
Решаема.
1. Если за внутреннее состояние соответствующего компонента отвечает соответствующий стор, поэтому когда мы вызываем перерендеринг, мы перерендериваем не все компоненты, а только те, в которых изменился стор.
2. Использовать линзы и immutable-js. Минусы: это не нативные конструкции js, поэтому придется постоянно оборачивать примитивы в конструкции immutable. Например, если мы делаем Promise.all().
3. Использовать facebook.github.io/react/docs/pure-render-mixin.html.
1. Если за внутреннее состояние соответствующего компонента отвечает соответствующий стор, поэтому когда мы вызываем перерендеринг, мы перерендериваем не все компоненты, а только те, в которых изменился стор.
2. Использовать линзы и immutable-js. Минусы: это не нативные конструкции js, поэтому придется постоянно оборачивать примитивы в конструкции immutable. Например, если мы делаем Promise.all().
3. Использовать facebook.github.io/react/docs/pure-render-mixin.html.
Интересно будет прочитать следующие статьи. Затупил и не нашел в блоге ссылку на rss. Продолжение будет на хабре?
Еще было бы интересно услышать ваше мнение про reflux.
На сервере тоже flux? Какое впечатление от использования? Будет ли статья? :)
Еще было бы интересно услышать ваше мнение про reflux.
На сервере тоже flux? Какое впечатление от использования? Будет ли статья? :)
я буду переводить\синхронизировать все что касается React at Yahoo Mail на хабре :)
долгое время мы сопротивлялись и не хотели использовать flux на сервере из-за сложности (синглтоны уже не могут быть синглтонами, каждый реквест должен создавать новый контекст для flux) но в конце концов пришлось перейти на сторону flux на клиенте и сервере.
про reflux, к сожалению, сказать ничего не могу. не знаком :)
долгое время мы сопротивлялись и не хотели использовать flux на сервере из-за сложности (синглтоны уже не могут быть синглтонами, каждый реквест должен создавать новый контекст для flux) но в конце концов пришлось перейти на сторону flux на клиенте и сервере.
про reflux, к сожалению, сказать ничего не могу. не знаком :)
На самом деле Flux на сервере выглядит так себе. нет особого профита. Тут лучше посмотреть на концепцию Атомов: habrahabr.ru/post/235121/. Очень похоже на reflux, но только чуть более богатое API, действительно решает проблемы. Flux отлично смотрится, если связь с клиентом осуществляется по веб-сокетам.
Дмитрий! А про синглтоны подробнее можете рассказать? Я с такой проблемой столкнулся наоборот на клиенте. В итоге, для консистентности, оставил сторы в которых может быть только одна модель.
Кстати, может быть заодно расскажите какие библиотеки/фреймворки используете помимо flux и react?
Я только начал использовать решение в своем личном проекте на клиенте и сервере и все время хочется расширить объекты, добавить новые.
Кстати, может быть заодно расскажите какие библиотеки/фреймворки используете помимо flux и react?
Я только начал использовать решение в своем личном проекте на клиенте и сервере и все время хочется расширить объекты, добавить новые.
изначально во flux от facebook все flux объекты были синглонами. в браузере это не проблема — все в скоупе одного юзера, все данные принаджелат только этому юзеру. один dispatcher, один store.
на сервере же все по-другому. если параллельно пришло 1000 рексестов от разных пользователей, то для каждого нужно создать свой контекст со своими данными. иначе все перемешается же :)
на сервере же все по-другому. если параллельно пришло 1000 рексестов от разных пользователей, то для каждого нужно создать свой контекст со своими данными. иначе все перемешается же :)
Надеялся увидеть описание как менялся сервис. Яшкина почта всегда привлекала интерфейсом. Случались интересные находки.
Я не пользуюсь почтой Яху и было бы интересно почитать кто, как и какие решение по интерфейсу принимал со временем
Я не пользуюсь почтой Яху и было бы интересно почитать кто, как и какие решение по интерфейсу принимал со временем
Интерфейс, конечно, хорошо. Но вот навязчивая реклама в списке писем и огромный баннер сбоку портят всё.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эволюция Yahoo Mail