Теренс Эден — разработчик web-стандартов — призывает отказаться от использования специализированных CDN для доставки JS-библиотек — "Please stop using CDNs for external Javascript libraries".
Десять лет назад подключение библиотек с внешних CDN считалось хорошей практикой. Популярных CDN было не так много и сайты использовали небольшой набор библиотек, что повышало шансы получения кода из кэша браузера.
На данный момент ситуация поменялась. Браузеры потихоньку отключают междоменное использование закэшированных ресурсов, остро стоят вопросы, связанные с приватностью пользователей, специалисты по безопасности не рекомендуют использовать сторонние ресурсы для доставки кода пользователям, также были случаи, когда сайты оказывались сломаны из-за использования JS-библиотек с внешних CDN.
Теренс предлагает начать считать антипаттерном подключение кода со сторонних доменов.
#musings #js
https://shkspr.mobi/blog/2020/10/please-stop-using-cdns-for-external-javascript-libraries/
Десять лет назад подключение библиотек с внешних CDN считалось хорошей практикой. Популярных CDN было не так много и сайты использовали небольшой набор библиотек, что повышало шансы получения кода из кэша браузера.
На данный момент ситуация поменялась. Браузеры потихоньку отключают междоменное использование закэшированных ресурсов, остро стоят вопросы, связанные с приватностью пользователей, специалисты по безопасности не рекомендуют использовать сторонние ресурсы для доставки кода пользователям, также были случаи, когда сайты оказывались сломаны из-за использования JS-библиотек с внешних CDN.
Теренс предлагает начать считать антипаттерном подключение кода со сторонних доменов.
#musings #js
https://shkspr.mobi/blog/2020/10/please-stop-using-cdns-for-external-javascript-libraries/
shkspr.mobi
Please stop using CDNs for external Javascript libraries – Terence Eden’s Blog
Regular blogging by Terence Eden.
Карл Джонсон рассказал, почему он отказался от поддержки IE11 в пользу улучшения работы сайта для браузеров с отключённым JS — "Dropping Support For IE11 Is Progressive Enhancement".
Основная мысль статьи. Число пользователей IE11 с каждым годом всё меньше и меньше, но мы продолжаем по инерции транспайлить код в ES5. В некоторых случаях надо прилагать дополнительные усилия, чтобы новая фича заработала под IE11 только для того, чтобы спустя полгода обнаружить, что она была сломана несколько месяцев назад.
Большинство команд без выделенного QA-отдела, постоянно проверяющего работу сайта в IE11, может без проблем дропнуть его поддержку. У пользователей IE11 скорее всего в системе установлен более современный браузер. Освободившиеся ресурсы можно отправить на улучшение доступности и работы сайта без JavaScript (progressive enhancement), это принесёт гораздо больше пользы.
Очень хорошая статья. Дайте её почитать вашим менеджерами, кто сомневается в пользе отказа от IE11.
#musings #ie
https://blog.carlmjohnson.net/post/2020/time-to-kill-ie11/
Основная мысль статьи. Число пользователей IE11 с каждым годом всё меньше и меньше, но мы продолжаем по инерции транспайлить код в ES5. В некоторых случаях надо прилагать дополнительные усилия, чтобы новая фича заработала под IE11 только для того, чтобы спустя полгода обнаружить, что она была сломана несколько месяцев назад.
Большинство команд без выделенного QA-отдела, постоянно проверяющего работу сайта в IE11, может без проблем дропнуть его поддержку. У пользователей IE11 скорее всего в системе установлен более современный браузер. Освободившиеся ресурсы можно отправить на улучшение доступности и работы сайта без JavaScript (progressive enhancement), это принесёт гораздо больше пользы.
Очень хорошая статья. Дайте её почитать вашим менеджерами, кто сомневается в пользе отказа от IE11.
#musings #ie
https://blog.carlmjohnson.net/post/2020/time-to-kill-ie11/
blog.carlmjohnson.net
Dropping Support For IE11 Is Progressive Enhancement
If you have to choose, you should prioritize users with no JavaScript over users with old JavaScript.
Реми Шарп поделился своими мыслями о влиянии JavaScript на доступность сайтов — "Please disable JavaScript to view this site".
Недавно Хэйдон Пикеринг — автор нескольких книг про фронтенд-разработку — сделал в своём блоге редизайн, который поставил на уши сообщество разработчиков. Если вы попробуете зайти на его сайт, с большой вероятностью вам будет предложено отключить JS, чтобы получить к нему доступ. Таким образом Хэйдон продемонстрировал своё отношение к текущим трендам web-разработки.
Для обычных разработчиков это может показаться дикостью — зачем заставлять пользователей отключать JS, чтобы попасть на сайт? Но при избыточном использовании JS подобным образом исключаются категории людей со слабыми устройствами, медленным интернетом, альтернативными средствами отображения веб-контента и т.п.
Основная мысль статьи: JavaScript настолько стал неотъемлем от веба, что мы перестали задумываться о его влиянии на доступность и воспринимаем его наличие как нечто само собой разумеющееся.
#js #musings #a11y
https://remysharp.com/2020/11/30/please-disable-javascript-to-view-this-site
Недавно Хэйдон Пикеринг — автор нескольких книг про фронтенд-разработку — сделал в своём блоге редизайн, который поставил на уши сообщество разработчиков. Если вы попробуете зайти на его сайт, с большой вероятностью вам будет предложено отключить JS, чтобы получить к нему доступ. Таким образом Хэйдон продемонстрировал своё отношение к текущим трендам web-разработки.
Для обычных разработчиков это может показаться дикостью — зачем заставлять пользователей отключать JS, чтобы попасть на сайт? Но при избыточном использовании JS подобным образом исключаются категории людей со слабыми устройствами, медленным интернетом, альтернативными средствами отображения веб-контента и т.п.
Основная мысль статьи: JavaScript настолько стал неотъемлем от веба, что мы перестали задумываться о его влиянии на доступность и воспринимаем его наличие как нечто само собой разумеющееся.
#js #musings #a11y
https://remysharp.com/2020/11/30/please-disable-javascript-to-view-this-site
Remysharp
Please disable JavaScript to view this site.
Heydon Pickering this last weekend released a redesign to their web site and upon visiting it, the contents prompted a series of interesting thoughts and ideas…
Нашел интересную статью Санди Мец про проблему неправильных абстракций — "The Wrong Abstraction".
В психологии есть понятие "ловушка невозвратных затрат" (sunk cost fallacy). Это особенность психики, которая заставляет инвестировать время, деньги и другие ресурсы в убыточное дело. То есть чем больше мы вкладываем усилия в что-то, тем больше оно для нас становится ценнее.
Такая же ловушка возникает и при работе с кодом. Если с течением времени некая абстракции при возникновении новых требований становится хуже, это хороший повод остановиться и подумать, что идёт не так, и это не повод продолжать усложнять код только потому, что в него было вложено много усилий. В этом случае полезно отстранится от такой абстракции и, возможно, заменить её обычным дублированием кода. В итоге это поспособствует здоровью кодовой базы в будущем.
Хорошая статья. Рекомендую почитать всем.
#programming #musings
https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
В психологии есть понятие "ловушка невозвратных затрат" (sunk cost fallacy). Это особенность психики, которая заставляет инвестировать время, деньги и другие ресурсы в убыточное дело. То есть чем больше мы вкладываем усилия в что-то, тем больше оно для нас становится ценнее.
Такая же ловушка возникает и при работе с кодом. Если с течением времени некая абстракции при возникновении новых требований становится хуже, это хороший повод остановиться и подумать, что идёт не так, и это не повод продолжать усложнять код только потому, что в него было вложено много усилий. В этом случае полезно отстранится от такой абстракции и, возможно, заменить её обычным дублированием кода. В итоге это поспособствует здоровью кодовой базы в будущем.
Хорошая статья. Рекомендую почитать всем.
#programming #musings
https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
Sandi Metz
The Wrong Abstraction — Sandi Metz
I've been thinking about the consequences of the "wrong abstraction." My RailsConf 2014 "all the little things" talk included a section where I asserted: > duplication is far cheaper than the wrong abstraction And in the summary, I went on to advise: >
Йехуда Катц — один из отцов Ember, cargo и участник W3C — написал в твиттере большой тред, о распространённом заблуждении, что фронтенд — это специализация для джуниоров.
Код фронтенда в отличие от бэкенда работает во враждебном окружении: он должен работать во всех современных браузерах (их много), операционных системах и на разных устройствах (десктоп, мобильные). Нужно учитывать восстановление системы из невалидных состояний, например, когда крышка ноутбука закрывается во время отправки запроса на сервер или когда пользователь подключён к нестабильной сети. Опытные фронтенд-разработчики при решении своих задач должны учитывать эти и многие другие факторы. Более того, опытные разработчики должны создавать такие абстракции, которыми смогут эффективно пользоваться новички.
Разнообразие тулинга во фронтенде объясняется не уровнем подготовки специалистов, а, снова, враждебной средой, в которой должен работать код. Код нужно транспилировать, чтобы поддержать разные браузеры; можно, конечно, использовать старые версии языка, но это больно. Большие проекты используют PostCSS для использования новых фич CSS, добавления вендорных префиксов и для автоматического обхода ошибок в браузерах. Чтобы код был доставлен пользователю как можно быстрее, он должен быть собран сборщиком и минифицирован. Код нужно оптимизировать, потому что основная масса пользователей используют мобильные устройства на слабых процессорах.
В общем, хороший тред. Очень рекомендую почитать.
#musings #web
https://twitter.com/wycats/status/1342484366279098369
Код фронтенда в отличие от бэкенда работает во враждебном окружении: он должен работать во всех современных браузерах (их много), операционных системах и на разных устройствах (десктоп, мобильные). Нужно учитывать восстановление системы из невалидных состояний, например, когда крышка ноутбука закрывается во время отправки запроса на сервер или когда пользователь подключён к нестабильной сети. Опытные фронтенд-разработчики при решении своих задач должны учитывать эти и многие другие факторы. Более того, опытные разработчики должны создавать такие абстракции, которыми смогут эффективно пользоваться новички.
Разнообразие тулинга во фронтенде объясняется не уровнем подготовки специалистов, а, снова, враждебной средой, в которой должен работать код. Код нужно транспилировать, чтобы поддержать разные браузеры; можно, конечно, использовать старые версии языка, но это больно. Большие проекты используют PostCSS для использования новых фич CSS, добавления вендорных префиксов и для автоматического обхода ошибок в браузерах. Чтобы код был доставлен пользователю как можно быстрее, он должен быть собран сборщиком и минифицирован. Код нужно оптимизировать, потому что основная масса пользователей используют мобильные устройства на слабых процессорах.
В общем, хороший тред. Очень рекомендую почитать.
#musings #web
https://twitter.com/wycats/status/1342484366279098369
Twitter
Yehuda Katz
The thing I find frustrating about the idea that frontend dev is "for juniors" is that nobody would say it about other specializations. Someone might say that it's *better* if a compiler author worked in a more full stack role. They *wouldn't* say "compiler…
Стэрен Джианнини решил отказаться от модных технологий и стал вести свой блог на чистом HTML и CSS без использования CMS, генераторов статических сайтов и т.п. Про это он написал статью "My stack will outlive yours".
Стэрен пишет о том, что концептуально в web'е существуют два вида страниц: web-страницы с простым содержанием и web-приложения. Обычный HTML и CSS покрывает всё необходимое, что может потребоваться для создания простых web-страниц: лендингов, сайтов-портфолио, блогов и сайтов с документацией. При разработке простого сайта не требуется настраивать сборку, устанавливать зависимости и использовать тяжёлые IDE. Он будет прекрасно работать и через 10 лет. Использование семантичной вёрстки поможет не заблудиться в коде, а если нужно будет поменять однотипные места на нескольких похожих страницах, то для этого можно использовать функцию редактора ”Replace in files”.
Мне лично нравится такой подход. Конечно, для сайтов с большим количеством страниц, это может быть непрактично, но для маленьких сайтов это хороший вариант.
#html #css #musings
https://blog.steren.fr/2020/my-stack-will-outlive-yours/
Стэрен пишет о том, что концептуально в web'е существуют два вида страниц: web-страницы с простым содержанием и web-приложения. Обычный HTML и CSS покрывает всё необходимое, что может потребоваться для создания простых web-страниц: лендингов, сайтов-портфолио, блогов и сайтов с документацией. При разработке простого сайта не требуется настраивать сборку, устанавливать зависимости и использовать тяжёлые IDE. Он будет прекрасно работать и через 10 лет. Использование семантичной вёрстки поможет не заблудиться в коде, а если нужно будет поменять однотипные места на нескольких похожих страницах, то для этого можно использовать функцию редактора ”Replace in files”.
Мне лично нравится такой подход. Конечно, для сайтов с большим количеством страниц, это может быть непрактично, но для маленьких сайтов это хороший вариант.
#html #css #musings
https://blog.steren.fr/2020/my-stack-will-outlive-yours/
blog.steren.fr
My stack will outlive yours
Джаред Уайт рассказал, почему он больше не хочет использовать Tailwind CSS — "Why Tailwind Isn't for Me".
Tailwind CSS — это набирающий популярность CSS-фреймворк, использующий методологию атомного CSS, в которой для каждой комбинации свойство/значение используется уникальный класс. Джаред пишет, что проработал с Tailwind год, но не смог свыкнуться с его недостатками:
— HTML-код с Tailwind выглядит неэстетично
— Для упрощения работы с фреймворком используется директива
— Tailwind использует дизайн-токены, которые определяется с помощью JavaScript, а не с помощью кастомных свойств
— Tailwind плохо подходит для работы с web-компонентами
— Использование Tailwind поощряет использование большого количества div'ов и span'ов
В последнее время видел в твиттере много хороших отзывов про Tailwind, поэтому познакомиться с альтернативным мнением было очень интересно.
#css #library #musings
https://dev.to/jaredcwhite/why-tailwind-isn-t-for-me-5c90
Tailwind CSS — это набирающий популярность CSS-фреймворк, использующий методологию атомного CSS, в которой для каждой комбинации свойство/значение используется уникальный класс. Джаред пишет, что проработал с Tailwind год, но не смог свыкнуться с его недостатками:
— HTML-код с Tailwind выглядит неэстетично
— Для упрощения работы с фреймворком используется директива
@apply, которая не является стандартом и в перспективе может принести проблемы, если проект будет переезжать на другой CSS-фреймворк— Tailwind использует дизайн-токены, которые определяется с помощью JavaScript, а не с помощью кастомных свойств
— Tailwind плохо подходит для работы с web-компонентами
— Использование Tailwind поощряет использование большого количества div'ов и span'ов
В последнее время видел в твиттере много хороших отзывов про Tailwind, поэтому познакомиться с альтернативным мнением было очень интересно.
#css #library #musings
https://dev.to/jaredcwhite/why-tailwind-isn-t-for-me-5c90
Бэн Шмидт — профессор университета Нью-Йорка — поделился своими мыслями о том, почему JavaScript может захватить Data Science в ближайшем десятилетии — "Javascript and the next decade of data programming".
Бэн пишет о том, что всё больше интерфейсов для интерактивной работы с данными строится поверх web-технологий. Основная причина — скорость. Если традиционным инструментам для визуализации данных нужно несколько минут для обработки данных, то для JavaScript-кода нужно всего лишь несколько секунд. Ситуация в будущем станет ещё лучше, когда во всех браузерах появится поддержка спецификации WebGPU, благодаря которой можно будет вынести обработку данных на GPU. Более того с некоторыми ограничениями можно задействовать GPU для обработки данных уже сегодня с помощью WebGL. Ещё автор статья возлагает большие надежды на WebAssembly, благодаря которому в будущем могут появиться удобные инструменты для работы с данными.
#js #datascience #musings
http://benschmidt.org/post/2020-01-15/2020-01-15-webgpu/
Бэн пишет о том, что всё больше интерфейсов для интерактивной работы с данными строится поверх web-технологий. Основная причина — скорость. Если традиционным инструментам для визуализации данных нужно несколько минут для обработки данных, то для JavaScript-кода нужно всего лишь несколько секунд. Ситуация в будущем станет ещё лучше, когда во всех браузерах появится поддержка спецификации WebGPU, благодаря которой можно будет вынести обработку данных на GPU. Более того с некоторыми ограничениями можно задействовать GPU для обработки данных уже сегодня с помощью WebGL. Ещё автор статья возлагает большие надежды на WebAssembly, благодаря которому в будущем могут появиться удобные инструменты для работы с данными.
#js #datascience #musings
http://benschmidt.org/post/2020-01-15/2020-01-15-webgpu/
Ben Schmidt
Javascript and the next decade of data programming | Ben Schmidt
I’ve recently been getting pretty far into the weeds about what the future of data programming is going to look like. I use pandas and dplyr in python and R respectively. But I’m starting to see the shape of something that’s interesting coming down the pike.…
Джаред Уайт рассказал о своей боли при работе с фронтенд-библиотеками и инструментами — "The Shocking Immaturity of JavaScript".
Джаред пишет, что в современном фронтенде среди авторов инструментов и библиотек есть тенденция уделять больше внимания маркетингу, а не проблемам пользователей. Из-за этого страдает вся экосистема, а новички, работающие с фронтендом, тонут в большом количестве багов, зачастую обвиняя себя в неспособности разобраться с проектом.
Решение проблемы — быть честнее со своими пользователями. Если библиотека находится в экспериментальном режиме, надо об этом рассказать в readme или добавить
Не все проекты страдают от подобных проблем. Автор советует брать пример с LitElement, PostCSS, Shoelace и Webpack.
#musings #js #opensource
https://dev.to/jaredcwhite/the-shocking-immaturity-of-javascript-c70
Джаред пишет, что в современном фронтенде среди авторов инструментов и библиотек есть тенденция уделять больше внимания маркетингу, а не проблемам пользователей. Из-за этого страдает вся экосистема, а новички, работающие с фронтендом, тонут в большом количестве багов, зачастую обвиняя себя в неспособности разобраться с проектом.
Решение проблемы — быть честнее со своими пользователями. Если библиотека находится в экспериментальном режиме, надо об этом рассказать в readme или добавить
alpha к номеру версии. Если у инструмента или библиотеки есть ограничения, надо об этом тоже написать и в самом лучшем случае посоветовать подходящие альтернативы.Не все проекты страдают от подобных проблем. Автор советует брать пример с LitElement, PostCSS, Shoelace и Webpack.
#musings #js #opensource
https://dev.to/jaredcwhite/the-shocking-immaturity-of-javascript-c70
DEV Community 👩💻👨💻
The Shocking Immaturity of JavaScript
Do code newbies realize just how shockingly buggy and incomplete all the tools they use really are?
Том МакРайт рассказал о своём подходе к работе с зависимостями — "Vendor by default".
Том использует вендоринг для небольших зависимостей, то есть копирует их исходный код к себе в проект. При копировании кода он его читает, рефакторит и удаляет неиспользуемые части. Такой подход позволяет лучше разобраться в библиотеке и понять её ограничения. Иногда бывает так, что он начинает рефакторить код зависимости и понимает, что будет проще написать её самому или что нужно найти альтернативу.
Интересная статья. Похоже на какую-то крайность, но почему бы и нет, если это решает проблему раздувания бандла приложения.
#npm #js #musings
https://macwright.com/2021/03/11/vendor-by-default.html
Том использует вендоринг для небольших зависимостей, то есть копирует их исходный код к себе в проект. При копировании кода он его читает, рефакторит и удаляет неиспользуемые части. Такой подход позволяет лучше разобраться в библиотеке и понять её ограничения. Иногда бывает так, что он начинает рефакторить код зависимости и понимает, что будет проще написать её самому или что нужно найти альтернативу.
Интересная статья. Похоже на какую-то крайность, но почему бы и нет, если это решает проблему раздувания бандла приложения.
#npm #js #musings
https://macwright.com/2021/03/11/vendor-by-default.html
macwright.com
Vendor by default
Just copy that sucker into your source tree why don’t you
Выбор библиотеки по её размеру
Владимир Клепов рассказал про подводные камни выбора библиотек с использованием размера как основной метрики — "Don't trust JS library size, min+gzip".
В статье Владимир пишет о том, что размер библиотеки в Readme, может не отражать реальный процент бандла, который она будет занимать. Обычно код жмётся лучше, чем больше в приложении используется стороннего кода. Также пайплайн сборки может оказывать негативный эффект на размер из-за транспиляции в старую версию JavaScript. Иногда меньший размер библиотеки означает, что нужно использовать больше кода по сравнению с альтернативной библиотекой с большим размером, поэтому размер в этом случае не имеет значения.
При выборе библиотеки автор рекомендует оценивать скорость инициализации. Меньшая библиотека с плохой скоростью инициализации будет оказывать негативный эффект на всех пользователей без исключения. В то время как большая библиотека с лучшей скоростью инициализации будет оказывать негативный эффект только один раз при загрузке бандла с сервера.
Хорошая статья. Рекомендую почитать.
#js #performance #musings
https://thoughtspile.github.io/2022/02/15/bundle-size-lies/
Владимир Клепов рассказал про подводные камни выбора библиотек с использованием размера как основной метрики — "Don't trust JS library size, min+gzip".
В статье Владимир пишет о том, что размер библиотеки в Readme, может не отражать реальный процент бандла, который она будет занимать. Обычно код жмётся лучше, чем больше в приложении используется стороннего кода. Также пайплайн сборки может оказывать негативный эффект на размер из-за транспиляции в старую версию JavaScript. Иногда меньший размер библиотеки означает, что нужно использовать больше кода по сравнению с альтернативной библиотекой с большим размером, поэтому размер в этом случае не имеет значения.
При выборе библиотеки автор рекомендует оценивать скорость инициализации. Меньшая библиотека с плохой скоростью инициализации будет оказывать негативный эффект на всех пользователей без исключения. В то время как большая библиотека с лучшей скоростью инициализации будет оказывать негативный эффект только один раз при загрузке бандла с сервера.
Хорошая статья. Рекомендую почитать.
#js #performance #musings
https://thoughtspile.github.io/2022/02/15/bundle-size-lies/
👍30