Предыстория к картинке выше: в issues ms/vscode кто-то написал, что падение TS Server может вызываться расширением Volar.

Эта, другие слова нежели "истеричка" на находятся, заявила, что он прекращает разработку и поддержку расширения в VS Code и переключается на JetBrains

Это далеко не первый раз, когда Volar не работает из-за каких-то "багов" в VS Code, TS плагинах и даже Node.js.

Честно говоря, для меня дико, что кто-то, выпускающий плохой, но распространенный продукт, постоянно обвиняет в своих неудачах инструменты, которыми он пользуется.
Почему нельзя использовать только стабильный функционал VS Code и TS?

Почему стратегические решения для Vue принимаются из-за нервных срывов отдельных лиц, которые, кстати, уже получают приличные деньги за свою работу, плюс известность позволяет ему работать на коммерческих проектах с повышенной ставкой?

Почему бОльшая часть времени разработки жутко баггованного и нестабильного Volar сейчас уходит на поддержку других фреймворков, а не Vue? Почему их грёбаная un-экспансия идет ценой Vue?

И бранная лексика в твитах допустима только для людей уровня Линсуса Торвальдса. По крайней мере, в цивилизованном мире. Этот твит выглядит кринжово для представителя серьезной организации или бизнеса.

Also, a big thank you to Astro and JetBrains for generously donating ten thousand dollars, allowing us to focus entirely on development without worrying about anything else.

Также большое спасибо Astro и JetBrains за щедрые пожертвования в размере десяти тысяч долларов, что позволило нам полностью сосредоточиться на разработке, не заботясь ни о чем другом.

Это цитата Джонсона. Не в этом ли причина? JetBrains, не сумев сама написать тулинг для Vue, просто переманила деньгами разработчика? Очень дерьмовая история.

И, кстати, Astro и JetBrains это не основные спонсоры Джонсона. И все равно он время от времени вылазит в медиа пространство и оскорбляет, ноет и эмоционально шантажирует миллионы пользователей.

#volar #jetbrains #vscode

В стандарте HTML давно появился <dialog> элемент и относительно недавно Popover API для модальных окон и всплывающих меню.

Они стандартизировали и значительно упростили работу с ними, частично избавив от необходимости использовать сторонние библиотеки. Только "умное" позиционирование тултипа/меню требует дополнительной логики.

Мы рассказывали ранее как анимировать появление диалогового окна / всплывающего меню через transition.

Тут пример создания CSS анимации для всплывающих элементов через keyframes.

#popoverapi #css

И чтобы закончить с Popover API - сайдбары и выезжающие боковые шторки можно делать тоже на нем

#popoverapi

В комментариях подсказали еще один eslint-config, сильно упрощающий настройку линтинга и форматирования кода - @sxzz/eslint-config,

По сравнению с eslint-config от Anthony Fu у него более строгие ESlint правила (от unicorn и perfectionist), которые заставляют писать более эффективный код, а для форматирования используется Prettier.

Поставил - пока положительные впечатления. Форматирует везде и неплохо. Не нужно поправлять вторым форматтером.

#eslint #prettier #eslintconfig

1. Инструментарий Vue всегда был лучше в VS Code, чем в Webstorm. Официальная документация рекомендует именно VS Code.
2. Джонсон Чу стал мейнтенером Volar
3. Джонсон Чу получает большие спонсорские гранты от JetBrains (как минимум 10 тысяч долларов).
4. Инструментарий Vue в VS Code превращается в кошмар
5. Поддержка Volar других фреймворков становится более важной для разработчика, чем поддержка Vue
6. Джонсон Чу регулярно публикует истеричные и оскорбительные посты о том, насколько глючен VS Code и насколько безответственны и некомпетентны его разработчики.
7. Джонсон Чу официально объявляет, что он фокусируется на Webstorm, оскорбившись на небезосновательное предположение, что VS Code может сломаться из-за некоторых его расширений.
8. Кто в выигрыше? Один конкретный человек и одна компания?

На это перечисление фактов (с моей точки зрения), воспринятое как наезд, даже вынужден был ответить представитель JetBrains:

Привет, адвокат разработчиков из JetBrains. Все уже было разъяснено несколько раз, но я просто хочу поделиться своей точкой зрения на эти вещи.

Части нашего плагина Vue действительно зависят от Volar и, следовательно, неотъемлемо от работы Джонсона. Люди используют наши инструменты для разработки Vue, поэтому у нас есть несколько стимулов для поддержания Volar как проекта. В будущем от Volar будет зависеть еще больше плагинов. Именно по этой причине мы решили спонсировать Volar. Мы также спонсируем другие проекты с открытым исходным кодом, от которых мы зависим (например, Vite, ESLint, pnpm, ...).

Помимо спонсорства, мы поддерживаем активную связь с Джонсоном и другими сопровождающими Volar, чтобы обсуждать проблемы, с которыми мы сталкиваемся, или проблемы, о которых сообщают на их стороне. Мы также предоставили несколько воспроизведений или исправлений замеченных нами проблем. Такое взаимодействие также не является чем-то уникальным, у нас есть подобные каналы связи с другими проектами (например, Angular, Astro, prisma, NX, ...).

При всем этом мы никогда не поощряли Джонсона использовать WebStorm, это полностью его собственное решение. Судя по тому, как с ним обращались, я не удивлен этим решением, и это явный признак того, что нам, как сообществу, нужно гораздо лучше относиться к сопровождающим OSS.

Неубедительно, особенно учитывая, что они с Джонсоном одновременно отреагировали на пост спустя двое суток после его публикации, но ок (c).

#volar #jetbrains #vscode

JavaScript worker threads / Web workers — это мощный функционал, доступный в современных веб-браузерах, а также в Node.js, Deno и Bun, который позволяет создавать независимые потоки выполнения в одной JavaScript-среде. Эти worker threads работают параллельно с главным потоком, позволяя приложению выполнять ресурсоемкие операции или обрабатывать сетевые запросы без блокировки пользовательского интерфейса.

Преимущества использования worker threads:

Повышенная отзывчивость: Передавая длительные задачи на worker threads, главный поток остается свободным для обработки пользовательских взаимодействий и обновления интерфейса. Это приводит к более плавному и отзывчивому пользовательскому опыту.

Повышенная производительность: Worker threads могут использовать несколько ядер современных процессоров, что позволяет параллельно выполнять ресурсоемкие задачи.

Эффективный обмен данными: В отличие от дочерних процессов, worker threads совместно используют память с главным потоком. Это позволяет эффективно передавать большие структуры данных между потоками, снижая необходимость дорогостоящей сериализации и десериализации.

Модульный код: Worker threads способствуют модульной организации кода. Мы можем изолировать сложные задачи в отдельных worker-скриптах, улучшая поддержку и повторное использование кода.

Варианты использования:

1. Ресурсоемкие вычисления

Представьте, что у нас есть сложная математическая формула для расчета данных по нескольким точкам. Непосредственное выполнение этого на главном потоке заблокирует пользовательский интерфейс и сделает наше веб-приложение неотзывчивым. Такие задачи идеально подходят для worker threads.

2. Обработка изображений/видео

Допустим, мы хотим разрешить пользователям загружать изображения в наше веб-приложение и применять фильтр черно-белого цвета перед отображением. Обработка изображения непосредственно в главном потоке может вызвать задержку во время применения фильтра. Опять же, это ресурсоемкая задача, где worker threads могут спасти ситуацию.

3. Анализ данных

На этот раз у нас есть большой набор данных о клиентах, и мы хотим фильтровать и сортировать его по разным критериям. Выполнение этих операций на главном потоке может значительно замедлить веб-приложение, особенно если набор данных большой.

4. Фоновые задачи

Представьте, что у нас есть веб-приложение, позволяющее пользователям сохранять свою работу в процессе. Постоянное сохранение данных на сервере во время редактирования может быть неэффективным и потенциально замедлить пользовательский интерфейс. Worker thread можно использовать для обработки фоновой функции сохранения.

5. Приложения в реальном времени

Приложения в реальном времени требуют постоянного общения с сервером для обновления пользовательского интерфейса последней информацией. Worker threads могут быть полезны для управления этими соединениями и обработки входящих данных без блокировки главного потока, ответственного за отрисовку пользовательского интерфейса.

#js #workerthreads

Интересный случай рассказали.

Человек прошел Школу 21 от Сбера, попал туда на стажировку на 1.5 месяца с зарплатой 100К в месяц, а после предложили джуниорскую позицию на 120К.

Не думал, что когда-то буду рекламировать Сбер, но это один из правильных способов вкатиться в IT - то есть, когда есть желание, но нет релевантного образования, знаний и опыта.

Обучение в школе очное, доступно во многих городах, бесплатное и длится от 1.5 до 3 лет. С трудоустройством Сбер помогает, и не только в себя.

#learning #jobs

Профессиональные преподаватели Школы 21 и подобных школ предлагали бесплатно получить знания и гарантированно трудоустроиться на оплачиваемую стажировку в солидные компании, но люди все равно шли к Минину и несли ему деньги...

#learning #minin

Vue Data UI библиотека

Множество компонент[ов] для визуализации отчетных данных

#lib

Vue 3.5.0-alpha.3 - Появился новый компосабл useId() для генерации ID в компонентах.
#vue_3_5 #changelog

const inputId = useId()

Зачем генерировать ID?

Типичный use-case - id элементов, например, форм и атрибуты для доступности.

Почему не просто `Math.random()` или `nanoid()`?

Результат получается невоспроизводимым, что усложняет тестирование и не работает на SSR

Почему не просто `id++`?

Такое решение может приводить к дублированию ID. Например, и в вашем приложении, и в UI фреймворке могли сделать input-label-${id++}.

Чтобы облегчить жизнь разработчиков, добавили долгожданный useId, возвращающий уникальный ID, префикс которого можно настроить в конфиге Vue приложения.

const app = createApp(App)
app.config.idPrefix = 'my-app'
// useId() === "my-app:0"

- PR: https://github.com/vuejs/core/pull/11404/

Общественные слушания

#minin #chernov

Наткнулся тут на Quake на JS, даже прошел до конца

Движок Quake был первым, способным полноценно обрабатывать трехмерную графику и стал отцом многих других движков.

Мод QuakeWorld двадцатишестилетней давности до сих пор остается непревзойденным по динамике боя и стратегическому видению игры, где мастерство игрока определяет всё.

Забавно, что всё самое крутое в IT было изобретено в 1995-1997 годах )

#gaming #offtop

Для отслеживания затрачиваемого на работу времени даже на личных пет проектах удобно использовать тайм-треккеры.

Я привык к Clockify. В бесплатной версии есть практически всё, что нужно, а недавно добавили и Calendar, что еще более улучшило UX.

Есть интеграция с Jira, чтобы оттуда стартовать-останавливать треккер по конкретным задачам, генерация таймшитов, командная работа, организация проектов, клиентов и многое другое хоть для безмятежного фриланса, хоть для комфортной гребли на галере, хоть для спокойного вкалывания в кровавом энтерпрайзе.

#timetracking #dx

На стоит превозносить open-source разработчиков и молиться на них как бескорыстных альтруистов.

Ездящий по конференциям с рюкзачком очкарик Эван живет в недешевом Сингапуре и коллекционирует спортивные машины не только в масштабе 1:12. Его ставка, по-моим оценкам, должна начинаться от $300/час. Он может месяц консалтить коммерческих заказчиков, потом год отдыхать в опен сорсе.

Никаких претензий, - Эван полностью заслужил это своим трудом и талантом. И большинство опен сорс разрабов именно так делает себе имя и резюме, которые потом приносят им деньги. И Anthony Fu с Johnson Chu вполне, уверен, востребованы на рынке, при их желании заработать. Поэтому слышать их нытье о депрессии от того, что много работы и мало денег - странно. И нытье о плохих отзывах тоже странно - пошли всех вместе с проектом нахрен и занимайся своим психическим здоровьем, если эмоционально не тянешь. Иди на завод в Facebook в их дружелюбный коллектив.

Развели детский сад, понимаешь...

#opensource #esse

О, Боже-ш ты мой!
И сразу попалось свежее интервью Vue Core member Натальи Теплухиной
Вот здесь она жалуется, что Vue мало критикуют
Что вообще не слышно голосов с конструктивной критикой
Что все как медом намазано на конференциях
И это после полугода кошмара с Volar
Кому-то надо промыть уши

#tepluhina #vuejs #interview

Как организовать конфигурационные параметры в приложении?

Наиболее удобна, имхо, следующая конфигурация конфигов.

Есть, грубо говоря, .env, .env.staging, .env.local

Локально используется .env.local, он в гитигноре, и у каждого разработчика свой. Если работаешь один, или у всех локально одна конфигурация - .env.local не нужен.

При CI/CD .env.staging заменяет .env. При этом используются / добавляются в конфиг (для бэка) нужные секреты. У CI/CD свой конфиг.

Есть два варианта распределения параметров по конфиг файлам.
- Первый - .env хранит основные параметры, а .env.local и .env.staging только переопределяют нужные (merge).
- Второй - в каждом из них хранится полная конфигурация.

У обоих свои плюсы и минусы. Первый - удобней, можно легко добавлять общие конфигурационные параметры и не просить всех разработчиков обновить свой .env.local. Второй - наглядней, при CI/CD можно просто заменять файлы.

Данная система позволяет, например, легко переключиться и поработать на локальном фронтенде со staging бэкендом вместо локального. Можно просто написать скрипт для этого в package.json.

В такой системе никто случайно не запушит свой конфиг в репозиторий, никто не имеет доступа к секретам и чужим параметрам.

env / dotenv - довольно старая штука и недостаточно гибка для реализации удобных конфигов, поэтому я храню конфиги в json / js файлах. Их легко объединять в коде и, вообще, закладывать нужную тебе логику. Ну и древовидная система конфигурационных параметров намного читабельней и удобней в работе в коде.

Доступ к конфигу в приложении:
import { config } from "@/app-config"

#tip #cicd

Дележка личным опытом прохождения Vue сертификации

#certification

Не всегда только Safari и Firefox тормозят прогресс в веб деве. В последнем Chrome появилось то, что в них было давно - CSS свойство font-size-adjust.

Оно позволяет корректировать размер шрифта. Для чего это нужно?

Представим, у вас основной шрифт, и фолбэк шрифт. Даже если они одного размера (font-size), визуально они могут сильно отличаться, и при загрузке основного шрифта могут происходить дёргания экрана. Чтобы этого не было можно подогнать font-size-adjust фолбэк шрифта.

#css

В GitHub решили обновить инфраструктуру базы данных и положили на час свой сервис для всего мира

#github #qa

В третьей стадии находится пропозал о декораторах в JavaScript

Если его примут, задание реактивных переменных возможно "упростится" до:

@reactive
let count = 0;

@shallowReactive
let messages = [];

Правда, после этого js перестанет быть js-ом...

#js #tc39 #decorators