Скорее всего для контроля версий вы используете git. Это очень мощный и гибкий инструмент. Но за гибкость надо платить: без хорошего git-интерфейса понять как происходила разработка в ветках бывает очень непросто.
Для macOS советую попробовать gitup — очень быстрый и приятный в использовании gui-инструмент с полностью открытым исходным кодом. С его помощью можно не только посмотреть, как ветки вливались друг в друга, но и при желании заребейзиться, черри-пикнуть или засквошить коммиты и сделать много всего другого.
https://gitup.co
#macos #tool
Для macOS советую попробовать gitup — очень быстрый и приятный в использовании gui-инструмент с полностью открытым исходным кодом. С его помощью можно не только посмотреть, как ветки вливались друг в друга, но и при желании заребейзиться, черри-пикнуть или засквошить коммиты и сделать много всего другого.
https://gitup.co
#macos #tool
Сегодня меня занесло в 2013-ый год. Прочитал статью журнала ACM, про оптимизацию сайтов для мобильных устройств. Несмотря на то, что статья была опубликована 6 лет назад и кое-какие моменты уже не так актуальны, очень многие идеи в ней до сих пор остаются полезными.
Чтобы увеличить отклик сайта, уменьшайте количество редиректов, снижайте количество запросов за разными ресурсами, консолидируя их в обособленные файлы, настраивайте кеширование ресурсов на сайте, чтобы браузер не скачивал одно и то же много раз, включайте gzip для сжатия текстовых ресурсов и т.п.
Раздел про оптимизации с помощью JavaScript немного устарел. От себя добавлю, что во всех современных браузерах, для того чтобы загрузка скрипта не блокировала рендеринг (что очень актуально для мобильных устройств) можно использовать атрибуты async или defer тега noscript. Для того чтобы избавиться от задержки в 300 мс при кликах на тач-девайсах, используйте
https://queue.acm.org/detail.cfm?id=2510122
#performance #mobile
Чтобы увеличить отклик сайта, уменьшайте количество редиректов, снижайте количество запросов за разными ресурсами, консолидируя их в обособленные файлы, настраивайте кеширование ресурсов на сайте, чтобы браузер не скачивал одно и то же много раз, включайте gzip для сжатия текстовых ресурсов и т.п.
Раздел про оптимизации с помощью JavaScript немного устарел. От себя добавлю, что во всех современных браузерах, для того чтобы загрузка скрипта не блокировала рендеринг (что очень актуально для мобильных устройств) можно использовать атрибуты async или defer тега noscript. Для того чтобы избавиться от задержки в 300 мс при кликах на тач-девайсах, используйте
<meta name="viewport" content="width=device-width"> в <head> документа.https://queue.acm.org/detail.cfm?id=2510122
#performance #mobile
queue.acm.org
Rules for Mobile Performance Optimization - ACM Queue
Performance has always been crucial to the success of Web sites. A growing body of research has proven that even small improvements in page-load times lead to more sales, more ad revenue, more stickiness, and more customer satisfaction for enterprises ranging…
Youtube в рекомендациях предложил посмотреть доклад Себастьяна Маккинзи с JSConf 2015. Стоит смотреть, если вам интересен небольшой общий рассказ про Babel от его создателя.
Для себя из доклада я вынес следующее: не стоит использовать транспиляторы как средство изучения новых фич языка. Так бывает, что при реализации трансформаций из нового стандарта к старому возникают проблемы, поэтому чем-то приходится жертвовать. Например, стрелочные функции из ES2015 не имеют прототипа и не могут быть использованы как конструкторы, но при их транспиляции в обычные функции это становится возможно.
https://www.youtube.com/watch?v=rKuNbEwoQfQ
#babel #talk #js
Для себя из доклада я вынес следующее: не стоит использовать транспиляторы как средство изучения новых фич языка. Так бывает, что при реализации трансформаций из нового стандарта к старому возникают проблемы, поэтому чем-то приходится жертвовать. Например, стрелочные функции из ES2015 не имеют прототипа и не могут быть использованы как конструкторы, но при их транспиляции в обычные функции это становится возможно.
https://www.youtube.com/watch?v=rKuNbEwoQfQ
#babel #talk #js
YouTube
Sebastian McKenzie: JavaScript Transformation | JSConf US 2015
I made the open source project Babel and will be presenting on how JavaScript transformation and ES6 can help improve developer workflow and how it can futureproof their code. Not only transpilation to ES6 but how Babel has support for Flow, JSX and React…
Уже больше недели в открытых вкладках у меня висела статья Эрика Эллиота о прогнозах про web и технологии на 2019 год.
В общем, React будет продолжать расти, Angular никуда не денется, а Vue.js будет набирать обороты дальше. С досадой Эрик смотрит на рост популярности TypeScript и пишет, что рост количества проектов на TS будет продолжаться. Но по его мнению TS все еще остаётся переоценённой технологией, так как выразить с помощью него некоторые концепции из мира функционального программирования нельзя.
Также по его мнению не стоит сбрасывать со счетов крипто-индустрию. Несмотря на текущее затишье, в будущем она будет продолжать расти. Стоит посматривать на следующие технологии: PWA, машинное обучение, виртуальная/дополненная реальность, робототехника, квантовые вычисления.
https://medium.com/javanoscript-scene/top-javanoscript-frameworks-and-topics-to-learn-in-2019-b4142f38df20
#web #js #musings
В общем, React будет продолжать расти, Angular никуда не денется, а Vue.js будет набирать обороты дальше. С досадой Эрик смотрит на рост популярности TypeScript и пишет, что рост количества проектов на TS будет продолжаться. Но по его мнению TS все еще остаётся переоценённой технологией, так как выразить с помощью него некоторые концепции из мира функционального программирования нельзя.
Также по его мнению не стоит сбрасывать со счетов крипто-индустрию. Несмотря на текущее затишье, в будущем она будет продолжать расти. Стоит посматривать на следующие технологии: PWA, машинное обучение, виртуальная/дополненная реальность, робототехника, квантовые вычисления.
https://medium.com/javanoscript-scene/top-javanoscript-frameworks-and-topics-to-learn-in-2019-b4142f38df20
#web #js #musings
Medium
Top JavaScript Frameworks and Topics to Learn in 2019
It’s that time of year again: The annual overview of the JavaScript tech ecosystem. Our aim is to highlight the learning topics and…
Сегодня Антон Виноградов из Яндекса опубликовал статью на хабре про историю объединения React и БЭМ. Честно говоря, я давно хотел прочитать подобную статью. В ней приводятся хорошие аргументы того, почему потребовалось скрещивать технологии между собой.
Если говорить кратко, React хорош для манипуляций с DOM, но при этом БЭМ позволяет очень точно управлять зависимостями, доставляя только нужный код клиенту. При этом БЭМ и React никогда не воевали между собой и не было цели их противопоставлять друг другу: "Компании не соревнуются в создании лучшего фреймворка на Земле. Если компания начнёт тратить меньше времени на инфраструктурные задачи при той же продуктивности, все от этого только выиграют".
Очень огорчил конец статьи, который по сути оказался пересказом доки архитектуры с гитхаба. Для своих этот раздел может, конечно, и ок, но для подавляющего большинства читателей статьи, я более чем уверен, он был непонятен. Очень надеюсь, что вторая часть статьи, которую обещают опубликовать через некоторое время, будет не менее интересна, а ситуация с заключением была просто недоразумением.
https://habr.com/ru/company/yandex/blog/438598/
#yandex #bem #react
Если говорить кратко, React хорош для манипуляций с DOM, но при этом БЭМ позволяет очень точно управлять зависимостями, доставляя только нужный код клиенту. При этом БЭМ и React никогда не воевали между собой и не было цели их противопоставлять друг другу: "Компании не соревнуются в создании лучшего фреймворка на Земле. Если компания начнёт тратить меньше времени на инфраструктурные задачи при той же продуктивности, все от этого только выиграют".
Очень огорчил конец статьи, который по сути оказался пересказом доки архитектуры с гитхаба. Для своих этот раздел может, конечно, и ок, но для подавляющего большинства читателей статьи, я более чем уверен, он был непонятен. Очень надеюсь, что вторая часть статьи, которую обещают опубликовать через некоторое время, будет не менее интересна, а ситуация с заключением была просто недоразумением.
https://habr.com/ru/company/yandex/blog/438598/
#yandex #bem #react
Хабр
React & БЭМ – официальная коллаборация. Часть историческая
Перед вами история интегрирования БЭМ-методологии в React-вселенную. Материал, который вы прочитаете, построен на опыте разработчиков Яндекса, развивающих самый масштабный и нагруженный сервис в...
Channel name was changed to «Defront – про фронтенд разработку и не только»
Сегодня разработчики React зарелизили новую версию библиотеки (v16.8) с поддержкой хуков.
Для React-сообщества это большое событие, так как подобное масштабное изменение апи было довольно давно, когда в 14-ой версии были добавлены функциональные компоненты. С помощью хуков можно использовать стейт, lifecycle-методы и другие фичи React, не используя class-based компоненты. Хуки расширяют возможности библиотеки, то есть от class-based компонентов React отказываться не будет. По ссылке в разделе "What are hooks?" есть небольшая подборка хороших статей и доков, для того чтобы начать погружение в новое апи.
В следующем квартале (2019 Q2), команда React планирует зарелизить конкурентный режим (Concurrent Mode). С помощью него такие события, как ввод текста или наведение курсора на элемент, смогут приостанавливать текущий рендеринг дерева компонентов в основном потоке браузера, для того чтобы приложение было более отзывчивым.
https://reactjs.org/blog/2019/02/06/react-v16.8.0.html
#react #hooks #release
Для React-сообщества это большое событие, так как подобное масштабное изменение апи было довольно давно, когда в 14-ой версии были добавлены функциональные компоненты. С помощью хуков можно использовать стейт, lifecycle-методы и другие фичи React, не используя class-based компоненты. Хуки расширяют возможности библиотеки, то есть от class-based компонентов React отказываться не будет. По ссылке в разделе "What are hooks?" есть небольшая подборка хороших статей и доков, для того чтобы начать погружение в новое апи.
В следующем квартале (2019 Q2), команда React планирует зарелизить конкурентный режим (Concurrent Mode). С помощью него такие события, как ввод текста или наведение курсора на элемент, смогут приостанавливать текущий рендеринг дерева компонентов в основном потоке браузера, для того чтобы приложение было более отзывчивым.
https://reactjs.org/blog/2019/02/06/react-v16.8.0.html
#react #hooks #release
legacy.reactjs.org
React v16.8: The One With Hooks – React Blog
This blog site has been archived. Go to react.dev/blog to see the recent posts. With React 16.8, React Hooks are available in a stable release! What Are Hooks? Hooks let you use state and other React features without writing a class. You can also build your…
Никита Прокопов один из самых известных представителей российского Clojure-сообщества. Время от времени он публикует очень интересные статьи у себя в блоге tonsky.me.
В ноябре 2018 года Никита написал небольшой пост "Решайте ту проблему, которую нужно решить". Основной посыл статьи в том, что тот код, в котором предусматриваются потенциальные проблемы, которые на данный момент не имеют смысла, создает больше проблем, чем приносит пользу. Такой код сложнее понимать и сложнее поддерживать. Он также говорит про то, что наверное не все смогут принять: обычно наши предсказания по поводу развития требований не сбываются, и получается, что мы усложняем код только ради усложнения кода...
"Вот чему научила меня экосистема Clojure. Все должно быть конкретным. У Clojure просто нет средств для переобобщения кода. Он либо конкретен как бетон, либо его нет".
#musings #clojure #programming
http://tonsky.me/blog/concrete-vs-abstract/
В ноябре 2018 года Никита написал небольшой пост "Решайте ту проблему, которую нужно решить". Основной посыл статьи в том, что тот код, в котором предусматриваются потенциальные проблемы, которые на данный момент не имеют смысла, создает больше проблем, чем приносит пользу. Такой код сложнее понимать и сложнее поддерживать. Он также говорит про то, что наверное не все смогут принять: обычно наши предсказания по поводу развития требований не сбываются, и получается, что мы усложняем код только ради усложнения кода...
"Вот чему научила меня экосистема Clojure. Все должно быть конкретным. У Clojure просто нет средств для переобобщения кода. Он либо конкретен как бетон, либо его нет".
#musings #clojure #programming
http://tonsky.me/blog/concrete-vs-abstract/
tonsky.me
Solve the problem at hand
Always prefer concrete code to abstract one. Don’t try to solve problems you don’t have.
Недавно слушал подкаст JavaScript Jabber, где Бэн Ко (разработчик Istanbul и DevOps NPM) рассказывал про свою жизнь и работу. Из этого подкаста я узнал, что он разрабатывает новый инструмент для измерения покрытия кода юнит-тестами - c8.
С8 интересен тем, что он не использует выделенный парсер и инструментатор кода как Istanbul, он использует встроенные возможности движка v8 для сбора покрытия, поэтому работает быстрее своего старшего брата.
Можно ли c8 уже использовать в продакшене? Наверное, нет, так как ещё есть нерешённые проблемы. Но тем не менее это очень интересный экспериментальный проект, который имеет потенциал превратиться в основной инструмент для измерения покрытия кода в мире JavaScript.
https://github.com/bcoe/c8
#nodejs #testing #tool #experimental
С8 интересен тем, что он не использует выделенный парсер и инструментатор кода как Istanbul, он использует встроенные возможности движка v8 для сбора покрытия, поэтому работает быстрее своего старшего брата.
Можно ли c8 уже использовать в продакшене? Наверное, нет, так как ещё есть нерешённые проблемы. Но тем не менее это очень интересный экспериментальный проект, который имеет потенциал превратиться в основной инструмент для измерения покрытия кода в мире JavaScript.
https://github.com/bcoe/c8
#nodejs #testing #tool #experimental
GitHub
GitHub - bcoe/c8: output coverage reports using Node.js' built in coverage
output coverage reports using Node.js' built in coverage - bcoe/c8
Интересная складывается ситуация: Chromium в последние годы очень сильно разогнался и браузеры, построенные на его основе, заняли большую часть рынка. Есть мнение, что это может негативно сказаться на развитии web-платформы. Об этом пишет в своём посте Джеффри Зельдман. Я готов подписаться под каждым абзацем, хотя и использую основную часть своего времени Chromium-based браузеры.
Джеффри пишет о том, что разнообразие браузеров и их конкуренция это именно то, что послужило бурному росту платформы. Он предлагает вспомнить, что было в мире фронтенд-разработки, когда доминировал Internet Explorer. Он переносит опыт с IE на текущую ситуацию с Chromium, и это по-настоящему заставляет задуматься.
Он призывает не рассматривать альтернативные браузеры как второй сорт, а, наоборот, поддерживать их в своих проектах на должном уровне, если мы хотим лучшего будущего для web-платформы.
#web #chromium #musings
https://www.zeldman.com/2018/12/07/browser-diversity-starts-with-us/
Джеффри пишет о том, что разнообразие браузеров и их конкуренция это именно то, что послужило бурному росту платформы. Он предлагает вспомнить, что было в мире фронтенд-разработки, когда доминировал Internet Explorer. Он переносит опыт с IE на текущую ситуацию с Chromium, и это по-настоящему заставляет задуматься.
Он призывает не рассматривать альтернативные браузеры как второй сорт, а, наоборот, поддерживать их в своих проектах на должном уровне, если мы хотим лучшего будущего для web-платформы.
#web #chromium #musings
https://www.zeldman.com/2018/12/07/browser-diversity-starts-with-us/
Jeffrey Zeldman Presents
Browser diversity starts with us.
Developers, designers, and strategists, here’s something you can do for the health of the web: Test all your sites in Firefox. Yes, we should all design to web standards to the best of our ability. Yes, we should all test our work in *every* browser and…
Как продолжение предыдущего поста сегодня мы отправляемся в 2008 год. На компьютерах большинства пользователей установлен Windows XP/Vista с IE 6/7. Мы пишем js-код
Мэтт Джука, объясняет, что это связано с тем, что в IE 6/7 был имплементирован JScript - надмножество ECMAScript 3, и в стандарте не было возможности получения символа по индексу с помощью квадратных скобок, для получения элемента надо было использовать стандартизированный метод
Теперь давайте немного посчитаем. IE6 вышел в 2001 году, IE8 - в 2009 году. 8 лет потребовалось, чтобы сделать жизнь JS-разработчикам немножко лучше. Вот яркий пример, к чему может привести монополия.
#js #history
https://unspecified.wordpress.com/2008/06/15/portable-javanoscript-string-indexing/
var str = 'Hello world'; var char = str[0]; и он падает...Мэтт Джука, объясняет, что это связано с тем, что в IE 6/7 был имплементирован JScript - надмножество ECMAScript 3, и в стандарте не было возможности получения символа по индексу с помощью квадратных скобок, для получения элемента надо было использовать стандартизированный метод
charAt(). Затем вышел новый стандарт ECMAScript 5, в котором эта проблема была решена и в IE8 наконец-то стало возможным использовать var char = str[0].Теперь давайте немного посчитаем. IE6 вышел в 2001 году, IE8 - в 2009 году. 8 лет потребовалось, чтобы сделать жизнь JS-разработчикам немножко лучше. Вот яркий пример, к чему может привести монополия.
#js #history
https://unspecified.wordpress.com/2008/06/15/portable-javanoscript-string-indexing/
В прошедшую субботу в Яндексе был митап "Я❤️Frontend". На нём выступал мой коллега Антон Кастрицкий с докладом «Вебпак, вид сквозь монокль». Для меня это был один из самых интересных и полезных докладов.
Вот небольшое содержание доклада: какие проблемы решают бандлеры и почему webpack остается популярным инструментом для сборки. Структура конфига и назначение его основных опций. Ещё Антон в докладе рассказывает про оптимизацию сборки, код-сплиттинг и динамическую загрузку модулей. Под конец доклада делится тем, как они у себя в проекте используют функциональные линзы для точечного изменения параметров в конфиге.
В общем, рекомендую посмотреть, даже если вы давно пользуетесь Webpack. Информации много и представлена она очень хорошо и доступно.
#webpack #talk
https://www.youtube.com/watch?v=iWPu3Crpys0&t=6077
Вот небольшое содержание доклада: какие проблемы решают бандлеры и почему webpack остается популярным инструментом для сборки. Структура конфига и назначение его основных опций. Ещё Антон в докладе рассказывает про оптимизацию сборки, код-сплиттинг и динамическую загрузку модулей. Под конец доклада делится тем, как они у себя в проекте используют функциональные линзы для точечного изменения параметров в конфиге.
В общем, рекомендую посмотреть, даже если вы давно пользуетесь Webpack. Информации много и представлена она очень хорошо и доступно.
#webpack #talk
https://www.youtube.com/watch?v=iWPu3Crpys0&t=6077
YouTube
Я❤️Frontend - запись трансляции 09.02.19
Конференция для фронтенд разработчиков в офисе Яндекс!
Ниже разбивка по времени начала докладов, а презентации докладов можно посмотреть по ссылке: https://events.yandex.ru/events/meetings/yalovefrontend/
1. 3:43 «О настоящем и будущем браузера» Константин…
Ниже разбивка по времени начала докладов, а презентации докладов можно посмотреть по ссылке: https://events.yandex.ru/events/meetings/yalovefrontend/
1. 3:43 «О настоящем и будущем браузера» Константин…
Франческо Черилло – автор метода помидора из тайм-менеджмента – оказывается опытный программист. В 2007 году он запустил кампанию "Anti-If". Идея компании состоит в распространении знаний наилучших инженерных практик в сфере разработки, повышая осознанность об одной из самых негативных практик – чрезмерном использовании if.
Конечно, в самом if ничего страшного нет, но только тогда, когда он используется очень умеренно. Большое же количество этих инструкций приводит к запутанному коду и его связности, разбираться в нем очень тяжело.
В общем, это интересная кампания, которая заслуживает того, чтобы вы про неё по крайней мере узнали.
https://francescocirillo.com/pages/anti-if-campaign
#programming #softwaredesign
Конечно, в самом if ничего страшного нет, но только тогда, когда он используется очень умеренно. Большое же количество этих инструкций приводит к запутанному коду и его связности, разбираться в нем очень тяжело.
В общем, это интересная кампания, которая заслуживает того, чтобы вы про неё по крайней мере узнали.
https://francescocirillo.com/pages/anti-if-campaign
#programming #softwaredesign
Вчера я рассказал про "Anti-If", но на сайте кампании нет практических примеров про то, каким образом можно избавиться от большого количества ветвлений в коде. Статья "Anti-If: The missing patterns" восполняет этот пробел.
Для того, чтобы уменьшить количество ветвлений разбивайте методы на более мелкие, если их логика зависит от логического параметра. Вместо использования switch, можно использовать полиморфизм. Не делайте явные проверки на null, используйте Optional типы либо альтернативы. Заменяйте if выражениями. Локализуйте проверки на граничные значения в одном месте, не позволяйте им расползаться по коду.
Да, статья использует Java, но, если вы сталкивались с типизацией в JS, разобраться в примерах не составит труда.
#programming #java #softwaredesign
https://code.joejag.com/2016/anti-if-the-missing-patterns.html
Для того, чтобы уменьшить количество ветвлений разбивайте методы на более мелкие, если их логика зависит от логического параметра. Вместо использования switch, можно использовать полиморфизм. Не делайте явные проверки на null, используйте Optional типы либо альтернативы. Заменяйте if выражениями. Локализуйте проверки на граничные значения в одном месте, не позволяйте им расползаться по коду.
Да, статья использует Java, но, если вы сталкивались с типизацией в JS, разобраться в примерах не составит труда.
#programming #java #softwaredesign
https://code.joejag.com/2016/anti-if-the-missing-patterns.html
Попалась на глаза серия из двух статей про CSS-in-JS от автора библиотеки JSS Олега Исонена. В первой части рассказывается про причины появления этого подхода.
CSS-in-JS это не какая-то библиотека, а идея, которая получила своё воплощение в целом ворохе библиотек, которые позволяют описывать и использовать CSS прямо в JS-коде. Это позволяет избежать целого класса проблем, присущих обычному CSS: отсутствие ограниченной области видимости, наличие неявных связей между стилями и кодом, накопление старого CSS-кода, недетерминированная специфичность, вызванная порядком загрузки стилей, могущественные селекторы, которые иногда сложно поддерживать, невозможность выразить стили на основе состояния приложения.
При этом в статье есть очень спорный момент. Автор пишет про то, что для решения некоторых описанных проблем были придуманы разные методологии наименования стилей и организации кода. При этом эти методологии очень сложны во внедрении, когда над проектом работает большое количество людей. По-моему личному опыту это не так. Конечно, какое-то недопонимание может быть в самом начале, но когда все участники разработки видят, что та структура, которую даёт BEM, Beavis и подобные методологии, лишает их головной боли, никаких проблем во внедрении быть не должно. Проблема потенциально может возникнуть только на уровне коммуникации, когда она доносится неправильно, и команда не видит в ней объективных преимуществ.
#cssinjs #css #bem
https://medium.com/dailyjs/what-is-actually-css-in-js-f2f529a2757
CSS-in-JS это не какая-то библиотека, а идея, которая получила своё воплощение в целом ворохе библиотек, которые позволяют описывать и использовать CSS прямо в JS-коде. Это позволяет избежать целого класса проблем, присущих обычному CSS: отсутствие ограниченной области видимости, наличие неявных связей между стилями и кодом, накопление старого CSS-кода, недетерминированная специфичность, вызванная порядком загрузки стилей, могущественные селекторы, которые иногда сложно поддерживать, невозможность выразить стили на основе состояния приложения.
При этом в статье есть очень спорный момент. Автор пишет про то, что для решения некоторых описанных проблем были придуманы разные методологии наименования стилей и организации кода. При этом эти методологии очень сложны во внедрении, когда над проектом работает большое количество людей. По-моему личному опыту это не так. Конечно, какое-то недопонимание может быть в самом начале, но когда все участники разработки видят, что та структура, которую даёт BEM, Beavis и подобные методологии, лишает их головной боли, никаких проблем во внедрении быть не должно. Проблема потенциально может возникнуть только на уровне коммуникации, когда она доносится неправильно, и команда не видит в ней объективных преимуществ.
#cssinjs #css #bem
https://medium.com/dailyjs/what-is-actually-css-in-js-f2f529a2757
Medium
What is actually CSS-in-JS?
CSS-in-JS refers to a collection of ideas to solve complex problems with CSS.
Вчера я поделился своими мыслями о первой части статьи "What is actually CSS-in-JS". Сейчас хочу рассказать про вторую часть - "The tradeoffs of CSS-in-JS", которая перечисляет существующие недостатки подхода.
Эти недостатки включают в себя накладные расходы в рантайме (при этом рассматриваются четыре стратегии бандлинга), потенциальная недоступность сайта на нестабильном соединении, если использовать библиотеки неправильно, вынос критического CSS при серверном рендеринге добавляет накладные расходы, генерируются новые CSS-правила для динамических деклараций (то есть опять дополнительные расходы cpu, но уже на клиенте), высокий порог входа для классических верстальщиков, нет интероперабельности между разными библиотеками, потенциальные риски безопасности, нечитаемые имена классов в некоторых библиотеках.
Хотя в статье есть много полезной информации, она получились какой-то однобокой, но автор честно признался, что его мнение может быть необъективно.
#cssinjs #css
https://medium.com/@oleg008/the-tradeoffs-of-css-in-js-bee5cf926fdb
Эти недостатки включают в себя накладные расходы в рантайме (при этом рассматриваются четыре стратегии бандлинга), потенциальная недоступность сайта на нестабильном соединении, если использовать библиотеки неправильно, вынос критического CSS при серверном рендеринге добавляет накладные расходы, генерируются новые CSS-правила для динамических деклараций (то есть опять дополнительные расходы cpu, но уже на клиенте), высокий порог входа для классических верстальщиков, нет интероперабельности между разными библиотеками, потенциальные риски безопасности, нечитаемые имена классов в некоторых библиотеках.
Хотя в статье есть много полезной информации, она получились какой-то однобокой, но автор честно признался, что его мнение может быть необъективно.
#cssinjs #css
https://medium.com/@oleg008/the-tradeoffs-of-css-in-js-bee5cf926fdb
Medium
The tradeoffs of CSS-in-JS
Every technology has tradeoffs. It’s time we had a reasonable talk about the tradeoffs CSS-in-JS has made.
Технический долг – одна из самых больных тем, которые возникают при продуктовой разработке. На него вечно не хватает времени, и бизнес часто не видит необходимости в его устранении. Статья "How great Product Managers deal with technical debt" приводит в пример некоторые инсайты, которые помогут в снижении долга.
В статье говорится про то, что технический долг возникает в тот момент, когда предположения, которые служили основой решения проблемы, устаревают. При этом наличие некоторого долга – нормальная ситуация: при разработке продукта в условиях конкуренции необходимо двигаться быстро, поэтому прийти сразу к идеальному решению практически невозможно. Если вы преследуете идею "нулевого долга", то скорее всего вы проиграете борьбу за пользователя.
Только команда, разрабатывающая продукт, может определить момент появления технического долга. Если это возникает, то ответственностью продуктолога становится оценка устранений долга. Во сколько устранение долга снизит количество обращений пользователей в техподдержку, во сколько увеличится производительность приложения, насколько станет стабильнее работать продукт. Более того надо иметь в виду, что после устранения долга побочным продуктом часто может быть ускорение доставки новых фич.
Имея на руках конкретные оценки и ясные доводы продуктолог сможет донести бизнесу важность устранения технического долга.
#pm #product
https://productcoalition.com/how-great-product-managers-deal-with-technical-debt-453edec3d473
В статье говорится про то, что технический долг возникает в тот момент, когда предположения, которые служили основой решения проблемы, устаревают. При этом наличие некоторого долга – нормальная ситуация: при разработке продукта в условиях конкуренции необходимо двигаться быстро, поэтому прийти сразу к идеальному решению практически невозможно. Если вы преследуете идею "нулевого долга", то скорее всего вы проиграете борьбу за пользователя.
Только команда, разрабатывающая продукт, может определить момент появления технического долга. Если это возникает, то ответственностью продуктолога становится оценка устранений долга. Во сколько устранение долга снизит количество обращений пользователей в техподдержку, во сколько увеличится производительность приложения, насколько станет стабильнее работать продукт. Более того надо иметь в виду, что после устранения долга побочным продуктом часто может быть ускорение доставки новых фич.
Имея на руках конкретные оценки и ясные доводы продуктолог сможет донести бизнесу важность устранения технического долга.
#pm #product
https://productcoalition.com/how-great-product-managers-deal-with-technical-debt-453edec3d473
Medium
How great Product Managers deal with technical debt
Learn to live without fear of technical debt, and learn the best way to pay it down
"XML and JSON Are Like Cardboard" - статья, рассказывающая про то, что представляют собой для современного мира слабоструктурированные (Semi-structured) текстовые форматы обмена данными.
Автор сравнивает XML и JSON с картоном. Практически любая промышленность использует картон для упаковки товара. Если вы закажите маленький чип в интернет-магазине, его вам доставят упакованным в большое количество картона, вес которого будет в несколько раз больше. Тем не менее использование избыточного количества картона в упаковке, превышает потенциальные потери, которые могут быть вызваны при транспортировке без него.
Точно также XML и JSON могут казаться избыточными, но лёгкость, с которой мы можем сформировать эти данные и использовать в своих приложениях, с лихвой окупают неэффективность текстовых данных.
В статье приводятся и другие интересные аналогии, например, подписывание коробки во время переезда можно сравнить с указанием схемы, которая определяет тип передаваемых данных.
#musings #xml #json
https://queue.acm.org/detail.cfm?id=3143320
Автор сравнивает XML и JSON с картоном. Практически любая промышленность использует картон для упаковки товара. Если вы закажите маленький чип в интернет-магазине, его вам доставят упакованным в большое количество картона, вес которого будет в несколько раз больше. Тем не менее использование избыточного количества картона в упаковке, превышает потенциальные потери, которые могут быть вызваны при транспортировке без него.
Точно также XML и JSON могут казаться избыточными, но лёгкость, с которой мы можем сформировать эти данные и использовать в своих приложениях, с лихвой окупают неэффективность текстовых данных.
В статье приводятся и другие интересные аналогии, например, подписывание коробки во время переезда можно сравнить с указанием схемы, которая определяет тип передаваемых данных.
#musings #xml #json
https://queue.acm.org/detail.cfm?id=3143320
queue.acm.org
XML and JSON Are Like Cardboard - ACM Queue
In cardboard, the safety and care for stuff is the important reason for its existence. Similarly, in XML and JSON the safety and care of the data, both in transit and in storage, are why we bother.
Давайте поговорим про js-фреймворки, а именно про будущий Vue 3.0. Кажется, что прошло совсем немного времени с момента релиза второй версии, но разработчики уже готовы выпустить следующий мажорный релиз. Статья "What Does Vue 3.0 Mean for Web Development?" рассказывает о том, чего нам ждать в будущем.
Основной упор был сделан на оптимизации производительности. Движок отслеживания изменений был переписан на ES2015 Proxy. Это позволило ускорить начальную инициализацию компонентов в 2 раза и снизить потребление памяти. Также разработчики разбили фреймворк на ещё большее количество модулей, что позволило уменьшить ядро до 10Кб (в gzip). Во второй версии были эксперименты с использованием Vue на нативных платформах аля React Native. В третей версии поддержка нативных платформ заявлена как основная фича. Под шумок разработчики переписывают код с Flow на TypeScript, мотивируя это тем, что пользователей TS гораздо больше. Очень много внимания уделили Developer Experience.
Ну что сказать, звучит это всё более чем любопытно. Очень интересно наблюдать за тем, как Vue стремительно развивается, не имея за спиной поддержки в лице больших корпораций. И кто знает, какую долю займёт Vue через несколько лет.
#vue #js #jsframeworks
https://medium.com/@mattmaribojoc/what-does-vue-3-0-mean-for-web-development-851052fc0138
Основной упор был сделан на оптимизации производительности. Движок отслеживания изменений был переписан на ES2015 Proxy. Это позволило ускорить начальную инициализацию компонентов в 2 раза и снизить потребление памяти. Также разработчики разбили фреймворк на ещё большее количество модулей, что позволило уменьшить ядро до 10Кб (в gzip). Во второй версии были эксперименты с использованием Vue на нативных платформах аля React Native. В третей версии поддержка нативных платформ заявлена как основная фича. Под шумок разработчики переписывают код с Flow на TypeScript, мотивируя это тем, что пользователей TS гораздо больше. Очень много внимания уделили Developer Experience.
Ну что сказать, звучит это всё более чем любопытно. Очень интересно наблюдать за тем, как Vue стремительно развивается, не имея за спиной поддержки в лице больших корпораций. И кто знает, какую долю займёт Vue через несколько лет.
#vue #js #jsframeworks
https://medium.com/@mattmaribojoc/what-does-vue-3-0-mean-for-web-development-851052fc0138
Medium
What Does Vue 3.0 Mean for Web Development?
How the upcoming version of Vue could make it more powerful and popular than React and Angular.
Внезапно меня занесло в баг-трекер v8, где я увидел очень интересный пропозал от разработчика из Microsoft.
Как оказалось в v8 оператор
Были произведены замеры с тестовой реализацией v8 на методе
#js #v8 #performance
https://docs.google.com/document/d/1tIfzywY8AeNVcy_sen-5Xev21MeZwjcU8QhSdzHvXig/edit
Как оказалось в v8 оператор
in не оптимизирован. Все его вызовы приводят к дорогостоящим рантайм проверкам. В пропозале идёт речь про переход к использованию инлайн кешей и jit-оптимизаций при использовании in. Но есть известные проблемы, когда перебираются все ключи объекта, в этом случае оптимизаций нет.Были произведены замеры с тестовой реализацией v8 на методе
Array.prototype.indexOf, который вызывался 10 раз у массива с 10 миллионами элементов. Результаты хорошие - заметно ускорение в 4-10 раз на разных типах массивов.#js #v8 #performance
https://docs.google.com/document/d/1tIfzywY8AeNVcy_sen-5Xev21MeZwjcU8QhSdzHvXig/edit
Google Docs
Optimizations for Javanoscript `in` operator
Optimizations for Javanoscript `in` operator Author: magardn@microsoft.com Status: Draft Bug: https://bugs.chromium.org/p/v8/issues/detail?id=8733 Created: 2019-1-10 / Last Updated: 2019-1-31 Motivation The in operator in Javanoscript is used to check for the…
Для меня было небольшим открытием, что на сайте npm есть semver-калькулятор.
Вводите в поле "pick a package" интересующий пакет, в поле "enter a range" диапазон версий и вуаля - зелёным цветом будут показаны все нужные версии.
В самом низу есть небольшая шпаргалка по тому, как задавать разные диапазоны версий. Удобно.
#npm #tool
https://semver.npmjs.com
Вводите в поле "pick a package" интересующий пакет, в поле "enter a range" диапазон версий и вуаля - зелёным цветом будут показаны все нужные версии.
В самом низу есть небольшая шпаргалка по тому, как задавать разные диапазоны версий. Удобно.
#npm #tool
https://semver.npmjs.com