Прежде чем писать некоторые новости, то хочется сделать к ним небольшие подводки, чтобы на них можно было ссылаться при обсуждении дальнейших новостей/записей. Так я буду уверен, что вы точно понимаете что я имею ввиду.

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

Реактивность - это свойство системы автоматически поддерживать себя относительно заданных правил. Правила могут быть как для входов, так и для выходов. И в зависимости от того на что рассчитаны правила, то реактивность можно разделить на: ориентированную на реактивное состояние, ориентированная на реактивные процессы(реакции).

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

a = 2
b = 5
c = a + b

что мы здесь видим? у нас есть состояние заданное 3мя ячейками: a/b/c. Если это императивный код, то изменение a/b не повлечет за собой обновление с. А вот для реактивной парадигмы если оказывается, что с перестал быть равен а + b. Если это произошло, то по сути мы нарушили заданные правила. Такая система не является реактивной

С другой стороны, если мы напишем что-то такое, чтобы обновить с:

a = 10
systemActualize()

то скорее всего внутри systemActulize произойдет нечто, что заставит обновиться и с. Только вот автоматизма в этом не особо много, так как мы должны вручную следить за обновлениями и вызывать эту функцию. Такая система тоже не является реактивной.

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

Это все о реактивном состоянии. Однако, важны и реактивные процессы, которые указывают как одни действия влекут за собой какие-то последствия. Они чуть сложнее. Проще всего их представить на знакомых большинству Event emitter-ах/Event Bus-ах. Те есть некоторая сущность на которую можно подписываться множеству слушателей, и ее можно триггерить. Только чаще всего подписываются не на какое-то событие, а вот прям на сам эффект триггера. Концепция простая, но невероятно мощная если вокруг нее накрутить сверху побольше "мясца". Те такая система будет реактивной, так как она будет автоматически преобразовывать "раздражители" в последствия. Важно, что реактивная система себя показывает в "реальном времени", те это не просто вызов функции. А как создание организма, которое будет реагировать на раздражители. Оставлю как основной пример такого подхода: Rx

Значит ли что если мы реализуем реактивное состояние, то исключаем реактивность процессов. Нет. Но чаще всего библиотеки сосредотачиваются на чем-то одном, а второй элемент оставляют побочным. Например, в Rx удобно описывать процессы, но вот работа с состояниями вызывает затруднения (а особенно, если мы хотим, чтобы код оставался производительным). Обратный пример это реактивная система Vue: в ней легко описывать данные и их соотношения, но вот процессы приходится писать весьма в императивном стиле, реактивные процессы задаются только для прослушивания изменений в данных. Однако, некоторые системы стараются быть одинаково удобны и для данных и для процессов. Такими примерами могут быть Reatom и Effector. (Если вам известны другие такие системы буду рад дополнить). Есть случаи, когда фреймворки просто оставляют 1 систему для данных, другую для процессов (например Angular).

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

PS. тут можно было бы оставить целую кучу ссылок на замечательные статьи от других авторов, но их так много, что это достоино отдельного поста

Если есть желание, то можете покидать в комментарии те, которые вы считаете наилучшими или полными по данной тематике

Сегодня расскажу про небольшой лайфхак. О котором просто несправедливо мало людей знают/применяют.

Часто полноценная реализация стилизации в браузере это неоптимальный выбор:
1) Вы не фронтендер и трогать CSS это последнее, что вам хочется делать(и я вас прекрасно пониманию), а накидать что-то на страничке надо
2) Вам нет смысла тратить на это много времени (напр в песочнице, при разработке PoC версий и тд)
3) Ставить полноценную библиотеку компонентов слишком запарно и не стоит того
4) да, даже накидывать подключать классы tailwind / bootstrap слишком муторно

А что-то +- адекватное все равно хочется (так как дефолтные стили браузера ну уж слишком никакие)

Какое решение? classless библиотеки стилей.
Происходит в них ровно то что написано: не пишите никаких классов для стилизации, только семантические теги. Да, просто пишите верстку, а библиотека сама делает все красивенько по мере возможности.

Вам не нужно учить такие библиотеки, макс слегка попривыкнуть к тому что в них реализовано. Вы просто подключаете 1 css-ник и накидываете фактически голый HTML. Конечно, полноценные сайты реализовать чисто на них будет сложновато, но как базовый стартер для чего-то минималистичного они просто прекрасно подойдут

Это экономит КУЧУ времени и позволяет не резать глаза, сосредоточившись на конкретной задаче которую вам надо реализовать.
Чтобы не мучаться с поиском таких решений есть вот такой репозиторий. Он активно пополняется различными вариантами и весьма подробен. Выбираете любую библиотеку на свой вкус и подключаете 1 строкой

Моим же фаворитом является PicoCSS (демка),
Если же вам привычен вид бутстрапа то обрабтите внимание на Holiday.css

PS. Если вы любите песочницы, то скорее всего вам будет полезно куда-то сохранить все равно минимальный пресет-стартер.
Можете сделать это в закладки / заметку / сниппет
Напр, для Vue playground вы можете подключить его так
В случае Vite и плейграундах основанных на нем быстрее всего закидывать в index.html


Будьте продуктивны и тратьте меньше времени на ненужные задачи!

Раз уже закинул инфу про ленивые стили, то теперь расскажу про вторую ультимативную фишку для скорости и простоты разработки: https://icones.js.org

На данный момент это поисковик по самой крупной на данный момент OpenSource базе иконок (их более 200 000).
Заходим, выбираем нужный пресет, натыкиваем опций и копируем/сохраняем как нам нравится

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

Можно пойти и серьезным путем встроив интеграцию себе прямо в сборщик благодаря unplugin-icons (советую отдельно разобраться с этим инструментом, так как он в целом предоставляет очень мощные опции для работы с иконками в проекте)
Тогда можно вообще не запариваться и писать вот такой код

import IconAccessibility from '~icons/carbon/accessibility'
import IconAccountBox from '~icons/mdi/account-box'

function App() {
  return (
    <div>
      <IconAccessibility />
      <IconAccountBox style={{ fontSize: '2em', color: 'red' }} />
    </div>
  )
}

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

Итак, уж не знаю в честь чего такой символизм, но в этот день нам всем вне зависимости от пола сделали большой подарок: Rolldown вышел в публичный доступ (репозиторий / сайт)!

Пояснения для тех кто не в теме:
На данный момент vite один из лучших, если не самый лучший, выбор сборщика для проектов в мире JS/TS. Однако он не был лишен заложенных архитектурных проблем:
- относительно медленный продакшен билд
- неконсистентная дев и прод сборка (так как сборщик для дев и прод сборки отличаются)
- проблемы с чрезмерной загрузкой ESM модулей по сети
- неприятные проблемы для SSR
- ограниченный контроль над разбиением на чанки
- отсутствует Module Federation из коробки (вариация кастомная для vite все-таки существует)

И вот Rolldown это решение призванное устранить часть этих проблем.
1) Оно будет написано на Rust, что даст решению высокую производительность
2) Оно заменит и esbuild и Rollup 1 собой
3) заменить собой часть внешнего туллинга в перспективе
4) Это НЕ ЗАМЕНА Vite, а замена для сердца Vite (esbuild + rollup -> rolldown)

Это будет означать новый рассвет для vite. Однако, решение пока находится в разработке. Но у него уже есть дорожная карта развития с которой можно ознакомиться
Из важного:
- Планируется полная совемстимость с Rollup
- Поддержка системы плагинов, в том числе на JS
- Тесная интеграция с oxc (интересно что покажет этот дует, учитывая что oxc стремится к полной самодостаточности)

Пока нигде не нашел каких-то обещаний по датам до полноценного выпуска и тем более до внедрения в Vite, но раз он вышел в OpenSource, то это становится лишь вопросом времени (моя ставка, что к концу года точно будут эксперементальные сборки vite с подкапотмным rolldown-ом)

PS. С праздником всех для кого сегодня это праздник 🥳🎉

Вообще не секрет, что Vue единственный популярный фронтенд-фреймворк за которым не стоит ни одна корпорация и Vue очень гордится этим (на самом деле Solid.js тоже может в эту категорию попасть, но ему нужно подрасти по популярности). Что же это значит? Что разработчики фреймворка сами вольны выбирать чем заниматься и определять вектор развития. Но это и значит, что финансы целиком зависят от поддержки других.

Существует и другой вектор получения прибыли: платные курсы и Vue вполне активно этот вектор развивает взаимодействуя с порталами vueschool и vuemastery.
Однако чтобы не вынуждать работяг тратить только свои кровные (ну и завлечь новых клиентов, конечно), несколько раз в году они делают акцию "бесплатные выходные". В это время все курсы доступны совершенно бесплатно. Их достаточно много и они хорошо покрывают всю экосистему целиком (там и Nuxt и Pinia и работа с firebase/vite/vitest и тд и тп так что даже опытные вьюшники найдут чем поживиться).

Вот 23-24 марта будет проводиться этот ивент вновь от vueschool.
Что нужно?
1) Регистрируемся на событие (если не успеете к началу, то ничего страшного, присоединиться во время ивента тоже можно)
2) Ждем указанных дат
3) Уходим в запой просмотра различных курсиков

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

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

Вот слежу я за последними тенденциями в мире JS. И не может не складываться ощущение, что курс весьма интересный наметился.

И вот мое мнение: если вы планируете погружаться в мир JS на уровень туллинга серьезно, то учите Rust. Я не собираюсь заниматься рекламой языка, ибо суть вообще не в этом. Тенденции уже достаточно много лет, что инструменты на JS для JS достаточно забагованные и медленные. И если первое решить системно сложновато. То второе поддается решением используя туллинга на компилируемом языке. Да JS может быть быстрым, но все больше и больше это не "good enough" в некоторых сценариях. И вот было 2 основных фаворита: Golang и Rust. Первый хорошо вписался в ряды фронтов/фуллстаков благодаря своей простоте и дружелюбности (сервера поднимать на гошке к своим фронтам не менее приятно). Но вот все равно инструменты все больше и больше кочуют в сторону Rust.

Главное: на Rust уже формируется полноценная экосистема для создания инструментов на Rust для JS. Примером служит как раз Rolldown, который показал, что oxc может стать прекрасным основанием для ваших инструментов. Я четко уверен, что тенденция будет развиваться как минимум ближайшие лет 5.

Поэтому если вы присматриваете себе какой-то дополнительный язык окромя JS(если вы JS-разработчик да и не только), то Rust будет замечательным вложением
Из плюсов: ниша все еще достаточно просторная, так что если вы хотите прогреметь в OpenSource, то Rust+JS позволят вам этого добиться при желании

Для тех кто заинтересовался оставлю чуточку информации: лучший способ изучение Rust это замечательный rustbook (ru). А на сайте можно ознакомиться с другими книгами для различных задач в Rust.

PS. Сам я тоже начал только вкатываться в данный язык. Поэтому если есть какие-то ресурсы позволяющие следить за жизнью Rust(подкасты, дайджесты, сайты и тп), то буду благодарен им в комментах

Итак сегодня 12 марта. Что это значит? А значит, что обманывать метрики в Core Web Vitals станет сложнее (да-да не удивляйтесь если у вас упадут в скором времени циферки в Lighthouse).

Что же там такого произошло? А все достаточно просто: одну метрику(FID) признают устаревшей, а новую метрику(INP) наоборот добавят.
А причина изменений проста: FID слишком легко подделывалась. Напомню, что FID это первый момент, когда можно будет впервые повзаимодействовать с контентом на сайте. Что же делали люди? Просто откладывали часть вычислений на момент после вычислений FID, в итоге и циферки красивые и директора довольные.

Сейчас на смену ей приходит метрика которая больше расчитана на общий пользовательский опыт работы со страницей: плавность скролла, скорость отклика на кнопках и тп. Поэтому если вам важны высокие метрики лучше ознакомиться получше с рекомендациями от google. Там целый раздел посвящен теперь только метрике INP(внимание в левую часть сайта, там целая куча ссылок по различным вопросам).

Как сильно изменится от этого выдача в поисковиках большой вопрос. Но вот директора/менеджеры могут прибежать с "у нас упали показатели Lightouse!!". Так что будьте готовы к такому повороту событий.

Посмотреть показатели можно тут: https://pagespeed.web.dev/?hl=ru

Раз уж подняли тему производительности, то вчера было еще одно важное событие в мире web perf-а. Под началом команды WebKit команды других браузеров (Google Chrome / Mozilla / Edge) и даже Intel объединились для прокачки бенчмарка для браузеров Speedometer 3,0.

1) Были улучшены способы замеры для более честной оценки производительности браузеров (подробнее можно ознакомиться в статье пункт Improved Test Harness)
2) Сместили очки: с предыдущей школой результаты могли улетать за 500. Теперь норма в 20-30 пунктах
3) Для всех популярных фреймворков на данный момент добавлены демки с замерами
4) Для приложения TODO сделаны 2 версии: с простым DOM и специально усложненным, чтобы лучше оценить как браузер с фреймворками справляются
5) 2 демки приложений имитирующих новостной сайт на Next и Nuxt
6) Несколько демок для визуализации данных (как D3 так и chart.js)
7) Из любопытного к бенчу добавлена демка с WYSIWYG-редактором

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

Так же в репе замечено что уже многое запланировано на 4-ую версию и даже 3.1

Хех. апрель выдастся жарким :D

Чтобы не мучаться придумывая 3 доклада разом, то на Стачку поедет переосмысление доклада с UfaDevConf-а: JS которого нет

Поговорим о уровнях погружения в язык и какие есть особенности у этих этапов

А эта конфа: Стачка. В городе Ульяновск 12-13 апреля. Буквально через неделю после нее уже лететь на Holy.js

Если раньше шутили что фронтенд фреймворки растут как грибы после дождя, то теперь это же можно сказать про рантаймы для JS. Чувствуется уже усталость народа от node.js, все так и норовят от него уйти (как и от v8 в частности).

Сейчас я хочу поведать о релизе нового рантайма WinterJS. Чем он примечателен? Да, это очередной Blazing-fast рантайм для JS/WASM на Rust на основе движка SpiderMonkey (это тот что у мозиллы под капотом); при этом заявлено что он WinterCG совместимый.

Начну с WinterCG. Это рабочая группа на основе объединения множества компаний, которые хотят обеспечивать совместимое API для рантаймов вне браузера, но разработанное для веба. Те есть спека в которой описано поведение fetch в браузерах, но как быть node.js/bun/deno и другим решениям? А они тоже пишут свои спеки относительно спецификаций Web-платформы, как для того же fetch. Таким образом разработчикам библиотек проще поддерживать решения которые будут совместимы между рантаймами, да и в целом разработчикам жизнь заметно упрощается, когда есть стандартизация. Ну вот WinterCG совместимая -- та что соответствует спецификациям этой рабочей группы.
Важный момент WinterCG не имеет прямого отношения к WinterJS!

Есть еще одна не неменее интересная тема, которая достойна отдельного разбора: WinterJS может быть собрана полностью в WASM и работать через WASIX. Это расширение для WASI. Так, не пугаться. Давайте по порядку. Начнем кратко с WASM. WASM - это особый формат для стековой виртуальной машины, которая почти идет придатком к JS рантаймам (JS движки также обеспечивают поддержку WASM). Но этот бинарный формат беззубый, те сам по себе у него нет никакого I/O, работы с системой и тп. Для того чтобы вооружить WASM и был инициирован проект WASI (его разрабатывает подгруппа WebAssembly CG, которая отвечает и за WASM). Ок, а WASIX это еще дополнительное расширение вокруг WASI, но уже уже от wasmer-а (Wasmer это рантайм для WASM приложений).

Итак, пока все не вылетело из головы. Мы имеем новый рнтайм от команды Wasmer и он обещает быть чертовски быстрым (до 150к запросов в секунду). Он направлен на облачные решения. Совместим с основными Web фреймворками (пункт Compatibility with existing Web frameworks. там же демки и стартеры).

Завоюет ли он какую-то популярность сказать сложно, но людям точно пора отвыкать что JS вне браузера = только Node.js. Уж больно много альтернатив повылезало для специфичных задач. Планирую подробнее подрасписать какие вообще сейчас есть решения и для чего они, ибо запутаться в них уже ой как не сложно. Точно также можно сказать и про v8: JS это не обязательно V8. Рантаймы активно пробуют другие решения: SpiderMonkey, JavaScriptCore. QuickJS etс...

Ух, подготовка к Holy.js в самом разгаре. Напоминаю, что тема будет кастомные рендереры во Vue. Тема очень интересная.
И я решил проверить, а что если отрендерить Vue приложение в React приложение? Те это не просто средендерить Vue в элемент и его использовать в React. А выходом Vue являются именно VNode от реакта

ОНО РАБОТАЕТ! Сижу, играюсь и радуюсь как ребенок :D

Финальная цель это запустить Vue приложение на Next / ReactNative / Expo

Те попытаться реализовать полный интероп из Vue в React.

Поиграться можно будет чуть позже

Больше стандартов богу стандартов! В недавней новости вы скорее всего впервые столкнулись с WinterCG(Web-interoperable Runtimes Community Group). Но вот буквально вчера анонсирована новая рабочая группа: OCWG(github).

Чем же займется эта группа? А тут надо отступить к другой новости, которую я решил не публиковать. Есть такой продукт Obsidian. Он нужен для заметок и прочего markdown-based контента с учетом, что это все на local-first(те первична работа от локальных файлов если упрощать). И вот там был особый синтаксис для хранения данных их WYSIWYG-редактора контента в свободной форме. Далее они решили, что этот формат стоит доработать и опубликовать как публичную спеку: JSON Canvas. Через нее можно описывать элементы на бесконечном холсте.

Казалось бы на этом можно и закончить, но инициативу подхватили другие продукты реализующие идеи бесконечных полотен такие как: tldraw, excalidraw, stately.ai, kinopio, dxos и другие. И будут они заниматься разработкой и распространением общего стандарта для приложений с функционалом бесконечного холста. Их великое множество и есть целый сайт посвященный таким приложениям. Однако, они не стали говорить, что JSON Canvas это их формат, вместо этого они обещают пойти еще дальше. Против JSON Canvas они ничего не имеют, но они хотят смотреть шире и быть группой по решению общих проблем для форматов описания бесконечных холстов.

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

Ожидаемые результаты работы группы:
- Разработка общего базового формата на основе принципов команды.
- Расширение формата для широкого спектра инструментов.
- Возможность синхронизации в реальном времени между несколькими полотнами.
- Создание тестового стенда сродни CSS Acid Tests.
- Предложение по улучшению спецификации JSON Canvas.

Формат встреч будет публичный(?) каждые 2 недели. Для обсуждения идей есть Discord, куда зовут всех заинтересованных.

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

3 ** 3

JS !== v8

Последнее время особенно, когда постоянно появляются новые рантаймы использующие всевозможные движки для исполнения JS. И чтобы знания не были ограничены лишь самым популярным движком v8, я предлагаю объединить усилия в сборе различной информации о всех движках и рантаймах. Интересует в данном случае больше глубокое их изучение, а не поверхностное использование.

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

Поэтому я набросал черновик проекта JSE(JavaScript Engines). В рамках которого и хотелось бы собрать всю полезную информацию для изучения.
Поскольку проект очень молодой, то любая помощь:
- перевод
- дополнения
- предложения
- запросы
и тп будут восприняты очень тепло и радостно

Я верю, что совместными усилиями мы сможем преодолеть дефицит информации по движкам и упростить их изучение!

Такс, для frontend-разработчиков caniuse не пустой звук. Но что делать если речь идет о рантаймах отличных от браузера коих сейчас расплодилось немало?

Ну тут к нам и приходит на помощь новый инструмент runtime-compat(Github) от unjs,
runtime-compat выдает нам таблицу современных рантаймов JS-а и их поддержку отдельных фичей. Также имеется дополнительный фильтр по совместимости со спецификацией от WinterCG о которой я писал ранее. Несмотря на схожесть с тестами в браузере, тесты для рантаймов несколько сложнее, так как часто требуется индивидуальный подход для вызова функионала того или иного рантайма. За основу были взяты тесты для браузеров в mdn-bcd-collector. Также стоит отметить, что тесты во многом автосгенерированы и могут быть несколько неточными по этой причине.

Я бы хотел рассказать тут еще подробнее и про unjs. Но это заслуживает отдельного поста, так как нужно будет рассуждать на тему философии развития экосистем фреймворков

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

Состоялся крупный релиз. Vitepress наконец-то получил свою долгожданную версию 1,0,0 (и все это после 45 release candidate).

Что это за фрукт? Изначально продукт назывался Vuepress и был предназначен для генерации статики в экосистеме Vue. Стоит отметить, что несмотря на заявленный SSG для Vue, люди оставляют неоднозначные отзывы про такое использование. а вот для контентных сайтов/документаций он подходит прямо отлично. Легко встроить в любой уже существующий проект, чтобы дать ему документацию.

Как можно понять, то основной движок при всем теперь: vite, а работает внутри как фреймворк все еще vue. Контент пишется на markdown c интеграцией Vue компонентов прямо внутри. Это действительно удобно, так как Vue полностью встраивается в markdown так как его синтаксис шаблонов полностью поддерживается парсерами HTML. Все докуменетации во Vue экосистеме написаны именно с использованием Vitepress(исключение экосистема Nuxt, но про нее позже).

На самом деле все больше в интернете вижу различных сайтов использующих Vitepress, даже если они никак не связаны с Vue, например сайт Hono или Mermaid.

В целом я сам использую переодически Vitepress и всем советую хотя бы попробовать познакомиться с ним. А команду поздравляю с действительно долгожданным релизом

Такс, особо не расслабляемся, сразу ходом пошел 1-ый release candidate у SolidStart(старая дока) и выход из статуса beta-версии. Это решение из разряда мета-фреймворков. Те нечто схожее по смыслу с Next.js(React) / Nuxt(Vue) / Analog(неофициальное решение для Angular) / SvelteKit(Svelte) но теперь, как можно долгадаться, для Solid.js.

Нам сходу заявляют о 3-ех режимах работы CSR(client-side rendering), SSR(server-side rendering), SSG(static site generator), те все по классике. В комплекте идут пресеты для развертывания на различных решениях: Netlify, Vercel, AWS, и Cloudflare.

Никого уже не удивить и роутинге основанном на файлах в папке routes. Отдельно выделены API Routes, для серверного API и они тоже работают на основе файлового роутинга.

"use client"/"use server" тоже идут в комплекте. Те опробовать мощь server functions можно и в нем.

Что у нас под капотом? SolidStart основан на Vinxi + Vite. Vinxi это по своей сути движок/набор примитивов для помощи в создании полноценных FullStack фреймворков на JS. Vinxi же держит под капотом Nitro, что достаточно любопытно. Nitro это решение для написания веб серверов со спецификой мета-фреймворков. Разрабатывается же Nitro как часть экосистемы unjs для нужд Nuxt-а. Нитро в свою очередь является надстройкой над h3. h3 - тоже часть экосистемы unjs и выполняет функцию высокопроизводительного аналога express-like решения для серверного фреймворка.

В остальном по тому что я вижу (я не разрабатывал конкретно на SolidStart еще), то решение пока сыроватое и ему нужно дать время окрепнуть и обрасти жирком.

Мне нравится Solid.js и я желаю этому фреймворку удачного развития и покорения рынка на смену React.js :D
Теперь ждем действительно первый релиз 1,0,0

А я напоминаю что сегодня у вас еще есть время чтоб проглядеть курсики по Vue которые вам интересны от vueschool.

И нет, это не реклама, а рекомендация от себя, так как часто спрашивают, какие брать курсы по Vue.
Так почему бы не воспользоваться шансом сделать это бесплатно?

Antfu вновь доказывает, что DX в мире JS-туллинга можно еще развивать и развивать.
Если вы его еще не знаете, то самое время познакомиться, но для начала о его новом решении: eslint-typegen

Кратко: решает проблему с отсутствием типизации в конфигах ESlint на основе кодогенерации. Те при первом прогоне он создает .d.ts файл основываясь на переданных правилах ESlint.

Имеется 2 варианта использовать:
- кодогенератор на основе переданного конфига (основной)
- Low Level API с преобразованием к строке для последующей записи в нужное место

Работает все это чудо основываясь на JSON Schema, которая указывается у правил в ESlint. Далее прогоняется через json-schema-to-typescript и далее небольшие трансформации для приведения к нужному виду. Готово. Общий объем библиотеки менее 300 строк кода, так что можно вполне изучить его за пару часов.

Из любопытного:
- если вы пользуетесь @antfu/eslint-config, то вам можно это дело не подключать, все уже настроено из коробки
- автором идеи он называет @Shinigami92

Если вас давно раздражает, что никаких подсказок в ESlint толком нет, то вот способ это исправить