TGViewer
Channel Public Channel
Настоящий JavaScript

Настоящий JavaScript

@true_js

Тот самый канал по JavaScript.

Личный блог автора - @just_genych
По вопросам рекламы или разработки: @g_abashkin
Subscribers
5.89K
Photos
3K
Videos
8
Links
2.7K

Showing posts older than #3558 · Back to latest

Older Posts 20 shown
Post #3550 1.09K
⁣CSP, CORS и security headers — что фронтендер обязан понимать глубже

Принято считать, что безопасность — это зона бэкенда.
Фронтенд «просто отправляет запросы и рендерит UI».

На практике фронтенд напрямую влияет на то,
будет приложение безопасным или нет.

CORS — это не про «разрешить запрос»

CORS часто воспринимают как настройку:
«чтобы запросы не падали из браузера».

Но по сути это механизм, который говорит:
кто имеет право читать ответ.

Важно понимать:

👉 сервер может обработать запрос
👉 но браузер может не дать прочитать ответ

Именно поэтому:

👉 Access-Control-Allow-Origin: * — не «фикс», а потенциальная дыра
👉 credentials + wildcard — запрещённая комбинация


CORS — это про контроль доступа, а не про обход ошибок.


CSP — ваш последний рубеж

Content Security Policy — это защита от XSS,
даже если у вас уже есть уязвимость.

Пример:


Content-Security-Policy: default-src 'self'; script-src 'self'


Что это даёт:

👉 запрещает выполнение inline-скриптов
👉 блокирует загрузку скриптов с чужих доменов
👉 режет целый класс атак

Но есть нюанс.

Если CSP выглядит так:


script-src * 'unsafe-inline' 'unsafe-eval'



Это не защита. Это иллюзия.


Security headers, которые реально важны

👉 X-Content-Type-Options: nosniff
Браузер не пытается угадать тип файла. Меньше атак через подмену.

👉 X-Frame-Options / frame-ancestors
Защита от clickjacking.

👉 Strict-Transport-Security (HSTS)
Принудительный HTTPS. Без вариантов.

👉 Referrer-Policy
Контроль того, какие данные уходят при переходах.

Где фронтендер влияет напрямую

👉 какие скрипты подключаются
👉 есть ли inline JS
👉 используются ли eval-подобные вещи
👉 как работают сторонние виджеты
👉 как обрабатываются пользовательские данные


Можно иметь идеальный бэкенд и сломать всё на уровне UI.


Частая ошибка

«Мы включили CSP — значит всё ок».

Но:

👉 нет nonce / hash
👉 разрешены любые источники
👉 подключены сторонние скрипты без контроля


В итоге защита есть только на бумаге.


Главная мысль

CSP, CORS и заголовки — это не чекбокс в настройках.
Это часть архитектуры.


Если фронтенд не понимает, как они работают,
безопасность становится случайностью.
Post #3545 1.01K

Forwarded from xCode Journal

🖥 Появился тул, который сам подбирает скиллы для вашего ИИ-агента

Запускаешь npx autoskills, и он сканирует репозиторий: читает package.json и конфиги, определяет технологический стек и ставит нужные скиллы из проверенного списка.

Короче, сильно экономит время на ручной настройке и поиске.

✖️ xCode Journal
Post #3543 1.17K

Forwarded from xCode Journal

🐱 GitHub покидают разрабы и опенсорс проекты

Разработчик Митчелл Хашимото, создатель популярного эмулятора терминала Ghostty, переносит проект из-за проблем со стабильностью платформы.
«Я пользователь GitHub под номером 1299, присоединился в феврале 2008 года. Я заходил на GitHub почти каждый день в течение более 18 лет. Для меня никогда не было вопроса, куда размещать свои проекты: всегда GitHub. Мне очень грустно это говорить, но пришло время уходить», — пишет он.


✖️ xCode Journal
Post #3541 1.06K

Forwarded from xCode Journal

🖥 Программист решил ускорить возвращение в нулевые и создал Шакализатор сайтов 3000

Сервис отбрасывает любой современный ресурс в эпоху Web 1.0: он вырезает из HTML все современные стили, скрипты, сжимает картинки, добавляет кислотный фон, гифки и прочее. Самое забавное — ссылки внутри тоже переписываются, так что погружение будет полноценным. И да, проект опенсорс.
«Я посмотрел на эти робкие попытки регуляторов и подумал: а зачем нам эти полумеры? Если интернет всё равно замедляют и ломают, почему бы не возглавить этот процесс и не деградировать с ветерком?»


✖️ xCode Journal
  • 👍 4
Post #3540 1.07K
Карпатый написал 4 инструкции для Claude Code. Репа набрала 40к звёзд за пару дней

Скилл из четырёх файлов меняет поведение модели: больше планирования, меньше галлюцинаций, аккуратнее код, чаще самопроверка. Андрей формализовал собственный подход к работе с агентами и выложил на GitHub.

Раньше работа с агентом выглядела так: «попросил в чате, получил код, скопировал».

Теперь рабочий цикл другой:

👉 SKILLS.md фиксирует повторяющиеся паттерны: как пишутся миграции, как оформляются ошибки, какие соглашения по логированию
👉 AGENTS.md лежит рядом с кодом и описывает архитектуру директории: что здесь живёт, что нельзя трогать
👉 MCP подключает агента к вики, БД, API-докам через стандартный протокол

За полгода узкое место сместилось с возможностей модели на навыки разработчика. Скиллов нужно освоить много: SPEC-разработка, контекст-инжиниринг, Plan Mode, AGENTS.md под каждую директорию, мультиагентные пайплайны. Собрать всё это в рабочую систему самому займёт примерно год экспериментов.

Команда Naition.ai научит этому за 12 недель на своем онлайн-буткемпе.
Преподают практики из Google, Yandex Cloud, Сбера. 15 живых вебинаров по 3 часа: теория, разбор кейса, практика на своём коде:
• настраиваешь ИИ-окружение под свой стек — RAG, MCP, агенты, контекст
• начинаешь быстрее делать фичи — от идеи до внедрения с ИИ на каждом этапе
• собираешь набор ИИ-агентов, которые берут на себя часть задач (бек, фронт, аналитика, DevOps)
• и много другое!

Записаться

Старт: 5 мая.
По промокоду WEUSEJS — скидка 20%.

Бонус для участников первых когорт: 3 месяца в закрытом клубе после обучения.

Записаться

Команда также собрала бесплатную дорожную карту из 40+ концептов со ссылками на источники. По сути оглавление того, что сейчас составляет базовую инженерную грамотность для работы с AI.
Забрать роадмеп по ссылке
Post #3539 1.11K

Forwarded from xCode Journal

💸 Сооснователь GitHub поднял $17 млн на нового Git-клиента

Скотт Чакон считает, что классический Git УСТАРЕЛ И плохо работает в мире, где код пишут не только люди, но и ИИ-агенты. Поэтому он создал пару лет назад GitButler и теперь выкатил CLI-версию. Главная его идея — более удобный интерфейс и отсутствие классического переключения между ветками + параллельная работа.

Вообще внутри много прикольных фич — сразу видно, что разрабатывал не новичок

✖️ xCode Journal
Post #3534 2.03K
Секунда уверенности → полгода страданий
  • 😁 4
Post #3533 1.71K

Forwarded from xCode Journal

🥲 Резюме в IT официально мертво

Свежее исследование 4261 спеца подтвердило, что честность сегодня не кормит. Рынок сломан HR-фильтрами, и выживают на нем только накрутчики. Крутят все и всё:
— 66% опрошенных рисуют опыт. Мидлы делают это так же часто, как джуны, чтобы просто пробить стену из ATS-ботов;
— Без «подкрутки» цифр соискателей не зовут даже на скрининги, зато с нарисованным стажем люди залетают в бигтех и финтех на хорошие ЗП и успешно проходят испыталку;
— В 77% случаев работодатели вообще не вдупляют, что опыт фейковый. Служба безопасности ловит лишь 4%;
— Кандидаты массово используют нейросети для резюме, чтобы обмануть нейросети рекрутеров


✖️ xCode Journal
  • 👍 1
  • 👎 1
Post #3532 1.41K

Forwarded from Геныч.

Недавно решил разобраться с фичей skills в Claude Code. Если коротко, это инструмент, который пришел на смену кастомным slash-командам и значительно расширяет их возможности.

В процессе изучения нашел несколько интересных моментов:

- Генерация маркетингового контента:
Анализирует приложение и помогает писать посты для продвижения, например для Хабра.

- Подбор свободных доменов:
Проверяет доступность доменов по теме проекта и предлагает варианты.

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

- Улучшение фронтенда:
Помогает привести сгенерированный нейросетью фронтенд в более аккуратный и продакшен-подобный вид. Так как фронт это мое основное направление то эта штука это то что я протестил чуть больше. Разница в качестве генерируемого кода мне показалась довольно заметной.

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

👉 Геныч.
Post #3530 967

Forwarded from xCode Journal

🖥 Anthropic выпустили Code Review

Систему, которую в компании запускают почти на каждом PR. За последний год объём кода на инженера в Anthropic вырос примерно на 200%. При такой скорости неудивительно, что ревью стало узким местом.

Теперь Code Review автоматически проверяет PR: несколько ИИ-агентов параллельно ищут баги, перепроверяют результаты и ранжируют проблемы по серьёзности. Причем чем более объемным и сложным будет PR — тем больше агентов туда пойдет работать.

✖️ xCode Journal
Post #3529
Настоящий JavaScript pinned «📍 Авторский канал про вайбкодинг и разработку ИИ-агентов ➡️ Геныч.»
Post #3528 1.38K
Как одна строка CSS может сломать производительность вашего приложения

Введение
Небольшие изменения в CSS могут существенно повлиять на производительность веб-приложения. Одна строка кода способна замедлить загрузку страницы и ухудшить пользовательский опыт.

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

Неиспользуемые стили
Загрузка неиспользуемых CSS-правил увеличивает размер страницы и время ее загрузки. Исследования показывают, что средний сайт содержит около 37% неиспользуемого CSS. Это приводит к дополнительной нагрузке на браузер и замедляет рендеринг. Регулярный аудит и удаление неиспользуемых стилей помогают оптимизировать производительность. Подробнее об этом вы можете узнать в статье о скрытых налогах производительности.

Инлайн-стили
Использование инлайн-стилей увеличивает размер HTML-документа и препятствует кэшированию стилей браузером, что замедляет загрузку страниц. Кроме того, инлайн-стили усложняют поддержку и обновление кода. Рекомендуется использовать внешние таблицы стилей для улучшения производительности и удобства сопровождения. Ознакомьтесь с причинами, почему следует избегать инлайн-стилей.

Оптимизация CSS
Для повышения производительности следует минимизировать и объединять CSS-файлы, избегать глубокого вложения селекторов и использовать только необходимые стили. Инструменты, такие как PurgeCSS, помогают выявлять и удалять неиспользуемые CSS-правила, снижая нагрузку на браузер и ускоряя рендеринг страниц. Узнайте больше о решении каскадных проблем в больших проектах из этой статьи.

Факты
👉 Средний сайт содержит около 37% неиспользуемого CSS, что замедляет загрузку страниц.
👉 Сложные селекторы и глубокая вложенность усложняют обработку стилей браузером, замедляя рендеринг.

Итог
❗️ Даже одна строка CSS может существенно повлиять на производительность приложения. Регулярный аудит и оптимизация стилей необходимы для обеспечения быстрой и эффективной работы веб-приложений.

Источники
Освоение сложных CSS-селекторов — Avoiding Common Mistakes in CSS.
Анализ неиспользуемого CSS — The Hidden Performance Tax: How Unused CSS and JavaScript Slow Down Every Page.
Влияние инлайн-стилей — Why You Should Avoid Inline Styles in HTML.
Оптимизация каскадных проблем — Overcoming CSS Cascade Issues in Large Projects.
C-Sharpcorner Avoiding Common Mistakes in CSS In this article, we discussed CSS's common mistakes. Generally, beginners are doing a mistake just because of non of experience.
Post #3527 844

Forwarded from xCode Journal

😭 Гендерный разрыв в IT никуда не делся

Исследование Selecty и hh․ru показало: >200 тыс. рублей в месяц получают 51,5% мужчин и только 34,8% женщин. В тестировании этот порог пробивают 60% парней и 45% девушек, а в бэкенде высокие доходы лишь у 26,5% разработчиц.

Почему так? Мужчины чаще забирают руководящие посты и сеньорские грейды.

✖️ xCode Journal
  • ❤ 1
Post #3526 955
📍 Авторский канал про вайбкодинг и разработку ИИ-агентов

➡️ Геныч.
Post #3525 1.31K

Forwarded from xCode Journal

😎 Сеньор-разработчик перепрыгивает с созвона одной валютной удаленки на созвон другой валютной удаленки:

💥 xCode Journal
  • ❤ 4
  • 👍 1
Post #3519 1.71K

Forwarded from Frontender's notes [ru]

⛔️ Performance budget который все любят на словах и игнорят в жизни

Про performance budget говорят красиво. На созвонах кивают, в доках рисуют цифры, в презентациях всё зелёное. А потом проходит пара спринтов и внезапно выясняется, что бандл потолстел, LCP поплыл, а никто даже не заметил. Я такое видел не раз и почти всегда причина одна и та же.

✅ Как performance budget обычно выглядит в теории

На бумаге всё выглядит аккуратно и логично. Ограничения на размер бандла, контроль LCP, TTI и CLS, лимиты на количество запросов, ожидания по времени рендера. Кажется, что если есть цифры, значит есть и контроль. Но реальность быстро вносит свои правки.

❌ Почему budget умирает почти сразу

Самая частая ошибка в том, что budget вводят как набор чисел, а не как процесс. Написали JS не больше условных 200 KB и разошлись. Никто не проговорил, что делать если лимит превышен, кто за это отвечает и что важнее в конкретный момент новая фича или перф. В итоге цифры есть, а решений ноль.

Вторая боль это отсутствие автоматической проверки. Если budget не проверяется в CI, его просто не существует. Локально у всех всё быстро, а в проде внезапно плюс десятки килобайт и лишние секунды LCP. И самое грустное никто этого не поймал в моменте.

👏 Почти всегда побеждают фичи

Когда нужно выбирать между релизом и остановкой из за производительности, команда почти всегда идёт в сторону релиза. Performance это отложенная боль, а фича нужна прямо сейчас. Потом к этому возвращаются. Или не возвращаются.

Ещё одна проблема в том, что budget делают слишком общим. Один лимит на всё приложение выглядит просто, но работает плохо. Лендинг, дашборд и админка живут по разным правилам и ожиданиям. Но budget почему то часто одинаковый для всех.

📣 И финальный гвоздь в крышку гроба это отсутствие прозрачности

Когда лимит превышен, никто не может быстро ответить, чем именно мы его съели. Без понимания причин budget превращается в абстрактную цифру из дока.

⚙ Когда performance budget реально начинает работать

Он перестаёт быть про килобайты и становится про пользовательские метрики. Он проверяется автоматически через CI, Lighthouse или Web Vitals. Он разбит по страницам и сценариям, а не размазан по всему приложению. И самое важное есть чёткое правило, что делает команда если лимит превышен. Performance становится частью Definition of Done, а не красивым бонусом.


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

🚪 Frontender's notes
Older posts →
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →