Под конец прошлого года, по ряду причин, ESLint отказались от дальнейшей поддержки и развития стилистических правил. А тема, как по мне, несправедливо осталась в тени. Давайте разберемся, почему так произошло и какие изменения нас ждут на поприще статического анализа и форматирования кода.
Здравствуйте дорогие читатели.
В статье делюсь опытом создания расширения для Chromium и Google Chrome браузера.
Причиной для создания расширения послужило отсутствие функции сохранения результатов записей в своём облаке и удобство этого процесса.
Раньше я пользовался «условно бесплатными расширениями и программами для записи скринкастов», но в какой-то момент некоторые из них стали платными, и их удобства сошли на “нет”. А в некоторых оставались вопросы к безопасности данных и сложности с оплатой.
Возможно вы скажите - зачем мне расширение для браузера?! Ведь я могу взять ffmpeg с x11grab, приправить всё это bash-скриптом с использованием curl, и отправлять результаты в облако одной лишь командой в терминале! И возможно быстренько "перенесу" это решение под все операционные системы! И вы будете правы, но решение получится сложным. А если у нас есть под рукой браузер, то воспользуемся его возможностями (да, это странно - браузер для просмотра HTML-страничек, который записывает ваш экран).
Ссылка на готовое решение под катом.
Привет!
Продолжаем создавать браузерную игру с использованием чистого JavaScript и элемента Canvas. Добавляем графику, вращения, гравитацию и адаптируем игру для мобильных устройств.
Привет, Хабр!
В разработке часто возникают ситуации, когда точность типов и нежелание допускать неясности в коде становятся первостепенными задачами. В таких случаях, разработчикам приходится искать инструменты, предоставляющие максимальную ясность и строгость в определении данных. Один из таких инструментов — ключевое слово as const. В данной статье мы рассмотрим, как as const может повысить уровень строгости и предсказуемости, а также рассмотрим практические примеры его использования для создания неизменяемых и точных типов.
Привет всем. Меня зовут Артурас, я пишу на Javascript. Полтора года назад я уволился из оффшорной компании и решил написать свой движок для браузерных 2d игр. Сегодня - делюсь результатами.
Фронтенд-разработка — это как собирать лего без инструкции: иногда весело и творчески, но порой ты забираешься на кровать и кричишь: «*@#%*, да где же этот пропавший блок?!»
Каждый новый проект во фронтенде — это как уникальный набор лего, и ты никогда не знаешь, какие интересные вызовы подкинет он на этот раз.
В этой статье, опираясь на личный опыт, я расскажу, что такое современный фронтенд, какие задачи решают фронтендеры и что вообще происходит в мире фронтенда.
Одной из интересных возможностей пакета typescript является то, что он содержит API для генерации TypeScript-кода, а также парсер для работы с написанным на TypeScript кодом. Кодогенерация часто используется для автоматического создания типов для работы с http api (типизация тела запроса, ответа, query параметров и тд.). В npm есть модули, генерирующие сервисы для работы с api на основе openapi, graphQl схем и тому подобное, и обычно возможностей существующих модулей хватает для решения большей части задач.
Но иногда возникает потребность расширить имеющийся интерфейс или даже написать свою кастомную реализацию. В этой статье мы рассмотрим основные принципы работы с инструментами для генерации и парсинга typescript кода, а так же некоторые подводные камни, на которые я наткнулся при работе с ним.
Сегодня я расскажу про hippotable — удобный инструмент для анализа данных. Мне часто нужно поковыряться в датасете среднего размера (1–100 Мб), чтобы ответить на довольно простые вопросы. Ни один из существующих инструментов (bash, google sheets, jupyter + pandas) не показался мне особо подходящим для такой задачи, и я... решил сделать свой! Хотел поделиться результатом, показать пару интересных JS-инструментов для обработки и отображения данных, и рассказать, как дальше планирую развивать продукт. Запрыгивайте, будет интересно.
Привет, Хабр! Я Софья, фронтенд-разработчик в одном из департаментов Тинькофф. Из года в год наша большая фронтенд-команда растет, ставит эксперименты и обменивается опытом. Уходящий год богат на достижения, поэтому мы решили поделиться статьями, докладами и находками для командной работы. Несем все самое полезное, что получилось запустить, внедрить, написать и подготовить.
Друзья, всем привет! Меня зовут Игорь Карелин, я frontend-разработчик в компании Домклик. Недавно стал общедоступен новый линтер «Oxlint», основанный на языке программирования Rust, и многие эксперты высоко оценили его. Какие преимущества Oxlint предоставляет по сравнению со своим предшественником ESLint?
Hello world!
На днях я прочитал статью о WebTransport API как будущей альтернативе или даже замене WebSockets. Мне стало интересно, что это такое и с чем его едят. Давайте разбираться вместе.
Заканчиваются рабочие дни уходящего года, а значит, самое время подводить итоги наших трудов. За 2023 год у проекта Taiga UI появилось более пятидесяти релизов, больше двух тысяч вмерженных PR-ов и свыше пятисот закрытых issue.
Taiga UI — это огромный Angular UI Kit, который активно используется в сотне продуктов компании Тинькофф и популярен за ее пределами. Разработка проекта много лет идет в Open Source, собирая свою аудиторию по всему миру.
Продолжу ежегодную традицию и напомню пользователям библиотек о самых интересных изменениях за последний год.
В статье Глубокий JS. В память и типах и данных мы говорили о том, как выглядит структура переменной каждого конкретного типа в памяти движка V8. В этой статье предлагаю теперь рассмотреть, где именно эти переменные хранятся и каким образом попадают в память.
Речь пойдет об Абстрактном Синтаксическом Дереве (AST), типах переменных, областях видимости и выделении памяти в стэке и куче.
Всем привет! Меня зовут Леша, я фронтенд-разработчик. Крашу кнопочки, пишу js скрипты, веду канал в TG https://t.me/frontend_tales (подписывайтесь, стараюсь выкладывать полезный материал).
В этой статье хотел бы поделиться с вами лайфхаками JavaScript, которые, возможно, помогут вам понять тонкости языка и улучшить ваш код. В общем, статья рассчитана на джуниоров и мидлов, сеньорам возможно будет скучно, но рады всем. Начнем!
Сложность алгоритмов - это ключевой аспект при проектировании и создании веб-приложений, особенно при работе с большим объемом данных или выполнении вычислительно сложных операций. Понимание, как оценивать сложность алгоритмов, помогает принимать обоснованные решения в выборе алгоритмов и структур данных, а также оптимизировать производительность своих приложений.
Сейчас мы рассмотрим, почему знание сложности алгоритмов является важным навыком для разработчика, какие методы используются для оценки сложности, и какие практические применения можно найти для этого знания при создании веб-приложений. На тему сложности алгоритмов часто задаются вопросы на техническом собеседовании. Поэтому я настоятельно рекомендую не пропускать это видео.
Я написал своё первое одностраничное веб-приложение на Javascript в 2005 году, сразу после того, как узнал о XMLHttpRequest и до появления серьёзных фреймворков. Я оставил профессиональную веб-разработку примерно в 2009 году (а начал её в 1997 году с WebObjects), а последний десяток лет своей карьеры занимался мобильными.
Сегодня я смотрю на мир веб-разработки, и меня поражает его безумие. Существует так много фреймворков для веба, и каждый день появляются новые. Для создания веб-приложения (в отличие от веб-сайта, например, моего сайта про искусство, который сгенерирован статически и содержит лишь немного Javascript), часто требуются кучи инструментов и технологий, часто меняющихся с большой частотой и содержащих бесконечные объёмы других технологий, о существовании которых мы и не подозреваем (о, смотрите-ка, в папке пакета две тысячи файлов).
Javascript — ужасный язык, никогда не задумывавшийся для чего-то подобного, но, как ни странно, ставший популярным, потому что он всегда был под рукой. Потрясающе, какой объём инноваций затрачен на построение современной вселенной веб-разработки, несмотря на достаточно шаткий фундамент, на котором она основана.
Привет, Habr! Я frontend-разработчик в Альфа-Банк. В статье я хотел бы поделиться опытом внедрения мобильной версии web приложения «Альфа-Бизнес» в нашу архитектуру. А точнее — как без массовых доработок 100 фронтовых сервисов мы заставили работать mobile web версию с новой навигацией.
Всем привет. Меня зовут Алексей. Сейчас я работаю frontend-разработчиком в компании Ozon. В свободное время мне нравится читать про новые технологии, фреймворки, а учитывая то, с какой скоростью развивается frontend, я никогда не скучаю. В этой статье пойдет речь о микрофронтах. В частности, мы посмотрим, как их реализовать на самом базовом уровне, разберемся, когда они нужны, а когда даже не стоит смотреть в их сторону.
На данный момент у нас используются три самых популярных менеджера пакетов (Npm, Yarn и Pnpm). И всё бы ничего, но разные команды начали периодически обращаться с проблемой несоответствия типов Typescript из наших транзитивных зависимостей. Выяснилось что это проблема Npm и Yarn, но как же её решать?
На ум сразу приходит самое очевидное решение: следить за версиями всех зависимостей в своих проектах и вовремя обновлять. К этому, естественно, необходимо стремиться всегда, но мы понимаем, на практике что это крайне сложно, а в legacy-проектах или в проектах, у которых нет постоянной поддержки и вовсе нереально. Следующим вариантом созрел Pnpm, тем более что в наших монорепах он себя уже продолжительное время отлично показывал. Я решил испытать его на действующих клиентских приложениях.
