Не секрет что популярный - не значит качественный, и наоборот.
Качественные решения с трудом проникают в нашу практику, а некачественные однажды набрав хайпа разрастаются как сорняк.
Далеко ходить не надо, возьмем Next.js - обрастает костылями и сомнительными решениями, но его все равно "хавают".

Сегодня у нас есть уникальная возможность посмотреть на примере как это работает.

alexgriss поделился своими мыслями о том как он приходит к выбору next.js, в своем посте про выбор стэка для нового проекта.
Речь там не о Proof of Concept или MVP, это имено продуктовый стэк.
Обратите внимание - в листе приоритетов нету ничего что должно волновать иженера:
- Подерживаемость
- Производительность
- Вендорлок
- Куда движется это решение и есть ли у него будущее
и так далее.

Вместо этого вы увидите что
- Мне надо побыстрее

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

На канале mefody_dev появился класный пост про то как сделать модалки с анимациями на нативных апишках.
(codepen демка)

В лисе анимашки не работают, но может через год два уже можно будет тащить в прод

По работе сейчас много работаю с Bazel, и подумал что вам будет интересно узнать с какими челеджами я сталкиваюсь и как оно вообще работает.
Для тех кто не в курсе пару слов о том что это:
monorepo.tools говорит нам что это тул для менеджмента мнорореп, что на самом деле не совсем совсем не так.
По факту он не делает ничего типа авторелизов или трэкинга / подьема версий / генерации ченжлогов и все то что обычно делают монореп тулы фронта.

Если в классическом монорепе возможно сделать так чтобы один пакет зависел от более старой версии пакета из этого монорепа, то bazel такой возможности не предоставляет

Он нужен в монорпе для того чтобы билдить все вот это что вы туда накидали написанное на разных ЯП и связать это между собой (т.е. что после чего надо собрать)
Короче, на языке фронтендеров - bazel это типа webpack, но не для сборки js, а для сборки чего угодно чем угодно*. Только в webpack мы все импортируем в js файлы, и пишем loader-ы, а в bazel мы все импортируем в BUILD.bzl** файл и пишем rules

* В теории, на практике есть нюансы о которых я буду расказывать позже
** Написаны они на языке starlark, который является диалектом Python с ужасной поддержкой в vscode

#bazel

Под каждый билд каждой зависимости Bazel создает отдельную дирректорию куда копирует* все необхожимое для конкретно этой стадии билда.

Так, например, в процессе описания билда приложения в Build.bzl надо перечислить все зависимости что ему нужны для работы (в случае js приложения это будут пакеты из node_modules и например другие пакеты в вашем монорепе, которые Bazel так же предварительно соберет аналогичным образом.)

* На самом деле он их не копирует, а создает симлинки. И на практике это постоянно стреляет в ногу. Сначала вы получаете легкое ранение если попытаетесь это все дело поднять на винде, которая как известно, имеет особые отношения с симлинками, а потом вы получите выстрел из дробовика, когда узнаете что чтобы нода не могла "сбежать" из своей папки "контейнера" bazel патчит ей весь fs пакет чтобы она не могла ходить по симлинкам в принципе (npm link - пока), и наконец ноги отрывает полностью когда оказывается что bazel так же патчит require от чего esm перестает нормально работать ведь import-ы замонкепатчить не получается

По сути это все очень напоминает недо-докер:
- Свой язык для описания билда в специальном файле - в докере есть
- Билды изолироваными "слоями", каждый из которых кэшируется - в докере есть (и реализовано лучше)
- Которые потом заливаются в репозиторий и могут быть скачаны оттуда без потребности их пересобирать - в докере есть

Как работает bazel с точки зрения пользователя (упрощенно):

а) Описываем рул для сборки приложения:
- от каких пакетов зависит (вернее сказать - от каких рулов)
- где взять сорс файлы
- какой бинарник с какими аргументами запустить
- даем ему имя например - build_dev

б) Описываем рул для запуска приложения и даем ему имя, например run_dev
- указываем что он зависит от build_dev
- каким бинарником
- какой файл из build_dev запустить

Теперь если мы хотим запустить приложение - пишем bazel run //путь/к/пакету:run_dev
Bazel составит граф зависимостей, и начнет его билдить с конца (или нет если они уже готовы. Те самые временные директории для билда, о которых я говорил ранее одновременно являютсья кэшем bazel), в конце запустит ваше приложение

Кроме run есть еще build (понятно - только билдит что-то) и test

Я очень внимательно слежу за тем как развивается продукт под названием AR очки.

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

Делает такие очки много разных компаний (в коментарии будет список), и цена у них в диапазоне 400-700$ (а не 3 куска)

Я такие очень хочу, но пока не покупаю, а все потому что я знаю страшную тайну - в них есть одна пока нерешенная техническая проблема (продолжение в следующем посте)

Отзывы о framework от ситника:
https://x.com/andrey_sitnik/status/1751987531158057129

Саммари:
1. First class linux support
2. Регулярное обновление железяк
3. Кастомки от сторонних производителей
4. Собирается за 5 минут
5. AMD по бенчам показал производительность близкую к m2, и энэргоэффектиновсть как у m1
(от себя добавлю что после его поста фреймворк выкатил опцию с новым intel ultra - производиельность уже намного выше чем у m2, при той же энэргоэфективности)
6. Фреймворк холодный и не шумит
7. На момент написания поста на винде работал 12 часов на линухе 9, фиксы энэргосбережения уже вмержены
8. На фреймворке легко быть на cutting edge, потому что он популярен у "различных хакеров", в качестве демо показывает что он уже на wi-fi 7
9. Во время презы его выручило что hdmi разьем можно перекинуть на другую сторону
10. Был косметический изьян по корпусу - выслали детальку на замену
11. 3:2 гораздо удобнее для кодинга чем 19:10
12. Очень хватил кастомную клавиатуру
14. Через пол года использования уже заказал новый экран 120гц 4к (обновления частей на практике - работает)

Я вот все думал что лучше использовать по дефолту interface или type.

Сегодня я определился что по дефолту надо юзать type, потому что interface работает очень странно, не интуитивно, и приведет к ошибкам в вашем коде (см скрин)

Песочница

Интересно что Matt Pocock (кто не в курсе кто это - погуглите) пришел к аналогичному выводу в своем посте

Как проверить доступен ли файл для чтения / записи в nodejs

fs.stat ноды возращает обьект в котором есть поле mode c числом.
Накладывая на него битовые маски можно извлечь необходимю информацию.

Проверяем что файл доступен для чтения (хоть кому-нибудь):

if (mode & (fs.constants.S_IRUSR | fs.constants.S_IRGRP | fs.constants.S_IROTH)) {
  console.log('file has read permissions');
}

аналогично для записи:

if (mode & (fs.constants.S_IWUSR | fs.constants.S_IWGRP | fs.constants.S_IWOTH)) {
  console.log('file has write permissions');
}

Значения констант:

S_ISUID  04000  set-user-ID bit (see execve(2))
S_ISGID  02000  set-group-ID bit (see below)
S_ISVTX  01000  sticky bit (see below)
S_IRWXU  00700  owner has read, write, and execute permission
S_IRUSR  00400  owner has read permission
S_IWUSR  00200  owner has write permission
S_IXUSR  00100  owner has execute permission
S_IRWXG  00070  group has read, write, and execute permission
S_IRGRP  00040  group has read permission
S_IWGRP  00020  group has write permission
S_IXGRP  00010  group has execute permission
S_IRWXO  00007  others (not in group) have read, write, and execute permission
S_IROTH  00004  others have read permission
S_IWOTH  00002  others have write permission
S_IXOTH  00001  others have execute permission

Обновлено:
Мне тут подсказали что есть менее гиковский вариант: fs.access

Google Translate ломает сайты на реакте. После того как я переехал жить в польшу и стал им часто пользоваться я постоянно с этим сталкиваюсь.

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

Об этом баге известно очень давно но, в браузерах считают что это проблема реакта (должны учитывать поведение браузера), а в реакте - что это баг браузера (не должны менять вёрстку).

И я даже не знаю кто тут прав.

Codesandox с демкой бага, воркэраунда, случаев которые ломают воркэранэунд и тп.

Случайно набрел на крутую статью о работе с node.js приложением с vite, который сам по себе больше расчитан на сборку под браузер, от автора @liuli-util/vite-plugin-node либы.
Затраигиваемые моменты:
- настройка vite
- настройка vitest
- vite-node для запуска.
- magic-string для совместимости esm - commonjs (require, __filename, __dirname, self)
- rollup-plugin-node-externals для исключения из билда пакетов самой ноды

Имена людей приложивших руку к созданию этого ноутбука
#framework

Сборка заняла 40 минут. Инструкция пошаговая, с короткими гифками, ничего сложного, просто много винтиков надо закрутить/открутить.
Понимаю почему никто раньше таких модульных ноутбуков не делал, инженеры из условного Lenovo просто сказали бы что это не возможно при соблюдении их стандартов. Счас покажу о чем речь
#framework

Не смотря на то что все тут в ноутбуке из толстенного алюминия (по меркам ноутбуков) тот факт что он состоит из множества кусочков делает его... Не монолитным. Хотя это возможно, им стоит поучиться у Lego ; )
Но они все равно молодцы что не смотря на это все же сделали его, я потом аккуратненько это все подогну, чтобы было в стык везде
#framework