Synthetic events в React
В React, "синтетические события" (synthetic events) - это система обработки событий, которая предоставляет кросс-браузерную и кросс-платформенную абстракцию над нативными событиями браузера. Они создаются и управляются React и обеспечивают более единообразное поведение обработки событий в различных браузерах.
Синтетические события предоставляются компонентам React как аргументы обработчиков событий и имеют схожий интерфейс с нативными событиями браузера, но с некоторыми различиями и улучшениями.
Пример использования синтетических событий:
В этом примере, event является синтетическим событием, передаваемым в обработчик
Синтетические события также имеют дополнительные преимущества, такие как автоматический пулинг (для оптимизации работы с памятью), нормализация различий между разными браузерами и поддержка делегирования событий.
👉 @seniorFront
В React, "синтетические события" (synthetic events) - это система обработки событий, которая предоставляет кросс-браузерную и кросс-платформенную абстракцию над нативными событиями браузера. Они создаются и управляются React и обеспечивают более единообразное поведение обработки событий в различных браузерах.
Синтетические события предоставляются компонентам React как аргументы обработчиков событий и имеют схожий интерфейс с нативными событиями браузера, но с некоторыми различиями и улучшениями.
Пример использования синтетических событий:
import React from 'react';
class Button extends React.Component {
handleClick = (event) => {
event.preventDefault();
console.log('Button clicked!');
};
render() {
return <button onClick={this.handleClick}>Click me</button>;
}
}В этом примере, event является синтетическим событием, передаваемым в обработчик
handleClick. Вы можете вызывать методы такие как preventDefault(), stopPropagation(), и другие, а также получать информацию о событии (например, event.target, event.clientX, и др.).Синтетические события также имеют дополнительные преимущества, такие как автоматический пулинг (для оптимизации работы с памятью), нормализация различий между разными браузерами и поддержка делегирования событий.
👉 @seniorFront
👍6👎1
This media is not supported in your browser
VIEW IN TELEGRAM
Blurry Text Reveal
Анимировано библиотекой gsap. Анимация запускается при прокрутке страницы.
👉 @seniorFront
Анимировано библиотекой gsap. Анимация запускается при прокрутке страницы.
👉 @seniorFront
👍7
Этот опасный рефакторинг (Как снизить риски?)
Ошибки во время рефакторинга могут дорого обойтись. Модернизация, ведущая к отказу системы, или внесение новой функциональности параллельно с ошибочными правками явно принесут вред. Но степень вреда может быть разной.
Некоторые задачи рефакторинга подразумевают крупные изменения и затрагивают несколько подсистем. Другие при этом ограничиваются одним компонентом, но могут непредвиденно повлиять на другие части системы и вызвать поломку важнейших бизнес-операций. В этом случае речь может идти о действующем потоке приобретения товара. Третья категория – это доработки, позволяющие внести новые возможности – например, изменение потока приобретения одного товара для поддержки большего числа его единиц и добавление ещё одного потока после.
Объединяет все эти сценарии то, что они сопряжены с высоким риском.
1. В случае ошибки такие доработки навредят бизнесу (потеря прибыли, недовольство клиентов), команде (подорвут доверие, мотивацию) или другим связанным функциям (разработка встанет).
2. Причём реализация этих изменений весьма затратна, так как требует повышенного внимания, усилий и времени. Предпочтительнее для таких задач задействовать опытных разработчиков, хорошо разбирающихся в этой области.
Как снизить риски
Рекомендую использовать чек-лист:
- Определите ограничения. Как далеко можно зайти?
- Изолируйте доработки от функциональности. Не применяйте их вместе.
- Напишите обширные тесты, более высокоуровневые (интеграционные) с меньшим числом деталей реализации, и сопровождайте ими внесение изменений.
- Проверьте всё наглядно. Запустите браузер.
- Не пропускайте тесты. Не ленитесь.
- Не полагайтесь слишком сильно на код-ревью и контроль качества (QA). Люди ошибаются.
- Не смешивайте масштабные зачистки с другими изменениями. Это можно делать в случае небольших доработок.
👉 @seniorFront
Ошибки во время рефакторинга могут дорого обойтись. Модернизация, ведущая к отказу системы, или внесение новой функциональности параллельно с ошибочными правками явно принесут вред. Но степень вреда может быть разной.
Некоторые задачи рефакторинга подразумевают крупные изменения и затрагивают несколько подсистем. Другие при этом ограничиваются одним компонентом, но могут непредвиденно повлиять на другие части системы и вызвать поломку важнейших бизнес-операций. В этом случае речь может идти о действующем потоке приобретения товара. Третья категория – это доработки, позволяющие внести новые возможности – например, изменение потока приобретения одного товара для поддержки большего числа его единиц и добавление ещё одного потока после.
Объединяет все эти сценарии то, что они сопряжены с высоким риском.
1. В случае ошибки такие доработки навредят бизнесу (потеря прибыли, недовольство клиентов), команде (подорвут доверие, мотивацию) или другим связанным функциям (разработка встанет).
2. Причём реализация этих изменений весьма затратна, так как требует повышенного внимания, усилий и времени. Предпочтительнее для таких задач задействовать опытных разработчиков, хорошо разбирающихся в этой области.
Как снизить риски
Рекомендую использовать чек-лист:
- Определите ограничения. Как далеко можно зайти?
- Изолируйте доработки от функциональности. Не применяйте их вместе.
- Напишите обширные тесты, более высокоуровневые (интеграционные) с меньшим числом деталей реализации, и сопровождайте ими внесение изменений.
- Проверьте всё наглядно. Запустите браузер.
- Не пропускайте тесты. Не ленитесь.
- Не полагайтесь слишком сильно на код-ревью и контроль качества (QA). Люди ошибаются.
- Не смешивайте масштабные зачистки с другими изменениями. Это можно делать в случае небольших доработок.
👉 @seniorFront
👍3
Как защитить PROD от багов и себя от стресса
Эта статья - взгляд QA на проблему возникновения багов на ПРОДе. Он выделил пять основных рисков:
1. Идея попадает к аналитику
Владелец продукта и аналитик на этапе проектирования тех. требований могут некорректно описать логику нового функционала (флоу). Заказчик имел ввиду одно, а по итогу в спецификациях совершенно другое. Решение данной проблемы может зависеть от правил взаимодействия с заказчиком в вашей команде.
Необходимо ли заказчику описывать предложения в письменном виде с точным описанием? Ответственность данного риска лежит на плечах владельца продукта и он в свою очередь может сделать общение с заказчиком более прозрачным для команды.
2. Разработка по тех. требованиям
Frontend и Backend разработчики берут задачи из бэклога в спринт, но в задаче может быть прикреплена устаревшая документация, ее может и вовсе не быть.
Пиши то - не зная что, реализуй так - не зная как.
Часто встречается и такая модель разработки - когда ответственность падает только на разработчика, минуя владельца продукта и аналитику. Это грустно и в таком случае помогут DOR и DOD.
Definition of Ready - это критерии готовности взять задачу в разработку, то есть DOR это условия, при выполнении которых задача может упасть в спринт. Команда сама выбирает критерии и придерживается их. Например: аналитика написана, есть точные тех.требования и т.д.
Definition of Done - это критерии завершения задачи, то есть условия после которых выполненная задача переходит в тестирование к QA.
3. Frontend и Backend выполняют задачи не синхронно
Под синхронным выполнением задачи я подразумеваю, что задачи на фронте и на бэке будут выполняться как минимум в одном спринте. Почему это критично? Тех.требования имеют свойства корректироваться на этапе разработки и если один разработчик взял задачу в одном спринте и подкорректировал реализацию на своей стороне, то второй разработчик может выполнить задачу по устаревшим требованиям.
4. Тестирование
Само тестирование может быть некачественным из-за человеческого фактора. Пропустил ошибку т.к. не написал тест-кейс по этой функциональности или не проверил негативные тесты. Недостаточно времени было на тестирование. Не было документации вовсе.
Данный риск зависит от самого инженера по тестированию, но описанные выше риски могу напрямую влиять на качество тестирования и ответственность ложится уже на вас.
Защитить себя и ваше время помогут вышеупомянутые DOR и DOD.
5. Релиз (Поддержка)
Данный риск зависит от четвертого, т.к. вы можете обнаружить ошибку только при регресс тестировании, а это значит мало времени уделено тестированию. В этот риск я бы добавил момент, когда вы выкатились на прод, но заказчику не нравится что-либо.
👉 @seniorFront
Эта статья - взгляд QA на проблему возникновения багов на ПРОДе. Он выделил пять основных рисков:
1. Идея попадает к аналитику
Владелец продукта и аналитик на этапе проектирования тех. требований могут некорректно описать логику нового функционала (флоу). Заказчик имел ввиду одно, а по итогу в спецификациях совершенно другое. Решение данной проблемы может зависеть от правил взаимодействия с заказчиком в вашей команде.
Необходимо ли заказчику описывать предложения в письменном виде с точным описанием? Ответственность данного риска лежит на плечах владельца продукта и он в свою очередь может сделать общение с заказчиком более прозрачным для команды.
2. Разработка по тех. требованиям
Frontend и Backend разработчики берут задачи из бэклога в спринт, но в задаче может быть прикреплена устаревшая документация, ее может и вовсе не быть.
Пиши то - не зная что, реализуй так - не зная как.
Часто встречается и такая модель разработки - когда ответственность падает только на разработчика, минуя владельца продукта и аналитику. Это грустно и в таком случае помогут DOR и DOD.
Definition of Ready - это критерии готовности взять задачу в разработку, то есть DOR это условия, при выполнении которых задача может упасть в спринт. Команда сама выбирает критерии и придерживается их. Например: аналитика написана, есть точные тех.требования и т.д.
Definition of Done - это критерии завершения задачи, то есть условия после которых выполненная задача переходит в тестирование к QA.
3. Frontend и Backend выполняют задачи не синхронно
Под синхронным выполнением задачи я подразумеваю, что задачи на фронте и на бэке будут выполняться как минимум в одном спринте. Почему это критично? Тех.требования имеют свойства корректироваться на этапе разработки и если один разработчик взял задачу в одном спринте и подкорректировал реализацию на своей стороне, то второй разработчик может выполнить задачу по устаревшим требованиям.
4. Тестирование
Само тестирование может быть некачественным из-за человеческого фактора. Пропустил ошибку т.к. не написал тест-кейс по этой функциональности или не проверил негативные тесты. Недостаточно времени было на тестирование. Не было документации вовсе.
Данный риск зависит от самого инженера по тестированию, но описанные выше риски могу напрямую влиять на качество тестирования и ответственность ложится уже на вас.
Защитить себя и ваше время помогут вышеупомянутые DOR и DOD.
5. Релиз (Поддержка)
Данный риск зависит от четвертого, т.к. вы можете обнаружить ошибку только при регресс тестировании, а это значит мало времени уделено тестированию. В этот риск я бы добавил момент, когда вы выкатились на прод, но заказчику не нравится что-либо.
👉 @seniorFront
❤2👍1🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Curious Geckos
Создано без использования JS, при помощи возможностей препроцессоров Pug и SCSS. А также CSS селектора :has. Подробное описание игры и процесса создания в статье.
👉 @seniorFront
Создано без использования JS, при помощи возможностей препроцессоров Pug и SCSS. А также CSS селектора :has. Подробное описание игры и процесса создания в статье.
👉 @seniorFront
❤3
Media is too big
VIEW IN TELEGRAM
Animated Download Button
В этом видео создаётся кнопка скачивания, анимируемая при нажатии
👉 @seniorFront
В этом видео создаётся кнопка скачивания, анимируемая при нажатии
👉 @seniorFront
👍3
This media is not supported in your browser
VIEW IN TELEGRAM
Slider with Two Different Sidebars
Слайдер реализован при помощи библиотеки Swiper. А также в JS создана логика проигрывания музыки.
👉 @seniorFront
Слайдер реализован при помощи библиотеки Swiper. А также в JS создана логика проигрывания музыки.
👉 @seniorFront
👍4
This media is not supported in your browser
VIEW IN TELEGRAM
3D wave animation
Создано на HTML и CSS. При помощи комбинатора '+' стили задаются соседним элементам.
👉 @seniorFront
Создано на HTML и CSS. При помощи комбинатора '+' стили задаются соседним элементам.
👉 @seniorFront
👍17🔥2❤1
Чем отличаются методы forEach() и map() при работе с массивами в JavaScript?
Anonymous Quiz
28%
forEach() изменяет исходный массив, а map() создает новый массив с результатами колбэка.
6%
forEach() возвращает новый массив, а map() ничего не возвращает.
67%
forEach() ничего не возвращает, а метод map() возвращает новый массив с результатами вызова колбэка.
👍19👎4
16 апреля в Айтилогии стартует 7-дневный бесплатный интенсив по frontend-разработке, на котором ты с нуля без знаний создашь фронтенд-проект на Angular 🔥
На интенсиве ты:
– Сверстаешь лендинг на HTML + CSS
– Реализуешь функционал на JavaScript
– Используешь фронтенд-фреймворк Angular
– Подключишь Backend и загрузишь сайт на хостинг
🎁 Будет общий чат, проверка домашек от экспертов, различные бонусы!
А за кодовую фразу, собранную во время интенсива, автор подарит своё резюме Senior-разработчика, с помощью которого устроился на ЗП 3500$
Первые 100 мест бесплатно, потом 6 990 руб. Не упусти👇🏻
Frontend Start
На интенсиве ты:
– Сверстаешь лендинг на HTML + CSS
– Реализуешь функционал на JavaScript
– Используешь фронтенд-фреймворк Angular
– Подключишь Backend и загрузишь сайт на хостинг
🎁 Будет общий чат, проверка домашек от экспертов, различные бонусы!
А за кодовую фразу, собранную во время интенсива, автор подарит своё резюме Senior-разработчика, с помощью которого устроился на ЗП 3500$
Первые 100 мест бесплатно, потом 6 990 руб. Не упусти👇🏻
Frontend Start
👍2👎2❤1
Media is too big
VIEW IN TELEGRAM
Responsive Contact us Page
В этом видео создается страница контактов с анимированной формой
👉 @seniorFront
В этом видео создается страница контактов с анимированной формой
👉 @seniorFront
👍6
This media is not supported in your browser
VIEW IN TELEGRAM
Fancy Fading Footer
Создано на HTML и CSS. Размытие реализовано при помощи CSS backdrop-filter. Форма размытия создана свойством mask-image.
👉 @seniorFront
Создано на HTML и CSS. Размытие реализовано при помощи CSS backdrop-filter. Форма размытия создана свойством mask-image.
👉 @seniorFront
👍17❤3🔥1
Debug Sum of Digits of a Number
Доработайте функцию getSumOfDigits, которая принимает целое положительное число для вычисления суммы его цифр. Предполагается, что аргумент является целым числом.
👉 @seniorFront
Доработайте функцию getSumOfDigits, которая принимает целое положительное число для вычисления суммы его цифр. Предполагается, что аргумент является целым числом.
👉 @seniorFront
👍3
Делаем код-ревью правильно
Если вы не проводите код-ревью, или делаете их «для галочки», то обрекаете себя на боль, пусть не сразу, но в конечном итоге однозначно. Это можно сравнить с возведением дома на фундаменте из песка. Какое-то время он, может, и простоит, но явно недолго. А в мире стартапов второго шанса у вас может уже не быть.
В этой статье автор привел свое виденье на то, как должен выглядеть процесс код-ревью. Он предлагает предлагаю вам прочесть статью, принять в ней то, с чем вы согласны, и проигнорировать остальное.
👉 @seniorFront
Если вы не проводите код-ревью, или делаете их «для галочки», то обрекаете себя на боль, пусть не сразу, но в конечном итоге однозначно. Это можно сравнить с возведением дома на фундаменте из песка. Какое-то время он, может, и простоит, но явно недолго. А в мире стартапов второго шанса у вас может уже не быть.
В этой статье автор привел свое виденье на то, как должен выглядеть процесс код-ревью. Он предлагает предлагаю вам прочесть статью, принять в ней то, с чем вы согласны, и проигнорировать остальное.
👉 @seniorFront
👍6❤1👎1
Что такое Tree shaking?
Когда приложение на Javascript достигает определенного размера, его обычно разделяют на модули. Однако, через какое то время, становиться сложно отслеживать все что импортируется и как это используется. В итоге при сборке пакетов, мы можем получить большое количество импортированный кода, который фактически не используется.
Tree shaking (Встряхивание дерева) – это метод оптимизации библиотек путем удаления любого кода из окончательного файла, который фактически не используется.
Допустим, у нас есть файл утилит с некоторыми математическими операциями, которые мы можем использовать в нашем основном скрипте.
В нашем основном скрипте импортируем и используем только функцию add().
Воспользуемся для сборки webpack. После сборки мы увидим, что все функции из файла mathUtils.js включены в финальный пакет, хотя мы только импортировали и использовали функцию add().
Если воспользуемся tree shaking, тогда только то, что мы импортировали и фактически использовали попадет в окончательную сборку.
Tree shaking, как правило, является функции сборщиков пакетов. Например, если вы используете webpack, вы можете просто установить mode в production в своем файле конфигурации webpack.config.js. Это, помимо других опций, так же запускает tree shaking.
👉 @seniorFront
Когда приложение на Javascript достигает определенного размера, его обычно разделяют на модули. Однако, через какое то время, становиться сложно отслеживать все что импортируется и как это используется. В итоге при сборке пакетов, мы можем получить большое количество импортированный кода, который фактически не используется.
Tree shaking (Встряхивание дерева) – это метод оптимизации библиотек путем удаления любого кода из окончательного файла, который фактически не используется.
Допустим, у нас есть файл утилит с некоторыми математическими операциями, которые мы можем использовать в нашем основном скрипте.
export function add(a, b) {
console.log("add");
return a + b;
}
export function minus(a, b) {
console.log("minus");
return a - b;
}
export function multiply(a, b) {
console.log("multiply");
return a * b;
}
export function divide(a, b) {
console.log("divide");
return a / b;
}В нашем основном скрипте импортируем и используем только функцию add().
import { add } from "./mathUtils";
add(1, 2);Воспользуемся для сборки webpack. После сборки мы увидим, что все функции из файла mathUtils.js включены в финальный пакет, хотя мы только импортировали и использовали функцию add().
Если воспользуемся tree shaking, тогда только то, что мы импортировали и фактически использовали попадет в окончательную сборку.
Tree shaking, как правило, является функции сборщиков пакетов. Например, если вы используете webpack, вы можете просто установить mode в production в своем файле конфигурации webpack.config.js. Это, помимо других опций, так же запускает tree shaking.
module.exports = {
...,
mode: "production",
...,
} ;👉 @seniorFront
👍23❤1👎1
ИТ-специалисты, ваш выход
Выбирайте вакансию по душе, а Тинькофф обеспечит комфортные условия для работы и возможность экспериментировать в команде единомышленников. Откликнуться в команду Тинькофф
АО «Тинькофф Банк», ИНН 7710140679
Выбирайте вакансию по душе, а Тинькофф обеспечит комфортные условия для работы и возможность экспериментировать в команде единомышленников. Откликнуться в команду Тинькофф
АО «Тинькофф Банк», ИНН 7710140679
👎7👍2
This media is not supported in your browser
VIEW IN TELEGRAM
Tailwind - form
Реализовано на HTML и стилизовано при помощи Tailwind. Анимации созданы в CSS.
👉 @seniorFront
Реализовано на HTML и стилизовано при помощи Tailwind. Анимации созданы в CSS.
👉 @seniorFront
👍19👎2❤1🔥1
Senior Frontend - javascript, html, css
16 апреля в Айтилогии стартует 7-дневный бесплатный интенсив по frontend-разработке, на котором ты с нуля без знаний создашь фронтенд-проект на Angular 🔥 На интенсиве ты: – Сверстаешь лендинг на HTML + CSS – Реализуешь функционал на JavaScript – Используешь…
Завтра идём на фронтенд-практику. Кто не успел записаться, присоединяйтесь 🔥
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Maria Zavarskaya
Открытое собеседование на Frontend разработчика
Привет! Это Эйч Навыки — команда разработчиков из бигтеха. Мы помогаем фронтенд-разработчикам апнуть грейд, сменить компанию или перейти с другого стека.
17 апреля в 19:30 по мск приходи онлайн на Открытое собеседование от Эйч Навыков. Это классная возможность узнать, чего ждут от кандидатов на middle-позиции и как подготовиться к собесу, чтобы получить оффер 👀
Как это будет:
1. Дима Дорофеев, тимлид в канадском стартапе Truv Inc, ex-VK и ментор Навыков, задаст реальные вопросы разработчику-добровольцу
2. Потом Дима даст подробную обратную связь: объяснит, зачем задавал тот или иной вопрос, как лучше на него ответить или решить задачу
3. В конце можно будет задать Диме любой вопрос о трудоустройстве, менторстве или фронтенде
Что узнаешь на Открытом собеседовании:
- Чего ждут от кандидатов на мидл-позиции во фронтенде
- Какие вопросы задают на интервью и зачем
- Как подготовиться к собесу, чтобы получить заветный оффер
Это бесплатно?
Бесплатно
Просто зарегистрируйся на открытое собеседование в нашем боте: @skills_mentee_bot
Реклама: ООО “Эйч Карьера” erid: LjN8KT9Fd
Привет! Это Эйч Навыки — команда разработчиков из бигтеха. Мы помогаем фронтенд-разработчикам апнуть грейд, сменить компанию или перейти с другого стека.
17 апреля в 19:30 по мск приходи онлайн на Открытое собеседование от Эйч Навыков. Это классная возможность узнать, чего ждут от кандидатов на middle-позиции и как подготовиться к собесу, чтобы получить оффер 👀
Как это будет:
1. Дима Дорофеев, тимлид в канадском стартапе Truv Inc, ex-VK и ментор Навыков, задаст реальные вопросы разработчику-добровольцу
2. Потом Дима даст подробную обратную связь: объяснит, зачем задавал тот или иной вопрос, как лучше на него ответить или решить задачу
3. В конце можно будет задать Диме любой вопрос о трудоустройстве, менторстве или фронтенде
Что узнаешь на Открытом собеседовании:
- Чего ждут от кандидатов на мидл-позиции во фронтенде
- Какие вопросы задают на интервью и зачем
- Как подготовиться к собесу, чтобы получить заветный оффер
Это бесплатно?
Бесплатно
Просто зарегистрируйся на открытое собеседование в нашем боте: @skills_mentee_bot
Реклама: ООО “Эйч Карьера” erid: LjN8KT9Fd
❤1
Самые полезные библиотеки JS для красивых анимаций
Интересное в исполнении приложение всегда сможет привлечь внимание, поскольку мы любим, когда красиво. Но что стоит за этим "красиво"? И начинка, и внешний вид. Сегодня поговорим о внешнем виде, ведь встречают по одежке. А конкретно - про анимации.
Three.js
Это высокоуровневая JavaScript-библиотека, специализирующаяся на создании 3D-графики и анимаций для веб-приложений. Используя Three.js, мы можем легко конструировать различные трехмерные сцены, от игр и впечатляющих визуализаций до сред виртуальной реальности. Библиотека облегчает процесс добавления объектов, наложения материалов и текстур, создания анимаций, а также интеграции 3D-моделей, созданных в Blender или других инструментах 3D-моделирования. За счет построения на базе WebGL, Three.js предоставляет интуитивно понятный API, позволяя разработчикам сконцентрироваться на дизайне трехмерных сцен без необходимости погружения в технические детали WebGL.
Mo.js
Представляет собой превосходный фреймворк, выделяющийся своей простотой использования и выразительным синтаксисом. Этот фреймворк значительно облегчает нашу работу в области создания анимаций, позволяя нам легко реализовывать всё, от базовых вращений до сложных, многоуровневых анимаций.
AniJS
редставляет собой элегантную JavaScript-библиотеку, предназначенную для упрощения взаимодействия с элементами пользовательского интерфейса без необходимости глубоких знаний в программировании. Эта библиотека разработана с учетом потребностей дизайнеров, и поэтому её синтаксис использует ясный и понятный английский язык, делая её доступной для понимания широкому кругу пользователей.
Ещё больше библиотек, а также примеры анимаций в статье.
👉 @seniorFront
Интересное в исполнении приложение всегда сможет привлечь внимание, поскольку мы любим, когда красиво. Но что стоит за этим "красиво"? И начинка, и внешний вид. Сегодня поговорим о внешнем виде, ведь встречают по одежке. А конкретно - про анимации.
Three.js
Это высокоуровневая JavaScript-библиотека, специализирующаяся на создании 3D-графики и анимаций для веб-приложений. Используя Three.js, мы можем легко конструировать различные трехмерные сцены, от игр и впечатляющих визуализаций до сред виртуальной реальности. Библиотека облегчает процесс добавления объектов, наложения материалов и текстур, создания анимаций, а также интеграции 3D-моделей, созданных в Blender или других инструментах 3D-моделирования. За счет построения на базе WebGL, Three.js предоставляет интуитивно понятный API, позволяя разработчикам сконцентрироваться на дизайне трехмерных сцен без необходимости погружения в технические детали WebGL.
Mo.js
Представляет собой превосходный фреймворк, выделяющийся своей простотой использования и выразительным синтаксисом. Этот фреймворк значительно облегчает нашу работу в области создания анимаций, позволяя нам легко реализовывать всё, от базовых вращений до сложных, многоуровневых анимаций.
AniJS
редставляет собой элегантную JavaScript-библиотеку, предназначенную для упрощения взаимодействия с элементами пользовательского интерфейса без необходимости глубоких знаний в программировании. Эта библиотека разработана с учетом потребностей дизайнеров, и поэтому её синтаксис использует ясный и понятный английский язык, делая её доступной для понимания широкому кругу пользователей.
Ещё больше библиотек, а также примеры анимаций в статье.
👉 @seniorFront
threejs.org
Three.js – JavaScript 3D library
👍11