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

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

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

Ленивая загрузка - это принцип, который должен быть известен большинству frontend разработчиков. Однако, этот механизм обманчиво прост, и его освоение является гораздо более комплексной задачей, чем кажется многим. Если уже используете Lazy Loading, у вас все равно могут быть серьезные пробелы в знаниях. Но даже если вы считаете, что знаете про ленивую загрузку абсолютно все, освежить память не будет лишним.

В этой статье мы рассмотрим основы ленивой загрузки: что это такое и почему это важно;
как мы можем использовать ленивую загрузку в наших проектах; а также какие части кода следует загружать лениво.

Относительно недавно в TC39 предложение с реализацией декораторов в EcmaScript вышло на 3-ю пред финальную стадию. Чуть позже MicroSoft выпустил 5-ю мажорную версию TypeScript, в которой новая реализация декораторов начала работать из коробки без каких-либо экспериментальных флагов. Babel тоже подсуетился, и в своей документации начал рекомендовать использовать новую реализацию декораторов. А это означает лишь то, что декораторы наконец-то начали полноценно входить в жизнь JavaScript разработчиков.

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

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

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

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

В статье вы увидите бенчмарк производительности EcmaScript фич; узнаете какой из компиляторов генерирует самый производительный JavaScript код; а также можно ли добиться прироста производительности, начав собирать сайт в более поздней версии ES.

Однажды я захотел создать небольшую NPM библиотеку по всем “best practices” - с покрытием тестами, написанием документации, ведением нормального версионирования и changelog'а и т.п. Даже написал пару статей, которые в деталях описали, какие вопросы решает библиотека и как её использовать. И одной из интересных для меня меня задач при создании библиотеки была задача по максимальному уменьшению размера выходного NPM пакета - того, что в конечном итоге в теории будет использовать другой программист. И в этой статье я бы хотел описать, к каким методам я прибегал для того, чтобы достигнуть желанной цели.

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

В этой статье я бы хотел подискутировать о том, насколько хорошо паттерн MVVM подходит для разработки Web приложений на React. Вместе этим, я собираюсь описать какие преимущества могут быть при разработке с использованием MobX с паттерном MVVM в сравнении с Redux. Запаситесь кофе, это будет долгое чтиво.

Стало мне как-то интересно, кто из языков Go или Rust лучше работает с конкурентными задачами. С одной стороны, особый механизм конкурентности в Go является чуть ли основополагающей фичей. С другой стороны сам по себе Rust является более производительным языком, и в глазах некоторых программистов даже является "убийцей" C и C++. Поэтому я решил провести небольшое тестирование и написать собственный бенчмарк для этого.

Для упрощения я буду горутины в Go и асинхронные задачи в Rust называть корутинами. Для проверки различные тесты запускались на количестве корутин 10¹, 10², ..., 10⁶. Смысл тестирования заключается в том, чтобы определить, какой из языков решит задачу наиболее быстро. По затраченному времени на выполнение задачи можно судить не только о скорости работы языка, но и том, насколько он страдает от большого количества конкуретных задач. Также в каждом тесте записывалась потребляемая память.

Содержание

• Основные различия
• Reproducibility crisis
• Система контроля версий
• Data Version Control
• Полезные ссылки

Введение

Несмотря на всю пользу DVC, об этом инструменте знает катастрофически мало разработчиков. Поэтому, думаю, не лишним будет для начала вас познакомить. DVC – это open-source система контроля версий данных, которая отлично подходит для машинного обучения. И основное отличие DVC от Git’a в том, что он: во-первых, имеет более широкий и удобный инструментарий для ML-проектов; во-вторых, создан для контроля версий данных, а не кода. И по большей части здесь их основные различия заканчиваются. А далее я постараюсь описать, чем же так хорош DVC, и почему Git'а не достаточно для ML.