Если задумываетесь о переезд с чистого JS на типизированный язык, то вот небольшая статья про плюсы/минусы TypeScript и Flow, т.к это основные игроки на сегодня:

➡️ https://www.scalablepath.com/javascript/flow-vs-typescript

От себя:
Если по какой-то причине рассматриваете миграцию на Flow, то ниже немного жизни и боли. У Flow есть приятная особенность - его можно подключать к отдельным файлам через специальный комментарий и проводить постепенную миграцию. Это подкупило и было принято решение переводить JS-проект на него.

Вот проблемы с которыми столкнулись:

1. Отвратительно медленно работает даже на хорошем железе. Не лечится.

2. С болью заводится на Windows. У некоторых коллег Flow не запускается и сегодня. Причины так и не удалось выяснить.

3. Не всякий код заработает из коробки без видимых причин.
При старте переезда, Flow упорно не хотел запускаться и падал без явной причины. Пришлось лезть в его внутренние логи и выискивать в интернетах по “сырым” стектрейсам ошибок. Информации было крайне мало. Проблема в итоге обнаружилась - был один файл, который блокировал запуск Flow-сервиса. Но почему он блокировал запуск для меня загадка по сей день, т.к файл был валиден с точки зрения JS и Flow. Решилось исключением этого файлы из списка файлов для проверки Flow.

4. Слабая поддержка типов для сторонних библиотек и модулей. Есть механизм для создания заглушек с any, но это сводит типизацию на нет.

5. Слабость самой типизиции у Flow в отличии от TS. Это не проблема, а скорее особенность.

6. Ну и https://reactnative.dev/blog/2023/01/03/typescript-first 🌚 Если кто не знал, то Flow, как и React Native, разрабатываются Facebook. Но с 0.71+ RN официально сделал TypeScript дефолтным шаблоном и выпилил поддержку Flow.

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

P.S. Несколько полезных ссылок по теме:

➡️ https://medium.com/airbnb-engineering/ts-migrate-a-tool-for-migrating-to-typescript-at-scale-cd23bfeb5cc
— Статья с примером миграции на TS у AirBnB

➡️ https://dev.to/danielhauser/convert-a-react-app-from-flow-to-typescript-without-losing-git-history-32i1
— Готовый рецепт как не потерять git-историю при изменении расширения на ts/tsx

Пролог:
Затянулось со 2й частью, но лучше поздно, чем никогда. Текста много, но и выходные впереди. И так, поехали:

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

1 - SOLID DRY KISS for YAGNI
Если кто-то увидел в этом предложении бессмысленность, не знает кто такая девушка Yagni и зачем ее вообще целовать, то не переживайте. Каждое слово - аббревиатура принципа разработки. Изучайте их по отдельности и это будет огромный буст вас, как профессионала. Основной обобщенный посыл фразы - структуризация, однозначность и четкость написанного кода.

Краткий список литературы, где можно подробнее изучить данные принципы:

SOLID - тут в первую очередь нужно идти к книгам Роберта Мартина, т.к он ввел данный термин в обиход, а конкретнее:

Agile Principles, Patterns, and Practices in C# - отличная книга. Не смотрите, что она для С# - приведенные примеры и пояснения универсальны для любого языка. Про SOLID в книге отдельная секция, где разжевывается каждая буква. Книга достойна быть прочитана от начала до конца - концепции и идеи, описанные в ней, фундаментальны и не зависят от языка и платформ.

DRY - аналогичная ситуация, в первую очередь идем к книге, которая ввела термин:

The Pragmatic Programmer: From Journeyman to Master - не устаревающая классика. Книга практическая, книга философская. Взгляд на программирование, как на искусство, где из тебя делают прекрасного и тонкого художника. То что нужно для профессионала дела.

KISS / YAGNI - тут лучше всего обращаться к книгам по чистоте кода.

Refactoring: Improving the Design of Existing Code
Clean Code: A Handbook of Agile Software Craftsmanship - обе книги являются справочниками рецептов для изменения вашего кода в лучшую сторону. Не со всеми “рецептами” нужно соглашаться, но посылы у книг правильные и нужные, поэтому они по праву считаются классикой. Если где-то увидите книги-“аналоги”, то скорее всего будет написано тоже самое только другими словами, поэтому лучше начинать именно с этих двух.

И пару книжечек, которые нельзя отнести к конкретному принципу, но концептуально про них же:

Code Complete: A Practical Handbook of Software Construction - для начинающих (да и не только) программистов маст хэв. Приучает с первых шагов к хорошему и правильному. Не всё в этой книге может нравиться, не совсем хочется соглашаться, но так и должно быть. Она учит самостоятельности и выработке собственного стиля и чувства прекрасного.

A Philosophy of Software Design - книга не для начинающих, но для ищущих новых взглядов на разработку и построение систем. Книга - микс различных тем, поэтому можно читать только секции, которые заинтересуют. Взгляд автора на некоторые вопросы не сходится с Фоулером, например, но это отлично - чем больше различных мнений, тем большим ваш кругозор. Наша цель сделать из вас профессионала, а он никогда не зациклен на одном мнении.

2 - Data Structures and Algorithms / «Структуры данных и алгоритмы»
Знание структур данных и алгоритмов помогает писать эффективный, лаконичный и понятный другим программистам код. С изучением структур и алгоритмов заметите, как будет приходить осознание и понимание работы технологий и инструментов, которые используете каждый день. Информация начнет раскладываться по полочкам сознания. К слову, при устройстве на работу в компании уровня FAANG - это маст хэв, а ребята бесполезные знания требовать не будут.

По структурам и частично алгоритмам есть бесплатный и крайне удачный курс на платформе Stepik (https://stepik.org/course/579/). Но в целом, конкретно тут тот самый случай, когда лучший способ изучения - это практика. Для этого прекрасно подходит LeetCode (https://leetcode.com/) или его аналоги. Обычно, на данных сервисах есть список разнообразных задач из практики на алгоритмистику и структуры данных с возможностью оценки вашего решения и с пояснением наилучшего для решаемой задачи.

Из книг подсказать что-то сложно, т.к их бесчисленно много, но для меня самыми полезными были:

Algorithms Illuminated - цикл книг и видео по алгоритмам (книги внизу сайта). Достаточно хорошо пояснена математическая база основных алгоритмов. Книги построены как справочник, поэтому можете выбирать нужный алгоритм и изучать конкретно его (только в первой части еще есть вводный экскурс в общую математику алгоритмистики). Часть алгоритмов охвачены в рамках курса на Stepik, который выше.

Introduction to Algorithms - сразу проговорю, что книга сложная и не для чтения перед сном, а скорее для сна 😀 Но настолько детальной книги по алгоритмам, их созданию и математической оценке, наверно, нет. Если алгоритмы нужны как часть общих знаний, то данная книга будет избыточной, пожалуй.

3 - Design Patterns / «Паттерны (шаблоны) проектирования»
Многие слышали, но далеко не все используют. А зря, ведь это готовые решения типовых задач, которые пришли проверку временем и бесконечным числом программистов. Паттерны абстрактны, поэтому применимы вне зависимости от языка программирования и его парадигмы. Да, паттернов много, все и не упомнить, но это и не нужно. Воспринимайте паттерны как справочник с ответами на общие вопросы, но который нужно хотя раз пробежать глазами, чтобы вообще быть в курсе какие вопросы есть и какие готовые ответы предлагают. На практике из ходовых вам нужно знать штук 7-10.

Design Patterns: Elements of Reusable Object-Oriented Software - вечная классика, неповторимый оригинал. Все основные паттерны сформулированы и задокументированы в этой книге. Возможно слишком строгая и формальная, поэтому ниже несколько более осовремененные варианты:

Agile Principles, Patterns, and Practices in C# - книгу уже рекомендовал выше, но тут есть отдельная секция с основными и наиболее “рабочими” паттернами.

Refactoring.Guru - очень удобный сайт, если нужно быстро вспомнить нужный паттерн. С картинками, примерами и отсылками на другие паттерны. То что нужно для повседневного использования.

Patterns.dev - справочник паттернов написанных на JavaScript и частично на React.

Среда, мои программисты. Раздаём всем фруктов сегодня:

https://v.thecode.media/7pfwi

#пб_Код

roadmap.sh

Этот сайт предоставляет дорожные карты, рекомендации и другой образовательный контент, чтобы помочь разработчикам выбрать путь и направить свое обучение. Особенно полезно для новичков.

Немного расширим кругозор в построении архитектур приложений или проще говоря в системном дизайне. Ниже полезная статья про частный пример Event-Driven архитектуры для реального приложения. Статья расскажет как организовать EDA с медиатором с использованием Kubernetes и AWS:

➡️ https://www.infoq.com/articles/eda-mediator/

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

#architecture #systemdesign

Если в твоей голове каша с браузерным кешем, то статья ниже поможет разобраться:

➡️ https://devcenter.heroku.com/articles/increasing-application-performance-with-http-cache-headers

От себя:
В статье выше покрыты основные моменты с кешем которых хватит для 99% задач. Для оставшегося 1% можно посмотреть описание всех свойств Cache-Control хедера (тыц) или уже гуглить свой конкретный кейс.

P.S. Если у вас на проекте NestJS, то можно поиграться с CacheInterceptor, как тут

Prettier выпустил мажорную версию 3.0.0! Изменений много, все перечислены тут:

➡️ https://prettier.io/blog/2023/07/05/3.0.0.html

От себя:
Очень большой релиз. Команда внесла много breakage изменений, поэтому обновляться нужно осторожно и точно отдельной полноценной задачей.

Из существенного можно отметить:

#1 Теперь trailingComma:”all” по-дефолту. Вернуть дефолтное поведение 2й версии можно выставив trailingComma:”es5”. Если говорить в целом, то я выставляю trailingComma:”none”, т.к. не вижу никаких преимуществ в запутывающей запятой. Кто-то скажет, что это помогает быстрее писать код (якобы не нужно постоянно думать поставил запятую в конце объекта/массива/функции/типа и т.д - она будет добавляться автоматом, если правильно настроены автофиксеры), но мне этого не понять, т.к. мы вроде как не машинистки, а программисты. Наше основное затраченное время - это мыслительные процессы, а не печатание 🙂

#2 Выпилили поддержку Flow специальных комментариев для Flow. Слишком мало кто использует Flow и их директивы, а код поддерживать нужно - решили в мусорку, чем затраты времени. Как ранее писал (тыц1, тыц2), переезжайте на TypeScript и будет вам счастье

#3 Неплохо улучшили поддержку TS. Добавили много приятных изменений/фиксов для форматирования типов, ключевых слов и т.д. Бывало такое, что после пробежки Prettier-ом типы становились менее читаемыми, чем хотелось бы. Новая версия должна помочь

Любой веб-разработчик рано или поздно сталкивается с CSS. Но речь ниже пойдет не про новые свойства или новомодные CSS-приемы (для этого есть прекрасный https://css-tricks.com/), а про организацию стилей в вашем приложении. Возможно, термин «организация стилей» может прозвучать громче, чем будет на самом деле 😁

С незапамятных времен разработчики пытались превратить необъятную массу селекторов и CSS-файлов в лаконичную структуру. Многие из вас слышали про методологии организации CSS. Проговаривать и пояснять за каждую здесь не буду, а приведу ссылки для общего ознакомления (тыц1, тыц2). Как видно из статей, основные методологии - это BEM, OOCSS, SMACSS, Atomic CSS. Но хоть они и существуют сколько существует CSS, по инфографике от https://stateofcss.com/ о них знает оптимистично не более 2/3 опрошенных разработчиков (тыц1, тыц2). Забавный момент, что CSS-методологии исключили из опроса начиная с 2021 года (или еще не успели добавить результаты?). Но по тренду 2019->2020 видно, что он снисходящий. Тема становиться менее неактуальной для разработчиков на сегодня, поэтому нет большого смысла углубляться и разбираться в нюансах каждой их методологий 👹

Но вопрос так и остается открытым - как же организовать свои стили, чтобы предотвращать дублирование, перекрытие стилей и по максимуму переиспользовать существующие? Ответ на вопрос можно грубо разделить на две категории:

1. Использовать готовые фреймворки (тыц на наиболее популярные за 2022 год)

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

2. Автосборочные решения

В настоящий момент наиболее ходовой подход к автосборке и генерации CSS - это пре-/пост-процессоры (тыц на наиболее популярные за 2022 год) и CSS-in-JS (тыц на наиболее популярные за 2022 год).

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

На счет организации стилей в приложении: самая простая и мощная структура - держать стили максимально близко к месту их использования. Идеально - в рамках одной папки или в файле с компонентом. Примеры таких организаций стилей: тыц1, тыц2, тыц3. Но проекты у всех разные, поэтому гуглите конкретно под свою ситуацию и/или читайте рекомендации по стилям к вашим фреймворкам (пример для next.js)

#css

Бонус: Stylelint

Говоря про стили, нельзя не упомянуть Stylelint. Как и основной код, описанные стили требуют проверки на корректность и упорядоченность. Если с вопросом проверки проблем не возникает, т.к вполне достаточно использовать stylelint-config-standard с уже готовым выстраданным набором правил, то с порядком свойств не всё так однозначно ведь он тревожит умы не первый десяток лет (тыц на пост за 2012 год). Но под самым популярным Grouped by type каждый понимает своё.

На сегодня существует несколько вариантов порядка стилей с готовой конфигурацией для Stylelint. Для удобства ссылки на модули приведу в инфографике на npmtrends. Расписывать про каждую не буду, но лично мне больше всего импанируют stylelint-config-property-sort-order-smacss, stylelint-config-recess-order и stylelint-config-concentric-order. Они отличаются незначительными деталями, но их объединяет общая идея - модель упорядочивания свойства. Первоочередно идут те свойства, которые влияют на то, как элемент вписан в страницу к свойствах изменяющим внешний вид элемента

#css #stylelint

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

➡️ https://blog.bitsrc.io/websockets-vs-server-sent-events-968659ab0870

От себя:
Вообще, задался вопросом про удобство SSE после прочтения лонгрида (тыц) о разработке дизайна системы для «живых комментариев» (aka комментарии к Live-трансляциям). Дизайн применим к любому высоконагруженному сервису с живым комментированием такие как YouTube, Twitch, Facebook, и т.д. В статье довольно подробно описано почему выбран именно SSE, а не другие альтернативы (про них тоже рассказано). Пересказать всё сложно, лучше прочитать самому. Но в голове нужно держать мысль, что не только вебсокетами едины и есть альтернативы.

Из личного опыта проблем с вебсокетами могу отметить две:

1. Скейлинг вебсокет-серверов. А точнее его отсутствие из коробки
Если не хочется тянуть сторонние библиотеки, то решить проблему получится только написав свою 🙃 Со сторонними библиотеками скейлинг настроить можно (например, у socket.io за это отвечает адаптер), но это требует лишних усилий как разработчика, так и девопса.
К слову, в свое время socket.io mongodb adapter работал некорректно и в итоге пришлось написать свой.

2. Несовместимость с proxy-серверами
Зачастую прокси-сервера просто не поддерживают вебсокеты из-за их технической природы (вебсокеты идут поверх TCP, что усложняет поддержку для прокси-серверов). Поэтому, опять приходится прибегать к сторонним решениям с поддержкой long-polling, как у вышеупомянутого socket.io (тыц)

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

Задача сборки фронтенда стара как мир. С давних времен стандартом для этого служит webpack. Он используется практически повсеместно, во много известном софте. Но его основная проблема - медлительность. На сегодня есть достойные конкуренты в лице Vite, Parcel.js, Rollup.js и т.д, но проблема общая - проблема переезда существующего приложения с webpack на альтернативу. Такая задача может отнять неподъемное количество времени и быть скорее в тягость, нежели в удовольствие. Но, что если появится быстрый сборщик совместимый с webpack-конфигурацией?

И такой нашелся! Встречайте rspack:

➡️ https://blog.stackademic.com/rust-port-of-webpack-rspack-the-new-kid-on-the-block-c3a3de569bfb

Да, пока мажорная версия 0 намекает на "сырость", но потенциал огромен. rspack написан на Rust, что дает огромный буст в скорости сборки по сравнению с JS-овским webpack. Если бегло гуглить статьи от переезжающих с webpack на rspack, то загвоздки хоть и есть, но они решаются. Поэтому, если задаетесь целью соскачить с медленного webpack на что-то более современное, то rspack может стать отличным вариантом

Как вызвать черную дыру на практике:

Эксперимент с созданием NPM-пакета, зависимого от всех пакетов в репозитории https://opennet.ru/60392/

Немного чтива на выходные:

➡️ https://tontinton.com/posts/database-fundementals/

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