Рендеринг всегда идет на стороне клиента. За исключением пары клинических случаев.
Неправильно сформулировал. Но суть и так должна понятна быть. Генерация представления в виде HTML.
Если бложик, новости, иб или что-то контентоподобное, то на сервере.
Если серьезное, сложное веб-приложение, то жсоны, вебсокеты, емберы и ангулары.
В предельном случае можно использовать общий бекенд для веб- и мобильных фронтендов.
А если интернет магазин?
ЗЫ: уже прочитал, что проблемы с сео при клиентсайд рендере.
На сервере. Но гугл уже научился нормально рендерить и индексировать такое, так что если магазин зарубежный, то можно и на клиенте. Хотя я бы типичный магазин делал по старинке, на сервере то есть.
>Намного сложнее поддерживать
Да ладно? По JSP, JSF спеца найти гораздо сложнее, чем фронтенд-макаку. Пердолинга меньше для бекендера.
>Тормозит и оче жирно
Ну это ещё как сказать, если у тебя хоть немного хайлоад, рисовалка на сервере покажет, что такое тормоза и жирно.
>Не нужно
Зависит от задачи - для бложика/гостевухи- да, ненужно.
По технологиям - Ангуляр хорошо подходит для подобной хуйни
Два чая адеквату.
На работе приходится импользовать ExtJS - не вздумай связываться. Весьма нишевая хуйня скорее для интранет приложений -очень сложная и из-за этого забагованная (жс хули).
Задрочи Ember или angular.
Мне еще думается что https://facebook.github.io/flux/ (react) интересная штука, но не имел с ней дела.
Еще meteorЖС сейчас форсят.
Олсо, за рендерингом на клиенте\синглпейдж\риа будущее.
А как поисковые системы индексируют подобные сайты? Или они могут в js и дом?
В эпоху облачных вычислений сама идея клиентского рендеринга выглядит утопичной.
Уже игры можно запускать удалённо.
Самый большой минус безусловно большой парк устройств. Если на йоба пк всё будет летать, то на рядовом пользовательском хромбуке летать будут полосы по экрану.
>Или они могут в js и дом?
Любая хрень в это умеет. Полно всяких фантомжс, хтмлунитов, селениумов и т.п.
Серверный рендеринг это как раз подход из девяностых и пхп-параши. Все современные сервисы отдают только жсон.
Кокие это? А то обычно когда хочешь попиздить данные с сайтика, обычно html приходит, особенно где хайлоад и важна скорость работы именно на клиенте. Тот же гугл так делает но у гугла есть конечно апи, но не всегда решает некоторые задачи.
Плюсы:
-Меньшие требования к каналу (ajax)
-Возможность встраивать готовые приложения в сторонние сайты без ебли с iframe
-Выше юзер экспириенс (пользователю всегда приятнее работать с одной сущностью, чем с набором страниц)
-Возможность оптимизации трафика на стороне клиента (актуально для хайлоада, особенно когда он развернут поверх CDN)
-Проще организовать кеширование данных, если они сильно юзеро-зависимы
-Удобно собирать различные метрики и багрепорты напрямую от приложений, пока идет отладка
-Оптимизация числа запросов
-Не так жирно, как генерация на серверной стороне (вычисления не наши, наше дело - сервер и r/s)
Минусы:
-Наследуются баги от фреймворков, на которых написаны
-JS имеет ограничения по производительности
-Сложно проводить анализ кода, не зная подробностей устройства конкретного фреймворка
-Код отдается клиенту
Почти любой крупный метапоисковик отдаёт данные в json.
>попиздить данные с сайтика
Недосайтики не нужны. У нормальных сервисов клиенты и браузеры и мобайл и другие сервисы, и работает всё через один апи. Собственно сервисная архитектура - общепринятый подход в программировании уже очень давно и только в веб-параше это стало модно несколько лет назад, так как там всё через жопу.
уходи. кормить не буду
У вас сервисы головного мозга.
Это не столько плохо, сколько бессмысленно. Проще генерировать страницы на сервере и отдавать готовые и получить работающий везде и всегда сайт чем более сложно устроенный, медленный, не работающий у половины пользвоателей и поисковиков. Причем клоуны которые делают такие поделия, зачастую и не слышали про мониторинг ошибок на клиенте.
Богатый клиент нужен если нужна высокая степень интерактивности, например если ты пишешь свой Google Drive.
Сервисная архитектура давно исплозуется в PHP: есть приложение, есть база данных, есть какой-нибудб мемкеш. А больше сервисов не надо.
В качестве преимущества SOA назвают возможность исплоьзовать разные платформы и технологии. Нужно это обычно клоунам, которые хотят написать кусок сайта на каком-нибудь ерланге или лиспе и свалить в закат, когда им надоест.
Проиграл с пхп-даунов.
В целом я с тобой согласен, но тренды таковы, что либо ты делаешь хоть какой-то интерактивный фронтенд, либо считаешься чмошником-ретроградом из второго эшелона, который ниасилил клиент-сайд. А у меня просто руки не подымаются делать UI из палок и говна, после того как писал на монолитных Qt или Swing, которые изначально заточены под UI. То ли я старею, то ли нынешняя молодежь знает о фронтенде больше чем я. В общем я всегда уговариваю заказчика делать поменьше всего на клиенте, потому что потом гораздо легче найти ребят которые быстро доделают и починят, да и тестировать проще - не надо раскидывать тесты по клиенту и серверу.
>Сервисная архитектура давно исплозуется в PHP: есть приложение, есть база данных, есть какой-нибудб мемкеш.
Ебать дебил. Как будто в принципе есть возможность эти вещи не разделять.. Тебе говорят про сервисную архитектуру твоего приложения.
Статья на тему какого пшека: http://eshlox.net/en/2014/05/04/short-story-about-rendering-html-client-side-vs-server-side/
Если коротко из статьи, то минусы клиент рендеринга:
1. отсутствие индексации поисковиками, что выливается в
2. атомная ебля с фреймворками (ибо необходимы)
3. атомная ебля с поддержкой клиентской стороны
4. долгая загрузка страниц (ВТФ?)
На мой взгляд, костяк проблем только в индексации поисковиками. Легко решается, но порождает рост приложения, а значит поддержку и хуеву тучу ошибок.
4-й пункт - хуита.
Дискач.
Я хуй знает, но твиттер одно время рендерили все на клиенте, потом дропнули, сказав, что дохуя головняков. Ты сможешь лучше?
Рендеринг на клиенте занимает довольно спецефическую нишу - приложухи для всяких интранетов, еще админки ЦМС-ок, где на поисковики похуй.
В обем, идея не нова, но не оправдывает себя в большинстве случаев.
И с отладкой соснешь, базарю.
Охуеть блядь, если б таких уеб как ты слушали, инторнет выглядил бы даже хуже чем на пикрилейтеде.
Тошо сервер не отдает скриншоты страниц а хтмл это уже рендер у клиента бля, а будущее за улучшением этого всего, аякса там и прочего, в идеале будут серваки одни заголовки отдавать, состояние клиента в куках забирать и все.
А тошо соснули пока с реализацией, так это пушо стандартизация страдает, когда сделают единое ядро типа и пидорнут все браузеры без этой шняги, вот тогда заживем.
> Я хуй знает, но твиттер одно время рендерили все на клиенте, потом дропнули, сказав, что дохуя головняков. Ты сможешь лучше?
Прохладная история. Зашел сейчас в твиттер, покликал по твитам. Типичное Singepage Application. Просто вместо хэшбенгов используются нормальные урлы.
>отсутствие индексации поисковиками
Сам же гугол форсит свои ангуляры, но при этом не знает как индексировать такие приложения?
>ебля с фреймворками
Как и в любом другом направлении, если хочешь что-то сделать сложнее хеллоу ворда.
>атомная ебля с поддержкой клиентской стороны
Как раз когда у тебя нормальный фреймворк, структурирующий всю кодобазу, а не говнопортянки на джиквери с динамической бекенд генерацией шаблонов с серверными вставками - то намного удобней поддерживать такой чистый клиентсайд.
Нытьё про отладку - это просто сопли неосиляторов.
Двачую.
Одностраничный сайт — говно.
Всплывающие окошки — аякс.
Постинг форм — аякс (с последующим редиректом).
Всякие автообновления на странице — аякс.
Всё остальное отдельными страницами, которые отдает сервер.
> 4. долгая загрузка страниц (ВТФ?)
Вместо того чтобы просто получить страницу тебе нужно скачать саму страницу, кучу жс говна и штук 5 джсонов.
Как там, в 2000 году?
Сейчас этот кодж закешируется, и грузить нужно будет только компактный шаблон, сжатые данные и всё. Далее рендер будет разворачивать на клиенте страничку с нужными данными в нужном объеме.
Да, вот эта вот вся хуйня против простой загрузки странички.
В приницпе есть. Называется Embedded Databases. А кеш можно банально заменить на массив в памяти прилоежния. Так что сам дебил.
> но тренды таковы, что либо ты делаешь хоть какой-то интерактивный фронтенд, либо считаешься чмошником-ретроградом из второго эшелона, который ниасилил клиент-сайд
Зачем слушать людей глупее тебя?
Я подозреваю, люди, делающию портянку на джейквери так же легко сделают ее на ангуляр.
И что в 2014 году люди стали тупее? Я прекрасно различаю загрузку за 50 мс (условно) и за 1500. И прекрасно отличаю легкую верстку от тяжелой при прокрутке. За других людей сказать конечно не могу, может у них мозги медленно шевелятся или у них компьютер всегда тормозит и они разницы не видят.
Ну и приведу конкретный пример как сайты становятся хуже: после редизайна мануал php начал использовать модные кастомные шрифты, и подключил к странице целый мегабайт их (8 файлов для разных начертаний, любой кто умеет пользоваться инспектором их увидит). Если раньше на странице сразу появлялся текст, то теперь часто появляется страница без текста и надо ждать пока шрифты загрузятся. Можно подумать шрифты там самая важная часть сайта.
Также не следует забывать про длинный хвост распределения времени ответа. Из N запросов 1 по какой-то причине может затормозиться. Чем больше сайт использует блокирующих ресурсов (яваскрипты, шрифты, аякс-запросы), чем больше из них размещены на стороннем домене, тем больше веоятность увидеть этот лаг на сайте.
Так что старые добрые технологии до сих пор надежнее и провереннее.
> Сейчас этот кодж закешируется
Наивный мальчик. Сейчас каждый сайт все свои ресурсы помечает как кешируемые и так как кеш не резиновый, файлы там и 20 минут не проживут.
Ну да, каждый раз тянуть гору говна это конечно гораздо лучше чем один раз дернуть гору говна а потом запрашивать только данные.
Главный вопрос на который не отвечает статья: ради чего вообще делать генерацию кода на клиенте? На сервере она делается прощу и требует меньше усилий.
Пример: пишем hello world, сохраняем под именем index.html. Сайт готов. А теперь попробуй сделать такой же простой сайт на основе клиентсайд рендеринга.
Я подозреваю, люди просто не знают ничего кроме яваскрипта и потому придумывают всю эту ерунду. Они еще и ноду с монгой наверно по той же причине вместо нормальных технологий посоветуют.
На обычных страницах всякие CSS, JS и изображения точно также кешируются. Если ты не налепил 200 килобайт лапши в шапку и футер каждой страницы то классический сайт вряд ли будет медленнее. При этом он будет во много раз проще устроен, открывается на Нокии 1100 и на твоем телевизоре, читается роботами, надежнее, отобразится даже если загрузился только html, и не покажет белый экран при исключении в js коде.
Получить тарелку говна лучше, чем получить яблоко, нож, дождаться, пока яблоко порежется на кусочки, прожуётся, переварится и высрется на тарелку.
Раз уж мы аналогиями разговариваем.
Ебать дебил, при серверсайд рендеринге всю js и css параше еще парсить придется, SPA это сделают только один раз при первой загрузке приложения
А при неотловленном исключении в коде на сервере все конечно же заебись продолжить работать, молодец
> SPA
Это еще что за поебень?
Верно. Но если твой CSS/JS небольшой, порядка 50 Кб, то это будет быстро. И даже если он больше, а зачем для этого полноценный клиентсайт рендеринг? Разве недостаточно скачать аяксом с сервера HTML и отобразить, без всех этих наркоманских бекбонов, ангуларов и моделей на клиенте? Это явно будет и проще в реализации и быстрее работать.
Серверные ошибки в отличие от клиентов мониторится. Плюс серверные ошибки в отличие от клиентских не зависят от браузера. Серверная ошибка видна в новом сафари которым пользуется разработчик, а яваскриптовая, специфичная только для некоторых браузеров, нет.
Кроссбраузерная реализация скачивалки страниц без перезагрузки мне кажется будет занимать строк 100-200 на vanilla js. Ее можно прямо в страницу встроить при желании. Вконтакте вроде бы именно такую схему и использует, рендеринг на сервере, на клиенте только отображение пришедшего html для второй и далее страниц.
Бро, зачем незачем это не тот вопрос который можно объективно обсуждать, если разработчик/заказчик хочет чтобы вебприложение работало без рефреш-релоуд циклов и задержен, он будет юзать клиентский рендеринг, если нет - то нет. Это просто подход со своими минусами и плюсами, но то что скорость приложения в пользовательском восприятии будет быстрее, а нагрузка на сервер уменьшится - факт
Диванный не палится. Нормальные пацаны уже давно умеют мониторить клиентские ошибки
> если разработчик/заказчик хочет чтобы вебприложение работало без рефреш-релоуд циклов и задержен
В том-то и проблема что дебилы хотят чтобы использовался модный %frameworkname%, а не чтобы сайт грузился быстрее. Но на практике выйдет наоборот, особенно если у тебя высокий пинг, мобильный интернет и прочее. Не может HTML страница загружаться медленнее чем HTML + куча JS + куча аякс запросов.
Шутишь?
Сервер сайд: стянуть HTML, пропарсить закешированный JS и CSS
Клиент сайд: стянуть JSON
Распиши то же самое для первого захода. Есть конечно сайты на которых я смотрю много страниц (например: хабр), но наверно половину сайтов я открываю из поиска, пролистываю и закрываю.
При том для того же хабра, я особо тормозов не замечаю. Современные браузеры, если страница грузится быстро (а стили и прочее закешированы), не показывают белый экран при переходе, а сразу показывают новую страницу, то есть выглядит как будто перезагрузки нет.
И сразу вопрос номер два, а нафига JSON а не готовый HTML? Для HTML не надо на клиентсайде городить приложение, а хватит кода уровня
$.ajax({
success: function (html) {
$(x).html(html);
}
По моему если уж избавляться от перезагрузки страницы то с серверсайдным рендерингом все равно проще выходит.
По моему SPA нужны там, где у нас не сайт, а приложение. Например штука где много форм, ты можешь что-то редактировать, перетаскивать, и т.д. А для сайта рассчитанного на потребление контента типа хабра, вконтакте, medium или янедкс все это излишне.
Первый заход
Сервер: стянуть HTML, стянуть CSS и JS, их же пропарсить
Клиент: стянуть CSS и JS, далее либо получить JSON и построить приложуху (даже глазу не будет заметно, ибо JS в современных браузерах очень быстр), либо отрендерить первую страницу на сервере (см. react.js например)
> индексации поисковиками
не нужно
>атомная ебля с фреймворками
Атомная ебля с фреймворками будет у двух пхп-васянов, решивших замутить сайт. В более-менее крупных проектах есть фронтендер, который знает хотябы ангуляр, которого вполне достаточно.
Ты видел решения для серверсайд-рендера на других языках, кроме пхп? Много там специалистов?
Но главная проблема убогого сервер-велосипеда даже не в этом. Сейчас эпоха мобильных приложений. Индусы ананируют на убогий ведроид, илита онанирует на аппл. И тут без сервиса уже не обойтись.
Ну так почему бы не использовать SPA для интерактивных приложений и классический серверсайд для контентных сайтов?
Очевидно, потомучто нахуй ненужно увеличивать объём кода в 2 раза, причём кода, делающего одно и то же
Потому что SPA отзывчевее, но нужно понимать насколько сложнее будет это запилить
Кода в классическом подходе как раз меньше. Это со SPA проблем больше, надо его писать, дублировать модели и там и там, настраивать цепочку сборки и деплоймента. Пи этом получается более громоздкий, мделенный и ненадежный код.
Если расшифровать SPA то там написано для чего он предназначен: для приложений.
Как предлагаешь работать с разной диагональю экрана? Страницу перезапрашивать?
Ты выдаешь с сервера разные страницы разным экранам? Алсо как ты насервере узнаешь диагональ?
@media
<picture>
<source>
srcset
sizes
Почитай что ли про HTML 5 и CSS 3. Для responsive design не нужен яваскрипт.
И да, это пока работает только в Хроме 38, тот же вконтакт переключает размеры картинок яваскриптом пока что. Но @media работает уже давно и везде.
Это был аргумент против рендера на сервере.
Окей, т.е. набор элементов UI у тебя один для всех платформ и они отличаются только размером?
Если ты хочешь намекнуть на мобильную версию, то ее делают либо адаптивной версткой, либо если этого не хватает, делают отдельный мобильный сайт.
Насчет элементов UI, лучшее решение на мобильных устройствах — исплоьзовать нативные элементы, они на них работают лучше всего. Умные библиотеки виджетов так и делают.
И я не понимаю, какое отношение ангулар или SPA имеет к проблеме отображения на разных устройствах. Для мобильных устройств просто HTML горазд удобнее с учетом ограничений по CPU и памяти.
>ограничений по CPU и памяти
Через год-полтора будет уже совершенно не актуально. Вобщем-то и сейчас не актуально, но к тому времени подойдет к концу лайфцикл телефонов 2007-2009 годов продажи.
>И я не понимаю, какое отношение ангулар или SPA имеет к проблеме отображения на разных устройствах.
Современный сайт - это приложение, as is. Это продиктовано бизнессом, а не веяниями в дизайне. Соответственно приложение должно запускаться на любом железе с правильным софтом, куда его можно поставить. Беря на себя ответственность за верстку отдельных версий на все случаи жизни ты теряешь время, теряешь время - ты дороже для заказчика, дороже для заказчика - теряешь рынок. Как-то так.
> Современный сайт - это приложение, as is.
А вот это уже фанатизм. Сайты разные. Есть сайты-приложения, есть контентные сайты, есть что-то между.
И рассмотри мой юзкейс: открываю страницы из поиска чтобы найти нужную. Мне в таком случае меньше всего нужно загружать какие-то приложения, а хочется быстрее увидеть текст и понять, то это или не то. Впрочем, большинство серверсайд сайтов (западные в основном) уже давно открываются небыстро из-за кучи рекламы, которая намертво блокирует вкладку на пару секунд или больше при загрузке.
> Через год-полтора будет уже совершенно не актуально
Наивный. Через год-полтора станет модным ставить фулскрин видео на фон и ресайзить на клиенте огромные картинки с наложением эффектов и развитие железа будет не заметно. Алсо, я читал статью где-то, мобильные архитектуры типа ARM по производительности на порядок проигрывают тому же интелу на той же частоте. Память там скорее всего тоже медленная. То есть не надо думать что 2-ядерный 1.8 Ггц ARM сопоставим с интеловскими десктопными процессорами.
> Беря на себя ответственность за верстку отдельных версий на все случаи жизни ты теряешь время, теряешь время
Достаточно сделать 2 версии средствами CSS: для больших экранов и для маленьких. Если заказчик не хочет платить за это, достаточно сверстать большую версию, а мобильный пользователь будет таскать ее пальцами, это лучше чем ничего. Ты то ли не верстал никогда то ли плохо в этом разбираешься.
И я по прежнему не понимаю при чем тут SPA. Ты без ангулара не способен ширину блока текста поменять?
>Ты без ангулара не способен ширину блока текста поменять?
Код должен укладываться во внутренник конвенции фирмы. Разнобоя быть не должно.
>это лучше чем ничего
Ну может да, ты вполне можешь быть прав (хотя мне как пользователю это было бы неудобно). Однако заказчик с тобой не согласится и ты потеряешь клиента.
Я к чему клоню, что здесь надо отойти от технологий и смотреть где лучше соотношение (число фич)/(число человеко-часов), причем в человеко-часы надо включать в т.ч. и поддержку. И исходя из этого принимать решение, какую технологию использовать. Фактически это только и выбилой "сервер-сайд" с рынка, а не какие-то прям ужасные технические ограничения.
> Код должен укладываться во внутренник конвенции фирмы. Разнобоя быть не должно.
Это в css делается.
> выбилой "сервер-сайд" с рынка
Слишком сильно преувеличиваешь.
В клиентсайде человеко часов будет как раз больше.
Он про случаи когда требуется не только сайт сделать, но и сам сайт, мобильную версию, андроид приложение, ios приложение, wp приложение, десктоп приложение для 2-3 OS, хроморасширение, файерфоксорасширение и прочее.
То есть на сервере только api.
> Если раньше на странице сразу появлялся текст, то теперь часто появляется страница без текста и надо ждать пока шрифты загрузятся
Ну вот смотри. У тебя либо уже есть открытая страница, и что-то на нее загружается под маской - ты видишь, что она загружается и все в порядке.
Либо ты сидишь перед пустым экраном браузера и ждешь, пока где-то в Зимбабве издыхающий от жары сервер закончит рендерить твой скриншот страницы, который всего-то десять тысяч триста девятый в очереди. А потом еще будешь ждать пока этот скриншот загрузится.
А в твоем примере тоже мне нашел пример - криворукий сайт на похапе, не осиливший кеширование шрифтов это будут и шрифты тоже. Захотел что-то поменять на странице - серверу отправил запрос и он снова начал рендер твоей страницы, а ты опять сидишь перед пустым экраном.
>дублировать модели
Это особая быдлокодерская забава такая - дублировать серверные модели там, где они нахуй никому не упали? Абстракцию еще в школе не проходили?
Я встречал другие варианты, приложения делают позже и для них добавляется АПИ сбоку к сайту.
> а и ждешь, пока где-то в Зимбабве издыхающий от жары сервер закончит рендерить твой скриншот страницы
Ты по моему никогда серверсайдом не занимался. Рендеринг шаблона в самом худшем случае (когда база и логика быстро работают) занимает половину времени. Это же всего лишь подстановка переменных в шаблон.
> не осиливший кеширование шрифтов
Если в моем кеше их нет, это никак не поможет. Криворукое решение именно исплоьзовать мегабайт кастомных шрифтов для технического мануала, у которого сценарий использования открыл — посмотрел порядок аргументов — закрыл. Ты по моему вообще ни в чем не разбираешься, фанатик какой-то упоротый.
Ты тоже фанатик. Серверные модели тебе понядобятся как только ты начнешь писать прилоежния сложнее TodoList что ты видимо никогда не делал.
>Серверные модели тебе понядобятся
На UI? Нет, не понадобятся. За десять лет разработки вот ни разу пригодились, веришь? Все как-то обходился абстрактной рефлексией.
Зачем нужен клиентсайд рендеринг:
отрендерить только часть контента, остальную — когда пользователь доскролит
на серере рендерится только то, что нужно индексировать, и потом обогащается клиентским рендерингом: виджетами-хуиджитами, фотками-хуетками
магазин с фильтрами-хуильтрами
один сервер, отдающий JSON, и хуилион клиентов: сайт, мобильный сайт, приложухи, админки
отрендерить только часть контента, остальную — когда пользователь доскролит
на серере рендерится только то, что нужно индексировать, и потом обогащается клиентским рендерингом: виджетами-хуиджитами, фотками-хуетками
магазин с фильтрами-хуильтрами
один сервер, отдающий JSON, и хуилион клиентов: сайт, мобильный сайт, приложухи, админки
приложухи-хуежухи
Работаю с React на Nodejs – изначальный рендер HTML производится на сервере, дальше на клиенте. Поэтому сайт правильно индексируется и работает с nojs-браузерами.
Даже для ПХП-блядей давно есть V8 kit и либы с подливой на выбор.
О чем тред-то?
Даже для ПХП-блядей давно есть V8 kit и либы с подливой на выбор.
О чем тред-то?
Поясни, что конкретно рендерится на клиентухе. Прост, если так, то вся эта хуита не сработает перед гугл-роботом и оный тупо возьмет на клык.
>зачем слушать людей глупее тебя?
Дело не в коллегах, которые по большей части понимают все проблемы раздутого фронтенда, а в заказчиках, тимлидах, которые просто не могут выпасть из тренда - везде все свистопердящее и динамичное, а статичные сайты, которые обновляются при переходе по ссылке - хуевый тон. Ну вот так вот сложилось. Думаю мы еще несколько лет поедим это дерьмо, но со временем пойдет тренд к упрощению, ну или хотя бы к четкому разделению ситуаций, когда нужен богаты фронтенд и когда он не нужен.
Лучше получить обед сразу и быстро, чем ждать пока тебе посолят салат, глядя как при тебе чистят картошку, которая по нескольким причинам может внезапно исчезнуть, оставив тебя наедине с чистой тарелкой. Ах да, обычная тарелка не подходит, ее нужно снизу усилить балками и костылями, чтобы она выдержала обед.
MY ANALOGYA IS BIGGER THAN YOURS
Маня прогоняет селениум тесты под всеми платформами? Ню-ню. Сразу видно узколобое офисное быдло, которое сидит на большом проекте или пачке однотипных проектов, под которые все настроено. У быдла сформировалось квадратно-гнездовое мышление, и теперь оно при переходе на новую работу будет вещать как надо ПРАВИЛЬНО делать.
Анон, оставь свое мыло пожалуйста. Нет, работу предлагать не буду, просто пообщаться.
Хорошо,а как ты делаешь валидацию форм/моделей на клиенте и сервере, особенно в случае, если JS отключен?
Клиентсайд намного удобнее и быстрее писать при рестфул модели. Кстати, как возможен MVC/MVVM на клиенте без рестфул и синлпейдж архитектуры?
>Думаю мы еще несколько лет поедим это дерьмо, но со временем пойдет тренд к упрощению
Ты же понимаешь что этого не произойдёт, как не мог, например, произойти переход из web2.0 обратно в web1.0? Приложения не становятся проще, они с каждым годом всё сложнее и пользователи хотят только больше возможностей. Никому нахуй не всрались статические сайтики, когда веб наполняется приложениями типа гуглдока. Веб эволюционирует и появление ангуляров это не просто от нехуй делать, чтобы в старбаксах обсуждать, это естественная реакция на возросшие потребности индустрии.
Позиция как у тебя, целиком ретроградская, как у байтослесарей из 80-х бугуртящих от ООП. Но как и в их случае, твои кукареки ни на что не влияют, и индустрия идёт дальше.
>и индустрия дальше жрет говно
пофиксил
Проекции пхпдауна
Ошибаешься, пидорок.
Ты не видишь картины в целом, наверняка потому что ты специализируешься на SPA. У меня тоже есть ангуляр в двух проектах, потому что так правда удобнее делать сложные таблицы, где редактирование идет прямо на месте, без открытия сущности. Но для большинства проектов сложный клиент-рендеринг - это оверкилл. Чтобы оно нормально работало, тебе нужно ставить ноду + минифактор + bower. Этого половина фронтендщиков делать не умеет. Если вручную накачать скрипты, то та же половина фронтендщиков не будет их обновлять до самого судного дня. Те фронтендщики, что могут это сделать стоят как 3 пыхомакаки, а потому не выгодны. Макак, которые могут заделать рестфул бэкенд и пиздатый фронтенд несравнимо меньше, чем макак, которые могут сделать нормальный бэкенд и в случае крайней необходимости сделать динамический фронтенд хоть как-то. У лоу-кост проектов, которых дохуя, не стоит вопрос сделать чтобы работало пиздато работало под всеми платформами, стоит вопрос сделать чтобы хоть как-то работало под всеми платформами.
Не надо забывать, что пых при всех своих недостатках стал лидером потому что быдло в него смогло. Чтобы нормально мочь в богатый фронтенд нужна большая квалификация, что сразу ограничивает мейнстримовость технологии.
Рест выглядит красиво только на картинках. То есть сама идея что сервер должен быть stateless хороша (но она реализуется и с серверным рендерингом), а вот идея что можно представить информацию ресурсами с урлами типа /user/1 и постить/путить/гегить их абсолютно нерабочая.
На практике тебе надо получить список последних 10 сущностей класса А, сущности класса B c идентификаторами 1, 2, 3, 4, 6, 10, 11 и привязанные к ним сущности класса С. Как ты это сделаешь со своим АПИ? Либо ты делаешь «неканоничный» АПИ за который тебя в твиттере обзовут пехапешником-быдлокодером, либо имеешь кучу мелких аякс запросов что не способствует скорости работы.
Все эти ваши клиенты это пятая нога. У нас уже есть клиент-браузер, есть АПИ под названием HTTP, по которому браузер может получать код страниц и отправлять данные. Если тебе нужно АПИ для мобильного приложения ты либо добавляешь в контроллере if чтобы отдавать данные в другом формате типа JSON либо каким-нибудь генератором это АПИ генерируешь. Тем более что скорее всего логика работы сайта и мобильного приложения разная (иначе зачем оно вообще нужно?) и им нужны разные функции АПИ и единое для них не сделать.
Ну и писать код на сервере удобнее хотя бы потому что это более контролируемая среда чем 100500 разных юзерагентов каждый со своими заскоками.
Может он там и не нужен?
Он ее не делает очевидно. Для TodoList она не требуется.
Ты все свалил в кучу. Есть приложения типа гуглдока, а есть блоги типа вордпресса, есть форумы типа реддита. Сайты разные, разные сценарии использования и разные технологии лучше подходят. Есть приложения где человек проводит много времени, есть где потребляет контент.
Конечно владельцы контентных сайтов типа хабра/реддита/котаку etc хотели бы превратить их в приложения чтобы они были постоянно запущены у пользователя, или хотя бы висели на стартовом экране браузера и мигали уведомлениями, чтобы постоянно просматривали новые статьи и рекламу, но я как пользователь это бы не хотел. Если я хочу прочесть пост на medium по ссылке я хочу прочесть пост а не отвлекаться на обновляющиеся списки новых постов, вылезающие со всех сторон предложения почитать что-нибудь еще и «рекомендации» сделанные на принципе «миллион мух не может ошибиться» (откройте главную ютуба чтобы понять что интересует миллион мух), вопросы не хочу ли я оставить свой имейл и так далее.
В случае с серверсайдом есть готовые платформы типа вордпресса, который используют не только для персональных блогов. Может конечно появится какая-то аналогичная платформа для клиентсайда и тогда это станет повсеместным (что скорее плохо чем хорошо, лучше быдлокод на сервере чем в твоем браузере). Более того, для совсем неграмотных ее можно не хранить на сервере, а подключать внешним скриптом как подключаются disqus/hypercomments. Но это для несерьезных приложений, так ни один нормальный человек не отдаст свою базу данных на сторону.
>есть готовые платформы типа вордпресса
Вся суть пхпдаунов, копротивляющихся прогрессу.
>javascript
>прогресс
>Если тебе нужно АПИ для мобильного приложения ты либо добавляешь в контроллере if
Yebat ты bydlocoder. А потом еще что-нибудь понадобится, и ты снова добавишь if. И еще. А потом еще. Ну а хуле, это же всего один if за раз, правда?
Ты просто не в теме, пёс.
>Может он там и не нужен?
Лол, охуенно просто. Может тебе твой серверный MVC тоже не нужен? Давайте просто ебашить портянки говнокода без разделения логики от данных и от представления, без биндингов, без DI, без инкапсуляции. Пиздец.
>есть готовые платформы типа вордпресса
Понятно. Александр! Это вы админку в битриксе делаете?
Я не знаю насколько нужно иметь засраные, закостенелые мозги, чтобы не понимать, что когда сервер манипулирует своими чистыми серверными данными, а клиент манипулирует своими чистыми клиент данными - это правильно.
Это просто логично, каждый компонент системы занимается своей работой отдельно, а передаваемая между ними информация должна находится в универсальном, максимально чистом виде. Клиент и сервер должны быть независимы друг от друга, и зависеть только от протокола обмена. Не нужно быть йобаным гением, чтобы это понимать, хотя подобный принцип используется повсюду, и даже не только в программировании, но и других областях, в той же теории систем.
Сейчас, когда клиентсайд имеет все средства для того, что бы быть полноценной платформой, а не статическим куском говна с местечковыми ajax-свистоперделками на архаичной джиквери-блевоте, этот принцип разделения, давно используемый в любой нормальной сфере программирования переходит наконец то и в веб. И визги ретроградов вроде тебя, что мол давайте по старинке, как же так, верните мой 2005 - звучат как симфония прогресса и это прекрасно.
Мне кажется ты просто онли-серверсайд макака (хотя те же рубиняши или нодовцы понимают смысл рестфула, так что ты просто пхп или питонодибил) или олдскульный фуллстек натягиватель шаблонов на вордпресс. В таком случае ты просто не можешь понять, насколько сильно фронтенд программирование с использованием рестфула и ангуляра/ембера отличается от того, что было раньше.
Может это ты просто восторженный неопытный школьник?
Ты просто мыслишь какими то странными категориями, типа производительности, которая может и должна быть оптимизирована на совсем другом уровне.
В твоём же примере, про много ajax запросов, хоть он и не совсем корректный, можно использовать вебсокеты/комет/кипэлайв кэшированное соединение/заголовки для отправки нескольких запросов за одну сессию и т.д.
К тому же, что страдает от этого? Типа сервер не потянет? Так ты же его наоборот разгружаешь, освобождая от ненужного на нём динамического формирования шаблона. Ведь теперь js просто стаскивает минимальный статический шаблон через роутинг и сам превращает его во что нужно, мощностями клиента, а не сервера. К тому же вебсервера статику отдают во много раз быстрее динамики, а если nginx под это дело поставить, так вообще охуеешь. Теперь когда у тебя на сервере чётко отделена статика от чистой динамической информации и оптимизирован протокол обмена, всё будет работать только быстрее.
И даже гипотетически, если это и дало бы какое-то замедление, что у тебя от него прям пиздец кишки распидорасило тормозит, то может это сервесайд говно, раз не может работать по принципиально правильной схеме? И пора бы с тормозной пхп-параши перейти на что-то посерьёзней?
Сколько раз видел, как жертвуют теоретически принципиально правильной моделью, ради каких-то мутных выигрышей по производительности - столько раз это всё в результате скатывалось в говно. Подобный подход в прикладном программировании вообще не уместен.
прагматичные умудрённые говноеды набежали
У меня от твоих постов ВЕБ ДВА О, блядь.
Поддвачну.
Ещё один натягиватель шаблонов на вордпрес порвался.
Пока нормальные люди пытаются перестать есть говно, коим веб до недавних пор и являлся, прагматичные говнари просят ложку побольше.
Да да, мы поняли, что ты школьник-максималист. Иди дальше натягивай ангуляр на жсон.
А сценарий таков:
Стандартизация ES6, выход AngularJS 2.0, становление его стандартом, как Spring в жабе. Все будут юзать рестфул с MVVM как в мобайле, будет тусовка хипсторов с альтернативными фреймворками и кучка пристарелых ретрогарадов занимающихся серверным шаблоновысиранием, с непониманием, зачем всё это надо было, ведь можно просто ебошить как 20 лет назад, но к ним у комьюнити будет отношение как сейчас к каким нибудь пердл/ткл некроёбам и вскоре им суждено кануть в небытие.
Олсо, всякие там пыхапе с серверов тоже будут убраны нахуй, несмотря на то, что там есть фреймворки для генерации рест-приложений. Причина будет не в самом пхп, а в многочисленных пхп-даунах, которые ничего, кроме шаблоновысирания на Kohana осилить не способны.
Стандартизация ES6, выход AngularJS 2.0, становление его стандартом, как Spring в жабе. Все будут юзать рестфул с MVVM как в мобайле, будет тусовка хипсторов с альтернативными фреймворками и кучка пристарелых ретрогарадов занимающихся серверным шаблоновысиранием, с непониманием, зачем всё это надо было, ведь можно просто ебошить как 20 лет назад, но к ним у комьюнити будет отношение как сейчас к каким нибудь пердл/ткл некроёбам и вскоре им суждено кануть в небытие.
Олсо, всякие там пыхапе с серверов тоже будут убраны нахуй, несмотря на то, что там есть фреймворки для генерации рест-приложений. Причина будет не в самом пхп, а в многочисленных пхп-даунах, которые ничего, кроме шаблоновысирания на Kohana осилить не способны.
То есть ты считаешь, что идея независимости подсистем (клиента и сервера) - таки неправильная?
Короче, вордпресоманьки, и прочие пхп-дауны, это ваш последний шанс выйти из этой охуитительной дискуссии не опущенками.
Либо вы приводите какие-то конструктивные опровержения сказанного в / в и в , либо с брюзжанием "пок-пок сопляк говна не поел не знаешь как надо" коллективно сливаетсь. Особенно интересует принципиальные противоречия, а не прикладные "пок пок красива тока на бумаге, на практике медленно работает, тупо сделали", хотя и последние так же можно оспорить.
MVC не нужен. Нормальный код не нужен. Нужен только битрикс и вордпресс!!!! кококо
Обана, сопляк говна поел.
Один слился, ждём остальных.
битордик_палится.тхт
Ждешь когда тебя обоссут? Так уже. Почитай тред еще разок. Было несколько хороших ответов , а твои высеры уровня "why angular.js/ember.js/huypizda.js is awesome" или "микросервисы - будущее" - нихуя не аргумент, а маркетинговое говно.
Правда я не знаю для кого ты их тут высрал. Дебилы и так найдут.
>мам, добро ведь победит и пхпэдауны соснут, да? скажи, мам, что да, скажи
нет, сына, нет
>вскукареки без конструктива
Понятно. Ещё один.
Олсо, в треде за генерацию на сервере выступали одни дауны без аргументов, тупо проскипавшие всю критику.
Я выложил некоторые аргументы: 1 по поводу разумности разделения и независимости подсистем (клиент-сервер), 2 по поводу невозможности MVC или MVVM на клиенте без рестфула, 3 по поводу того, что повышение нагрузки при рестфуле - миф, 4 по поводу того, что приложениям с течением времени свойственно усложнятся, а не наоборот.
Никаких ответов на это в треде нет.
>микросервисы - будущее
Да блять, сервис-ориентированная архитектура - настоящее индустрии уже десятки лет, и только в отсталом вебе к этому пришли недавно, а не могли раньше это сделать из-за отсутствия полноценной клиент-сайд платфоры.
Иди зашейся порватка, по всему треду воняешь, а сказать толком ничего не можешь.
Я вижу в треде ЯРОСТЬ фронтендопетуха, который не может понять, почему остальные не бегут мазаться говном, в котором он сам уже по уши.
Что ты имеешь в виду под генерацией на клиенте?
Вот зашел человек на сайт, что ему придет? Пустой хтмл с ссылкой на скрипт, который ему весь дом построит?
Или будет общий хтмл со скриптами, которые асинхронно подсосут весь контент?
http://www.youtube.com/watch?v=ri2XWgIt59U
Вот классный доклад.
Если коротко.
Критический HTML и CSS на 1000 пикселей вниз надо отдавать в первые 14Кб. Для этого есть специальные средства.
Дальше отдавать весь остально ксс, весь джс, дальше всю рекламу и так далее. Результат - 99/100 в анализе гугла и загрузка за 0.5 секунд. Насчет шрифтов там тоже есть, видел в треде бугуртят, там тоже рассказано как делать надо.
Вот классный доклад.
Если коротко.
Критический HTML и CSS на 1000 пикселей вниз надо отдавать в первые 14Кб. Для этого есть специальные средства.
Дальше отдавать весь остально ксс, весь джс, дальше всю рекламу и так далее. Результат - 99/100 в анализе гугла и загрузка за 0.5 секунд. Насчет шрифтов там тоже есть, видел в треде бугуртят, там тоже рассказано как делать надо.
> В твоём же примере, про много ajax запросов, хоть он и не совсем корректный, можно использовать вебсокеты/комет/кипэлайв кэшированное соединение/заголовки для отправки нескольких запросов за одну сессию и т.д.
И это будет рест апи? С сессиями? На вебсокетах? Наркоман?
То есть только чтобы назло php программистам поставить ангулар, мы должны городить еще комет демона, как-то налаживать его взаимоотношения с другими компонентами (тащить глючные полифиллы для не поддерживающих вебсокет клиентов). Ты то ли упорот, то ли никогда больше TodoList ничего не писал.
> К тому же, что страдает от этого?
Здравый смысл
> мощностями клиента, а не сервера.
Ты школьник знаешь какое железо ставят на сервера (а не на твой хостинг за 5 копеек в год) и какое встречаетя на клиентах? Их даже близко сравнивать нельзя. Тем более я не представляю какой роутинг надо нагородить чтобы нужны были «мощности». Алсо сразу вопрос номер 2, как ты думаешь, сколько роутов, контроллеров, моделей, сущностей, таблиц в базе данных, шаблонов в типичном активно развивающемся проекте который пилят человек 5-7 в течеие 3 лет? И сколько надо из этого вытащить на клиент в твоей схеме?
> К тому же вебсервера статику отдают во много раз быстрее динамики,
Рест апи это динамика ребенок.
> Сколько раз видел,
Судя по тому что ты пишешь если что ты и видел много раз так это борщ от твоей мамки.
В треде давай общаться. Только я тут нечасто появляюсь.
Если это надо сделать одинаково во многих контроллерах то можно добавить функцию. Но на практике скореее всего каждй раз это будет немного по разному и придется все же ставить иф.
> Критический HTML и CSS на 1000 пикселей вниз надо отдавать в первые 14Кб
Если не упарываться и не писать огромные простыни и подключить 10 абстрактных less sass grunt css фреймворков то это реально без всяких специальных оптимизаций.
В общем
— надо различать сайты-как-приложения и сайты-не-как-приложения, для них нужны разные подходы
— если делать клайентсайд, нужно решать проблему дублирования моделей, бизнес логики и шаблонов. Пока для этого из реально работающих вещей есть только нода с какими-то хитрыми фреймворками
— сделать эффективно сайт и мобильное/десктопное приложение на общем Апи вряд ли получится
— чистый рест из учебников не совместим с высоколатентными соединениями кои реальность сгодняшнего веба и никуда не денутся в обозримом будущем ибо скорость света не победишь. Фанатики рест пытаются спасти ситуацию даже тем что помещают рест клиент на сервер: он собирает страницу через рест апи на сервере (там это быстрее выходит) и отдает клиенту.
>сколько надо из этого вытащить на клиент в твоей схеме
Не больше представления пятидесяти строк одной таблицы, периодически с простенькими джоинами. Что сказать-то хотел?
Все-таки оставь мыльце, мне было бы интересно поговорить с тобой не только о фронтенде. На том же gmx.com зарегать постяонное дело пары минут.
Промазал.
При богатом клиенте может случиться обосрамс, если нужно будет какие-то действия с уже имеющимися моделями выполнять на сервере - расчет статистики, поиск неактивных юзеров, или юзеров которые что-то там особое покупают, на основании чего их данные нужно скидывать в отдел продаж каждый месяц. Да тысячи таких примеров.
У меня React на Sails.
А почему бы просто не провести эксперимент? Посмотреть несколько сайтов с примерно одинаковым размером контента, но реализованных по-разному. И протестировать на каком нибудь гугле или
Что именно тестить?
Тут
https://developers.google.com/speed/pagespeed/insights/
или тут
www.webpagetest.org/
Отправил раньше времени
Ну эт самое. Производительность. Или насчет чего тут холивар?
Ну ОКАУ, можно начать с производительности.
Но холивар вроде более глобальный.
А можно вообще примеры этих сервисов? Что в результате отвечает за внешний вид?
icloud, google docs, gmail итд. Это то где необходим толстый фронтенд. А вообще его куда уже только не пихают, даже для написания банальных бложиков.
> отвечает за внешний вид
Такие же шаблоны как и везде.
Дай какие нибудь статейки про это почитать с примерами.
Есть такая сферическая архитектура в вакууме: бекенд отвечает всегда в JSON. Всё остальное на фронтенде.
Я пока вижу это так:
минусы:
0. Намного сложнее поддерживать
1. Тормозит и оче жирно
2. Не нужно
плюсы:
0. Возможноcть нескольких фронтендов
1. Не грузить сервер генерацией шаблонов (это вообще онли для жирнохайлоад)
2. Вся вёрстка-говно полностью на фронтендерах
Стоит ли юзать это говно? Моё имхо - нет.
Алсо, советуйте свои технологии и фреймворки для этого. Интересно, что другие юзают для этого говна.
Пикрандом.