Для того, чтобы можно было реализовать классы, пришлось переделать процедуру создания объект, а кроме того, добавить возможность pзадать прототип не только создаваемого объекта, но и его конструктора.
Да, я об этом и говорю, что class это сахар.
Принципиальная новизна заключается в том, что классы позволяют создавать полностью работоспособных наследников от встроенных конструкторов. Например Array.
Это не классы позволяют делать, а обновленный конструктор и новые методы в Object.
Полифил этого функционала невозможен.
Простите, но зачем полифил для конструктора Array, в каком-то браузере не работает [] или new Array? Я понимаю к чему вы ведете, но все таки… ощущение что вы хотите завалить меня нюансами языка а не найти в споре истину :)
А Вы ответ читать не пробовали? Для промисов возможно написать полностью работоспособный полифил. Следовательно, принципиальной новизны они не содержат. Это всего лишь перенос в стандартную библиотеку логики, которая могла бы быть реализована средствами самого языка.
Да, я прочитал, под развернуть я имел в виду пример.
Новизна != Возможность написания полифила.
Другими словами, возможно или нет реализовать полифил для нового функционала зависит от кол-ва нового функционала и его связью с другим новым/старым функционалом.
Например, для промисов нужен псевдо рантайм и генератор функций, поэтому полифил есть, но очень медленный.
Ну, попробуйте создать наследника Array, так, чтобы Object.getPrototypeOf(MyArray) было равно Array.
Мне кажется, что получится (чтобы они вернули true), но боюсь что-то точно перестанет работать либо статичные методы либо нативный конструктор либо еще что-то, они у вас не возвращают true только потому что у функции полифила и нативной функции конструктора разные id в рантайме.
При том, промисы не содержат принципиальной новизны
Не содержать принципиальной новизны? — Это классы не содержат принципиальной новизны и являются по факту сахаром, а промисы этот как раз новый функционал, которого никогда не было с новым низкоуровневым Api.
Промисы — это больше про асинхронное программирование и насколько мне известно, до 2014 года в стандарте его не было.
Иначе бы полифил для них было написать невозможно.
Разверните пожалуйста ответ — почему невозможно?
Зная язык программирования и алгоритм можно написать программу, которая повторяет низкоуровневый функционал данного языка программирования, правда у вас будут колоссальные потери в скорости и «ньюансы» работы.
Например, полифил промисов работает в 20 раз медленней чем родной.
Приведите пример пожалуйста, не могу придумать сам.
Пример, в котором ошибку сложно/невозможно решить не зная время этой ошибки.
Я, например, использую trackjs в работе, этот сервис позволяет видеть все ошибки на фронте клиента, все до единой.
промисы как я понял уже считаются неэлегантными, на их место пришел async/await
Вы не поверите, но под сахаром async/await находятся промисы.
Так что статья устарела
Нужно обладать колоссальным опытом что-бы подобное утверждать. На мой взгляд информация в статье актуальна и полезна.
Используйте Коллбэки, как завещали Керниган и Ричи. там по крайней мере понятно когда выполняется код.
Звучит как анти-совет. Промисы действительно решают проблему callback-hell.
Да и зачем вам знать когда выполняется код? — В голову приходит только тики для обновления мира, но обычно это в разработке игр используется.
Можно узнать чем Webpack (сборщик фронта) лучше Gulp (менеджер задач) в задачах которые автор упомянул в статье?
Судя по gulp-задачам предположу, что рабочий процесс команды автора подразумевает выдачу статичного фронта. В который потом интегрируют бэкэнд.
На мое мнение, стоит все таки начать с простого для понимания (новичками) Gulp.
Таким образом новичок будет настраивать/учиться с Gulp в разрезе терминов:
— принцип единственной ответственности;
— сборщика проекта;
— таск менеджера.
Новичок сможет сделать сборщик фронта на Gulp, но он не сможет сделать менеджер задач на Webpack, потому что работая с Webpack вы учитесь работе с Webpack (тут я немного утрирую, каюсь, но 90% функционала Webpack все таки связанна с бандлингом js).
Я последние лет 5 использую Gulp (все кроме js). Для сборки js Rollup.
Много ньюансов, альтернативных способов, предостережений и объяснений
JS
1. Обязательным будет свойство async для подключаемых скриптов (кроме jQuery). Это точно избавит вас от замечания в GPSpeed по поводу асинхронной загрузки скриптов.
1.1. Данная рекомендация не обязательна, используйте на свой страх и риск, устанавливая флаги с async вы должны точно знать логику работы js на данной странице.
1.2. Если у вас есть инлайн скрипты которые используют что-то из js файла с async флагом все сломается т.к. на время чтения DOM данный файл не загружен/прочитан, это же касается и js файлов которые грузятся без async флага.
1.3. Все js файлы c async флагом грузятся в том же порядке в котором были спарсены в html.
1.4. Все js файлы которые были вставлены как инекция в html(то как вставляют счетчики гугл аналитикс, например) будут загружены в том же порядке что и объявлены в html(они асинхронны по умолчанию).
1.5. В старых браузерах defer используется как фалбэк для async. Defer “отодвигает” событие DOMContentLoaded пока все файлы с данным флагом не будут прочитаны.
1.6. Уже стандарт хранить ресурсы js/css в футере.
2. Совет банальный, но он очень толковый — старайтесь использовать сложные и массивные библиотеки по минимуму.
2.1. Если все же вынуждены и данные скрипты используются на большинстве страниц, положите их все в отдельный файл даже если в итоге он будет 100кб. Файл кэшируется что в долгосрочной перспективе(путешествие пользователя по сайту) выгодно.
2.2. Старайтесь не использовать jquery библиотеки если есть аналогичные на чистом js.
2.3. Важно: Основная проблема «сложных и массивных библиотек» это цена парса/компиляции кода, 1кб js не равен 1кб картинки (в плане скорости загрузки/интерактивности сайта). Прежде чем ваш js код выполнится браузер делает очень много работы на ним и чем раньше он это закончит тем быстрее приложение станет интерактивно (главный поток станет idle). Поэтому 100кб jquery в разы медленней чем 100кб чистого js который в свою очередь в разы медленней чем обработка 100кб картинки.
3. Свои настройки js библиотек (slick, fancybox) или небольшие фрагменты кода, которые выполняют разные задачи лучше заливать на сервер одним файлом. В моём случае, и скрипт для отправки почты, и маска для input и анимация и всё-всё находится в одном файле build.js ( которому я так же задаю async.
3.1. Страница должна грузить только тот js который необходим на данной странице, ничего лишнего (логика которая используется на другой странице, не нужна).
3.2. Практически идеальный вариант для боевых условий это AMD подход и CommonJS в частности (если говорим о front-end).
4. Этот совет ситуативный, то есть под ситуацию смотрите. Если у вас сразу после открытия страницы на её первом экране выполняется какой-то скрипт, то его будет правильнее подключить отдельно и не давать ему async
Простите, не понял о чем вы, что за скрипт на первом экране?
CSS
1. Тут немного посложнее. К тегу link вам необходимо будет добавить такое свойство
Именно в таком виде ваши css файлы будут подключаться лишь после дерева DOM. Грубо говоря, это тот же async только для .css
Не советую так делать (это даже не костыль, а подпорка какая-то).
1.1. После каждого обновление CSSOM будет происходит отрисовка страницы, в данном случае страница ПОЛНОСТЬЮ отрисуется еще раз после того как media сменится.
1.2. Если у вас больше 1го css на странице вы не сможете сделать нормальную стратегию загрузки.
1.3. Сам гугл рекомендует LoadCSS.js (https://github.com/filamentgroup/loadCSS)
1.4. На самом деле стили загрузятся последними (onload событие) а не «после древа DOM» (DOMContentLoaded событие)
2. Очень важный и действенный совет! Он добавляет от 5 до 10 баллов гарантированно. Нужно разделить ваш main.css на два файла. В первом будут только те стили, которые подгружаются для того контента, который виден сразу после открытия страницы. Это top bar, header, первая картинка, первая form и тд. В общем то, что вы поместили на «лицо» вашего сайта. Во втором уже всё остальное.
Не совсем понял о чем тут речь, если речь о критическом css то стоит обратить внимание на следующее:
2.1. Если пользователь нажал обновить страницу находясь в нижней части сайта (если длина сайта 4 экрана, например) браузер может восстановить позицию скролла на 3ем экране на котором все будет развалено т.к. критический css уже применен и страница отрисована но еще не применены стили для всей страницы (браузер всегда старается как можно раньше хоть что-то отрисовать).
2.2. Такой метод подходит очень, очень узкому типу сайтов, по моему опыту только лэндингам, сайтам визиткам и всем сайтам которые по PWA патерну сделаны.
Шрифты
Я обнаружил новое для себя css свойство для шрифтов
font-display
А конкретно, его параметр swap, который не дожидаясь подгрузки вашего красивого и тяжёлого шрифта показывает текст в браузере используя встроенный в этот же браузер шрифт (например sans-serif). Это сразу же убирает одну из ошибок в GPSpeed.
1. font-display canIuse 25% global. На нее полагаться нельзя.
2. Сайт который 2 раза рендерит шрифт? Это звучит как антисовет.
3. Sans-serif это не шрифт, это тип гарнитуры, фактически это значит «гарнитура без засечек». Но какой шрифт именно там будет вы не знаете, что скорей всего приведет к сильному «дерганью» при рендере страницы.
4. Если вы используете веб-шрифт как основной значит вы смирились, не стоит больше ничего делать, woff2 и кэша вполне достаточно.
5. Рекомендую dns-prefetch и prefetch в частности. Подробнее можно почитать Robin Rendle (https://css-tricks.com/prefetching-preloading-prebrowsing/).
Подключение шрифтов
1. В основном встречаются два вида подключения — с помощью ссылки (например на google fonts, или же локально, на сервере. Так вот, по поводу второго способа, его так же можно поделить на 2: отдельным css файлом (с помощью link подключаем fonts.css) и напрямую через код (через ваш style.css).
И поскольку сейчас мы ведём речь именно об оптимизации сайта для GPSpeed, то я убедился в том, что лучше подключаться шрифты через ваш главный файл css.
1.1. Тут можно быть и более настойчивым. Шрифты ВСЕГДА должны грузится с того же сервера с которого и css. Путь должен быть относительный без абсолютных ссылок.
2. И ещё один совет, который помогает — положите файлы со шрифтами (woff, ttf и тд) рядом с вашим файлом css, который его запрашивает. Раньше у меня была отдельная папка на сервере для шрифтов, но потом я переместил их скорость загрузки шрифтов увеличилась в 2 раза. (по данным GPSpeed на подключение шрифта Muller раньше у меня уходило 180ms, сейчас 70-90ms)
Вы уверены?
Изображения, картинки и т.д.
За следующие 2 совету ручаюсь, помогли не только мне, а всему офису и даже друзьям отдалённо работающим.
1. Загружайте абсолютно все картинки с помощью lazyloading. Выглядеть это будет так
И не забудьте подключить lazyload.min.js
Лично я рекомендую lazysizes.js
2. Если у вас на странице много svg элементов, то их лучше добавлять чистым кодом, без лишнего обращения к тегу img. Кроме того, svg необходимо ужимать, например, с помощью этого сайта jakearchibald.github.io/svgomg (не реклама).
2.1. Если у вас на сайте много svg элементов и это иконки — используйте svg inline sprites подход, он наиболее выгоден.
2.2. Если у вас на сайте много svg элементов и это картинки — используйте их как img src, так они хотя бы кэшируются.
Это не классы позволяют делать, а обновленный конструктор и новые методы в Object.
Простите, но зачем полифил для конструктора Array, в каком-то браузере не работает [] или new Array? Я понимаю к чему вы ведете, но все таки… ощущение что вы хотите завалить меня нюансами языка а не найти в споре истину :)
Да, я прочитал, под развернуть я имел в виду пример.
Новизна != Возможность написания полифила.
Другими словами, возможно или нет реализовать полифил для нового функционала зависит от кол-ва нового функционала и его связью с другим новым/старым функционалом.
Например, для промисов нужен псевдо рантайм и генератор функций, поэтому полифил есть, но очень медленный.
Мне кажется, что получится (чтобы они вернули true), но боюсь что-то точно перестанет работать либо статичные методы либо нативный конструктор либо еще что-то, они у вас не возвращают true только потому что у функции полифила и нативной функции конструктора разные id в рантайме.
Промисы — это больше про асинхронное программирование и насколько мне известно, до 2014 года в стандарте его не было.
Разверните пожалуйста ответ — почему невозможно?
Зная язык программирования и алгоритм можно написать программу, которая повторяет низкоуровневый функционал данного языка программирования, правда у вас будут колоссальные потери в скорости и «ньюансы» работы.
Например, полифил промисов работает в 20 раз медленней чем родной.
Можно узнать причем полифил к промисам?
Промисы — это новый функционал.
Полифилы — следствие graceful degradation подхода и нужны только там где используется этот подход.
В моем случае, например, сборщик сам определяет по целевым браузерам необходим ли полифил, и если необходим включит его сам из core-js.
Нет, промисы это новый функционал c новым Api.
Приведите пример пожалуйста, не могу придумать сам.
Пример, в котором ошибку сложно/невозможно решить не зная время этой ошибки.
Я, например, использую trackjs в работе, этот сервис позволяет видеть все ошибки на фронте клиента, все до единой.
Вы не поверите, но под сахаром async/await находятся промисы.
Нужно обладать колоссальным опытом что-бы подобное утверждать. На мой взгляд информация в статье актуальна и полезна.
Звучит как анти-совет. Промисы действительно решают проблему callback-hell.
Да и зачем вам знать когда выполняется код? — В голову приходит только тики для обновления мира, но обычно это в разработке игр используется.
Судя по gulp-задачам предположу, что рабочий процесс команды автора подразумевает выдачу статичного фронта. В который потом интегрируют бэкэнд.
На мое мнение, стоит все таки начать с простого для понимания (новичками) Gulp.
Таким образом новичок будет настраивать/учиться с Gulp в разрезе терминов:
— принцип единственной ответственности;
— сборщика проекта;
— таск менеджера.
Новичок сможет сделать сборщик фронта на Gulp, но он не сможет сделать менеджер задач на Webpack, потому что работая с Webpack вы учитесь работе с Webpack (тут я немного утрирую, каюсь, но 90% функционала Webpack все таки связанна с бандлингом js).
Я последние лет 5 использую Gulp (все кроме js). Для сборки js Rollup.
1.1. Данная рекомендация не обязательна, используйте на свой страх и риск, устанавливая флаги с async вы должны точно знать логику работы js на данной странице.
1.2. Если у вас есть инлайн скрипты которые используют что-то из js файла с async флагом все сломается т.к. на время чтения DOM данный файл не загружен/прочитан, это же касается и js файлов которые грузятся без async флага.
1.3. Все js файлы c async флагом грузятся в том же порядке в котором были спарсены в html.
1.4. Все js файлы которые были вставлены как инекция в html(то как вставляют счетчики гугл аналитикс, например) будут загружены в том же порядке что и объявлены в html(они асинхронны по умолчанию).
1.5. В старых браузерах defer используется как фалбэк для async. Defer “отодвигает” событие DOMContentLoaded пока все файлы с данным флагом не будут прочитаны.
1.6. Уже стандарт хранить ресурсы js/css в футере.
2.1. Если все же вынуждены и данные скрипты используются на большинстве страниц, положите их все в отдельный файл даже если в итоге он будет 100кб. Файл кэшируется что в долгосрочной перспективе(путешествие пользователя по сайту) выгодно.
2.2. Старайтесь не использовать jquery библиотеки если есть аналогичные на чистом js.
2.3. Важно: Основная проблема «сложных и массивных библиотек» это цена парса/компиляции кода, 1кб js не равен 1кб картинки (в плане скорости загрузки/интерактивности сайта). Прежде чем ваш js код выполнится браузер делает очень много работы на ним и чем раньше он это закончит тем быстрее приложение станет интерактивно (главный поток станет idle). Поэтому 100кб jquery в разы медленней чем 100кб чистого js который в свою очередь в разы медленней чем обработка 100кб картинки.
3.1. Страница должна грузить только тот js который необходим на данной странице, ничего лишнего (логика которая используется на другой странице, не нужна).
3.2. Практически идеальный вариант для боевых условий это AMD подход и CommonJS в частности (если говорим о front-end).
Простите, не понял о чем вы, что за скрипт на первом экране?
CSS
Не советую так делать (это даже не костыль, а подпорка какая-то).
1.1. После каждого обновление CSSOM будет происходит отрисовка страницы, в данном случае страница ПОЛНОСТЬЮ отрисуется еще раз после того как media сменится.
1.2. Если у вас больше 1го css на странице вы не сможете сделать нормальную стратегию загрузки.
1.3. Сам гугл рекомендует LoadCSS.js (https://github.com/filamentgroup/loadCSS)
1.4. На самом деле стили загрузятся последними (onload событие) а не «после древа DOM» (DOMContentLoaded событие)
Не совсем понял о чем тут речь, если речь о критическом css то стоит обратить внимание на следующее:
2.1. Если пользователь нажал обновить страницу находясь в нижней части сайта (если длина сайта 4 экрана, например) браузер может восстановить позицию скролла на 3ем экране на котором все будет развалено т.к. критический css уже применен и страница отрисована но еще не применены стили для всей страницы (браузер всегда старается как можно раньше хоть что-то отрисовать).
2.2. Такой метод подходит очень, очень узкому типу сайтов, по моему опыту только лэндингам, сайтам визиткам и всем сайтам которые по PWA патерну сделаны.
Шрифты
1. font-display canIuse 25% global. На нее полагаться нельзя.
2. Сайт который 2 раза рендерит шрифт? Это звучит как антисовет.
3. Sans-serif это не шрифт, это тип гарнитуры, фактически это значит «гарнитура без засечек». Но какой шрифт именно там будет вы не знаете, что скорей всего приведет к сильному «дерганью» при рендере страницы.
4. Если вы используете веб-шрифт как основной значит вы смирились, не стоит больше ничего делать, woff2 и кэша вполне достаточно.
5. Рекомендую dns-prefetch и prefetch в частности. Подробнее можно почитать Robin Rendle (https://css-tricks.com/prefetching-preloading-prebrowsing/).
Подключение шрифтов
1.1. Тут можно быть и более настойчивым. Шрифты ВСЕГДА должны грузится с того же сервера с которого и css. Путь должен быть относительный без абсолютных ссылок.
Вы уверены?
Изображения, картинки и т.д.
Лично я рекомендую lazysizes.js
2.1. Если у вас на сайте много svg элементов и это иконки — используйте svg inline sprites подход, он наиболее выгоден.
2.2. Если у вас на сайте много svg элементов и это картинки — используйте их как img src, так они хотя бы кэшируются.