Что меня смущает в Solid, так это излишняя непрозрачность.
Пример с classList лишь один из многих. Чтобы прочитать значение сигнала, надо вызывать как функцию. К тому же нужно юзать control-flow операторы.
Очень невнятно выглядят ошибки иной раз, но…
Stunning Absolutely Ideal Framework на эффекторе должен поддерживать react, svelte и solid из коробки, #ящитаю
Пример с classList лишь один из многих. Чтобы прочитать значение сигнала, надо вызывать как функцию. К тому же нужно юзать control-flow операторы.
Очень невнятно выглядят ошибки иной раз, но…
Stunning Absolutely Ideal Framework на эффекторе должен поддерживать react, svelte и solid из коробки, #ящитаю
Forwarded from Монада Кедавра (Дима Zerꙫbias)
Things you should never do
Создатели Arc Browser смачно кинули всех пользователей и фактически закрыли проект чтобы запустить брузер с ИИшкой (куда же без неё). Буквально, браузер для энтузиастов не принес столько денег сколько нам хотелось бы, так что поедем на хайптрейне. Жаль что понятия «репутация» и «доверие» им видимо не знакомо
Одно из классических клише VC-новояза, в котором вторая часть предложения противоречит первой, проект по сути остановлен в развитии, все планы отправились в on hold (в утиль)
Вспоминается классическая статья Things You Should Never Do, Part I, в которой рассказывается как флагман браузеров Netscape Navigator сел на мель во время переписывания с нуля и какие выводы из этого можно сделать. Захватывающее чтиво. Прошло почти 25 лет, по меркам IT — целая вечность, а тезисы становятся всё более актуальными. Главный вывод: please dont. В эту ловушку люди попадались множество раз, и судя по текущей новости, будут попадаться вновь и вновь.
Я понимаю, что расчёт Browser Company на успешный pivot (резкое изменение курса компании в попытке нащупать market fit) в сторону ИИ, но с такими конкурентами (свои фичи завозят google, apple и microsoft) и с таким отношением к своим пользователям перспективы у них не вдохновляющие
В целом, могу сформулировать «Things you should never do part 2»: не пользоваться продуктом VC-стартапа до тех пор пока он не покажет своё истинное лицо (vercel) или не выживет после кучи pivot-ов. Либо не расчитывать на длительное пользование, легко пришло — легко ушло
А если вы решили поучаствовать в переписывании проекта с нуля, то стоит убедиться, что ключевые участники действа знакомы с этим классическим текстом и понимают на что идут
Создатели Arc Browser смачно кинули всех пользователей и фактически закрыли проект чтобы запустить брузер с ИИшкой (куда же без неё). Буквально, браузер для энтузиастов не принес столько денег сколько нам хотелось бы, так что поедем на хайптрейне. Жаль что понятия «репутация» и «доверие» им видимо не знакомо
Arc won't be abandoned, but the new focus will primarily be on stability updates and bug fixes
Одно из классических клише VC-новояза, в котором вторая часть предложения противоречит первой, проект по сути остановлен в развитии, все планы отправились в on hold (в утиль)
Вспоминается классическая статья Things You Should Never Do, Part I, в которой рассказывается как флагман браузеров Netscape Navigator сел на мель во время переписывания с нуля и какие выводы из этого можно сделать. Захватывающее чтиво. Прошло почти 25 лет, по меркам IT — целая вечность, а тезисы становятся всё более актуальными. Главный вывод: please dont. В эту ловушку люди попадались множество раз, и судя по текущей новости, будут попадаться вновь и вновь.
Я понимаю, что расчёт Browser Company на успешный pivot (резкое изменение курса компании в попытке нащупать market fit) в сторону ИИ, но с такими конкурентами (свои фичи завозят google, apple и microsoft) и с таким отношением к своим пользователям перспективы у них не вдохновляющие
В целом, могу сформулировать «Things you should never do part 2»: не пользоваться продуктом VC-стартапа до тех пор пока он не покажет своё истинное лицо (vercel) или не выживет после кучи pivot-ов. Либо не расчитывать на длительное пользование, легко пришло — легко ушло
А если вы решили поучаствовать в переписывании проекта с нуля, то стоит убедиться, что ключевые участники действа знакомы с этим классическим текстом и понимают на что идут
How-To Geek
Arc Browser Creator Moving On To New Project
The Arc browser is "done" apparently.
😢11👍5😁2
Продолжаю эстафету
Вбиваем промпт и скидываем в комменты
Странно, что меня нет в кадре, видимо отдыхаю где-то на улице… давно пора.
https://t.me/bearlogin_dev/320
Вбиваем промпт и скидываем в комменты
Based on what you know about me from our previous conversations, please draw a picture how in your opinion my life could look like
Странно, что меня нет в кадре, видимо отдыхаю где-то на улице… давно пора.
https://t.me/bearlogin_dev/320
👍13👎7🔥3😁1😡1
Сначала люди в интернетах пишут, что Ruby умер и вообще только легаси на нем.
А потом вижу проект этого года на Ruby on Rails и всё еще радуюсь, как приятно на нем было писать.
https://github.com/maybe-finance/maybe
А потом вижу проект этого года на Ruby on Rails и всё еще радуюсь, как приятно на нем было писать.
https://github.com/maybe-finance/maybe
👍10❤2
React-hooks не отделяют логику от UI
Не раз в чатах видел, как люди предлагают решать проблему прибитой логики к компонентам — просто вынесите логику в кастомные хуки. Но это вообще никак не помогает, хотя хуки позволяют вынести код из компонентов в отдельные функции, сама логика всё равно остаётся зависимой от React.
Почему? Возьмём useEffect. Этот хук будет вызываться дважды в strict mode, потому что он связан с жизненным циклом компонента. И это не баг, а фича React, спорная конечно, но в результате, любая бизнес-логика внутри такого хука становится заложником жизненного цикла React.
И это только самый наглядный пример! Наверняка вы сами можете привести еще десяток менее очевидных примеров. Чего стоит только каскад ререндеров из-за необходимости указывать dependencies между разными useEffect. Приходится городить решения поверх особенностей реакт и выглядит это совсем не просто.
Из-за этой привязки к React, тестирование также превращается в проблему. Приходится оборачивать тесты в условный
Можно решить "по-старинке": вынести логику в обычные функции или классы, а хуки использовать только как мост между React и бизнес-логикой. Но тогда мы сталкиваемся с новой проблемой – нужно самостоятельно продумывать реактивность и управление состоянием.
Хоть может показаться, что реактивность не обязательна, современные приложения демонстрируют как раз реактивную природу. Чем меньше в коде ручного/императивного управления состоянием, тем проще код. Но это вовсе не означает, что нужно перестать писать императивный код и погрузиться в пучину декларативности или функциональности.
Используйте инструменты по назначению!
Не раз в чатах видел, как люди предлагают решать проблему прибитой логики к компонентам — просто вынесите логику в кастомные хуки. Но это вообще никак не помогает, хотя хуки позволяют вынести код из компонентов в отдельные функции, сама логика всё равно остаётся зависимой от React.
Почему? Возьмём useEffect. Этот хук будет вызываться дважды в strict mode, потому что он связан с жизненным циклом компонента. И это не баг, а фича React, спорная конечно, но в результате, любая бизнес-логика внутри такого хука становится заложником жизненного цикла React.
И это только самый наглядный пример! Наверняка вы сами можете привести еще десяток менее очевидных примеров. Чего стоит только каскад ререндеров из-за необходимости указывать dependencies между разными useEffect. Приходится городить решения поверх особенностей реакт и выглядит это совсем не просто.
Из-за этой привязки к React, тестирование также превращается в проблему. Приходится оборачивать тесты в условный
act(), или же мокать хуки и поведение React – и всё это только потому, что бизнес-логика не отделена от компонентов.Можно решить "по-старинке": вынести логику в обычные функции или классы, а хуки использовать только как мост между React и бизнес-логикой. Но тогда мы сталкиваемся с новой проблемой – нужно самостоятельно продумывать реактивность и управление состоянием.
Хоть может показаться, что реактивность не обязательна, современные приложения демонстрируют как раз реактивную природу. Чем меньше в коде ручного/императивного управления состоянием, тем проще код. Но это вовсе не означает, что нужно перестать писать императивный код и погрузиться в пучину декларативности или функциональности.
Используйте инструменты по назначению!
👍42💯10🔥7😐5
Astro 5 + Vite 6
Из самого интересного:
Content Layer
Позволяет динамически грузить данные для страничек из любых источников. Например из notion или вообще через fetch() откуда угодно. Что круто, так это кеширование.
Когда я трогал beta версию, можно было руками перезапустить выгрузку данных, а потом быстро рендерить уже загруженную инфу.
Server Islands
Пререндерим всё статическое в .html, а динамику из бд можем грузить и рендерить на сервере. Причем только для небольших частей интерфейса.
Нормально реализованные идеи Next.js, без привязки к React!
astro:env
Ну и самая ожидаемая мной фича — безопасное извлечение переменных и секретов.
Описываем все переменные в виде zod-схемы, а затем импортируем из
Секреты доступны только на сервере из
Очень рекомендую почитать релиз ноутс и официальный гайд по Env vars.
SVG Components
В экспериментальном режиме Astro поддерживает импорт SVG как компонентов Astro.
Но не спешите грустить, есть разные варианты взаимодействия. Можно как инлайнить, так и бандлить SVG в спрайты.
Из самого интересного:
Content Layer
Позволяет динамически грузить данные для страничек из любых источников. Например из notion или вообще через fetch() откуда угодно. Что круто, так это кеширование.
Когда я трогал beta версию, можно было руками перезапустить выгрузку данных, а потом быстро рендерить уже загруженную инфу.
Server Islands
Пререндерим всё статическое в .html, а динамику из бд можем грузить и рендерить на сервере. Причем только для небольших частей интерфейса.
Нормально реализованные идеи Next.js, без привязки к React!
astro:env
Ну и самая ожидаемая мной фича — безопасное извлечение переменных и секретов.
Описываем все переменные в виде zod-схемы, а затем импортируем из
astro:env/server или astro:env/client.Секреты доступны только на сервере из
astro:env/server, а вот переменные окружения доступны в любом окружении при импорте из astro:env/client.Очень рекомендую почитать релиз ноутс и официальный гайд по Env vars.
SVG Components
В экспериментальном режиме Astro поддерживает импорт SVG как компонентов Astro.
Но не спешите грустить, есть разные варианты взаимодействия. Можно как инлайнить, так и бандлить SVG в спрайты.
Astro
Astro 5.0 | Astro
Astro 5.0 brings exciting new features like the Astro Content Layer for seamless content loading from any source, and Server Islands for effortlessly combining static and dynamic personalized content.
👍26❤3
Сова пишет…
Личные консультации по effector, react и FSD! За почти 10 лет коммерческого опыта в веб-разработке, я насобирал внушительный опыт в разных технологиях. Хотя специализируюсь я в React + Effector, готов помочь решить очень разнообразные задачи и ответить на…
Давно не писал о том, что я делаю когда ко мне обращаются за помощью на личных консультациях.
С 2022 года провел 60+ часов консультаций, не очень много, по разным причинам, но это всегда интересное времяпровождение для меня.
Из интересного по моим логам:
Построение структуры фронтенд проектов.
Обсжудаем цели продукта, особенности команды, скопившееся легаси, технический стек, наличие свободного ресурса и исходя из этого строим план модернизации.
Иногда это введение инструментов контроля качества кода, иногда новые практики в команде, чаще настройка CI/CD, реже изменение архитектуры и дата-флоу.
Ревью кода и рекомендации.
Не редко приходят ребята с запросом поревьювить код, помочь улучшить фичу, задизайнить техническое решение, обсудить реализацию конкретного компонента в специфическом стеке.
В этом случае я выдаю рекомендации основанные на ситуации и опыте, вместе с литературой на-почитать.
React, Effector, FSD, Atomic-Router, Next.js
Конечно же, в основном приходят с вопросами по моему основному стеку. Как реализовать сложную задумку, какой архитектурный подход может лучше сработать, какие практики стоит рассмотреть, да и вообще взгляд на решение со стороны.
Я не часто использую Next.js, но приходится в нем разбираться, иногда запрашивая у клиента время на исследование.
Менторинг, личное развитие, управление временем.
Кроме технических штук, за 12+ лет работы в коммерции, пришлось перепробовать кучу разных практик по управлению своим временем, а также временем команды. Это тоже опыт, который можно из меня вытащить на консультациях.
Построить трек из списка навыков, необходимых современному разработчику, проверить собственные скиллы (я регулярно нанимаю людей в разные компании, могу поднатаскать), найти слабые места и придумать как их прокачать.
Может у вас есть задачи для меня, которые я еще не делал?
Или что-то из списка выше откликается?
В любом случае, приходите @sovasergey
С 2022 года провел 60+ часов консультаций, не очень много, по разным причинам, но это всегда интересное времяпровождение для меня.
Из интересного по моим логам:
Построение структуры фронтенд проектов.
Обсжудаем цели продукта, особенности команды, скопившееся легаси, технический стек, наличие свободного ресурса и исходя из этого строим план модернизации.
Иногда это введение инструментов контроля качества кода, иногда новые практики в команде, чаще настройка CI/CD, реже изменение архитектуры и дата-флоу.
Ревью кода и рекомендации.
Не редко приходят ребята с запросом поревьювить код, помочь улучшить фичу, задизайнить техническое решение, обсудить реализацию конкретного компонента в специфическом стеке.
В этом случае я выдаю рекомендации основанные на ситуации и опыте, вместе с литературой на-почитать.
React, Effector, FSD, Atomic-Router, Next.js
Конечно же, в основном приходят с вопросами по моему основному стеку. Как реализовать сложную задумку, какой архитектурный подход может лучше сработать, какие практики стоит рассмотреть, да и вообще взгляд на решение со стороны.
Я не часто использую Next.js, но приходится в нем разбираться, иногда запрашивая у клиента время на исследование.
Менторинг, личное развитие, управление временем.
Кроме технических штук, за 12+ лет работы в коммерции, пришлось перепробовать кучу разных практик по управлению своим временем, а также временем команды. Это тоже опыт, который можно из меня вытащить на консультациях.
Построить трек из списка навыков, необходимых современному разработчику, проверить собственные скиллы (я регулярно нанимаю людей в разные компании, могу поднатаскать), найти слабые места и придумать как их прокачать.
Может у вас есть задачи для меня, которые я еще не делал?
Или что-то из списка выше откликается?
В любом случае, приходите @sovasergey
👍25
difftastic
Это тулза для сравнения исходников через AST-деревья, вместо построчного и посимвольного.
По умолчанию, git воспринимает исходники как строки текста, поэтому перемещение, добавление врапперов или переименования выглядят слишком глобально.
Иногда тяжело понять, поменялась целиком строка или только пару переменных в ней, git подсветит всю строку.
Да, в git есть разные режимы сравнения, как и в VSCode/WebStorm, но они также не учитывают семантику языка.
difftastic исправляет этот недочет.
Его также можно настроить для использования по умолчанию.
Пока что главный минус — отсутствие плагина для VSCode/WebStorm. Но как минимум стоит попробовать его, чтобы понять разницу.
Это тулза для сравнения исходников через AST-деревья, вместо построчного и посимвольного.
По умолчанию, git воспринимает исходники как строки текста, поэтому перемещение, добавление врапперов или переименования выглядят слишком глобально.
Иногда тяжело понять, поменялась целиком строка или только пару переменных в ней, git подсветит всю строку.
Да, в git есть разные режимы сравнения, как и в VSCode/WebStorm, но они также не учитывают семантику языка.
difftastic исправляет этот недочет.
Его также можно настроить для использования по умолчанию.
Пока что главный минус — отсутствие плагина для VSCode/WebStorm. Но как минимум стоит попробовать его, чтобы понять разницу.
brew install difftastic
# ~/.gitconfig
[alias]
dl = -c diff.external=difft log -p --ext-diff
ds = -c diff.external=difft show --ext-diff
dft = -c diff.external=difft diff
[difftool]
prompt = false
[difftool "difftastic"]
cmd = difft "$MERGED" "$LOCAL" "abcdef1" "100644" "$REMOTE" "abcdef2" "100644"
[pager]
difftool = true
[diff]
external = difft
tool = difftastic
6👍31❤7🔥6🤔1
Готовьте ваши крипто кошельки
За ними пришел Гугл
https://blog.google/technology/research/google-willow-quantum-chip/
За ними пришел Гугл
https://blog.google/technology/research/google-willow-quantum-chip/
Google
Meet Willow, our state-of-the-art quantum chip
Our new quantum chip demonstrates error correction and performance that paves the way to a useful, large-scale quantum computer.
😁10👎7🔥3🤔2👍1
Две игры вышли в 2024 году:
STALKER Heart of Chornobyl — 153GB
Sons of the Forest — 9GB
Графоний и оптимизации сами сравнить можете.
Сталкер на днях получил крупный патч размером120GB .
STALKER Heart of Chornobyl — 153GB
Sons of the Forest — 9GB
Графоний и оптимизации сами сравнить можете.
Сталкер на днях получил крупный патч размером
😁26👎7🤯7👍2
Я участвую в программном комитете Podlodka React Crew!
Уже через пару месяцев будет конференция.
Поэтому предлагаю проголосовать за тему сезона по ссылке ниже
https://docs.google.com/forms/d/e/1FAIpQLSdkD0nx4U0IEoQbVnS6_FmRVJfpbiWCYsTbLkexZShTKVscJw/viewform
Кстати, среди проголосовавших до 17:00 по МСК 26 декабря ребята разыграют билет на новый сезон!
Уже через пару месяцев будет конференция.
Поэтому предлагаю проголосовать за тему сезона по ссылке ниже
https://docs.google.com/forms/d/e/1FAIpQLSdkD0nx4U0IEoQbVnS6_FmRVJfpbiWCYsTbLkexZShTKVscJw/viewform
Кстати, среди проголосовавших до 17:00 по МСК 26 декабря ребята разыграют билет на новый сезон!
🔥22👍10👎3