Нет. Люди в первую очередь говорят о «совместимости с JavaScript».
Говорить стоит о совместимости с версией JavaScript, которая выражается в номерах ECMAScript.
Сейчас большинство браузеров полностью совместимы с ECMAScript 3.1 5, частично с ES6 ES2015. ES3 код должен работать корректно во всех браузерах с начала второго тысячелетия
Конечно я знаю, что можно решить одну и ту же задачу десятками разных способов, это же программирование! Подзадача была такая: исключить дублирование ключей в разных списках, сразу брать их из интерфейсов и иметь возможность работать с их именами после транспиляции.
И вот кстати решение
Всем спасибо, было очень интересно узнать о TS, открыл для себя новую тему для чтения. Возможно когда нибудь удастся убедить остальных членов команды это попробовать.
Не очень силён в TS, чтобы точно сказать как себя поведут здесь типы, вижу интерфейсы, а чего там дальше с ними происходит — искТри. Вот вы скажите у вас проптайпы начинают пахнуть или, что? Без TS туда можно свои функции с любыми проверками отправлять. Имхо гибко, не?
const { search, x2 } = this.props
Вы же выносите метод в класс, используете его в соседнем методе. Мой деструктор без проблем позволит добавить в него методы компонента и стейт, а не вермешелить ниже в методе. А вы просто ими не пользуетесь и пишите this.props.items.map(…
propTypes кстати тоже автоматически исчезают (как и много другое) при продакшен компиляции сборки.
В рантайме девелопера конечно остаются, что немного сказывается на производительности, но не критично.
И раз для данных прибывающих из вне такая пичалька, то все равно приходится использовать нечто вроде prop-types для данных приходящих по API (а у меня это большинство данных)?
Читаю это, норм? Там нашёл, что интерфейсы наследуются так-же как и классы, это здорово. Совсем забыл обо всей этой кухне с тех пор как перестал на PHP писать
А если метод вызывается не на прямую, а погружен глубоко в недры декораторов, или ещё чего, что его пропускает сквозь себя, это тоже будет работать?
С PropTypes такая пичаль, что нельзя сделать
static propTypes = {...modificators, ...themes}
и сохранить подсказки при заполнении пропсов. А приём таки необходимый в некоторых ситуациях, иначе приходится дублировать списки, чтобы оставить PropTypes в примитивном виде. Вся надежда на разработчиков IDE
Наверное стоит объяснить зачем мне это. Проще всего будет на компоненте иконок.
Есть компонент <Icon />, его можно использовать так <Icon search x2 /> и это отрендерит иконку с лупой двойного размера. В таком формате можно получать подсказки к названию иконок, но после разделение пропсов на имена иконок и модификаторы, для последующего использования ключей этих списков внутри класса, часть профита, в виде автодополнения, теряется. Разработчик шторма услышь мои стенанья
Да, отдельный модуль, но нужно ли оно, если валидация происходит только после запуска, а в случае с ts / flow — прямо при написании кода?
Вот именно, что возбраняется React.PropTypes и вместо него рекомендуют использовать отдельный пакет prop-types. Это как бы намекает на выход парадигмы за пределы экосистемы ReactJS, что косвенно подтверждает эффективность.
Ты — бэкендщик, я — фронтендщик, нам Дург друга не понять.
Не проблема, что валидация происходит только после запуска. Запуск и перезапуск для меня естественное состояние, а учитывая hotReload ещё и автоматическое. Консоль браузера почти всегда открыта, а даже если в мастер ветку попадёт неправильно объявленный тип, мне об этом сообщат на стадии интеграции.
Возможно твоя любовь к статической типизации объясняется подходом к разработке при котором приложение может писаться часами, а после запускается и работает.
Когда корректность работы каждого кусочка программы проверяется во время написания итеративными правками, то это возможно не так важно.
То, что я сам себе тестер съедает конечно порядочно времени, но не уверен, что статическая типизация мне его сэкономит.
Расскажи как часто ты запускаешь код который пишешь? Раз в минуту, пять, час, день…?
ЗЫ я не призываю тебя съехать с TS, скорее изучаю дружественную пати
Хорошей привычкой является написание небольших функций — не более 10 строк.
Сравните с утверждением — «Функция должна быть компактной».
Это тот случай где абстракция побеждает конкретику. Функция функции функция.
Например, от хорошей привычки доведённой до автоматизма, попытка поделить функцию которой нужно занимать больше десяти строк (например только дестркутор в начале функции может быть в восемь строк. Его, что? В отдельную функцию выписывать?) приведёт к чрезмерному усложнению кода, который станет в последствии сложно читать и породит статью Синди Шридхаран.
Парадоксально абстрактная статья о вереде абстракции. Nix Solution видимо наняла копирайтера по методологии Porozjnyak.
В защиту «Чистого кода» скажу, что автор книги с самого начала пишет о недогматичности своих рассуждений и просит в первую очередь руководствоваться здравым смыслом. Вся книга это не сборник правил, а скорее тру стори о внесении ясности в существующий код. Она должна стать началом вашей собственной истории вдохновлённой чужим опытом, коррелирующим со своим собственным. А никак не очередным шаблоном для нового культа Карго с постепенным переходом к обратному [культу Карго].
В противовес ей эта статья polnayaMetodovVisasonyhIzPalcaKotorieSlozhnoChitatIzZaIhDlinyhImen (автор чистого кода не рекомендует так делать) и граблей из слепого следования тезисам. Всё это похоже на обратный культ Карго. Синди как бы намекает, что те кто пишет лаконичные функции сами танцуют на граблях, но так умело, что никто этого не понимает кроме неё, немогущей прочитать, что за ними кроется.
Дорогой переводчик сего эпоса. Прочитай сам «Чистый Код», а не полагайся на выжимки глупого треугольника. Это задача не из лёгких, автор пишет об этом в самом начале (для меня было оптимальным чтение перед сном, отлично усыпляет).
Но, если ты ещё не натанцевался на граблях и не чувствуешь, что тебе сложно читать свой собственный код, написанный несколько месяцев назад — танцуй! Иначе не хватит мотивации, чтобы её дочитать. Вся книга — история оптимизации настоящего не абстрактного кода, целью которой является его ясность, а не следование конкретным характеристикам.
Как пример — «разбить функцию из 60 строк на 4 функции по 15 строк» из этой статьи. Это ведь реально сложный абстрактный пример не применимый в реальных условиях. Делить нужно на необходимое количество функций в зависимости от их логической основы, в не от результирующего количества строк в каждой из них.
А Yuniy Padavan, что? Верен словам мастера и делит функцию на ноль четыре идеально равных части. Без сомнений, чего бы это ни стоило. Ну и потом разочарование с переходом на байткод дарксайд.
P.S. Я понимаю негодование Синди Шридхаран, сам встречал людей упоротых тезисами и превозносящими их над здравым смыслом. Возможно если бы она не писала настолько абстрактно, то получилась бы годная статья о вреде слепого следование правилу один — «Функция должна быть компактной» и правилу два — «Функция должны быть ещё компактней». Но вышло не только без достаточной конкретики, так ещё и с превозношением копипасты и деградации.
Множество субъективных и объективных факторов… В частности командная разработка не дадут так просто изменить стек технологий.
Кстати es6 / es2015 это разве не одно и то же?
ES6 — всё таки стандарт ДжаваСкрипта, а подмножества вроде CoffeScript неплохое поле для обкатки новых идей, самые (недеюсь) годные из которых перекачёвывают в ESNext, а сами подмножества медленно отмирают. Андерс Хейлсберг конечно уважаемый человек, но и его детище может уступить дорогу новому стандарту.
За 12 лет привык к динамической типизации, статическую типизацию мне заменяют prop-types и регистровая типизация (смешиваю всякие снейк_кебаб-КамельКейсы для разных типов, в т.ч. для имён файлов)
В данный момент не вижу причин усиленно разбираться с TS, но учитывая встроенную поддержку IDE ваша рекомендация прибавила желания попробовать.
ЗЫ что-то мне подсказывает, что избавившись от бабеля нельзя просто так взять и избавиться от тяжести той работы которую он выполняет. Я так понимаю у вас уже серьёзный проект с большим количеством кода, сколько времени занимает промежуток от ctrl+s до завершения компиляции?
Спасибо. Оттуда и почерпнул информацию. Хорошо написано, с удовольствием прочитал второй раз.
О себе могу сказать, что пишу на ES2015, всё реже на ES5.
А если я скажу, что «пишу на JavaScript» — не сильно конкретизирует и может означать как то, что было на старте тысячелетия с падающими снежинками (при этом нужно обязательно уточнить браузер), так и классы, промисы, импорты и прочие плюшки современности.
В заключении к первой статье из цикла об истории JS, пишут такое:
На сегодняшний день JavaScript это всего лишь коммерческое название ECMAScript.
ИМХО JavaScript — не стандарт, а поле боя для браузерных войн толкающих свои стандарты
А я думал, что когда дело дошло до стандартизации, то из-за опасения копирайта на Java часть в названии, её заменили на всякий случай на ECMA. После чего «JavaScript» стал народным названием языка, а ECMAScript официальным.
Иначе временной парадоксс и вообще не понятно кто на этом ECMAScript пишет.
Погорячился с двойными походами на API. Но вёрстку таки дважды загрузить придётся (+1 раз в качестве внутренностей bundle.js).
А favicon какой не отдавай, все равно такой будет пока бандлы грузятся.
window.initialState мы конечно сохраняли. И данные на сервере загружали. Но это сопряжено с временными затратами. После ещё одного потерянного дня на отлов багов серверного рендера, которые сложнее дебажить, мы перешли на prerender.io и довольны.
Возможно мы опять вернёмся к рендеру на сервере, но когда прогресс пройдётся кремниевыми сапогами по этому раздолью для деятельности. И он идёт, прогресс этот. Шаг ему на встречу React 16 и эта статья. Я верю в то, что сейчас является примером рутины через некоторое время сократится до единого флага в настройках.
В моём случае серверный рендер прибавляет к весу страницы вёрстку. Эти +400кб прилетели конечно почти мгновенно, но похоже было больше на бутафорию.
Не всё жмётся (кликается) и не всё отображено так как должно быть (некоторые штуки хотят window. Так сложилось).
А потом прилетели 512кб ДжаваСкрипта и всё встало на свои места, но осадочек остался.
Я понимаю это мой частный случай и в ином пришлось бы ждать нескольких мегабайт скриптов, но это ещё более оттянуло бы момент нормальной работы кнопок.
И вот вся эта бутафория стоит батхерта синхронизации стора? Мне кажется штука крутая конечно, но требует доработки. В первую очередь Promise Midleware, а во вторых акцента на <main></main> / <article></article> секциях.
Нужно быть готовым к тому, что исходник будут читать читалки, боты или программисты c собакой, которые знают где ты живёшь, в терминале через cat.
Prerender.io следит за клиентом, и если рендер ему не нужен отдаёт только коротенький index.html и несколько js/css файлов для самостоятельного рендера на клиенте.
Возможно я чего то не понимаю и у вас есть LiveView на которых от рендера на сервере количество трафика не увеличилось, а скорость загрузки и работы сайта возросла.
Ок. Из api можно и правда дважды не грузить. Дважды загрузится только вёрстка. Вернее результат и бандл по которому он построен. Возможно это совсем крохотная разница, а излишки вёрстки в виде датастора в конце страницы можно удалять после его восстановления в redux. А может так статься, что вёрстка превысит размеры бандла, тогда это всё будет иметь смысл только на крайне медленных девайсах, на которых время JS рендера страницы критично.
Моя позиция связана скорее с той болью которая возникает когда приходится постоянно перезагружать дев сервер из-за застрявшего в серверном рендере чего-то и попутно следить, чтобы на сервере загрузились все данные из десятка методов API, а потом решать экзотические проблемы возникающие из-за того, что у тебя серверный рендер вообще есть, тем более дебажится он не так просто (я знаю про --inspect, но не панацея).
В общем мы были рады переходу на prerender.io, вдоволь налюбившись с рендером на сервере.
Идея рендера на сервере мне импонирует, но мне кажется она далека от своего завершения. Вместо того чтобы плеваться целиком страницей, стоит выделять важные части за которыми пришёл пользователь.
Я думаю врятли ему интересен в первую очередь хедер и подвал, а пришёл он скорее за конкретным контентом, будь то список товаров или статья. Так показав ему основной контент можно дальше загружать всё остальное. На это время пользователь занят поглощением контента за которым пришёл.
Вопросом магии и ловкости рук остаётся положение контента на странице, чтобы он не скаканул и не изменился после загрузки. А также особое меню для тех у кого отключен JS. Но это совсем другая история.
Зато мы получаем настоящую доступность и сокращение трафика даже для тех девайсов которые будут читать HTML в чистом виде. Ведь ради доступности всё, да?
Говорить стоит о совместимости с версией JavaScript, которая выражается в номерах ECMAScript.
Сейчас большинство браузеров полностью совместимы с ECMAScript
3.15, частично сES6ES2015.ES3 код должен работать корректно во всех браузерах с начала второго тысячелетия
Подробнее об этом рассказано в этом цикле статей → Как появился Mocha/LiveScript, позже переименованный в JavaScript.
И вот кстати решение
Всем спасибо, было очень интересно узнать о TS, открыл для себя новую тему для чтения. Возможно когда нибудь удастся убедить остальных членов команды это попробовать.
Не очень силён в TS, чтобы точно сказать как себя поведут здесь типы, вижу интерфейсы, а чего там дальше с ними происходит — искТри. Вот вы скажите у вас проптайпы начинают пахнуть или, что? Без TS туда можно свои функции с любыми проверками отправлять. Имхо гибко, не?
Вы же выносите метод в класс, используете его в соседнем методе. Мой деструктор без проблем позволит добавить в него методы компонента и стейт, а не вермешелить ниже в методе. А вы просто ими не пользуетесь и пишите this.props.items.map(…
На вашем примере это выглядело бы так:
А по поводу моей задачи есть смысл её дальше формировать только если можно взять интерфейс и получить его ключи из метода компонента.
«TS интерфейс итерация» у Гугла ничего не дал
В рантайме девелопера конечно остаются, что немного сказывается на производительности, но не критично.
И раз для данных прибывающих из вне такая пичалька, то все равно приходится использовать нечто вроде prop-types для данных приходящих по API (а у меня это большинство данных)?
Хочется иметь возможность все пропсы с этого уровня вложенности вычистить, чтобы передать тегу вниз. Или найти название темы в пропсах:
Читаю это, норм? Там нашёл, что интерфейсы наследуются так-же как и классы, это здорово. Совсем забыл обо всей этой кухне с тех пор как перестал на PHP писать
Есть деструкторы же, так куда лаконичнее:
чем:
Так и так мою задачу не решают. Можно наследовать два и более интерфейсов? Свойства интерфейса можно перебирать через .map например?
А если метод вызывается не на прямую, а погружен глубоко в недры декораторов, или ещё чего, что его пропускает сквозь себя, это тоже будет работать?
С PropTypes такая пичаль, что нельзя сделать
и сохранить подсказки при заполнении пропсов. А приём таки необходимый в некоторых ситуациях, иначе приходится дублировать списки, чтобы оставить PropTypes в примитивном виде. Вся надежда на разработчиков IDE
Наверное стоит объяснить зачем мне это. Проще всего будет на компоненте иконок.
Есть компонент
<Icon />, его можно использовать так<Icon search x2 />и это отрендерит иконку с лупой двойного размера. В таком формате можно получать подсказки к названию иконок, но после разделение пропсов на имена иконок и модификаторы, для последующего использования ключей этих списков внутри класса, часть профита, в виде автодополнения, теряется. Разработчик шторма услышь мои стенаньяВот именно, что возбраняется React.PropTypes и вместо него рекомендуют использовать отдельный пакет prop-types. Это как бы намекает на выход парадигмы за пределы экосистемы ReactJS, что косвенно подтверждает эффективность.
Ты — бэкендщик, я — фронтендщик, нам Дург друга не понять.
Не проблема, что валидация происходит только после запуска. Запуск и перезапуск для меня естественное состояние, а учитывая hotReload ещё и автоматическое. Консоль браузера почти всегда открыта, а даже если в мастер ветку попадёт неправильно объявленный тип, мне об этом сообщат на стадии интеграции.
Возможно твоя любовь к статической типизации объясняется подходом к разработке при котором приложение может писаться часами, а после запускается и работает.
Когда корректность работы каждого кусочка программы проверяется во время написания итеративными правками, то это возможно не так важно.
То, что я сам себе тестер съедает конечно порядочно времени, но не уверен, что статическая типизация мне его сэкономит.
Расскажи как часто ты запускаешь код который пишешь? Раз в минуту, пять, час, день…?
ЗЫ я не призываю тебя съехать с TS, скорее изучаю дружественную пати
Кстати в другом вашем переводе встречается такой тезис:
Сравните с утверждением — «Функция должна быть компактной».
Это тот случай где абстракция побеждает конкретику. Функция функции функция.
Например, от хорошей привычки доведённой до автоматизма, попытка поделить функцию которой нужно занимать больше десяти строк (например только дестркутор в начале функции может быть в восемь строк. Его, что? В отдельную функцию выписывать?) приведёт к чрезмерному усложнению кода, который станет в последствии сложно читать и породит статью Синди Шридхаран.
Парадоксально абстрактная статья о вереде абстракции.
Nix Solution видимо наняла копирайтера по методологии Porozjnyak.
В защиту «Чистого кода» скажу, что автор книги с самого начала пишет о недогматичности своих рассуждений и просит в первую очередь руководствоваться здравым смыслом. Вся книга это не сборник правил, а скорее тру стори о внесении ясности в существующий код. Она должна стать началом вашей собственной истории вдохновлённой чужим опытом, коррелирующим со своим собственным. А никак не очередным шаблоном для нового культа Карго с постепенным переходом к обратному [культу Карго].
В противовес ей эта статья polnayaMetodovVisasonyhIzPalcaKotorieSlozhnoChitatIzZaIhDlinyhImen (автор чистого кода не рекомендует так делать) и граблей из слепого следования тезисам. Всё это похоже на обратный культ Карго. Синди как бы намекает, что те кто пишет лаконичные функции сами танцуют на граблях, но так умело, что никто этого не понимает кроме неё, немогущей прочитать, что за ними кроется.
Дорогой переводчик сего эпоса. Прочитай сам «Чистый Код», а не полагайся на выжимки глупого треугольника. Это задача не из лёгких, автор пишет об этом в самом начале (для меня было оптимальным чтение перед сном, отлично усыпляет).
Но, если ты ещё не натанцевался на граблях и не чувствуешь, что тебе сложно читать свой собственный код, написанный несколько месяцев назад — танцуй! Иначе не хватит мотивации, чтобы её дочитать. Вся книга — история оптимизации настоящего не абстрактного кода, целью которой является его ясность, а не следование конкретным характеристикам.
Как пример — «разбить функцию из 60 строк на 4 функции по 15 строк» из этой статьи. Это ведь реально сложный абстрактный пример не применимый в реальных условиях. Делить нужно на необходимое количество функций в зависимости от их логической основы, в не от результирующего количества строк в каждой из них.
А Yuniy Padavan, что? Верен словам мастера и делит функцию на
нольчетыре идеально равных части. Без сомнений, чего бы это ни стоило. Ну и потом разочарование с переходом набайткоддарксайд.P.S. Я понимаю негодование Синди Шридхаран, сам встречал людей упоротых тезисами и превозносящими их над здравым смыслом. Возможно если бы она не писала настолько абстрактно, то получилась бы годная статья о вреде слепого следование правилу один — «Функция должна быть компактной» и правилу два — «Функция должны быть ещё компактней». Но вышло не только без достаточной конкретики, так ещё и с превозношением копипасты и деградации.
Кстати книга Роберта Мартина начинается так:
Спасибо за отличную историю
Ничего они не deprecated
Просто переехали в отдельный пакет из Реакта:
https://www.npmjs.com/package/prop-types
Множество субъективных и объективных факторов… В частности командная разработка не дадут так просто изменить стек технологий.
Кстати es6 / es2015 это разве не одно и то же?
ES6 — всё таки стандарт ДжаваСкрипта, а подмножества вроде CoffeScript неплохое поле для обкатки новых идей, самые (недеюсь) годные из которых перекачёвывают в ESNext, а сами подмножества медленно отмирают. Андерс Хейлсберг конечно уважаемый человек, но и его детище может уступить дорогу новому стандарту.
За 12 лет привык к динамической типизации, статическую типизацию мне заменяют prop-types и регистровая типизация (смешиваю всякие снейк_кебаб-КамельКейсы для разных типов, в т.ч. для имён файлов)
В данный момент не вижу причин усиленно разбираться с TS, но учитывая встроенную поддержку IDE ваша рекомендация прибавила желания попробовать.
ЗЫ что-то мне подсказывает, что избавившись от бабеля нельзя просто так взять и избавиться от тяжести той работы которую он выполняет. Я так понимаю у вас уже серьёзный проект с большим количеством кода, сколько времени занимает промежуток от ctrl+s до завершения компиляции?
Спасибо. Оттуда и почерпнул информацию. Хорошо написано, с удовольствием прочитал второй раз.
О себе могу сказать, что пишу на ES2015, всё реже на ES5.
А если я скажу, что «пишу на JavaScript» — не сильно конкретизирует и может означать как то, что было на старте тысячелетия с падающими снежинками (при этом нужно обязательно уточнить браузер), так и классы, промисы, импорты и прочие плюшки современности.
В заключении к первой статье из цикла об истории JS, пишут такое:
ИМХО JavaScript — не стандарт, а поле боя для браузерных войн толкающих свои стандарты
А я думал, что когда дело дошло до стандартизации, то из-за опасения копирайта на Java часть в названии, её заменили на всякий случай на ECMA. После чего «JavaScript» стал народным названием языка, а ECMAScript официальным.
Иначе временной парадоксс и вообще не понятно кто на этом ECMAScript пишет.
Не претендую на истинность, версий слишком много
Вы всё правильно не поняли. Разницы нет в размере между статической генерацией и рендером на сервере. Разница с генерацией разметки на клиенте.
thx
Погорячился с двойными походами на API. Но вёрстку таки дважды загрузить придётся (+1 раз в качестве внутренностей bundle.js).
А favicon какой не отдавай, все равно такой будет
пока бандлы грузятся.
window.initialState мы конечно сохраняли. И данные на сервере загружали. Но это сопряжено с временными затратами. После ещё одного потерянного дня на отлов багов серверного рендера, которые сложнее дебажить, мы перешли на prerender.io и довольны.
Возможно мы опять вернёмся к рендеру на сервере, но когда прогресс пройдётся кремниевыми сапогами по этому раздолью для деятельности. И он идёт, прогресс этот. Шаг ему на встречу React 16 и эта статья. Я верю в то, что сейчас является примером рутины через некоторое время сократится до единого флага в настройках.
В моём случае серверный рендер прибавляет к весу страницы вёрстку. Эти +400кб прилетели конечно почти мгновенно, но похоже было больше на бутафорию.
Не всё жмётся (кликается) и не всё отображено так как должно быть (некоторые штуки хотят window. Так сложилось).
А потом прилетели 512кб ДжаваСкрипта и всё встало на свои места, но осадочек остался.
Я понимаю это мой частный случай и в ином пришлось бы ждать нескольких мегабайт скриптов, но это ещё более оттянуло бы момент нормальной работы кнопок.
И вот вся эта бутафория стоит батхерта синхронизации стора? Мне кажется штука крутая конечно, но требует доработки. В первую очередь
Promise Midleware, а во вторых акцента на<main></main>/<article></article>секциях.index.html 1Mb
+bundle.js 1Mb
‣ CSR (SSR выключен)
index.html 10 kb
+bundle.js 1 Mb
Prerender.io следит за клиентом, и если рендер ему не нужен отдаёт только коротенький index.html и несколько js/css файлов для самостоятельного рендера на клиенте.
Возможно я чего то не понимаю и у вас есть LiveView на которых от рендера на сервере количество трафика не увеличилось, а скорость загрузки и работы сайта возросла.
Я бы посмотрел
Ок. Из api можно и правда дважды не грузить. Дважды загрузится только вёрстка. Вернее результат и бандл по которому он построен. Возможно это совсем крохотная разница, а излишки вёрстки в виде датастора в конце страницы можно удалять после его восстановления в redux. А может так статься, что вёрстка превысит размеры бандла, тогда это всё будет иметь смысл только на крайне медленных девайсах, на которых время JS рендера страницы критично.
Моя позиция связана скорее с той болью которая возникает когда приходится постоянно перезагружать дев сервер из-за застрявшего в серверном рендере чего-то и попутно следить, чтобы на сервере загрузились все данные из десятка методов API, а потом решать экзотические проблемы возникающие из-за того, что у тебя серверный рендер вообще есть, тем более дебажится он не так просто (я знаю про --inspect, но не панацея).
В общем мы были рады переходу на prerender.io, вдоволь налюбившись с рендером на сервере.
Идея рендера на сервере мне импонирует, но мне кажется она далека от своего завершения. Вместо того чтобы плеваться целиком страницей, стоит выделять важные части за которыми пришёл пользователь.
Я думаю врятли ему интересен в первую очередь хедер и подвал, а пришёл он скорее за конкретным контентом, будь то список товаров или статья. Так показав ему основной контент можно дальше загружать всё остальное. На это время пользователь занят поглощением контента за которым пришёл.
Вопросом магии и ловкости рук остаётся положение контента на странице, чтобы он не скаканул и не изменился после загрузки. А также особое меню для тех у кого отключен JS. Но это совсем другая история.
Зато мы получаем настоящую доступность и сокращение трафика даже для тех девайсов которые будут читать HTML в чистом виде. Ведь ради доступности всё, да?
Всем любви