SvelteJS *

Недавно я заметил такую штуку: знакомые фрилансеры и маленькие студии разработки частенько теряют заказы, да и организовано у них всё так себе. Сообщения находятся то в одном сайте, то в другом, программисты в Discord сервере, заказчики и прогрев в Telegram, но при этом ещё надо в какую‑то CRM заходить и там ещё что‑то тыкать щёлкать. В общем — мест много, запутанно всё и не удобно.

Подумал: «А что если сделать CRM, которая работает ИЗ телеграма?» Клиент отправляет заказ боту, менеджеры видят в веб‑интерфейсе, программисты предлагают цены, все получают уведомления. Всего два места, но при этом заказчику вообще не надо об этом думать, он в телеграмме, там где уже зарегистрирован. Красиво же?

И я начал.

React — самый популярный фреймворк среди фронтенд‑разработчиков. Его подходы к разработке приложений часто воспринимаются как единственные правильные. Но что, если такие «стандарты» — это не необходимость, а вредная привычка, ломающая Developer Experience?

В статье разберем типичные проблемы Developer Experience в React: избыточный бойлерплейт, сложность управления состоянием и неочевидные оптимизации производительности. Покажем, как эти же задачи решаются в Svelte и обсудим, как смена фреймворка может упростить разработку.

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

Даже если вы никогда не заглядывали «под капот» фреймворков, Svelte 5 — отличный повод это сделать. Вместо сухих теорий мы шаг за шагом разберём, как привычный HTML-подобный код Svelte превращается в быстрый JavaScript, способный работать без лишнего балласта. Автор статьи, Тан Ли Хау из сообщества Svelte, показывает этот процесс на простых примерах, так что вы сможете буквально «скомпилировать» Svelte у себя в голове и понять, что на самом деле делает ваш код.

Надоел Pinokio? Мне тоже. Популярный установщик для нейросетей оказался медленным, тяжеловесным и, что самое страшное, — закрытым "котом в мешке". Я заглянул под капот, ужаснулся и за пару вечеров написал свою альтернативу — PortableSource. Внутри статьи — полное разоблачение Pinokio с доказательствами и рассказ о создании по-настоящему портативного и честного инструмента.

Всем привет! Меня зовут Владимир Глебовец, также известный в среде юридического сообщества, как LawCoder. С 2007 года я работаю юристом, а с 2018 в свободное от работы время, программирую инструменты, которые потом использую в юридической работе. Обычно я пишу заметки на VC и в телеграме, а вот писать на Хабр не решался, т.к. ничего полезного для «трушных» программистов я написать не мог, ибо мой уровень соответствует понятию Low Coding, каламбур из которого (Low‑Law) собственно и дал название моему блогу об автоматизации юридических процессов.

Так зачем же тогда я пришел на Хабр сейчас? Научился программировать, поверил в себя и решил огрести в комментариях? Нет, за последние три года, я пользуясь ЛЛМ, программируя в режиме вайб‑кодинга, растерял и без того слабые навыки программирования. Может быть решил прорекламировать свой блог? Тоже нет, здесь нет моей целевой аудитории, да и я собственно его недавно официально даже на паузу поставил, потеряв к ведению блога интерес.

Пришел я сюда, с желанием проверить одну гипотезу, возможно Хабр поможет мне её подтвердить или опровергнуть. При этом для меня это ситуация win‑win, т.к. любой результат меня устроит.

С этой статьи я начну цикл материалов, посвященных базовым концепциям реактивности, основанных на идеях и примерах, которые подробно изложил автор SolidJS, Райан Карниато (Ryan Carniato), в своем блоге. Наша цель — разобрать фундаментальные принципы, лежащие в основе реактивных систем, и показать их применимость в различных контекстах.

После почти 18 месяцев разработки, включающей тысячи коммитов от десятков участников, Svelte 5 наконец‑то стабилен.

Это самый значительный релиз в истории проекта. Svelte 5 — это полная переработка: ваши приложения станут быстрее, меньше и надежнее. Вы сможете писать более последовательный и идиоматичный код. Новичкам в фреймворке предстоит изучить меньше материала.

Здравствуйте :)

Коротко о чем тут, чтобы вы могли понять нужно ли оно вам или нет.

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

Материал может быть полезен как для новичков, так и для более опытных.

Примеры будут на React и Effector, но это не важно, потому что тут важна идея, а не реализация. К тому же это везде будет примерно одинаково выглядеть.В конце будут так же ссылки на примеры с svelte + effector и react + redux thunk

Привет, Хабр! В этом посте делюсь опытом разработки на Svelte, демонстрируя это на моем пет-проекте.

Код проекта: GitHub
Лайв демо: ivan-sem.com

Сталкивались ли вы с проблемой возникновения багов из-за пересечения включенных фичей в приложении? Или, возможно, была необходимость одновременно проводить большое число A/B-экспериментов в одном компоненте? 

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

Меня зовут Денис Стасьев. В этой статье расскажу о том, как мы внедряли машину состояний в одном из компонентов главной страницы Mail.ru — блоке новостей, что получили на выходе и ещё подробнее о том, почему в итоге остановились на XState.

В 2019 году Svelte 3 превратил JavaScript в реактивный язык. Svelte - это фреймворк для создания веб-интерфейса, который использует компилятор для превращения декларативного кода компонентов в такой...

Приветствую всех. Уже как неделю я переписываю свой проект, который был на Vue options api с использованием Quasar и перевожу его на Svelte-Sveltkit-DaisyUI. Скажу сразу, он мне очень понравился, особенно в если учитывать что Vue composition api стал больше похож на React, нежели чем на самого себя. Складывается впечатление что Svelte это то к чему должен был прийти Vue, но он пришел к реакту))) (ты должен был бороться...)

Итак, тот код, который я писал на вью(вуй в простонародье) 10 месяцев на свелт был написан за 9 дней, и то успел добавить дополнительные функции. Кое-что еще не реализовано, но это легкая часть, которая займет дня 3-4, не больше. Затем привязка к бэкенду и тестирование и через 2-3 недели все должно быть в целом готово. Справедливости ради стоит отметить что не все время из этих 10 месяцев было использовано на написание кода. Половина времени было потрачено на безрезультатные попытки(пытки) написать бэкенд самому. Прыгал с одной технологии на другую, но в основном пытался(пытал себя) написать на фшарп. Ничего не вышло, перешел на ноду-экспресс. Кое-что вышло, но в процессе написания понял что бэк не мое. Один бэкендер говорил что работа бэкендера это как 8 часов решать "судоку" на работе, а в остальное время решать судоку для отдыха. Полностью с этим согласен. Главное что вовремя осознал свою неспособность писать бэкенд, а заодно и нелюбовь решать судоку. Хотя когда был в школе любил, вероятно и бэк в то время зашел бы, но не факт. Отныне, если когда-нибудь я буду писать бэк для чего-то, то буду использовать лишь готовые вещи вроде strapi или directus.

Статья рассчитана на начинающих программистов, уже знакомых с git, html/css, typescript и nodejs. В статье будет много кода и мало текста - все, как вы любите - так что приготовьтесь поработать. Некоторые места в коде я прокомментирую, чтобы облегчить вам его понимание. Конечно, для разработки игр существуют и более подходящие специализированные инструменты, нежели фронтенд-фреймворк общего назначения Svelte, но, в демонстрационно-учебных целях, почему бы и нет?..

Я решил попробовать использовать ChatGPT для создания игр и хотел выбрать что-то простое, что можно сделать за несколько вечеров. В итоге, в сотрудничестве с ChatGPT, мы пришли к идее пошагового рогалика, где основной механикой является бросок кубика. Финальный результат можно посмотреть здесь https://dicequest.vercel.app/

Процесс разработки под катом

Эта статья рассчитана на Spring Boot разработчиков, желающих пощупать мир современного фронтенда. Я потратил некоторое количество времени на поиск наиболее приличного фреймворка и мой выбор пал на Svelte. Почему именно он, а не React или Vue? Лучше всего на этот вопрос ответит главная страница фреймворка, а я выделю главные его особенности.

Разработчик из консалтинговой компании в области разработки This Dot Labs рассказывает, как использовать canvas в Svelte и как превратить многословный API Canvas в краткий, более декларативный. Подробности — к старту нашего курса по фронтенду.

В этой статье рассказывается о том, как внедрить аутентификацию в ваш SvelteKit проект. Это будет JWT аутентификация с использованием refresh токенов для дополнительной безопасности. Мы будем использовать Supabase в качестве базы данных (PostgreSQL), но основы должны быть теми же.

Привет, Хабр! В этой статье хочу поделиться с вами историей о проекте носимой электронике, в примере кепки с эквалайзером, бегущей строкой и эффектами.

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

Аккордеон имеет 34 кнопки со стороны высоких частот и 12 кнопок со стороны басов. В отличие от фортепианного аккордеона, который имеет такое же логическое хроматическое расположение, как и фортепиано, у диатонического аккордеона просто набор кнопок, и я действительно не знал, с чего начать. Кроме того, каждая нота отличается независимо от того, вытягиваете ли вы меха или вталкиваете их, поэтому на самом деле на стороне высоких частот 68 нот (хотя некоторые из них повторяются). Кроме того, как я думаю, вы знаете, аккордеоны громкие. Очень громкие. Чтобы сильно не злить соседей, и узнать, как работает компоновка этой коробки, я решил сделать маленькое веб-приложение.

Одна из моих работ связана с отлаживанием протоколов общения теплосчётчиков для удалённого снятия показаний. Чаще всего теплосчётчик даже не мой, а находится у клиента на объекте, поэтому я подключаю его через GPRS-терминал к какой-либо своей сетевой машине, где поднят TCP сервер откуда посылаю байтики и смотрю, что мне ответит теплосчётчик. Посылать байты с консоли можно, но не очень удобно. Есть ряд приложений с которыми этот процесс упрощается, но я решил сделать себе в помощь специальный TCP сервер в виде Node-приложения с Web-интерфейсом, созданном с помощью фреймворка Malina.js.

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