))) имеется в виду компиляция + возможность импортирования одних модулей в другие ( юзаем $include, а не только главное ядро)

у меня примерно так сейчас и реализовано - js и css являются обычными php скриптами, где в нужных местах стоят <? include( 'wysiwyg.js' ); ?> и <?= $body_width; ?> 

cruelangel, а кеширование как же?

также как и со всем остальным  при необходимости можно включить...

Это сообщение отредактировал(а) cruelangel - 26.9.2007, 21:57

да фиг знает, что лучше через php модули вставлять или $include через js реализовывать. 
в первом случае меньше тормазов, меньше запросов. но реализация многомодульности будет примерно такая же как я планирую на js - использование массивов с названиями загруженных библиотек.
для тестирования второй случай не требует сервера вообще (точнее php), то есть находимся в рамках одной технологии.
опять же компиляция может решить проблемы. компилятор может сыграть типа роль php - сделать аналогичный php $include со встроенными проверками, чтобы один и тот же модуль более 2х раз не загрузился. то есть и на этапе разработки удобно (все пашет), и после компиляции замечательно )

JSman, а в чем сокральный смысл разделять на модули js код? в том виде в котором ты это предлагаешь.

программирование на языке javascript требует кардинальных перемен. каждый раз изобретать велосипед не нужно. любой проект включает совокупность независимых друг от друга компонентов, связанных в общем смысле идеей, носящий индивидуальный характер, в частном  случае  - кодом, привязанному к определенной верстке. этим я и обосновываю целесообразность использования готовых средств и на базе них создания новых. 
ядро библиотеки не должно быть просто совокупностью функций. оно может содержать, например, до 1000! функций. поэтому с учетом развития ядра и пополнения функциями мы нуждаемся в логическом объединении в классы функций. размещение классов в отдельных модулях (файлах) упростит изучение класса, дополнение. разработчику удобнее работать с кодом класса в одном файле, чем разбираться с тем же кодом с тысячной строчки по тысяча трехсотую.

> в частном  случае  - кодом, привязанному к определенной верстке.

код нужно писать так, чтобы он не был привязан ни к какой вёрстке

JSman, ну так имеющиеся библиотеки релизуют это вполне. зачем изобретать велоспед...

...
и, разумеется, ядро, разделившись на модули (каждый занимается своей сферой - css ,например), дает будущим компонентам структуированную основу для разработки. модули могут использовать в себе иные модули с функциями на более "низком" уровне. поэтому весь скомпилированный код будет своего рода иерархией от функций низкого уровня до высокого. функции, объекты, классы в данном случае синонимы.

привязанность к верстке означет в данном случае вставка например графического компонента в определенное пользователем библиотеки место.

не велосипед. понимаете, дураку и так понятно, что удобнее хранить в модулях. но альтернативы библиотекам создаются либо с целью объединить лучшее из имеющегося, либо внести туда новую концепцию. например о том что я упоминал выше по поводу сохранения страницы.
библиотека сама по себе полезна. но при использовании компилятора это уже некий Ру-проект.
тем более нельзя забывать людей за пределами мск и спб, для которых скорость и вес имеют большое значение.

JSman, ну понятно, у тебя чисто спортивнй интерес. просто если библиотека лишь инструмент,а не цель, то конечно выбрать готовую выгоднее. и комьюнити, и обновления и поддержка всё уже есть. и выбрать под свой стиль можно, благо js библиотек щас в изобилии.
А насчет размера я бы не переживал - один раз загрузить, а потом браузер берет из кеша и всё. плюс можно посжимать пооптимальней. проблема, как мне кажется, надумана.