До этого просто надо..дорасти чтоль. До умения признаваться самому себе, что делаешь что-то не то, и дропнуть это кхерам, чтобы сделать лучше с нуля, а не пытаться облагоражвать болото, увязая в нем все глубже. Или не дропнуть, а откатиться по версиям на месячишко назад. Я вот тоже буквально вот совсем недавно откатывал один из механизмов. Тупо потому, что при переделке не учел пару юзкейсов, которые ломали все кхерам и делали его непригодным. Жалко ли свои усилия? Еще бы. Но проекту на пользу, а себе урок. --- Добавлено --- Это вот к слову о припекании. У начальника пекло тоже будет чем позднее, тем сильнее. Сейчас на это можно закрывать глаза, но это бомба с часовым механизмом. Да, всякие фейсбуки и вконтакты тоже не сразу к такому пришли, но у них-то путь был эволюционный. Когда они начинались, подобных практик не было. Тот же реакт - детище Фейсбука. У вас же другая ситуация. Все практики существуют и обкатаны. Инструментария - хоть лопатой кидай. Документации - целый океан.
@igordata @Fell-x27 Это всё круто но у меня сроки по проекту, и проблема в том что это сейчас тёмный лес, и специалиста по js на столько крутого найти чтобы он смог поднять там архитектуру сложно, поэтому пока пас. Будут деньги будет время, будем делать как парвильно. Я признаю эта методология революционна в веб разработке тот кто до неё допёр, он просто гений.
А вот интересно, имеет мне смысл переходить на все эти ангуляры/реакты, если я беру принципиально только средние проекты, не претендующие на хайлоад, и натягиваю на них вёрстку сам? В чём польза такого подхода? Я обычно вообще даже когда у меня ajax какой-нибудь, лезу на сервер за вёрсточкой, и именно её и кидаю куда надо. Поскольку (хотя, может в ангуляр это и не так, я его мельком смотрел) сборка html из javascript-а - это куча кода средней говняности. Или нужно везде готовые скрытые блоки с плейсхолдерами расставлять
@mkramer прикол например в том, что воркер может сохранять интерактивность в оффлайне. Пользователь с мобилки не получает травму от потери сигнала в подземном переходе. Ну и плюс что надо быть в тренде. Сейчас, к примеру, дико же выглядит табличная верстка из 00х.
И кстати, в чём профит такого подхода даже для хайлоада? Ведь формирование вёрстки - это не самая медленная операция даже при традиционном подходе. Ведь основное время - это как раз получение данных. @[vs] - ну так интерактивность в оффлайне есть до тех пор, пока не нужно за очередной порцией json-а лезть на сервер. И если мобилка в этот момент потеряла сигнал в подземном переходе - это снова станет проблемой для пользователя.
@mkramer соль в том что часть логики при таком подходе можно перенести на js. То есть на серверной части можно заниматься только фильтрацией поступающих данных и выбором данных из бд, и получаемые данные можно вообще отправить в js и кодить на нём на стороне клиента.
Ну JS и так кучу логики содержит обычно, того, что надо делать интерактивным. Ладно, сейчас смотрю вебинарчик по ангуляру, может проникнусь Может реально профит будет, хотя я хайлоадом и не занимаюсь
Эффективность использования канала. Сравни объем значимых данных в ответе с объемом верстки. Если у тебя какой-то новостной сайт или типа того, то вопросов нет. А вот если соцсеть, пердящая контентом нонстоп куда можно и нельзя, то тут уже окажется, что у тебя, грубо, 80% канала уходит на верстку. Которая не меняется от вызова к вызову. Раз за разом. А канал шире не становится. И, чтобы расширить клиентскую базу, у тебя выбор - либо рыть траншею до датацентра, прокидывая новый уберкабель, либо выгрузить клиенту либу, которая будет собирать верстку на месте, увеличивая, опосредованно, емкость твоего канала в несколько раз. Вот по этому тот же фейсбук и написал реакт.
@Fell-x27, спасибо, понял, в каких случаях стоит это использовать. В общем, для большей части моих сайтов неактуально действительно.
В котором HTML можно писать прямо в JS-коде ) Код (Javascript): // Ня! class Welcome extends React.Component { render() { return <h1>Hello, {this.props.name}</h1>; } }
Да! Без этого вот гемора с построением дерева ручками. Не то, чтоб, конечно, так нельзя и без реакта делать, но, если писать что-то свое, подобное, в итоге получится тот же реакт... Но, скорее всего, далеко не тот же. И не факт, что в лучшую сторону.
проблема не в ресурсе, а в дублировании. Одно и то же делать и там и сям - бесит. допустим есть у меня чат и список френдов. Я не хочу при каждом запросе всё это выбирать. Я хочу подписаться на изменения и их только отображать. а у меня страница дергается каждый раз заново. Но при этом сообщения в чат и френды ещё и прилетают. Мне их на бэке рисовать, потом на фронте рисовать. Следить за тем, чтоб одинаково. потом у меня попёрло, мне надо приложения для мобилы мутить. Надо АПИ которое будет ровно все то же самое делать, но данные не в хтмл, а в джсон. Мне проще забить вообще на хтмл. т.е. Это для приложенек хорошо сюда ещё докидываешь http://electron.atom.io и победа
да хоть react native я говорю про логику, которая в основном и является тем, что геморно дублировать и синхронизировать в разных инкарнациях твоего приложения. Соотв. если её сделать общей для всех видов приложений - веб, айфон, андроид, десктоп - то всё остальное делается малой командой специалистов дешевле и быстрее, чем если бы им пришлось под каждую платформу держать свой полный набор реализаций логики на разных языках.