Мне кажется проблема в сообществе, низкий порог входа, поэтому у людей нет нормального бекграунда и для них все эти «типа» сложны, непонятно и просто излишни. Кроме этого, огромная проблема с самими инструментами, они не TS-friendly, что Vue, что React (особенно с Redux) в них TS смориться инородно и монструозно.
Увы, люди не видят полной картины, что TS, кроме проверки типов, даёт супер крутой autocomplete, изумительно удобный рефакторинг, а ещё если вникнуть в Transformer API, то инструмент раскроет себя во всей красе.
Безапелляционные? Ну вроде я вроде приложил ссылки, но и без ссылок видно, что расклад сил уже давно устаканился и изменения нужно искать не в веб компонентах, ui либах и тем более инструментах для дизайнера, но если вам это не очевидно, могу развернуть:
Custom Elements. Уже давно не будущее, но за все года они показали крайне мало пригодным. Обычно их выбирают огромные копрорации (ибо стандарт, да и гугл за спиной), но из реальных, крупных решений вышел, наверно только Youtube и текущая ситуация с ним очень показательна.
Кроме этого, использовать их себе дороже, а профит сомнительный, проблема шаринга высосана из пальца, мы уже лет 5+ живем в эру компонентов (до которой были jquery plugins/widgets на любой вкус), поэтому проблема найти для того же React, Angular, Vue готовый, качественный компонент, просто нет, любые серьезные либы имеют биндинг под каждую из них.
Проблема как раз в таких решениях как Lit-html, StencilJS или SvelteJS (который не понятно как попал в этот список, ведь совсем не про CE). Можно было рассчитывать, что эти решения займут нишу для построения виджетов, но практика показывает, что проще сделать на чистом JS с литеральными шаблонами, или собрать из готовых React компонентов, заменить React.createElement на h, чтобы сжималось лучше, в финале выкинуть React, добавив Preact и готово.
Фреймворки. И тут как обычно видим React, хотя FW на фронте, которые ещё живы, это Ember, Angular и Vue (Aurelia может). React только либо, а дальше во круг неё люди стоят бог знает что, сам Реакт никакой официальной архитектуры не предлагает, только тонкие намёки… хотя вру, с появлением useReducer, намёки становиться более прямыми, думаю весь 2019 год мы будем наблюдать, как люди обмазываются хуками изобретаю чудных монстров типа Flux, а дальше очередной «Дэн» нам покажет, как можно «проще», вот так и наступит 2020.
GraphQL. Опять же, какое это будущее? Он есть, он работает и уже давно, кто хотел, то уже использует, но если мы говорим про реальные highload проекты, то там как был RPC/REST, то так и останется, т.к. особой проблемы при их использовании нет.
Ну и так далее, такое ощущение, что автора нам пишет из 2016-2017, всё что он написал подходит к любому этому году.
Тредны на 2020 будут достаточно простыми, ситуация мало чем изменятся, проблем с компонентами и их стилизацией нет уже сейчас, максимум можно чего ожидать, это новые версии популярных компонент, типа Ant.Design, Material Design и т.п.
Главным будет конечно WASM, но скорей главным он будет к концу 2019, пока на фоне люди будут выяснять, как же лучше использовать хуки в React ;]
Ещё ещё один важный тренд и ниспадающий, это безопасность и тут конечно WebAuthn.
Да, и если говорить про дизайн и разработку, то тут нас ждет больше Grid'ов и конечно типографики.
HTTP/2 везде, но опять же, есть мониторинг трафика, поэтому если откуда-то выползает HTTP/1, разбираемся.
Brotli стоит в планах, готовить его будем при сборке, а то никакого железа не хватит, но это только после запуска так называемых HTTP2-бадлов, на которые у нас большие надежды.
Смысл в том, что в HTTP2-бандл, это не сборка исходников в один файл, а только файл декларация, в которой объявлены все зависимости в порядке их использования, т.е.
В итоге при загрузке такого бандла сразу запрашиваются все файлы из него и т.к. у нас HTTP/2 всё должно пройти как нельзя лучше ;] Но самый профит, что при изменении любого файла сборки, юзеру не нужно будет выкачивать весь мегабайтный бандл (что сейчас происходит абсолютно у всех), а только обновленную декларацию и низменные файлы у которого изменился checksum (такой подход называется дедубликация).
Про бандлы. Где webpack, там кто-во что горазд, но больше руками, на Почте своя система сборки на основе r.js и там тоже руками, но c с хитростью, бандлы объявляются в виде массива и каждый следующим бандл становиться зависимым от предыдущего, поэтому и не включает в себя его зависимости, даже если из явно указать. В самом конце этого массива есть rest-bundle, в который попадают все файлы, которые не вошли ни в одну из сборок.
У нас нет задачи угодить ботам, а поддержка SSR это время, кроме этого, мы же Приложение (с большой буквы), тут SSR полноценный не выйдет, не всеми данными обладает сервер. Если брать туже Главную, то там и гидриротировать нечего, там вся страница отдаётся маленькими независимыми блоками (html + js + css).
Хм, звучит интересно. Но, у нас нет SSR (почти нет), а в тех местах где есть наоборот хотим провести обратный эксперимент с его отключением, чтобы мгновенно отдавать крохотный HTML и потом быстро рендерить приложение.
TTI интересная метрика, но я больше доверяю когда само приложение говорит Ready и обычно оно это делает заметно раньше ;], а лонг таски, лонг тасками, это ещё не значит, что интерфейс залип.
Поэтому в планах сделать непрерывный мониторинг интерактивности, но пока не очень вижу, как именно снимать сконструировать такую метрика (одно понятно, что она точно должна быть комплексной).
Хороший вопрос, сделайте пример на каком-нибудь jsfiddle/jsbin, подумаю как это решить. Но на первый взгляд, можно добавить методы для ручного делегирования событий scroll и/или scrollStart/scrollEnd.
Бюджет понятие очень размытое, у каждого проекта он свой, конечно мы стремимся к максимальной скорости, например Главная не просто быстро должна быстро отдаётся, она изначально сконструирована особым способом, чтобы по мере загрузки пользователь увидел сначала самые важные блоки, а потом уже остальные. В то же время для Почты, первая загрузка важна, но всё же это тяжелый SPA, тут другие правила.
Кроме этого, проекту много лет, поэтому нам немного проще, запуская новую Главную или Почту, нам однозначно нельзя сделать хуже ;] Кроме этого, периодически мы запускаем хакатон по оптимизации первой загрузки Почты.
Ну и на остальные вопрос:
Да, меряем и не только кеширование, но ещё и делим метрики на какой интет у юзера
Для процентилей использует внутренний инструмент и он не в опенсорсе и вряд ли будет
Мониторим постоянно, рядом с рабочими местами всят с мониторы с графиками, а так же есть SMS-алертинг, если что-то пошло не так
Ответ достаточно прост, это по БЭМу и так работает i-bem, логика состояния блока описывается в JS, кроме того, доступность hover может зависеть от других состояний, например disabled и т.п. Поэтому чтоб не писать :not(.disabled):hover, :not(.bla-bla-bal):hover { ... } (ну или отменять эти стили), логику ховера проще завернуть в js.
Хмм и откуда по вашему взялись все эти библиотеки (тут список из вашего package.json), как и сам React?
С таким подходом регрессионное тестирование, в какой-то момент, растянется на «года», ведь тестов нет, а изменения есть.
Мне кажется проблема в сообществе, низкий порог входа, поэтому у людей нет нормального бекграунда и для них все эти «типа» сложны, непонятно и просто излишни. Кроме этого, огромная проблема с самими инструментами, они не TS-friendly, что Vue, что React (особенно с Redux) в них TS смориться инородно и монструозно.
Увы, люди не видят полной картины, что TS, кроме проверки типов, даёт супер крутой autocomplete, изумительно удобный рефакторинг, а ещё если вникнуть в Transformer API, то инструмент раскроет себя во всей красе.
Безапелляционные? Ну вроде я вроде приложил ссылки, но и без ссылок видно, что расклад сил уже давно устаканился и изменения нужно искать не в веб компонентах, ui либах и тем более инструментах для дизайнера, но если вам это не очевидно, могу развернуть:
Custom Elements. Уже давно не будущее, но за все года они показали крайне мало пригодным. Обычно их выбирают огромные копрорации (ибо стандарт, да и гугл за спиной), но из реальных, крупных решений вышел, наверно только Youtube и текущая ситуация с ним очень показательна.
Кроме этого, использовать их себе дороже, а профит сомнительный, проблема шаринга высосана из пальца, мы уже лет 5+ живем в эру компонентов (до которой были jquery plugins/widgets на любой вкус), поэтому проблема найти для того же React, Angular, Vue готовый, качественный компонент, просто нет, любые серьезные либы имеют биндинг под каждую из них.
Проблема как раз в таких решениях как Lit-html, StencilJS или SvelteJS (который не понятно как попал в этот список, ведь совсем не про CE). Можно было рассчитывать, что эти решения займут нишу для построения виджетов, но практика показывает, что проще сделать на чистом JS с литеральными шаблонами, или собрать из готовых React компонентов, заменить
React.createElementнаh, чтобы сжималось лучше, в финале выкинуть React, добавив Preact и готово.Фреймворки. И тут как обычно видим React, хотя FW на фронте, которые ещё живы, это Ember, Angular и Vue (Aurelia может). React только либо, а дальше во круг неё люди стоят бог знает что, сам Реакт никакой официальной архитектуры не предлагает, только тонкие намёки… хотя вру, с появлением
useReducer, намёки становиться более прямыми, думаю весь 2019 год мы будем наблюдать, как люди обмазываются хуками изобретаю чудных монстров типа Flux, а дальше очередной «Дэн» нам покажет, как можно «проще», вот так и наступит 2020.GraphQL. Опять же, какое это будущее? Он есть, он работает и уже давно, кто хотел, то уже использует, но если мы говорим про реальные highload проекты, то там как был RPC/REST, то так и останется, т.к. особой проблемы при их использовании нет.
Ну и так далее, такое ощущение, что автора нам пишет из 2016-2017, всё что он написал подходит к любому этому году.
Тредны на 2020 будут достаточно простыми, ситуация мало чем изменятся, проблем с компонентами и их стилизацией нет уже сейчас, максимум можно чего ожидать, это новые версии популярных компонент, типа Ant.Design, Material Design и т.п.
Главным будет конечно WASM, но скорей главным он будет к концу 2019, пока на фоне люди будут выяснять, как же лучше использовать хуки в React ;]
Ещё ещё один важный тренд и ниспадающий, это безопасность и тут конечно WebAuthn.
Да, и если говорить про дизайн и разработку, то тут нас ждет больше Grid'ов и конечно типографики.
Ну и так далее и тому подобное.
Как же надоели такие статьи, сил нет.
Если бы автор реально пытался анализировать тренды, то хотя бы воспользовался существующими исследованиями:
И вот на основе их понял, какую поверхностную лажу он написал.
Сорян, за такие слова, но сколько можно-то?!
Ясно, просто Brotli, по идее, должен разжимается быстрее GZip, возможно пережали ;]
Конечно, в независимости от результата напишем.
А вот про brotli интересно (все же пишут только про размер, а не реальный профит ;]), вы это по каким метрикам увидели?
HTTP/2 везде, но опять же, есть мониторинг трафика, поэтому если откуда-то выползает HTTP/1, разбираемся.
Brotli стоит в планах, готовить его будем при сборке, а то никакого железа не хватит, но это только после запуска так называемых HTTP2-бадлов, на которые у нас большие надежды.
Смысл в том, что в HTTP2-бандл, это не сборка исходников в один файл, а только файл декларация, в которой объявлены все зависимости в порядке их использования, т.е.
В итоге при загрузке такого бандла сразу запрашиваются все файлы из него и т.к. у нас HTTP/2 всё должно пройти как нельзя лучше ;] Но самый профит, что при изменении любого файла сборки, юзеру не нужно будет выкачивать весь мегабайтный бандл (что сейчас происходит абсолютно у всех), а только обновленную декларацию и низменные файлы у которого изменился checksum (такой подход называется дедубликация).
Про бандлы. Где webpack, там кто-во что горазд, но больше руками, на Почте своя система сборки на основе r.js и там тоже руками, но c с хитростью, бандлы объявляются в виде массива и каждый следующим бандл становиться зависимым от предыдущего, поэтому и не включает в себя его зависимости, даже если из явно указать. В самом конце этого массива есть
rest-bundle, в который попадают все файлы, которые не вошли ни в одну из сборок.Упс, это я случайно, вот правильная ссылка https://jsfiddle.net/RubaXa/uhtecoas/3/
У нас нет задачи угодить ботам, а поддержка SSR это время, кроме этого, мы же Приложение (с большой буквы), тут SSR полноценный не выйдет, не всеми данными обладает сервер. Если брать туже Главную, то там и гидриротировать нечего, там вся страница отдаётся маленькими независимыми блоками (html + js + css).
Пойдет https://jsfiddle.net/RubaXa/uhtecoas/2/ ?
Хм, звучит интересно. Но, у нас нет SSR (почти нет), а в тех местах где есть наоборот хотим провести обратный эксперимент с его отключением, чтобы мгновенно отдавать крохотный HTML и потом быстро рендерить приложение.
TTI интересная метрика, но я больше доверяю когда само приложение говорит Ready и обычно оно это делает заметно раньше ;], а лонг таски, лонг тасками, это ещё не значит, что интерфейс залип.
Поэтому в планах сделать непрерывный мониторинг интерактивности, но пока не очень вижу, как именно снимать сконструировать такую метрика (одно понятно, что она точно должна быть комплексной).
А там через
setTimeoutвызываетсяdebugger;]Хороший вопрос, сделайте пример на каком-нибудь jsfiddle/jsbin, подумаю как это решить. Но на первый взгляд, можно добавить методы для ручного делегирования событий
scrollи/илиscrollStart/scrollEnd.Бюджет понятие очень размытое, у каждого проекта он свой, конечно мы стремимся к максимальной скорости, например Главная не просто быстро должна быстро отдаётся, она изначально сконструирована особым способом, чтобы по мере загрузки пользователь увидел сначала самые важные блоки, а потом уже остальные. В то же время для Почты, первая загрузка важна, но всё же это тяжелый SPA, тут другие правила.
Кроме этого, проекту много лет, поэтому нам немного проще, запуская новую Главную или Почту, нам однозначно нельзя сделать хуже ;] Кроме этого, периодически мы запускаем хакатон по оптимизации первой загрузки Почты.
Ну и на остальные вопрос:
Ответ достаточно прост, это по БЭМу и так работает
i-bem, логика состояния блока описывается в JS, кроме того, доступностьhoverможет зависеть от других состояний, например disabled и т.п. Поэтому чтоб не писать:not(.disabled):hover, :not(.bla-bla-bal):hover { ... }(ну или отменять эти стили), логику ховера проще завернуть в js.Хотя думаю погорячился, так что всё это ИМХО, просто у себя я именно так и сделал, вот: