Есть ли динамические загрузчики модулей/модульные системы, которые позволяют прозрачно и выгружать модули из коробки?
Думаю чем забить свой новосозданный github, в роли портфолио и перерываю свои относительно давние кодинги в поиске чего то небольшого и интересного, что можно облагородить и закомитить как code-sample.
Существуют ли уже модульные загрузчики, которые отслеживают не только модульные связи при загрузке, но и при выгрузке модулей?
Конечно, "выгрузить" вручную модуль можно через хаки (почистить ссылки во внутреннем кеше загрузчика) с тем же AMD и requireJS, но только на свой страх и риск и только сам модуль, а не его ссылку, т.е нужно самому контролировать его зависимости в таком случае.
Вообщем ищу "конкурентов" с похожей философией (чтоб с ними ознакомится) на свой, который 3 года назад мне взбрело в голову накодить, где на каждый load/use/requiere/*, который возвращает экземпляр модуля, был некий парный метод release()- если все ссылки закрылись - значит через через время вызываем, если есть, метод модуля uninitialize, дабы он смог подчистить после себя, выкидываем из кеша модуль, внутренние ссылки зануляем, мусорщик потом убивает, все прекрасно...=)
Александр Таратин: ну как зачем? =)
Имхо, память какая не есть- не безгранична и не нужно ее забивать из за лени. Особо ничего не усложняет с точки зрения пользования, то почему бы не освобождать? Более менее сложное приложение может сотни мб отжать, если долго не перезагружать SPA, даже без утечек выглядит прожорливо. А сколько из загруженного нужно приложению в отдельный момент времени?
Да и без этого не написать масштабированную клиентскую архитектуру - всегда будет предел. А если вспомнить что есть мобильные клиенты у которых 256мб-4гб, то еще больше обязывает искать решения. В принципе, для маленьких приложений не столь критично, но тогда не построить серьезную cms с spa архитектурой, а к этому все ровно придем. Если можно выгрузить неиспользуемое - почему бы нет? =)
Digital Brain: >приложение может сотни мб отжать
Могу представить только один случай - результат компиляции unity3d в webgl таргет, и тот с натяжкой.
Данные могут и несколько гигов отжать спокойно, но никак не сами модули. Но тут же не поможет загрузчик. Или я не понял вас?
Александр Таратин: ну вообщем то да, сами сущности что создаются при загрузке и через module.exports передаются вряд ли много займут по сравнению с данными гигового пула самого приложения, но все ровно же займут. Будет какой то момент при увеличении их количества, при котором уже можно упереться в предел, либо просто замечать последствия накапливающегося мусора в памяти.
Почему то по аналогии в прикладном программировании делают выгрузку dll скажем, хотя она сущие пустяки в памяти сама по себе занимает. Просто пока в веб оно и "так работает"=)
5 лет назад и текущее положение дел казалось вполне невероятным, а ведь клиент будет продолжать усложнятся семимильными шагами в направлении десктопных приложений.
Digital Brain: >Будет какой то момент при увеличении их количества, при котором уже можно упереться в предел,
Нет. В предел упремся на этапе работы с данными, а не загрузки новых модулей.
>либо просто замечать последствия накапливающегося мусора в памяти.
При штатной работе никакого мусора в памяти быть не должно. Если что-то течет, то 99,999% виноват разработчик и никакой умный загрузчик это не исправит.
>в прикладном программировании делают выгрузку dll скажем
Можно пример прикладного приложения выпущенного в ближайшие 10 лет, занимающегося чем то подобным?
Я наблюдаю напротив лишь желание перейти от динамической линковки в пользу статической (go, некоторые из backend dlang).
У вас модуль, получается, это и файл, и бизнес-сущность. В общем случае это, на самом деле, разные вещи. Например, может существовать два инстанса одного и того же виджета. Поэтому загрузчики отдельно, архитектура отдельно, и это правильно. А с приходом нативных модулей в ES2015 (и загрузчиков для них) нет смысла изобретать велосипеды.
