Мир был более безмятежным, когда существовали только HTML, CSS, JavaScript и jQuery. (с)

#quote

Node.js решила не тормозить и включиться в гонку на скорость с остальными JS движками.

Переписывают весь node:fs пакет на C++

Именно работа с файловой системой является бутылочным горлышком.

#nodejs

Группой доброжелателей закончен перевод официальной документации Vue 3 на русский язык. Вторая ревизия, - более качественная, корректная и современная, чем https://v3.ru.vuejs.org.

Пока лежит тут - https://vuejs-doc-ru.vercel.app

#vuejs #docs

Лонгрид о JavaScript

JavaScript - ужасный язык программирования. По сравнению с другими распространёнными языками он выглядит генетическим уродом. Дело даже не в отсутствии многопоточности или статической типизации, а в том, что 10 человек одну и ту же несложную задачу могут написать на нём 10 различными способами. Каждый из них с трудом будет понимать, что написал другой, и тихо его материть. Причем, так напишут и новички, и опытные, которые просто привыкли писать по-своему или захотели выпендриться.

Синтаксис и семантика JavaScript неадекватно усложнены и запутаны. Принято считать, что Java - серьезный язык для серьезных проектов, а JavaScript - лёгкий скриптовый язык для веб-страничек. В принципе, да, вот только код на Java получается намного проще и чище кода на JavaScript. В нём на порядок меньше всевозможных абсолютно ненужных рудиментарных заморочек. И, в то же время, с возможностями Java как языка можно реализовать практически всё.

JavaScript удобен для фронта, для несложных скриптовых блоков кода в SFC. Я предпочитаю начинать обучение детей программированию с простой веб-разработки - сделать страничку, скриптом добавить небольшую анимацию, потом загрузить через fetch прогноз погоды и красиво отрисовать его. Это их сильно заинтересовывает.

На JavaScript можно написать несложный бэкенд API на Express.js или serverless functions, но это его потолок. Использовать его для чего-то серьезного на серверной стороне - ошибка.

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

Есть еще сборщики. Даже для бэкенда их используют. И их не один, и не два, и не три. И чтобы в твоем прикладном коде просто отобразить на странице картинку, ты должен подчиняться правилам сборщика.

А у сборщиков есть плагины, и чтобы отобразить на странице svg иконку, ты должен подчиняться правилам выбранных плагинов. И еще есть js runtime engines - движки. И их тоже уже не только Node.js - Deno, Bun, Cloudflare Workerd, Netlify, Vercel Edge, AWS LLRT, - один другого краше.

Вроде бы уже дно? Нет, у движков и сборщиков есть еще версии, и то, что работает на Node 16, не работает на Node 20, и наоборот.

Всё? Почти. Окружение, включая операционные системы. Нравится удобство Cloudflare workers - пиши под Cloudflare. Supabase? Только Deno до недавнего времени. Хочешь быстрый Bun? Переписывай всё под него. И он на Windows не работает пока, если что. Netlify, Vercel, AWS Lambda - у каждого свои требования и особенности.

Когда изобрели Java у нее был девиз: Write once, run everywhere. Не сильно ошибусь, если скажу, что программу, написанную на С или Java 25 лет назад можно без особых проблем скомпилировать и запустить и сейчас. А как этот слоган применим к JavaScript? Никак. Ты должен ходить везде с чемоданом набитым своим фреймворком, библиотеками под него, сборщиком, плагинами к нему, своим js рантаймом и только по своим хостерам. И всё чтобы было своих определенных версий. И ходить можно только очень небольшое количество лет, после которых ты вместе со всем этим чемоданом безнадежно устареешь.

И самое веселое, что со временем всё не унифицируется и упрощается, а совсем наоборот.

Теперь представим архитектора или техлида в здравом уме, который должен решить, на чем писать нетривиальное серверное приложение с расчетом на работу дольше одного года. В каких случаях он выберет JavaScript? Видны три варианта:

1. Он/его команда больше ничего не умеют
2. Его вынуждают это сделать силой
3. Он не совсем в здравом уме.

TypeScript может давать локальное симптоматическое лечение, но в целом ситуацию только ухудшает.

На бэкенде еще есть возможность выбрать для работы другой язык, но на фронте глобально поможет только создание и внедрение нового языка с нуля, как это было с Java или C#, с продуманными спецификациями языка программирования и виртуальной машины и всех нужных API.

#js #lang #esse

Популярный web фреймворк Remix полностью перешел на Vite в своем create-remix

#remix #vite

Иногда в шаблоне может понадобиться временная переменная - например, в v-for цикле

Для этого можно использовать следующую конструкцию:

<div :set="user = someLongExpression">
{{ user.firstName }} : {{ user.lastName }}
</div>

set - это не какой-то специальный атрибут, можно использовать любое имя. Vue просто выполнит этот код в данном скоупе.

Недокументированные возможности Vue

#tip

Иконки флагов стран в SVG формате - https://flagicons.lipis.dev
Можно выбрать необходимые, но если нужны все, то png формат (sprite) может быть значительно оптимальней.

#flag #svg #lib

Автор Volar 2 / Vue Official / Vue language tools столкнулся с неразрешимыми проблемами при переходе на новую архитектуру, и решил откатить всё назад

#volar

Напоминаю, что 23-24 марта 2024 будут очередные 48 часов бесплатного доступа к урокам VueSchool

Зарегистрироваться на них можно здесь

#vueschool #learning

Если человек долго и упорно пытается работать в open source разработке, то он либо супер классный, либо психопат
(с) Johnson Chu

На этой неделе сразу два видных контрибьютера во Vue экосистему Anthony Fu и Johnson Chu (автор Volar) сделали два поста о тяжести бремени работы в OSS. Первый поведал о воздействии последнего на психику, второй - также о стрессе и финансовых проблемах.

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

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

#vuejs #evanyou

Artem Zakharchenko, автор библиотеки для тестирования MSW с 15К звезд на GitHub, поделился мыслями о Test Driven Development:

TDD - это неправильная практика. Она всегда была неправильной. Она неправильна по определению. Ее главная заслуга - поощрение тестирования, но на этом все и заканчивается.

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

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

Я не считаю TDD жизнеспособным подходом в быстро развивающихся системах, таких как веб. Он может иметь гораздо больше смысла при написании систематического программного обеспечения, в котором очень мало что меняется от проекта к проекту. Это полная противоположность тому, что вы пишете в Интернете.

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

Я не придерживаюсь TDD. Это не значит, что я не пишу тесты. Я пишу много тестов. Я занимаюсь разработкой прототипов, итераций и тестов.

Прототип. Я даю своим идеям простор и позволяю им дышать, не слишком заботясь о тестировании на первых порах. Я экспериментирую, меняю вещи, ломаю вещи, ставлю себя на место пользователя и разрабатываю API, поведение и ожидания. Как я уже сказал, это может занять некоторое время.

Итерация. Я трачу это время на то, чтобы убедиться, что моя система имеет смысл и удовлетворяет предъявляемым к ней требованиям (которые сами по себе могут развиваться и менять то, зачем я это делаю).

Тестировать. Наконец, я пишу тесты. Это стало неотъемлемой частью моего рабочего процесса. Я не могу представить себе, что не пишу тесты.

Конечно, бывают исключения. Если я пишу простую функцию ввода-вывода, то не нужно тратить день на то, чтобы понять, что она делает, потому что это все, что она будет делать. Я могу написать для нее несколько модульных тестов с самого начала. Но большинство моих (и, я уверен, ваших тоже) работ - это не простые функции. Это сложная логика, на отладку которой требуется время. Если я буду неукоснительно следовать TDD, я буду тратить время на написание тестов, которые в итоге выброшу. Это бесполезно и не поможет мне обрести уверенность в том, что я создаю.

Не отчаивайтесь. Применяйте те практики, которые работают для вас (даже если это TDD, лишь бы вы не лгали себе!). Главное, что тестирование имеет значение. Оно всегда имело значение. Разработчики тестируют программное обеспечение с 80-х годов, я полагаю. Вы тоже должны! Я сделаю все возможное, чтобы показать вам, что тестирование может быть доступным и увлекательным.

#testing #tdd #article

Свершилось. Вышел VitePress 1.0.0.

VitePress - генератор статических сайтов (SSG), который удобен для создания как технических документаций, так и просто сайтов.

Больше 2 лет он был в статусе release candidate, стабильный, но постоянно добавляющий в себя функционал.

VitePress - один из трех китов империи Эвана, и обязателен к как минимум "попробовать" для любого Vue.js разработчика.

#vitepress #release

Svelte украл у Vue руны

По подозрению Evan You

#svelte #evanyou

Если в DevTools браузера вам нужна только консоль, то плагин vite-plugin-terminal позволяет выводить информацию в терминал (где запущен Vite), таким образом давая больше места странице в браузере. В VS Code его можно "отцепить" в отдельное окно.

#tip

Интересная табличка совместимости современных JavaScript рантаймов с JavaScript (сорри за мой рязанский французский)

https://runtime-compat.unjs.io

#jsre

Case study о вреде Nuxt и ошибках в архитектуре

VueStorefront, предлагавший услуги Frontend-as-a-Service, а именно, фронтенд для онлайн магазинов для подключения к headless e-commerce решениям, так и не смог за 4 года апгрейднуть Nuxt со второй на третью версию и в расстроенных чувствах решил переехать на React и Next.js, попутно сменив название на Alokai

При выборе технологий для магазина Arty-Crafty я долго изучал VueStorefront, но так и не понял, что это за зверь и с чем его едят. Теперь это проблема реактовцев.

#nuxt #ecommerce #vuestorefront

Основные функции фронтенд фреймворков

Фреймворки для веб-разработки - это, по сути, пресобранные библиотеки кода, которые обеспечивают структурированную основу для создания веб-приложений. Они предлагают целый ряд возможностей, таких как:

Компонентная архитектура: Фреймворки часто разбивают пользовательские интерфейсы на многократно используемые компоненты, что способствует модульности и удобству сопровождения.

Связывание данных (data binding): Эта функция автоматически синхронизирует данные между пользовательским интерфейсом и базовой моделью, упрощая логику и сокращая ручные манипуляции с DOM.

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

Управление состоянием: Сложные приложения иногда требуют управления состоянием различных компонентов. Фреймворки часто предоставляют встроенные или совместимые решения для этого.

Инструменты разработки (devtools): Многие фреймворки предлагают такие инструменты для разработчиков, как отладчики, горячая перезагрузка и профилирование производительности, что повышает удобство разработки.

Эти функции значительно сокращают количество шаблонизированного кода, упрощают процесс разработки и обеспечивают последовательность действий при разработке.

#frontend

В CSS есть правило color-scheme для реализации цветовых тем на сайте. Не очень удобное, по сравнению с использованием для этой цели CSS переменных.

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

:root {
  color-scheme: light dark;
}

.element {
  color: light-dark(black, white);
  background-color: light-dark(white, black);
}

В Firefox она уже была реализована

#css #tip

Одна из самых серьезных проблем в разработке программных средств — их тучность, или раздутость. Программы просто становятся слишком большими. Это может быть связано с неразумным выбором функций, но чаще всего становится следствием плохой архитектуры. Популярное средство повторного использования кода — наследование, но его работа оставляет желать лучшего, поэтому вместо него зачастую применяются копирование и вставка кода. Не следует сбрасывать со счетов и чрезмерную зависимость от библиотек, платформ и пакетов, тесно связанных со многими другими библиотеками, платформами и пакетами. Раздутость может быть побочным эффектом приемов гибкой разработки. Чтобы справиться с ней, увеличивают численность команды разработчиков, но это порождает еще большую раздутость.
…
Лучший способ справиться с раздуванием программ — не допускать его. Приоритетом при разработке и реализации программы нужно сделать ее «худобу». Следует избегать внедрения в практику раздутых пакетов и инструментов, способствующих раздуванию. Обходитесь без классов. Нанимайте небольшие квалифицированные команды разработчиков. И активно практикуйте удаление кода. Создайте резерв из нескольких циклов разработки с целью удаления ненужного кода и избавления от проблемных пакетов. Радуйтесь, когда количество строк кода в проекте уменьшается. Придерживайтесь принципа наименьшей раздутости.

(с) Дуглас Крокфорд, программист, автор формата JSON и книги "How JavaScript Works"

#quote