Комментарии 31
Я его смотрел. Боюсь ошибиться, но вроде как он по-другому работает и несколько другую задачу решает. Там скорее именно подгрузка файлов, причем вроде как любых, а не более жесткая стандартизация, но может, и ошибаюсь, конечно. И настройка там вроде по-сложнее немного.
0
Почему вы не разобрались с существующими решениями перед тем как делать что-то своё?
Вообще советую взглянуть на пути развития загрузчика в YUI3, втч и различные варианты от которых отказались — такие как remote loading server. Ну чтобы примерно понимать с чем имеешь дело, тк то что у вас сейчас реализовано практически полностью сделано неправильно.
Вообще советую взглянуть на пути развития загрузчика в YUI3, втч и различные варианты от которых отказались — такие как remote loading server. Ну чтобы примерно понимать с чем имеешь дело, тк то что у вас сейчас реализовано практически полностью сделано неправильно.
+2
Каюсь, как-то не задалось. Если идея окажется интересна людям и будет смысл её развивать, то прочитаю о загрузчиках как можно раньше. Так как все силы не на это направлены пока что.
+2
Для начала надо сделать правильное подключение «пакетов», а потом решать проблему динамической загрузки. А ещё лучше создавать песочницы, внутри которых исполнять содержимое «пакетов».
Например в YUI3 это работает так:
YUI() — возвращает новую песочницу
.use() — подключает пакеты и все их зависимости, а потом исполняет коллбэк, параметром которого является песочница.
Далее чтобы добавить пакет в систему, нужно выполнить функцию YUI.add(функция объекта YUI, а не сконструированой песочницы)
Используя такую конструкцию мы можем асинхронно подгружать жаваскрипты и у нас не будет проблемы с тем что какой-то пакет загрузился раньше другого, тк исполнение будет отложено до момента создания песочницы и вызова use(), а в этот момент в системе уже будет присутствовать вся деревяшка пакетов. Часть пакетов может тупо не отрабатывать, используя что-нибудь вроде проверок на фичи браузера(например если у нас нет нативной реализации транзишенов, то подключать пакет, если есть, то просто не отрабатывать его подключение).
А с динамической загрузкой всё ещё гораздо сложнее ;)
Например в YUI3 это работает так:
YUI().use('pkg-one', 'pkg-two', function(Y) {
Y.abc ...
});
YUI() — возвращает новую песочницу
.use() — подключает пакеты и все их зависимости, а потом исполняет коллбэк, параметром которого является песочница.
Далее чтобы добавить пакет в систему, нужно выполнить функцию YUI.add(функция объекта YUI, а не сконструированой песочницы)
YUI.add('pkg-one', function(Y) {
Y.pkg_one = 123;
}, '0.0.1', {'requires': 'pkg-base'});
Используя такую конструкцию мы можем асинхронно подгружать жаваскрипты и у нас не будет проблемы с тем что какой-то пакет загрузился раньше другого, тк исполнение будет отложено до момента создания песочницы и вызова use(), а в этот момент в системе уже будет присутствовать вся деревяшка пакетов. Часть пакетов может тупо не отрабатывать, используя что-нибудь вроде проверок на фичи браузера(например если у нас нет нативной реализации транзишенов, то подключать пакет, если есть, то просто не отрабатывать его подключение).
А с динамической загрузкой всё ещё гораздо сложнее ;)
0
Т.е. вы предлагаете в данном примере github.com/arturgspb/jpack/blob/master/example/utils.html в обоих jpack.run указывать какие пакеты/модули им нужны? Я правильно понял?
0
Нет, я предлагаю начать с создания песочниц, отложеного запуска модулей с поддержкой davidwalsh.name/html5-async на уровне конструкций модулей, а не самой загрузки.
А вообще просто начните использовать YUI3, там все эти проблемы уже давно решены ;)
А вообще просто начните использовать YUI3, там все эти проблемы уже давно решены ;)
+1
Я к тому, что на самом деле хочется где-нибудь в head видеть что на странице подключено, про YUI3 понял, посмотрю, но… только для того, чтобы сделать мир лучше обучиться и прокачать свою либу. Ведь jQuery тоже когда-то не было, а все считали, что чистый js весьма нормален. Ну и повторюсь, что YUI это немного не то, что хочу сделать я. Хочется сделать хорошо компанованные пакеты с возможностью быстро и просто дописывать новый функционал.
Юзать сторонние вещи — не грех, не спорю. Но часто вы копаетесь в исходниках jQuery или YUI? А если не копаетесь, возникает меньше проблем и, соответственно, не думаете над их решением. Плюс разве это сделать что-лучше того, что уже есть такая неразрешимая задача? Все зависит от хотелки.
Вам огромное спасибо за указанное направление для развития. Почитаю что да как и сделаю.
Юзать сторонние вещи — не грех, не спорю. Но часто вы копаетесь в исходниках jQuery или YUI? А если не копаетесь, возникает меньше проблем и, соответственно, не думаете над их решением. Плюс разве это сделать что-лучше того, что уже есть такая неразрешимая задача? Все зависит от хотелки.
Вам огромное спасибо за указанное направление для развития. Почитаю что да как и сделаю.
0
>в head видеть что на странице подключено
кхм, даже в небольшом проектике у меня кол-во используемых модулей >100 (yui+мои). Вы хотите все эти 100 модулей вытащить в кучу вызовов load'а куда-нибудь в head?
>Ведь jQuery тоже когда-то не было, а все считали, что чистый js весьма нормален.
jquery как бы тоже не решает проблем при разработке сложных масштабируемых(в плане разработки) проектов. Это же просто нормальный апи для дома.
>Хочется сделать хорошо компанованные пакеты с возможностью быстро и просто дописывать новый функционал.
Как раз это YUI и реализует, ничего более ;) Просто к этому добавлена куча уже написаных модулей, можно их даже не использовать.
>Плюс разве это сделать что-лучше того, что уже есть такая неразрешимая задача? Все зависит от хотелки.
Разрешимая, я например для своих экспериментов с загрузчиками как раз использую YUI по причине что у них уже написана и отлично задокументирована громадная куча модульного кода. Просто компилирую всю либу со своими модификациями и подставляю свою реализацию YUI объекта.
кхм, даже в небольшом проектике у меня кол-во используемых модулей >100 (yui+мои). Вы хотите все эти 100 модулей вытащить в кучу вызовов load'а куда-нибудь в head?
>Ведь jQuery тоже когда-то не было, а все считали, что чистый js весьма нормален.
jquery как бы тоже не решает проблем при разработке сложных масштабируемых(в плане разработки) проектов. Это же просто нормальный апи для дома.
>Хочется сделать хорошо компанованные пакеты с возможностью быстро и просто дописывать новый функционал.
Как раз это YUI и реализует, ничего более ;) Просто к этому добавлена куча уже написаных модулей, можно их даже не использовать.
>Плюс разве это сделать что-лучше того, что уже есть такая неразрешимая задача? Все зависит от хотелки.
Разрешимая, я например для своих экспериментов с загрузчиками как раз использую YUI по причине что у них уже написана и отлично задокументирована громадная куча модульного кода. Просто компилирую всю либу со своими модификациями и подставляю свою реализацию YUI объекта.
0
> Вы хотите все эти 100 модулей вытащить в кучу вызовов load'а куда-нибудь в head?
Боже мой, конечно нет. jpack — это скорей не компановщик ваших «кастомных» js файлов для проекта (под этим я понимаю допустим обработку событий для кликов, отправку формы и пр. js-код для обычного функционирования проекта, т.е. для реализации, наверное, бизнес-логики или просто для функционирования интерфейса в общем понимании). Т.е. в java, конечно, вроде бы все пакетами делается, в моём случае предполагается для начала, что jpack — это скорее набор разных библиотек, например как в go golang.org/pkg/ Что-то вроде того.
> jquery как бы тоже не решает проблем при разработке сложных масштабируемых(в плане разработки) проектов. Это же просто нормальный апи для дома.
Ну я в общем плане говорил. Нет панацеи ни для чего — Вы должны это понимать. Как раз, наверное, requirejs + jquery даст лучший эффект для структурирования файлов вашего приложения. jpack — это не просто загрузчик файлов.
> Как раз это YUI и реализует, ничего более ;) Просто к этому добавлена куча уже написаных модулей, можно их даже не использовать.
Ну, тогда я его посмотрю, может я и действительно велосипед сделал. ;)
Боже мой, конечно нет. jpack — это скорей не компановщик ваших «кастомных» js файлов для проекта (под этим я понимаю допустим обработку событий для кликов, отправку формы и пр. js-код для обычного функционирования проекта, т.е. для реализации, наверное, бизнес-логики или просто для функционирования интерфейса в общем понимании). Т.е. в java, конечно, вроде бы все пакетами делается, в моём случае предполагается для начала, что jpack — это скорее набор разных библиотек, например как в go golang.org/pkg/ Что-то вроде того.
> jquery как бы тоже не решает проблем при разработке сложных масштабируемых(в плане разработки) проектов. Это же просто нормальный апи для дома.
Ну я в общем плане говорил. Нет панацеи ни для чего — Вы должны это понимать. Как раз, наверное, requirejs + jquery даст лучший эффект для структурирования файлов вашего приложения. jpack — это не просто загрузчик файлов.
> Как раз это YUI и реализует, ничего более ;) Просто к этому добавлена куча уже написаных модулей, можно их даже не использовать.
Ну, тогда я его посмотрю, может я и действительно велосипед сделал. ;)
0
А вообще то что вы пытаетесь сделать практически один в один реализовано в Google Closure Library
0
Вы положили меня на лопатки. Я сдаюсь, но не закончу свои изыскания) Вообще раньше не видел их библиотеку, как видно не я один.
0
Не советую что-либо делать с использованием их либы :) Примерно так же выглядел YUI2 много лет взад, но они решились переписать всё с нуля с учётом прежних ошибок, особенно проблемна вся та часть кода что связана с UI.
А вообще я не представляю что можно придумать лучше чем Asynchronous Module Definition , в YUI3 есть один недостаток по сравнению с AMD — это то что передаётся от модуля к модулю весь инстанс YUI песочницы, в который происходит добавление различных свойств. Но у AMD есть недостаток, это то что никто так и не сделал качественной либы вроде YUI3 с использованием AMD.
А вообще я не представляю что можно придумать лучше чем Asynchronous Module Definition , в YUI3 есть один недостаток по сравнению с AMD — это то что передаётся от модуля к модулю весь инстанс YUI песочницы, в который происходит добавление различных свойств. Но у AMD есть недостаток, это то что никто так и не сделал качественной либы вроде YUI3 с использованием AMD.
0
Но, очевидно, тема вас всё же заинтриговала. ;)
0
Да, верно. requirejs разве имеет встроенный набор библиотек?
0
Но ведь так приходится таскать из проекта в проект целую пачку файлов :)
0
Подключения большого количества файлов не есть хорошо. Да и к тому же, я не увидел обработчика события загрузки скриптов. Что если run произойдёт раньше чем load. Лучше тогда уж сделать сборщик: по-отмечал галочками что нужно, нажал «Собрать» и получил готовый минимизированный один js файл. А вообще, такие универсальные функции, не зависящие не от чего, лучше сразу внеси в один common файл, и его тягать по проектам.
0
Про большое кол-во файлов я писал в конце поста. Про load спасибо, проглядел. По поводу галочек — повторюсь, что тут фича именно в том, что все разложено по «полочкам», каждый метод в своем как-бы «пространстве имен». Сделать компоновщик — дело десятое. Суть идеи не в этом.
По сути эта библиотека позволит сообществу составить целые пакеты для общего пользования различных направленностей. Т.е. допустим, кто-то дописывает пакет system и добавляет модуль jpack.system.utils.math для расчета чего-то более сложного, нежели позволяет стандартная библиотека. А потом все этим пользуются. (Да вот такая утопия)
Стоит понимать, что фича библиотеки не в загрузке файлов — это дело десятое. Фича — жесткая регламентированная компоновка по пакетам и модулям и ни шагу в сторону.
По сути эта библиотека позволит сообществу составить целые пакеты для общего пользования различных направленностей. Т.е. допустим, кто-то дописывает пакет system и добавляет модуль jpack.system.utils.math для расчета чего-то более сложного, нежели позволяет стандартная библиотека. А потом все этим пользуются. (Да вот такая утопия)
Стоит понимать, что фича библиотеки не в загрузке файлов — это дело десятое. Фича — жесткая регламентированная компоновка по пакетам и модулям и ни шагу в сторону.
0
А почему конструктор не может так же само на создавать пространства имён? А вот оптимизация для веба это одно из первостепенных пунктов. Так что либы подобного функционала можно использовать только на стадии разработки. На этой стадии это может быть удобно.
0
Не спорю, что это важно, но пока что это не готовая библиотека, а скорее, прототип. Я же писал, что оптимизация — это то, что можно сделать всегда, лишь бы только небольшой задел для неё оставить.
Сейчас я хочу сконцентрироваться именно на пользовательском интерфейсе и понять — стоит ли игра свеч. Хочется, чтобы пользоваться jpack было очень удобно — считаю это очень важно.
Про конструктор к сожалению не понял. Если можете — поясните примером.
Сейчас я хочу сконцентрироваться именно на пользовательском интерфейсе и понять — стоит ли игра свеч. Хочется, чтобы пользоваться jpack было очень удобно — считаю это очень важно.
Про конструктор к сожалению не понял. Если можете — поясните примером.
0
> Я же писал, что оптимизация — это то, что можно сделать всегда, лишь бы только небольшой задел для неё оставить.
При таком подходе у вас никак не получится сделать оптимизацию, если будут грузится файлы.
> Про конструктор к сожалению не понял. Если можете — поясните примером.
Это относится, больше к первому моему комменту. Сделать страницу с галочками выбора нужных функций, страница будет генерироваться скриптом на основе того, какие файлы лежат в папках. После выбора пакетов, данные обрабатывает скрипт и генерирует один жс файл, в котором пакеты имеют такую же структуру и неймспейс.
А по теме, вспомогательные функции хранить в одном файле и не парится.
При таком подходе у вас никак не получится сделать оптимизацию, если будут грузится файлы.
> Про конструктор к сожалению не понял. Если можете — поясните примером.
Это относится, больше к первому моему комменту. Сделать страницу с галочками выбора нужных функций, страница будет генерироваться скриптом на основе того, какие файлы лежат в папках. После выбора пакетов, данные обрабатывает скрипт и генерирует один жс файл, в котором пакеты имеют такую же структуру и неймспейс.
А по теме, вспомогательные функции хранить в одном файле и не парится.
-1
> При таком подходе у вас никак не получится сделать оптимизацию, если будут грузится файлы.
Повторяюсь, наверное при любом механизме загрузки файлов не «в лоб», а через параметр какой-нибудь функции, думаю есть возможность это все оптимизировать именно в этой самой функции, но потом.
> А по теме, вспомогательные функции хранить в одном файле и не парится.
Ну скажите это java и go разработчикам — думаю там не просто так это сделано. А париться надо, иначе как новое изобретать?
Повторяюсь, наверное при любом механизме загрузки файлов не «в лоб», а через параметр какой-нибудь функции, думаю есть возможность это все оптимизировать именно в этой самой функции, но потом.
> А по теме, вспомогательные функции хранить в одном файле и не парится.
Ну скажите это java и go разработчикам — думаю там не просто так это сделано. А париться надо, иначе как новое изобретать?
0
Не как вы не сделаете, чтобы не загружались файлы. Их нужно собирать в один файл, или выплёвывать инлайново все на страницу. Если даже вы будете пхп скриптом собирать жс файл по указанным параметрам в head, вы сделаете ещё хуже.
Я говорю про вспомогательные функции, а не про целые классы.
Я говорю про вспомогательные функции, а не про целые классы.
0
Ага. Я понял о чем вы. Можно и так сделать. Опять же это потом не так уж сложно, может быть даже проще php скриптик сделать, который будет собирать всё по урл типа /get-js.php?jpack.system.out&jpack.system.url&jpack.utils.datetime и кешировать. Чтобы руками не собирать каждый раз. Сделать реализации такого backend файла для основных языков и вперёд.
0
Если пхп будет для каждой страницы собирать свой скрипт, про кеш можно забыть. Да и к тому же каждая страница будет иметь свой скрипт и загружать одинаковый функционал. Вы пытаетесь не просто велосипед изобрести, велосипеды я люблю, а ракету на ручной тяге.
0
А мы уже с nuit пришли к выводу, что google всех опередил habrahabr.ru/post/143586/#comment_4814149
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пакеты в JavaScript — jpack