Как стать автором
Обновить

Комментарии 31

Я его смотрел. Боюсь ошибиться, но вроде как он по-другому работает и несколько другую задачу решает. Там скорее именно подгрузка файлов, причем вроде как любых, а не более жесткая стандартизация, но может, и ошибаюсь, конечно. И настройка там вроде по-сложнее немного.
Почему вы не разобрались с существующими решениями перед тем как делать что-то своё?
Вообще советую взглянуть на пути развития загрузчика в YUI3, втч и различные варианты от которых отказались — такие как remote loading server. Ну чтобы примерно понимать с чем имеешь дело, тк то что у вас сейчас реализовано практически полностью сделано неправильно.
Каюсь, как-то не задалось. Если идея окажется интересна людям и будет смысл её развивать, то прочитаю о загрузчиках как можно раньше. Так как все силы не на это направлены пока что.
Для начала надо сделать правильное подключение «пакетов», а потом решать проблему динамической загрузки. А ещё лучше создавать песочницы, внутри которых исполнять содержимое «пакетов».
Например в 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(), а в этот момент в системе уже будет присутствовать вся деревяшка пакетов. Часть пакетов может тупо не отрабатывать, используя что-нибудь вроде проверок на фичи браузера(например если у нас нет нативной реализации транзишенов, то подключать пакет, если есть, то просто не отрабатывать его подключение).
А с динамической загрузкой всё ещё гораздо сложнее ;)
Т.е. вы предлагаете в данном примере github.com/arturgspb/jpack/blob/master/example/utils.html в обоих jpack.run указывать какие пакеты/модули им нужны? Я правильно понял?
Нет, я предлагаю начать с создания песочниц, отложеного запуска модулей с поддержкой davidwalsh.name/html5-async на уровне конструкций модулей, а не самой загрузки.
А вообще просто начните использовать YUI3, там все эти проблемы уже давно решены ;)
Я к тому, что на самом деле хочется где-нибудь в head видеть что на странице подключено, про YUI3 понял, посмотрю, но… только для того, чтобы сделать мир лучше обучиться и прокачать свою либу. Ведь jQuery тоже когда-то не было, а все считали, что чистый js весьма нормален. Ну и повторюсь, что YUI это немного не то, что хочу сделать я. Хочется сделать хорошо компанованные пакеты с возможностью быстро и просто дописывать новый функционал.

Юзать сторонние вещи — не грех, не спорю. Но часто вы копаетесь в исходниках jQuery или YUI? А если не копаетесь, возникает меньше проблем и, соответственно, не думаете над их решением. Плюс разве это сделать что-лучше того, что уже есть такая неразрешимая задача? Все зависит от хотелки.

Вам огромное спасибо за указанное направление для развития. Почитаю что да как и сделаю.
>в head видеть что на странице подключено
кхм, даже в небольшом проектике у меня кол-во используемых модулей >100 (yui+мои). Вы хотите все эти 100 модулей вытащить в кучу вызовов load'а куда-нибудь в head?

>Ведь jQuery тоже когда-то не было, а все считали, что чистый js весьма нормален.
jquery как бы тоже не решает проблем при разработке сложных масштабируемых(в плане разработки) проектов. Это же просто нормальный апи для дома.

>Хочется сделать хорошо компанованные пакеты с возможностью быстро и просто дописывать новый функционал.
Как раз это YUI и реализует, ничего более ;) Просто к этому добавлена куча уже написаных модулей, можно их даже не использовать.

>Плюс разве это сделать что-лучше того, что уже есть такая неразрешимая задача? Все зависит от хотелки.
Разрешимая, я например для своих экспериментов с загрузчиками как раз использую YUI по причине что у них уже написана и отлично задокументирована громадная куча модульного кода. Просто компилирую всю либу со своими модификациями и подставляю свою реализацию YUI объекта.
> Вы хотите все эти 100 модулей вытащить в кучу вызовов load'а куда-нибудь в head?

Боже мой, конечно нет. jpack — это скорей не компановщик ваших «кастомных» js файлов для проекта (под этим я понимаю допустим обработку событий для кликов, отправку формы и пр. js-код для обычного функционирования проекта, т.е. для реализации, наверное, бизнес-логики или просто для функционирования интерфейса в общем понимании). Т.е. в java, конечно, вроде бы все пакетами делается, в моём случае предполагается для начала, что jpack — это скорее набор разных библиотек, например как в go golang.org/pkg/ Что-то вроде того.

> jquery как бы тоже не решает проблем при разработке сложных масштабируемых(в плане разработки) проектов. Это же просто нормальный апи для дома.
Ну я в общем плане говорил. Нет панацеи ни для чего — Вы должны это понимать. Как раз, наверное, requirejs + jquery даст лучший эффект для структурирования файлов вашего приложения. jpack — это не просто загрузчик файлов.

> Как раз это YUI и реализует, ничего более ;) Просто к этому добавлена куча уже написаных модулей, можно их даже не использовать.
Ну, тогда я его посмотрю, может я и действительно велосипед сделал. ;)
А вообще то что вы пытаетесь сделать практически один в один реализовано в Google Closure Library
Вы положили меня на лопатки. Я сдаюсь, но не закончу свои изыскания) Вообще раньше не видел их библиотеку, как видно не я один.
Не советую что-либо делать с использованием их либы :) Примерно так же выглядел YUI2 много лет взад, но они решились переписать всё с нуля с учётом прежних ошибок, особенно проблемна вся та часть кода что связана с UI.

А вообще я не представляю что можно придумать лучше чем Asynchronous Module Definition , в YUI3 есть один недостаток по сравнению с AMD — это то что передаётся от модуля к модулю весь инстанс YUI песочницы, в который происходит добавление различных свойств. Но у AMD есть недостаток, это то что никто так и не сделал качественной либы вроде YUI3 с использованием AMD.
Уйдет много времени, прежде чем я познаю то и то досконально, так что порадовать Вас симбиозом YUI и AMD в ближайшие полгода вряд ли получится.
Но, очевидно, тема вас всё же заинтриговала. ;)
Я просто работаю над проблемой эффективной динамической загрузки в больших проектах. Когда жаваскрипт нужно разбивать на большие куски и при этом всё должно происходить прозрачно для разработчика.
Да, верно. requirejs разве имеет встроенный набор библиотек?
Но ведь так приходится таскать из проекта в проект целую пачку файлов :)
Подключения большого количества файлов не есть хорошо. Да и к тому же, я не увидел обработчика события загрузки скриптов. Что если run произойдёт раньше чем load. Лучше тогда уж сделать сборщик: по-отмечал галочками что нужно, нажал «Собрать» и получил готовый минимизированный один js файл. А вообще, такие универсальные функции, не зависящие не от чего, лучше сразу внеси в один common файл, и его тягать по проектам.
Про большое кол-во файлов я писал в конце поста. Про load спасибо, проглядел. По поводу галочек — повторюсь, что тут фича именно в том, что все разложено по «полочкам», каждый метод в своем как-бы «пространстве имен». Сделать компоновщик — дело десятое. Суть идеи не в этом.

По сути эта библиотека позволит сообществу составить целые пакеты для общего пользования различных направленностей. Т.е. допустим, кто-то дописывает пакет system и добавляет модуль jpack.system.utils.math для расчета чего-то более сложного, нежели позволяет стандартная библиотека. А потом все этим пользуются. (Да вот такая утопия)

Стоит понимать, что фича библиотеки не в загрузке файлов — это дело десятое. Фича — жесткая регламентированная компоновка по пакетам и модулям и ни шагу в сторону.
А почему конструктор не может так же само на создавать пространства имён? А вот оптимизация для веба это одно из первостепенных пунктов. Так что либы подобного функционала можно использовать только на стадии разработки. На этой стадии это может быть удобно.
Не спорю, что это важно, но пока что это не готовая библиотека, а скорее, прототип. Я же писал, что оптимизация — это то, что можно сделать всегда, лишь бы только небольшой задел для неё оставить.

Сейчас я хочу сконцентрироваться именно на пользовательском интерфейсе и понять — стоит ли игра свеч. Хочется, чтобы пользоваться jpack было очень удобно — считаю это очень важно.

Про конструктор к сожалению не понял. Если можете — поясните примером.
> Я же писал, что оптимизация — это то, что можно сделать всегда, лишь бы только небольшой задел для неё оставить.

При таком подходе у вас никак не получится сделать оптимизацию, если будут грузится файлы.

> Про конструктор к сожалению не понял. Если можете — поясните примером.

Это относится, больше к первому моему комменту. Сделать страницу с галочками выбора нужных функций, страница будет генерироваться скриптом на основе того, какие файлы лежат в папках. После выбора пакетов, данные обрабатывает скрипт и генерирует один жс файл, в котором пакеты имеют такую же структуру и неймспейс.

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

> А по теме, вспомогательные функции хранить в одном файле и не парится.
Ну скажите это java и go разработчикам — думаю там не просто так это сделано. А париться надо, иначе как новое изобретать?
Не как вы не сделаете, чтобы не загружались файлы. Их нужно собирать в один файл, или выплёвывать инлайново все на страницу. Если даже вы будете пхп скриптом собирать жс файл по указанным параметрам в head, вы сделаете ещё хуже.

Я говорю про вспомогательные функции, а не про целые классы.
Ага. Я понял о чем вы. Можно и так сделать. Опять же это потом не так уж сложно, может быть даже проще php скриптик сделать, который будет собирать всё по урл типа /get-js.php?jpack.system.out&jpack.system.url&jpack.utils.datetime и кешировать. Чтобы руками не собирать каждый раз. Сделать реализации такого backend файла для основных языков и вперёд.
Если пхп будет для каждой страницы собирать свой скрипт, про кеш можно забыть. Да и к тому же каждая страница будет иметь свой скрипт и загружать одинаковый функционал. Вы пытаетесь не просто велосипед изобрести, велосипеды я люблю, а ракету на ручной тяге.
Ну что же это ваше право. Я сам таким путём шёл, который оказался тупиковым, зато много опыта наберётесь в других моментах )
Отчасти ради этого и затеял всё
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории