JavaScript *

Недавно, после нескольких месяцев отсутствия использования .Net/C#, я улучшал существующее приложение .Net/C# WPF, используя .Net Task Parallel Library (TPL).

Но, наивно применяя шаблоны обещаний JavaScript, которые я использовал в предыдущие месяцы, я столкнулся со странной проблемой, которая заставила меня использовать довольно экзотический метод расширения Unwrap.

В этой статье описывается проблема, объясняется ее причина, предлагается исправление с помощью Unwrap и, наконец, представлена ​​более современная версия с парадигмой async/await C# 5.0.

Простой рабочий процесс в JavaScript с Promises

Вот JavaScript-реализация простого рабочего процесса, состоящего из трех шагов, второй из которых имитирует отложенную обработку с помощью setTimeout с использованием Promise API:

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

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

Мы поговорим о библиотеках JavaScript упрощающих добавление этих анимаций для разработчиков, делая приложения более приятными.

Приятного прочтения :-)

Привет! Я — Алексей Бондаренко, работаю в команде Платформа Банки.ру. Сегодня хочу рассказать о semantic-release и его практическом применении на примере упрощения разработки и внедрения библиотеки в проект. 

В этой статье c помощью простого чек листа за пару шагов выясним, являются ли функции, которые вы пишете в своем vue коде, настоящими composables

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

В этом материале расскажем о безопасности на примере мультиязычного e-commerce сервиса – интернет-магазина с аккаунтом покупателя. Проект построен на NextJS, где часть бекенда на JS и пишется фронтендерами. Поэтому помнить о безопасности в таком случае приходится более старательно, держа в уме случаи, о которых расскажем в этой статье. 

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

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

При этом написание типов бывает действительно утомительным, но Typescript предоставляет возможности ускорить и этот процесс. Здесь нам на помощь придут дженерики.

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

Всем привет! Меня зовут Анатолий Барцев, я frontend-разработчик в команде Модерации Циан. Я решил протестировать Copilot, чтобы оценить, полезен ли он для реальной разработки. В статье расскажу, какие выделил для себя плюсы использования, а также покажу, как GitHub Copilot помогает в разработке на примере проекта на React/Typescript.

Hello world!

По данным 2023 JavaScript Rising Stars библиотека htmx заняла второе место в разделе Front-end Frameworks (первое место вполне ожидаемо принадлежит React) и десятое место в разделе Most Popular Projects Overall.

htmx — это библиотека, которая предоставляет доступ к AJAX, переходам CSS, WebSockets и Server Sent Events прямо из HTML через атрибуты, что позволяет создавать современные пользовательские интерфейсы (насколько сложные — другой вопрос), пользуясь простотой и мощью гипертекста. На сегодняшний день у библиотеки почти 30 000 звезд на Github. Удивительно, что до такого решения мы додумались только сейчас, учитывая, что весь функционал был доступен уже 10 лет назад (вы сами убедитесь в этом, когда мы изучим исходный код htmx).

В этой статье мы с вами разберемся, как htmx работает. Но давайте начнем с примера ее использования.

С точки зрения разработчика, объекты в JavaScript довольно гибкие и понятные. Мы можем добавлять, удалять и изменять свойства объекта по своему усмотрению. Однако мало кто задумывается о том, как объекты хранятся в памяти и обрабатываются JS-движками. Могут ли действия разработчика, прямо или косвенно, оказать влияние на производительность и потребление памяти? Попробуем разобраться во всем этом в этой статье.

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

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

Казалось бы, что можно рассказать о том, о чем все и так знают? Но практика и чтение статей на Хабре, показали, что есть некоторые нюансы использования деструктуризации в React, которые не все из нас знают или просто не все из нас о них задумываются, хотя они и являются очевидными.

Всем привет! В этой статье я хотел бы поделиться своими мыслями о том, почему виртуального DOM можно избежать при создании реактивности сегодня. Я работаю со всем этим уже около полутора лет, создавая фреймворк Cample.js, и у меня есть некоторые соображения по этому поводу.

Недавно я столкнулся с задачей, известной как one billion row challenge. Два аспекта этого вызова меня заинтриговали:

1. Каковы будут последствия, если я попробую решить этот вызов на фронтенде?

2. Удастся ли мне это?

Хотя я не уверен в возможности визуализировать миллиард строк в таблице, цифра в миллион кажется вполне достижимой. Узнав о таком интересном вызове, я решил заняться маленьким проектом, целью которого было отображение миллиона строк в React.

Давайте я вас подробно ознакомлю с тем, что именно произошло, как это было сделано и по каким причинам.

JavaScript — ужасный язык программирования. По сравнению с другими распространёнными языками он выглядит генетическим уродом. Дело даже не в отсутствии многопоточности, или статической типизации, или того, что node_modules для простого проекта занимают сотни мегабайт, а в том, что в JavaScript столько стилей и подходов, что семь человек одну и ту же несложную задачу могут написать на нём семью различными способами. Каждый из них с трудом будет понимать, что написал другой, и тихо материться. Причем, так напишут и новички, и опытные программисты, которые просто привыкли писать по‑своему или захотели выпендриться.

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

Создание веб-приложений должно быть простым...

К сожалению, современная веб-разработка постепенно становится все более сложной и запутанной. Веб всегда был просто вебом, так почему же он не стал проще? Почему мы не становимся более продуктивными?

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

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

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

В этой статье мы рассмотрим, как реализовать Event Loop в JavaScript.

"Вносите вклад в открытый исходный код, это лучшее, что со мной случилось!" - все чаще и чаще слышу я в Twitter в последнее время. Хотя я не возражаю против самого высказывания, мне кажется, что в нем непреднамеренно (или намеренно) упускается приличная часть правды о вкладе и авторстве открытого кода. Это похоже на то, как если бы вы рекомендовали туристический маршрут, с которого в конце концов открывается незабываемый вид, но при этом вы не упоминаете о том, сколько трудностей и подготовки требует этот поход.

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