Ага. Я понял о чем вы. Можно и так сделать. Опять же это потом не так уж сложно, может быть даже проще php скриптик сделать, который будет собирать всё по урл типа /get-js.php?jpack.system.out&jpack.system.url&jpack.utils.datetime и кешировать. Чтобы руками не собирать каждый раз. Сделать реализации такого backend файла для основных языков и вперёд.
> При таком подходе у вас никак не получится сделать оптимизацию, если будут грузится файлы.
Повторяюсь, наверное при любом механизме загрузки файлов не «в лоб», а через параметр какой-нибудь функции, думаю есть возможность это все оптимизировать именно в этой самой функции, но потом.
> А по теме, вспомогательные функции хранить в одном файле и не парится.
Ну скажите это java и go разработчикам — думаю там не просто так это сделано. А париться надо, иначе как новое изобретать?
> Вы хотите все эти 100 модулей вытащить в кучу вызовов load'а куда-нибудь в head?
Боже мой, конечно нет. jpack — это скорей не компановщик ваших «кастомных» js файлов для проекта (под этим я понимаю допустим обработку событий для кликов, отправку формы и пр. js-код для обычного функционирования проекта, т.е. для реализации, наверное, бизнес-логики или просто для функционирования интерфейса в общем понимании). Т.е. в java, конечно, вроде бы все пакетами делается, в моём случае предполагается для начала, что jpack — это скорее набор разных библиотек, например как в go golang.org/pkg/ Что-то вроде того.
> jquery как бы тоже не решает проблем при разработке сложных масштабируемых(в плане разработки) проектов. Это же просто нормальный апи для дома.
Ну я в общем плане говорил. Нет панацеи ни для чего — Вы должны это понимать. Как раз, наверное, requirejs + jquery даст лучший эффект для структурирования файлов вашего приложения. jpack — это не просто загрузчик файлов.
> Как раз это YUI и реализует, ничего более ;) Просто к этому добавлена куча уже написаных модулей, можно их даже не использовать.
Ну, тогда я его посмотрю, может я и действительно велосипед сделал. ;)
Не спорю, что это важно, но пока что это не готовая библиотека, а скорее, прототип. Я же писал, что оптимизация — это то, что можно сделать всегда, лишь бы только небольшой задел для неё оставить.
Сейчас я хочу сконцентрироваться именно на пользовательском интерфейсе и понять — стоит ли игра свеч. Хочется, чтобы пользоваться jpack было очень удобно — считаю это очень важно.
Про конструктор к сожалению не понял. Если можете — поясните примером.
Я к тому, что на самом деле хочется где-нибудь в head видеть что на странице подключено, про YUI3 понял, посмотрю, но… только для того, чтобы сделать мир лучше обучиться и прокачать свою либу. Ведь jQuery тоже когда-то не было, а все считали, что чистый js весьма нормален. Ну и повторюсь, что YUI это немного не то, что хочу сделать я. Хочется сделать хорошо компанованные пакеты с возможностью быстро и просто дописывать новый функционал.
Юзать сторонние вещи — не грех, не спорю. Но часто вы копаетесь в исходниках jQuery или YUI? А если не копаетесь, возникает меньше проблем и, соответственно, не думаете над их решением. Плюс разве это сделать что-лучше того, что уже есть такая неразрешимая задача? Все зависит от хотелки.
Вам огромное спасибо за указанное направление для развития. Почитаю что да как и сделаю.
Про большое кол-во файлов я писал в конце поста. Про load спасибо, проглядел. По поводу галочек — повторюсь, что тут фича именно в том, что все разложено по «полочкам», каждый метод в своем как-бы «пространстве имен». Сделать компоновщик — дело десятое. Суть идеи не в этом.
По сути эта библиотека позволит сообществу составить целые пакеты для общего пользования различных направленностей. Т.е. допустим, кто-то дописывает пакет system и добавляет модуль jpack.system.utils.math для расчета чего-то более сложного, нежели позволяет стандартная библиотека. А потом все этим пользуются. (Да вот такая утопия)
Стоит понимать, что фича библиотеки не в загрузке файлов — это дело десятое. Фича — жесткая регламентированная компоновка по пакетам и модулям и ни шагу в сторону.
Каюсь, как-то не задалось. Если идея окажется интересна людям и будет смысл её развивать, то прочитаю о загрузчиках как можно раньше. Так как все силы не на это направлены пока что.
Я его смотрел. Боюсь ошибиться, но вроде как он по-другому работает и несколько другую задачу решает. Там скорее именно подгрузка файлов, причем вроде как любых, а не более жесткая стандартизация, но может, и ошибаюсь, конечно. И настройка там вроде по-сложнее немного.
Повторяюсь, наверное при любом механизме загрузки файлов не «в лоб», а через параметр какой-нибудь функции, думаю есть возможность это все оптимизировать именно в этой самой функции, но потом.
> А по теме, вспомогательные функции хранить в одном файле и не парится.
Ну скажите это java и go разработчикам — думаю там не просто так это сделано. А париться надо, иначе как новое изобретать?
Боже мой, конечно нет. jpack — это скорей не компановщик ваших «кастомных» js файлов для проекта (под этим я понимаю допустим обработку событий для кликов, отправку формы и пр. js-код для обычного функционирования проекта, т.е. для реализации, наверное, бизнес-логики или просто для функционирования интерфейса в общем понимании). Т.е. в java, конечно, вроде бы все пакетами делается, в моём случае предполагается для начала, что jpack — это скорее набор разных библиотек, например как в go golang.org/pkg/ Что-то вроде того.
> jquery как бы тоже не решает проблем при разработке сложных масштабируемых(в плане разработки) проектов. Это же просто нормальный апи для дома.
Ну я в общем плане говорил. Нет панацеи ни для чего — Вы должны это понимать. Как раз, наверное, requirejs + jquery даст лучший эффект для структурирования файлов вашего приложения. jpack — это не просто загрузчик файлов.
> Как раз это YUI и реализует, ничего более ;) Просто к этому добавлена куча уже написаных модулей, можно их даже не использовать.
Ну, тогда я его посмотрю, может я и действительно велосипед сделал. ;)
Сейчас я хочу сконцентрироваться именно на пользовательском интерфейсе и понять — стоит ли игра свеч. Хочется, чтобы пользоваться jpack было очень удобно — считаю это очень важно.
Про конструктор к сожалению не понял. Если можете — поясните примером.
мир лучшеобучиться и прокачать свою либу. Ведь jQuery тоже когда-то не было, а все считали, что чистый js весьма нормален. Ну и повторюсь, что YUI это немного не то, что хочу сделать я. Хочется сделать хорошо компанованные пакеты с возможностью быстро и просто дописывать новый функционал.Юзать сторонние вещи — не грех, не спорю. Но часто вы копаетесь в исходниках jQuery или YUI? А если не копаетесь, возникает меньше проблем и, соответственно, не думаете над их решением. Плюс разве это сделать что-лучше того, что уже есть такая неразрешимая задача? Все зависит от хотелки.
Вам огромное спасибо за указанное направление для развития. Почитаю что да как и сделаю.
По сути эта библиотека позволит сообществу составить целые пакеты для общего пользования различных направленностей. Т.е. допустим, кто-то дописывает пакет system и добавляет модуль jpack.system.utils.math для расчета чего-то более сложного, нежели позволяет стандартная библиотека. А потом все этим пользуются. (Да вот такая утопия)
Стоит понимать, что фича библиотеки не в загрузке файлов — это дело десятое. Фича — жесткая регламентированная компоновка по пакетам и модулям и ни шагу в сторону.