Комментарии 24
НЛО прилетело и опубликовало эту надпись здесь
Проще указать что же осталось в итоге от ангуляра. Кажется, что только сама структура: возможность написания сервисов, директив и контроллеров.
Было бы интересно почитать о том, как происходил выбор либ и прочего.
Статья супер!
Было бы интересно почитать о том, как происходил выбор либ и прочего.
Статья супер!
Можно уточнить смысл (<|<), (>|>|\\s) и (>|>) в регулярках? Выглядит как бесполезное усложнение.
Не рассматривали angularlight? Ну или knockout, vue или что-то ещё компактное и обеспечивающее только биндинги с DOM (остальное вы всё равно отрезали от оригинального ангуляра, насколько я понял).
Разумеется рассматривали и Angular Light и Vue.js и даже были маниакальные идеи переписать все на чистый JS.
Но отправной точкой послужило почти готовое и протестированное приложение на AngularJS.
С точки зрения рисков, мы оценили, что переписать приложение на другой JS фреймворк против доработать (зарефачить) готовую кодовую базу значительно проигрывает по трудозатратам.
В любом случае, код для http-запросов, роутингу, скролу и т.д. пришлось бы писать свой, а «кастрация» AngualrJS до состояния более легковесных фреймворков занимает, уж поверьте, очень мало времени.
Если же за отправную точку взять старт проекта, то тут разумеется выбор бы пал на Vue.js, сообщество Angular Light показалось нам каким-то полумертвым, а готовых модулей для http-запросов и роутинга днем с огнем не сыщешь.
Но отправной точкой послужило почти готовое и протестированное приложение на AngularJS.
С точки зрения рисков, мы оценили, что переписать приложение на другой JS фреймворк против доработать (зарефачить) готовую кодовую базу значительно проигрывает по трудозатратам.
В любом случае, код для http-запросов, роутингу, скролу и т.д. пришлось бы писать свой, а «кастрация» AngualrJS до состояния более легковесных фреймворков занимает, уж поверьте, очень мало времени.
Если же за отправную точку взять старт проекта, то тут разумеется выбор бы пал на Vue.js, сообщество Angular Light показалось нам каким-то полумертвым, а готовых модулей для http-запросов и роутинга днем с огнем не сыщешь.
Интересно, что вы описали, сколько времени это у вас заняло: около 10%. По моим ощущениям, для оптимизации программ до «приемлемого» состояния у меня обычно уходит процентов 30 времени, но все равно это намного меньше, чем люди обычно себе представляют, когда им предлагают оптимизировать свой код.
Делать пул xhr объектов целесообразно сейчас для обычных браузеров? Пусть, например, веб-сайт собирается посылать по запросу раз в 10 секунд и работать в таком режиме пару дней на компьютере. Если реализовать переиспользование xhr, получится ли выигрыш по памяти, занимаемой вкладкой? Или gc всё сделает хорошо, и приём в статье нужен чисто потому, что оперативки ксерокса хватаешь лишь на считанные минуты, и gc не успевает всё подмести?
В обычной веб-разработке целесообразность не то чтобы нулевая, а скорее отрицательная, так как все параллельные запросы выстроятся в очередь и приложение станет менее отзывчивым. Про потребление памяти XHR тоже не беспокойтесь, а вот контент оптимизируйте.
Если же ваше приложение работает на специфичной платформе с ограниченным количеством ОЗУ, то тут вам повезло — мы собрали грабли и поделились кодом.
Если же ваше приложение работает на специфичной платформе с ограниченным количеством ОЗУ, то тут вам повезло — мы собрали грабли и поделились кодом.
Насчет отзывчивости — я понимаю, да. Но, во-первых, для борьбы с неконтролируемым распуханием вкладки, отзывчивостью можно частично пожертвовать, а во-вторых, всегда можно дселать пул такого размера, чтобы вероятность простаивания была крайне мала. Но спасибо за ответ, похоже, что вы правы, и xhr не входит в основные причины утечек.
НЛО прилетело и опубликовало эту надпись здесь
Что у вас вообще осталось от ангуляра-то? :-)
Мне кажется, что в вашем случае preact(preactjs.com) был бы адекватнее.
> из исходной xml (которая нам пришла в виде строки) мы с помощью регулярного выражения “вынимаем” только тот тег, который нам интересен
А это не является грязным хаком?
А это не является грязным хаком?
Есть запрос к soap-сервисам, который возвращают несколько десятков килобайт данных о самом МФУ, но из этого набора данных нужна всего лишь информация, поддерживает МФУ листы формата А3 или нет. Такая же история и в момент постановки документа на печать — интересен только статус задачи, а не килобайты балластных для нас данных.
Разумеется это грязный хак, но вынужденный — приоритет находится на стороне потребления памяти, а не красоты и универсальности решения.
Разумеется это грязный хак, но вынужденный — приоритет находится на стороне потребления памяти, а не красоты и универсальности решения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
А ваш AngularJS умеет работать на 3.5Mb ОЗУ?