История изменений

Ну, с поправкой на время, это можно простить. Да и это был всего лишь пример, как я понял.

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

Как мне тонна зависимостей в npm решит эту проблемы? Или тонна жирных class-файлов?

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

Ну, с поправкой на время, это можно простить. Да и это был всего лишь пример, как я понял.

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

Как мне тонна зависимостей в npm решит эту проблемы? Или тонна жирных class-файлов?

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

Ну, с поправкой на время, это можно простить. Да и это был всего лишь пример, как я понял.

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

Как мне тонна зависимостей в npm решит эту проблемы? Или тонна жирных class-файлов?

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