Меняем JS-библиотеку анимации на View Transitions

Теперь не нужно подтягивать тяжелые JavaScript библиотеки для анимаций в ваш проект. В Chrome и Safari появилась поддержка View Transitions API. Эта апишка дает нам механизм для простого создания анимированных переходов между различными состояниями веб-сайта без необходимости расписывать сложную логику с помощью JS.

Как это работает вы можете увидеть здесь.

#фронтенд #css #javascript


Original post link: t.me/tproger_web/5326
Forwarded and filtered by @smartfeed_bot

Используем tan(atan2()) для работы с вьюпортами в CSS

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

Как это работает и где можно использовать, подробно рассказано здесь.

#css #фронтенд #лайфхак


Original post link: t.me/tproger_web/5328
Forwarded and filtered by @smartfeed_bot

​Как тебя тянут назад, а ты этого не замечаешь. Менталитет краба

Хочу поговорить про менталитет краба — штуку коварную и часто незаметную, но сильно тянущую назад.

Суть менталитета краба: когда люди видят, что вы пробуете новое или добиваетесь успеха, вместо поддержки они критикуют, буллят, обесценивают. Их цель — остановить вас, чтобы вы не выбились вперёд. Почему? Зависть и страх.

Примеры менталитета краба:
— Вижу это у "опытных" в IT — они внушают новичкам, что "Рынок переполнен", "Без 5 лет страданий ничего не добьёшься". Одна из причин (осознанно или нет) — отпугнуть конкурентов и сохранить свой статус.

— Те, кто хотел бы уехать, но боится, осуждают тех, кто решился: "Ты там никому не нужен", "Вот уедешь, а потом пожалеешь!", "Ты предал нас".

— Ты строишь карьеру или делаешь бизнес: "Деньги — это не главное, когда жить собираешься?", "Ты как робот — только работа, цели, задачи. Расслабься!", "Ты слишком амбициозная, независимая, серьезная — мужчинам это не нравится" (женский вариант).

— Ты развиваешь свой блог или канал: "Да кому это вообще интересно?", "Блогеры — это несерьёзно, вот на заводе (в больнице и тп) настоящие профессии".

— Ты завершил сложный проект, который занял у тебя 2 месяца и делишься этим в соц сетях: "Ой, да я такое за час сделаю", "И что тут такого, чем можно было бы удивить?".

— Когда старшее поколение считает, что молодые должны повторить их сложный путь: "Мы в 90-е без выходных пахали за копейки, а вы хотите нормальные зарплаты, удалёнку, баланс работы и жизни, путешествия, свободу выбора? Много хотите!"

— "А ты уверен, что тебе это надо?", "Ты что думаешь, лучше других?", "Бизнес — это опасно", "Ты недостаточно молодой/старый [подставить нужное]". И так далее.

И тут вы скажете — просто не общаться с такими людьми и будете правы (в книгах по саморазвитию не зря говорят о важности окружения). Но есть несколько нюансов:

1. Это только самые очевидные примеры, но на деле всё сложнее.
— Если это говорит авторитетный человек — его слова воспринимаются совсем иначе. "Нельзя переезжать, пока не выучишь язык" — и ты уже сомневаешься (это ж гуру говорит, как ему не поверить).
— Чем умнее человек, тем он опаснее в этом плане. Он выдаст 500 фактов, расчётов, логичных доводов, почему вам нельзя что-то начинать делать и у вас не получится.

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

3. Люди не всегда хотят навредить — часто это просто их сомнения и страхи, но результат один: тебя это тянет вниз.

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

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

Идти своим путём — только я знаю, что для меня правильно. Слушать советы, но не позволять другим управлять жизнью. Зависнешь на чужом мнении — останешься в ведре.

👉 @seniorFront

Как в Notion развивают код с помощью пользовательских правил ESLint

В Notion разработали систему «растягивания», которая помогает постепенно внедрять правила линтинга в течение длительного периода времени, что способствует модернизации кодовой базы без ущерба для скорости работы разработчиков.

О том, как это работает и как вам попробовать эту систему, рассказали в блоге.

#eslint


Original post link: t.me/tproger_web/5339
Forwarded and filtered by @smartfeed_bot

​Зачем необходим DOM?

DOM (Document Object Model) необходим для взаимодействия с веб-страницами и управления их содержимым, структурой и стилями программным образом. DOM представляет собой программный интерфейс для HTML и XML документов. Он описывает логическую структуру документов и позволяет языкам программирования взаимодействовать с ними.

Зачем он нужен
1. Доступ к элементам страницы: Позволяет программно получать доступ к элементам HTML-документа (теги, текст, атрибуты) и манипулировать ими.
2. Изменение содержимого: С помощью него можно изменять содержимое страницы динамически, например, обновлять текст, менять изображения, добавлять или удалять элементы.
3. Обработка событий: Позволяет обрабатывать события, такие как клики, нажатия клавиш, прокрутка и другие взаимодействия пользователя с веб-страницей.
4. Динамическое изменение структуры страницы: Предоставляет методы для добавления, удаления и изменения элементов и атрибутов, что позволяет динамически изменять структуру страницы.
5. Интерактивность: С помощью него можно создавать интерактивные веб-приложения, которые реагируют на действия пользователя без перезагрузки страницы.

Как он работает
Представляет собой древовидную структуру, где каждый элемент страницы является узлом дерева. Вершиной дерева является объект document, который представляет весь HTML-документ. Узлы могут быть элементами (<div>, <p>, <a> и т.д.), текстом, комментариями и другими типами.

Пример HTML-документа:

<!DOCTYPE html>
<html>
<head>
  <title>Document Object Model</title>
</head>
<body>
  <h1>Hello, world!</h1>
  <p>This is a paragraph.</p>
</body>
</html>

Структура для этого документа:

document
 └── html
     ├── head
     │   └── title
     │       └── "Document Object Model"
     └── body
         ├── h1
         │   └── "Hello, world!"
         └── p
             └── "This is a paragraph."

Основные методы и свойства

Доступ к элементам:
✅document.getElementById(id): Возвращает элемент по его id.
✅document.getElementsByClassName(className): Возвращает все элементы с указанным классом.
✅document.getElementsByTagName(tagName): Возвращает все элементы с указанным тегом.
✅document.querySelector(selector): Возвращает первый элемент, соответствующий CSS селектору.
✅document.querySelectorAll(selector): Возвращает все элементы, соответствующие CSS селектору.

Создание и удаление элементов:
✅document.createElement(tagName): Создает новый элемент.
✅parentElement.appendChild(childElement): Добавляет элемент в конец дочерних элементов родителя.
✅parentElement.removeChild(childElement): Удаляет элемент из дочерних элементов родителя.

Изменение содержимого и атрибутов:
✅element.innerHTML: Изменяет или получает HTML-содержимое элемента.
✅element.textContent: Изменяет или получает текстовое содержимое элемента.
✅element.setAttribute(name, value): Устанавливает значение атрибута элемента.
✅element.getAttribute(name): Получает значение атрибута элемента.

Пример:

// Изменение текста заголовка
const header = document.querySelector('h1');
header.textContent = 'Hello, DOM!';

// Добавление нового параграфа
const newParagraph = document.createElement('p');
newParagraph.textContent = 'This is a new paragraph.';
document.body.appendChild(newParagraph);

// Изменение атрибута
const link = document.querySelector('a');
link.setAttribute('href', 'https://www.example.com');

👉 @seniorFront

Разница между SPA и PWA

Мы часто сталкиваемся с терминами SPA (Single Page Application) и PWA (Progressive Web App). Давайте разберемся, что они означают и в чем их основные отличия.

SPA — это веб-приложение, которое загрузится однажды и будет динамически обновлять контент на странице без необходимости перезагрузки. Это значит, что после начальной загрузки сайта пользователю не нужно ожидать, пока загрузится новая страница. Все взаимодействия происходят на одном HTML-документе, что делает работу с приложением более плавной и быстрой. Примеры SPA: Gmail, Google Maps.

Для создания простого SPA можно использовать библиотеки или фреймворки, такие как React или Vue.js. Вот небольшая структура на React:

import React from 'react';
import ReactDOM from 'react-dom';
function App() {
    return (
        <div>
            <h1>Привет, мир!</h1>
            <p>Это простое SPA приложение.</p>
        </div>
    );
}
ReactDOM.render(<App />, document.getElementById('root'));

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

Для создания простого PWA вам нужно добавить файл манифеста и service worker. Пример манифеста:

{
    "name": "Мое PWA приложение",
    "short_name": "PWA",
    "start_url": ".",
    "display": "standalone",
    "background_color": "#ffffff",
    "theme_color": "#000000",
    "icons": [
        {
            "src": "icon.png",
            "sizes": "192x192",
            "type": "image/png"
        }
    ]
}

Основные отличия:

1. SPA нацелено на улучшение пользовательского опыта за счет динамической загрузки данных, в то время как PWA — на создание полноценного приложения, доступного на разных устройствах и с функциональностью, как у нативных приложений.

2. SPA может быть частью PWA. PWA включает все возможности SPA и добавляет дополнительные функции, такие как работа в офлайн-режиме, установка на устройство и поддержка push-уведомлений.

3. SPA чаще всего использует JavaScript-библиотеки и фреймворки (React, Angular, Vue), тогда как PWA требует дополнительных технологий, таких как сервисные работники и манифесты.

#простымисловами #spa #pwa

​Ожидание vs реальность: какие взгляды я поменял за 10 лет в разработке

Старший инженер-программист в Amazon Крис Киль (Chris Kiehl), автор книги по дата-ориентированному программированию на Java поделился заметкой о том, как изменились его взгляды за 10 лет пребывания в индустрии разработки ПО.

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

О чём поменял своё мнение
Вот что я верю сейчас, но о чём раньше бы поспорил:

- Простота — не данность. Она требует постоянной работы.
- Нечем гордиться, если вы оперируете и мыслите сложными конструкциями.
- Типизация в языках программирования нужна в командах с разным уровнем опыта.
- Java — великий язык, потому что скучный.
- Среды REPL (интерактивные среды исполнения) бесполезны в проектировании, но как инструмент для исследований они хороши.
- Львиную долю программирования нужно выполнять задолго до написания первой строчки кода.
- Frontend-разработка — это кафкианский кошмар, который я больше не выношу.
- Привлекательность — это не метрика.
- Эффективное управление бесценно. За свою карьеру я многое повидал и пережил прежде, чем сам узнал, что такое хороший менеджмент.
- DynamoDB — хорошая база данных, только если ваша рабочая нагрузка не выходит за рамки её возможностей.
- Объекты хороши исключительно для тех целей, для которых они предназначены. Слепая преданность функциональному подходу — глупость.

О чём сформировал мнение

- Разработка — это про коммуникацию.
- Никогда не используйте полные монады в Java.
- Планировщик запросов — это злая госпожа.
- Если что-то кажется мне простым — это точно что-то, чего я до конца не понимаю.
- Молодым разработчикам нужно давать пространство для ошибок и экспериментов.
- Нужно активно инвестировать в развитие своих софт-скиллов. Это быстро окупается.
- В разработке приложений мало места для абстракций. Просто пишите нужный код.
- А вот разработка библиотек, наоборот, основана на абстракциях. Потратьте время на поиски алгебраических структур.
- ORM — это дьявол во всех языках и реализациях. Используйте SQL.
- Главная беда функционального программирования — это функциональные программисты.
- В долгосрочной перспективе вы глубоко пожалеете о выборе бессерверных функций.
- Типы — это просто утверждения о мире, в котором работает ваш код.
- Распределённые блокировки по-прежнему и по какой-то непонятной причине остаются очень сложными.
- Навыки формального моделирования и анализа — это база.
- Изоляция — важнейшее свойство хорошего набора интеграционных тестов.
- Худшее, что можно выбрать для разработки приложений общего назначения — это DynamoDB.
- Большинству плевать на ремесло программиста. Берегите тех, кому не всё равно. С остальным смиритесь.
- Будущее за языками с постепенной зависимой типизацией.
- Вы буквально не можете добавлять к тестовому коду слишком много комментариев (готов поспорить с тем, кто сможет).

О чём мнение не поменялось
- Те, кто заморачивается над стилем кода, правилами линтинга и прочими мелочами — извращенцы. Занимайтесь более важными вещами.
- Покрытие кода никак не связано с качеством кода. А зачастую и вовсе обратно пропорционально ему.
- Монолиты остаются довольно няшными.
- Крайне сложно превзойти десятилетия исследований и доработок реляционных баз данных.
- Использование микросервисов нужно обосновывать, а то их всё чаще воспринимают как решение по умолчанию.
- Большинство проектов не нужно масштабировать. Иллюзия этой необходимости только вредит.
- Если завтра исчезнут 93%, а может быть, даже 95,2% проджектов — ничего не изменится, а то и повысится эффективность работы.

А вы согласны с автором или в каких-то моментах готовы поспорить, потому что ваш опыт говорит о другом? Менялось ли ваше отношение к разработке в процессе работы? Расскажите.

👉 @seniorFront

​Переключение между контекстами убивает эффективность разработчиков на корню

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

Как избежать переключения между контекстами

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

2. 📝 Заносите задачи в список дел. Используйте любой инструмент, например, Todoist или Microsoft To Do, чтобы выгружать задачи из головы. Это снизит напряжённость. В любой момент можно свериться со списком и решить, над какой задачей работать дальше. Выберите самую важную задачу и начните с неё.

3. 🔢 Расставляйте приоритеты. Этот приём поддерживает вовлечённость в работу и не даёт отвлекаться.

4. 🔒 Выделяйте время для сосредоточенной работы. Установите полуторачасовые интервалы для сосредоточенной работы по методике, описанной в книге Кэла Ньюпорта «В работу с головой». Это оптимальное время для сохранения стабильной концентрации внимания. При этом нужно организовать минимум 4–6 часов сосредоточенной работы. Отметьте эти блоки у себя в календаре и для их выполнения выберите время дня, когда вы на пике энергии. Для большинства людей это — утро.

5. 🅿️ Используйте «парковку идей». Во время работы держите открытым текстовый файл. Если вам в голову приходит мысль или возникает новая задача, не переключайтесь на неё, а просто быстро запишите её в файл. Так вы сможете не отвлекаться.

6. 🚧 Оставляйте себе «хлебные крошки» на случай, если вас отвлекут. Когда вы занимаетесь сложной задачей, оставляйте себе подсказки. Если вас отвлекли, лаконичный комментарий о том, почему в файле с исходным кодом в IDE вы написали именно эту строчку, сэкономит вам несколько часов, которые ушли бы на восстановление вашего хода мысли. Этим же приёмом можно пользоваться в конце дня. Тогда завтра вы точно будете знать, с чего продолжить. А ещё это помогает бороться с эффектом Зейгарник — стремлением заполнять рабочую память незавершёнными задачами.

7. 🔕 Минимизируйте отвлекающие факторы. Как вариант, наденьте шумоподавляющие наушники, отключите неважные уведомления или создайте изолированное рабочее пространство. Отличный вариант — выключать на какое-то время мессенджеры и включать на телефоне режим «Не беспокоить».

8. 🤹 Откажитесь от многозадачности. Наш мозг может корректно и сосредоточенно работать только над одной задачей. Так что берите в работу что-то одно.

9. 💺 Продумайте эргономику. Обзаведитесь эргономичным столом и стулом, настройте монитор, чтобы сократить физический дискомфорт.

10. 📂 Организуйте пространство. Не загромождённое рабочее пространство снижает когнитивную нагрузку и помогает сосредоточиться на задаче.

👉 @seniorFront

Интерактивный гайд по CRDT

Благодаря CRDT можно легко создавать приложения с совместным редактированием, такие как Google Docs, но без необходимости подключаться к серверу.

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

https://jakelazaroff.com/words/an-interactive-intro-to-crdts/

#typescript #crdt


Original post link: t.me/tproger_web/5368
Forwarded and filtered by @smartfeed_bot

const

Когда раньше разработчик хотел объявить константу в JavaScript, до ES6 это было лишь условное обозначение переменной в шапке блока. Это не делало переменную безопасной, а всего лишь давало понять другим разработчикам, что перед ними переменная — константа, значение которой не следует менять.

Сейчас мы можем использовать модификатор const. Он не делает переменную неизменной, а просто блокирует ее присвоение (пример 1). Если у вас не примитивное присвоение (объект или массив), в этом случае значение переменной может быть изменено (пример 2).


Original post link: t.me/senior_front/2487
Forwarded and filtered by @smartfeed_bot

Что такое миксины?

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

Часто используются для добавления методов или свойств к классам. Это позволяет комбинировать функциональность из разных источников.

let sayHiMixin = {
    sayHi() {
        console.log(`Привет, ${this.name}`);
    },
    sayBye() {
        console.log(`Пока, ${this.name}`);
    }
};

class User {
    constructor(name) {
        this.name = name;
    }
}

// Копируем методы sayHiMixin в User.prototype
Object.assign(User.prototype, sayHiMixin);

let user = new User("Вася");
user.sayHi(); // Привет, Вася
user.sayBye(); // Пока, Вася

В этом примере миксин sayHiMixin добавляет методы sayHi и sayBye к классу User.

Миксины в CSS (Sass/SCSS)
Обычно используются в препроцессорах, таких как Sass или Less. Миксины позволяют определять наборы стилей, которые можно повторно использовать в различных местах стилей.

@mixin border-radius($radius) {
    -webkit-border-radius: $radius;
       -moz-border-radius: $radius;
            border-radius: $radius;
}

.box { 
    @include border-radius(10px);
    width: 100px;
    height: 100px;
    background-color: lightblue;
}

В этом примере миксин border-radius определяет стили для создания скругленных углов. Затем он используется в классе .box для применения этих стилей.

Почему это важно?
- Повторное использование кода: Миксины позволяют избежать дублирования кода, что упрощает его поддержку и уменьшает вероятность ошибок.
- Организация кода: Миксины помогают организовать код, разделяя общую функциональность на логические блоки.
- Удобство и гибкость: С миксинами легко добавлять или изменять функциональность, не затрагивая основные классы или стили.

👉 @seniorFront

​GraphQL или REST: Какой API выбрать, чтобы не прогадать?

Расскажу о GraphQL, сравню с REST. Разберемся в плюсах и минусах каждого подхода к проектированию API. Выбираем лучший для вашего проекта!

Распространенность и интеграция
В 2015 году Facebook представил GraphQL. С тех пор эта технология набирает популярность, но REST остается лидером. По данным Postman на 2024 год, GraphQL используют 29% разработчиков, REST — 90%.

Если заранее неизвестны потребители API, лучше выбрать REST — он проще и популярнее:
- Разработчикам, знакомым с HTTP, легко освоить REST. Он использует стандартные HTTP-методы и принципы.
- REST API можно реализовать на любом языке, поддерживающем HTTP, без дополнительных слоев.
- REST — проверенная технология с сильным сообществом и множеством готовых инструментов.

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

Рассмотрим пример. Есть сущность «Игрушка» (Toy), которую создает «Мастер» (Master), привязанный к «Пользователю» (User). У игрушки также есть «Категория» (Category) и «Теги» (Tags).

GraphQL позволяет получить все данные одним запросом:

query getToy {
  toy(id: 1) {
    id
    name
    category {
      id
      name
    }
    tags {
      id
      name
    }
    master {
      id
      info
    }
  }
}

В случае REST API потребовалась бы серия запросов:

GET http://localhost:8080/toys/1 - Получаем игрушку по ID
GET http://localhost:8080/categories/2 - Получаем категорию игрушки по ID, который взяли из объекта игрушки
GET http://localhost:8080/tags?id=1&id=2&id=3 - Получаем теги игрушки по ID, которые взяли из объекта игрушки
GET http://localhost:8080/masters/3 - Получаем мастера игрушки по ID, который взяли из объекта игрушки
GET http://localhost:8080/users/4 - Получаем пользователя, к которому привязан мастер, по ID, который взяли из объекта мастера

В приложениях со сложными связями между доменами GraphQL упрощает получение данных: один запрос вместо пяти (в примере). Кроме того, можно исключить ненужные поля, например, createdAt и updatedAt. GraphQL возвращает только то, что нужно.

Версионирование
GraphQL использует одну версию endpoint. Изменения вносятся в схему без явного версионирования API, что упрощает развитие.

REST API нужно версионировать для безопасных изменений. Обычно это делается в URL, например: http://localhost:8080/v1/toys.

Ошибки и коды ответа
GraphQL всегда отвечает кодом 200 OK, даже при ошибках. Информацию об ошибке ищите в поле errors JSON-ответа. Клиент не может проверить статус по HTTP-коду и вынужден анализировать тело ответа.

REST использует стандартные HTTP-коды (400, 404, 500) для обозначения результата. Это делает обработку ошибок в REST более наглядной

Заключение
Выбор между GraphQL и REST — это вопрос потребностей проекта. REST лидирует благодаря простоте, популярности и развитым инструментам. GraphQL же гибче в запросах: запрашиваем только нужное, не перегружаем сеть лишним, что важно для сложных приложений.

Тестировать GraphQL сложнее, особенно с файлами: больше настроек в запросах, чем в REST. GraphQL проще версионировать — меняем схему, и всё, а в REST приходится менять URL. Наконец, GraphQL всегда отвечает кодом 200 и сообщает об ошибках в теле ответа, а REST использует стандартные коды ошибок, что делает их более заметными.

👉 @seniorFront

– OpenAI представила новый голосовой ассистент, который теперь может в реальном времени анализировать изображение, речь и текст — конкуренция Siri и Alexa становится серьезной.
– Google тестирует поиск с интеграцией ИИ-резюме, который меняет привычный способ продвижения сайтов. SEO-специалисты — держитесь!
– TikTok анонсировал AI Creative Assistant — теперь ИИ помогает создавать и тестировать рекламные креативы за секунды.

Хочешь быть в курсе последних новостей в мире ИИ/ИТ/маркетинга ?

Мы собрали папку Telegram-каналов, где эксперты каждый день:

https://t.me/addlist/gs3Io1EOk2lhNmEy

✔ разбирают тренды
✔ выкладывают кейсы
✔ делятся фреймворками, которые экономят десятки часов
✔ и сразу показывают, как использовать ИИ в маркетинге и ИТ на практике.

📂 Открой доступ к Telegram-папке → https://t.me/addlist/gs3Io1EOk2lhNmEy


Original post link: t.me/frontendnoteschannel/4625
Forwarded and filtered by @smartfeed_bot

Стрелочные и обычные функции в JavaScript: в чём разница?

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

Давайте разберёмся, в чём заключаются эти различия, посмотрим на пример и выясним, когда какую функцию стоит использовать.

Обычные функции пишутся с использованием ключевого слова function, а стрелочные — с помощью более компактного синтаксиса =>.

//Обычная функция
function greet(name) {
  return "Привет, " + name;
}

//Стрелочная функция
const greet = (name) => "Привет, " + name;

This. Одно из главных различий — как функции работают с контекстом this.

— В обычной функции this зависит от того, как её вызвали.
— В стрелочной функции this берётся из внешнего окружения и не меняется.
Это важно, когда вы работаете с объектами или обработчиками событий.

Аргументы. Обычные функции имеют встроенный объект arguments для доступа ко всем переданным параметрам, а стрелочные — нет (но можно использовать ...args).

Конструкторы. Обычную функцию можно использовать с new для создания объектов, стрелочную — нельзя.

Генераторы. Обычные функции поддерживают синтаксис function* для генераторов, стрелочные — нет.

Чтобы понять разницу работы с this на практике, рассмотрим пример с объектом:

const person = {
  name: "Алекс",
  sayHello: function() {
    console.log("Привет, я " + this.name);
  },
  sayHelloArrow: () => {
    console.log("Привет, я " + this.name);
  }
};

person.sayHello();       // Привет, я Алекс
person.sayHelloArrow();  // Привет, я undefined

— В методе sayHello (обычная функция) this указывает на объект person, и мы получаем доступ к свойству name.

— В методе sayHelloArrow (стрелочная функция) this берётся из внешнего контекста (например, window), где name не определён, поэтому результат — undefined.
Этот пример показывает, почему выбор типа функции важен в зависимости от задачи.

Стрелочные функции отлично подходят для коротких коллбэков (например, в map или setTimeout) и случаев, когда не нужен собственный`this`.

Обычные функции нужно использовать в методах объектов, где важен динамический this, или когда нужны конструкторы и объект arguments.

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

#простымисловами #javascript

​Зачем нужен Nginx?

Nginx — это мощный веб-сервер, который используется для раздачи статических файлов, балансировки нагрузки, проксирования запросов и обеспечения безопасности.

Как Nginx раздаёт фронтенд-приложение?
Когда мы билдим SPA-приложение (например, React/Vue/Angular), в папке dist появляются статические файлы (index.html, app.js, styles.css).

server {
    listen 80;
    server_name myapp.com;
    root /var/www/myapp/dist;
    index index.html;
    
    location / {
        try_files $uri /index.html;
    }
}

Как Nginx проксирует запросы к бэкенду?
Если фронтенд (myapp.com) и бэкенд (api.myapp.com) находятся на разных серверах, Nginx может перенаправлять запросы на API.

server {
    listen 80;
    server_name myapp.com;
    root /var/www/myapp/dist;
    index index.html;

    location / {
        try_files $uri /index.html;
    }

    # Проксирование API-запросов
    location /api/ {
        proxy_pass http://localhost:5000/; # Node.js, Python, PHP и т. д.
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Как Nginx балансирует нагрузку?
Если у нас несколько бэкенд-серверов, Nginx может распределять нагрузку между ними.

upstream backend {
    server backend1.myapp.com;
    server backend2.myapp.com;
}

server {
    listen 80;
    server_name api.myapp.com;

    location / {
        proxy_pass http://backend;
    }
}

Как Nginx ускоряет сайт с кэшем?
Кэширование уменьшает нагрузку на сервер и ускоряет загрузку страниц.

location /static/ {
    expires 7d; # Кэшировать файлы на 7 дней
    add_header Cache-Control "public, max-age=604800";
}

👉 @seniorFront

​Гореть, но не сгорать: практические советы по борьбе с burnout’ом

Важно понять: выгорание — это не ваш личный факап или ошибка. Это сигнал всей системы — целого организма — что что-то идет не так. Бороться с выгоранием через «затыкание дыр» не выйдет. Если вы наконец-то полноценно отдохнете в эту субботу и даже воскресенье, а потом вернетесь к привычному режиму, проблема никуда не уйдет. И если ее игнорировать, тоже.

Что на самом деле нужно делать?
Только системный подход, только хардкор — смена личных и рабочих привычек, выстраивание нового подхода к рабочему процессу. Ниже — несколько советов.

Отказываемся от перфекционизма
Перфекционизм в ИТ не только бесполезен, но даже опасен. Код не обязан быть идеальным с первой попытки, а технический долг — это нормальная история. Можно попробовать упражнение «достаточно хорошо»: установить четкие критерии завершения задачи и не позволять себе бесконечно её улучшать. Никаких больше «Нет предела совершенству».

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

Беремся за физическое восстановление
Здоровье у вас одно, стимуляторы из Fallout у нас пока не изобрели, а бионические протезы не так доступны, как в Cyberpunk 2077. Поэтому беремся за восстановление организма. Учимся замечать усталость. В глазах рябит от кода, в голове туман — идем отдыхать, а не терпим. Можно попробовать внедрить правило 90/30 (30-минутный отдых каждые полчаса) или другой формат перерывов. Естественно, во время отдыха не скроллим ленты и стараемся вообще не смотреть в экран. Обедаем где-нибудь вдали от клавиатуры, если на удаленке — тем более.

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

Главное — помните. К этому состоянию вы пришли не за один месяц, а значит, восстановление тоже займет какое-то время. Не ждите, что после недельки в новом режиме или отпуска сразу все наладится.

👉 @seniorFront

Оптимизация производительности веб-приложений с помощью Lighthouse

Цель этой темы - показать, как использовать инструмент Lighthouse от Google для оптимизации производительности веб-приложений. Lighthouse - это автоматизированное средство для проверки качества веб-страниц, которое анализирует различные аспекты производительности и дает рекомендации по их улучшению.

В этом примере мы используем Lighthouse API для запуска аудита производительности веб-приложения. Сначала мы запускаем Chrome в Headless-режиме с помощью chrome-launcher. Затем мы вызываем функцию lighthouse, передавая URL веб-приложения и необязательный конфигурационный объект.

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

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

Разработка адаптивных веб-приложений с помощью Microsoft Blazor

Microsoft Blazor - это фреймворк для создания интерактивных веб-приложений с использованием языка C# и .NET. Одним из ключевых преимуществ Blazor является возможность создания адаптивных приложений, которые автоматически масштабируются и оптимизируются для различных устройств и экранов.

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

Blazor использует компонентную модель разработки, где каждый компонент представляет отдельную часть пользовательского интерфейса. Вы можете создавать более сложные компоненты, взаимодействовать с данными и использовать возможности языка C# для разработки функциональности вашего веб-приложения.

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

Освоение Microsoft Blazor позволит вам создавать адаптивные и интерактивные веб-приложения, используя знакомые инструменты и язык программирования C#.

​Вайб-кодинг: практика, о которой почему-то не говорят

В феврале мир разработки перевернулся с выходом Sonnet 3.7. Потому что вдруг внезапно оказалось, что джуны уже не очень-то и нужны. И нейросетка нормально заменяет мидлов тоже.

Я откидываюсь в кресле, беру наушники и смотрю, как работает LLM. Можно сразу несколько, работающих над разными частями проекта:

Пример проекта с прикручиванием аналитики к инфраструктуре:
- Сначала в GPT 4.5 провёл продуктовые исследования и сформулировал требования.
- Попросил превратить это в архитектурный план.
- Отревьюил, поправил тупые ошибки.
- Затем этот план (как метапромпт) скормил Sonnet в VS Code через плагин Cline. Попросил сначала создать общую структуру, шаблонные имплементации, документацию, спецификации API (protobuf для gRPC, REST API).
- Архитектурно сразу заложил микросервисы. Sonnet для каждого сервиса подобрал и обосновал оптимальную базу данных (где-то Postgres, где-то ClickHouse и т.д.).
- Сгенерировал SDK для взаимодействия, примеры использования. Сразу заложил observability: централизованные логи, метрики Prometheus, трейсинг Jaeger/Tempo, дашборды для Grafana.
- Потом итерационно генерировал код: сначала тесты (End-to-end, BDD), потом имплементацию под эти тесты.
- Написал манифесты для Kubernetes и Docker Compose для локального запуска.
- Сгенерировал даже скрипты для тестов REST API через curl и gRPC через gRPCurl.

И всё.

А теперь практика — что делать с тем, что современные нейросети учились преимущественно на говнокоде и как быть с джунами. Продолжение в статье

👉 @seniorFront

7 признаков профессиональной стагнации разработчика

В мире кода есть понятие code smells — признаки плохого кода. Сегодня я расскажу о junior smells — характерных признаках «старого джуна». У каждого из них есть яркие черты, по которым их легко распознать. И, что самое важное, — для каждого из этих признаков я подготовил конкретное решение, которое поможет перейти на следующий уровень.

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

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

ИИ-зависимость
Когда-то это был синдром «копипасты» со Stack Overflow. Сегодня — новое поколение зависимости: от нейросетей. Всё начинается с удобства — автодополнение, готовые сниппеты, помощь в дебаге. Но со временем инструменты становятся костылём, без которого разработчик чувствует себя беспомощным.

Мастер временных решений
Это один из самых распространённых и опасных признаков старого джуна. В условиях дедлайнов, давления, багов на проде и непрерывного потока задач, он начинает использовать «временные решения» — быстрые костыли, которые якобы потом будут переписаны.

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

Скоростной гонщик
Это разработчик, который поставил скорость выше всего остального. Быстрее закрытые тикеты, больше строк кода, меньше обсуждений. На первый взгляд — мечта менеджера. Но только до тех пор, пока не наступает фаза изменений. Проблема не в скорости как таковой. Проблема в игнорировании качества. Код гонщика часто не покрыт тестами, написан без оглядки на читаемость и сопровождение, перегружен неочевидной логикой.

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

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

👉 @seniorFront