Не пора ли объединить знания, привести в некую структуру? Давно уже сидим на скриптах и каждый раз при создании компонента пишем заново с нуля. Где прогресс? 
Винградовский форум о скриптах - один из центральных форумов рунета по данной тематике. Поэтому мы можем навязывать наши осмысленные и утвержденные решения, так как они оптимальны и специалистов здесь хватает. Я считаю обязательным создание именно нашего фреймворка и обязательной к нему документацией. После полноценной разработки данного проекта ответы на вопросы в большинстве случаях будут ссылки на конкретную часть нашей документации, описанной в научно-популярном стиле. А ведь не за горами написание книги с использованием этих материалов. Сейчас некоторые авторы книг, такие как Закас, Мак-Пик, Фосетт и другие пропагандируют свои библиотеки. Созданием единой документации можно таким образом снять загрузку с форума и заставить людей читать. Говоря о форуме, то мне кажется, что здесь не хватает логического разделения ответа на вопрос: на сами обсуждения и на так называемое оптимальное решение конкретной проблемы.
   Мои мысли по поводу фреймворка: разумеется библиотека должна состоять из модулей. Понятное дело, что вес должен быть минимальным. Я не хочу рассуждать  об абстракциях и слышать их. Все конкретно, приземленно.

   Мое решение:
 библиотека пишется в соответствии определенной спецификации. 

библиотека имеет в себе "системные переменные". например, $version, $platform, $units[](массив). и "системные функции". например, $include(). а также из функций и объектов, которые подключаются из модулей.

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

библиотека кроссбраузерна. каждый модуль рассчитан под конкретный тип браузера (ie, opera, firefox + mozilla, safari)
клиент будет загружать только те части модулей, которые нужны под его браузеру. это можно решить компиляцией модуля. как это понимать? 
разработчик пишет, не думая о размере кода, скрипт. затем проверяет все ли пашет. после этого запускает специальный мною написанный компилятор - программу, отвечающую за поиск использованных функций в модулях,  - и создает например единый код.

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

а теперь представьте. вопросы на форуме по кроссбраузерности и размера вообще бы отпали=)

ребята, делимся мыслями

Сардар, помнится, начинал какое-то время назад. 
Как я понимаю, забил. 
Некоторое количество людей высказало ему свою поддержку.
Как я понимаю, только на словах.

Ваше предложение имело бы гораздо больше веса в виде: "вот я продумал и проработал фреймворк, сделал основу, то то и то то, вот дока по этому, подключайтесь мужики, давайте всем утрем нос ".

JSman, 

вспомнилось мне, что чуть меньше года назад ты горел другой идеей. Сгорел? ;-)


Что касается фреймворка, то я ещё могу себе представить, как винград помогает некому паровозу, который берёт всё на себя и тащит, но не могу увидеть, как все это делают дружно и сообща.


Какой спецификации?


"The dollar sign is intended for use only in mechanically generated code." (ECMAScript 7.6)


Не могу представить.

какая у тебя память хорошая! =) мне на самом деле приятно, что кто-то помнит) 

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

знаешь, эта тема сильно связана с той.. слова на ветер не летят. ;-)



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



проблемы нет. при компиляции эти переменные и методы можно переименовать программным путем. но при обмене кодом системные составляющие нужно выделить визуально. 


ну посмотрим, если доживем.

=============================================================================================
=============================================================================================

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

=======ШАБЛОН================================================================================

имена системных функций и переменных - ^\$([a-z][A-Z]*)+


завтра я дам полную версию правил именования остальных объектов.

=============================================================================================
СВОИ ПРИМЕРЫ ИМЕНОВАНИЯ ДАВАТЬ В СООТВЕТСТВИИ С ШАБЛОНОМ, УКАЗАННОМ ВЫШЕ, ТО ЕСТЬ С ИСПОЛЬЗОВАНИЕМ РЕГУЛЯРНЫХ ВЫРАЖЕНИЙ.



Это сообщение отредактировал(а) JSman - 2.9.2007, 20:04

 прогресс в головах программистов.

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

разберутся кому что надо и скопипастят....

dstorm81, обрати внимание на это

сорри, я не спец в регвыр, но не проще было написать так: ^\$[A-Za-z]+?
или сказать, что имена начинаются с $ и состоят из латинских символов?
и вообще - разве это главное?

Слегка разные вещи. JSman требует не только доллар на первом месте, но и букву в диапазоне [a-z] на втором, то есть букву в соответствующем регистре.

ВНИМАНИЕ! перед критикой прошу вас прочитать вдумчиво от начала до конца.


ПЕРЕЧЕНЬ ЗАКРЫТЫХ СИСТЕМНЫХ ПЕРЕМЕННЫХ И ФУНКЦИЙ.
 
в конечном коде класса они НЕ используются. они предназначены для компилятора сценариев.

$name /:String:/ - название браузера 

================================================================================

ПЕРЕЧЕНЬ ОТКРЫТЫХ СИСТЕМНЫХ ПЕРЕМЕННЫХ И ФУНКЦИЙ


$version /*:Number*/ - версия браузера

$classFolder /*:String*/ -директория с классами
ВНИМАНИЕ! переменная используется только в рамках функции $include.

$classes /*:Object*/ - ассоциативный массив, состоящий из имен загруженных модулей
ВНИМАНИЕ! переменная используется только в рамках функции $include.

function $createClass(className /*:String*/)/*:null*/ - создает JavaScript Object с именем аргумента функции 
ВНИМАНИЕ! эта функция используется только один раз в каждом файле класса в секции "2. автоматическое создание класса". См. Структура файла класса

function $include (importClassName /*:String*/)/*:Boolean*/ - загружает класс (объект) с именем importClassName, добавляет его в коллекцию $classes и возвращает успешность загрузки. функция общается к файлу importClassName.js в директории $classFolder

пример использования:

    $include('System.Manifest');
    
    System.Manifest.load(themePath);

обратите внимание, что загрузка класса System.Manifest - не означает загрузку класса System! этот прием используется только для логической группировки классов.
================================================================================

ПРАВИЛА СОЗДАНИЯ КЛАССОВ
-------------------------------------------------------
Структура файла класса

Состоит из двух частей:
1. конструктор класса. именование конструктора: РодительскийОбъект_ДочернийОбъект. 
пример

    function System_Manifest() {
    var _ = this; 
    ...
    }

обязательно создайте указатель _ на текущий объект.
для описания методов используется сначало объявление функции, а только потом ее присваивание к свойству класса.

пример

    function System_Manifest() {
    var _ = this; 
        function load(themePath /*:String*/) { ... }
        _.load = load;
    ...
    }


2. автоматическое создание класса

    $createClass('System.Manifest');
    System.Manifest = new System_Manifest();
-------------------------------------------------------
Именование методов класса

Методы делятся на 2 вида:
1. Общие для всех браузеров - функции поддерживаются всеми браузерами. 
пример

    function System_Manifest() {
    var _ = this; 
        function load(themePath /*:String*/) { ... }
        _.load = load;
    ...
    }

2. Специфические.
Так как клиент будет загружать, только тот код, который ему предназначается в зависимости от браузера, то нужно определить специфические методы.
Правило именования: $name_methodName

затем все специфические методы для достижения кроссбраузерности библиотеки объединяются одним общим методом.

пример

    function System_Manifest() {
    var _ = this; 
    
        function $opera_load(themePath /*:String*/) { ... }
        function $firefox_load(themePath /*:String*/) { ... }
        function $internetExplorer_load(themePath /*:String*/) { ... }
        ...
        
        _.$opera_load = $opera_load;
        _.$firefox_load = $firefox_load;
        _.$internetExplorer.load = $internetExplorer_load;
        ...          
    
        function load(themePath /*:String*/) { 
        eval('_.'+ $name + '_load(' + themePath +');');        
         }
        _.load = load;
    ...
    }

данный код является кроссбраузерным, что облегчает проверку в любом браузере.
================================================================================

О КОМПИЛЯТОРЕ
-------------------------------------------------------
Итак, мы имеем ограниченное число браузеров, которым хотим обеспечить поддержку. Идея в следующем.
Файл с кодом каждого класса после применения компилятора делится на столько частей, сколько браузеров поддерживается. В каждой части содержится только специфический для определенного браузера код. Вытягивание кусков кода идет в соответствии c именованием методов класса ($name_method). Таким образом, в конечной части процесса компиляции будут полностью отсутствовать методы второго типа (спицифические) с точки зрения синтаксиса, вместо имени специфического будет использоваться общий метод. Более того, компилятор обеспечит удаление тех методов, которые не нужны при решении конкретной задачи.

пример

содержимое файла разработчика 

    $include('System.Manifest');
    
    System.Manifest.load(themePath);
    
начальное содержимое файла System.Manifest.js
    function System_Manifest() {
    var _ = this; 
    
        function $opera_load(themePath /*:String*/) { ... }
        function $firefox_load(themePath /*:String*/) { ... }
        function $internetExplorer_load(themePath /*:String*/) { ... }
        ...
        
        _.$opera_load = $opera_load;
        _.$firefox_load = $firefox_load;
        _.$internetExplorer.load = $internetExplorer_load;
        ...          
    
        function load(themePath /*:String*/) { 
        eval('_.'+ $name + '_load(' + themePath +');');        
         }
        _.load = load;
    ...
    }
    
    $createClass('System.Manifest');
    System.Manifest = new System_Manifest();

вместо этого кода после компиляции будет, например, 3 файла класса для каждого браузера с именем System.Manifest.js в папках 'opera', 'firefox', 'internetExplorer' со следующим содержимым: 

    function System_Manifest() {
    var _ = this; 
        function load(themePath /*:String*/) { ... }
        _.load = load;
    ...
    }
    
    $createClass('System.Manifest');
    System.Manifest = new System_Manifest();    
    
содержимое метода load будет разным в 3х файлах.

на этапе проверки браузера $classFolder присвоит новое значение взависимости от имени браузера.
---------------------------------------------------------------------
Компилятор также имеет возможность сжатия скриптов так называемым обфускатором.

пишите комментарии. затем приступим к реализации системных функций. кто в команде?

Так ты хочешь фреймворк винградовский создать или всё-таки освоить свой компилятор? Если первое, то начинаешь явно с конца, если второе, то отдельный код для отдельного браузера - это слегка пугает:

- как точно определить браузер/версию?
- зачем разбивать модули по-браузерно, если можно сделать один, подстроив его нужным макаром? *

(*)допустим, поддержка браузера А решается тремя строчками, удобно ли подтягивать эти три строчки отдельным скриптом...

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


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

2 JSman
мда, тяжко читать такое, ох как тяжко...

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

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

процесс компиляции скриптов аналогичен компиляции программного кода delphi, например. 

разработчик создает свой сценарий и подключает к нему классы. проверяет как страница работает в различных браузерах. затем нужно сжать код. запускает компилятор.
компилятор (программа *.exe) смотрит код разработчика и вытягивает из классов только те функции, которые использует разработчик. после выполнения каждый класс файла делится на столько частей, сколько браузеров он поддерживает. группировать скрипты под конкретные браузеры можно в папках. например js/opera, js/ie, js/ff. 





Это сообщение отредактировал(а) JSman - 4.9.2007, 11:05

ну пример приведу

ДО работы компилятора
---------------------------------------------------------------------------------
в директории на компе разработчика есть следующие файлы

< .. >
< css >
< JScriptLibrary >
         System.Manifest.js

index.html
hello.js

в hello.js он подгружает класс из папки < JScriptLibrary > с именем System.Manifest.js.

ПОСЛЕ работы компилятора 
---------------------------------------------------------------------------------
< .. >
< css >
< js >
         < opera >
                         System.Manifest.js
         < ie >
                         System.Manifest.js
         < ff >
                         System.Manifest.js
index.html
hello.js

таким образом и на серваке будет структура файлов и каталогов.

Добавлено через 2 минуты и 25 секунд
обратите внимание, что System.Manifest.js до работы компилятора весит больше, чем System.Manifest.js после. а клиент будет грузить только один из новых созданных скриптов

 - а суммарный вес их будет намного больше одного кроссбраузерного

ну и к чему это приведёт?
приведет к тому что вместо 10 файлов которые будет nх10 файлов (где n:опера (куча версий), осел, гекко (куда модов движка, даже гекковские движки имеют свои особености, к примеру к-мелеон не поддерживает установку в избранное))
это все усложнит намного жизнь как и разработчикам, так и НАЧИНАЮЩИМ КОДЕРАМ.

пойми размер текстового файла по сути не важен (если скрипт получается большой и тормозной, то тому по большей части выноваты руки растущие из анального отверстия) основной вес страницы - графика.
в конце концов для большого изврата можно отдавать gzip ом и страницу и приаттаченные скрипты, реально уменьшая размер
*.exe - ну-ну, винда, линуксы, маки - уже всё продумано - на чем пишем? дельфи учим?- ЛИШНИЙ ГИММОРОЙ
Подобно забиванию гвоздика на подкове у блохи кувалдой - можно, но сложно

извини, но не могу удержаться - КГ (пока обойдемся без АМ)

dstorm81, ты вообще ничего не понял)).


на это ты сам ответил так:




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


использованием документированных общих методов? или описанная структура класса такая сложная?


ты о чем? я предложу готовое средство. 

всё я понял 
сделай красиво мужчина:
 предложи, а там посмотрим.

специально поставлю в закладки эту страницу, жду от тебя работающего функционала
продолжение разговора за неимением ГОТОВОГО СРЕДСТВА  не считаю нужным

dstorm81, ДОГОВОРИЛИСЬ, я понимаю, что тема экспериментальная. я тебя  хочу попросить написать свой пример кода на свой вкус в соответствии с теми правилами, которые я описал. выложи 2-3 кода небольших полноценных классов. и веб-страницу, подключающую их. я как напишу компилятор, сразу скину на форум его. пусть не все функции классов  будут задействованы. 

имхо, лучше так: 

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

Это сообщение отредактировал(а) cruelangel - 12.9.2007, 20:31

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

Может ещё строем заставить их ходить?;)

JSman, в последнее время js принимает уже не второстепенную функцию. некоторые даже увлекаются и делают сайты целиком на ajax 8-\
яваскрипт может рулить схлопывающимися менюшками, подсветкой при наведении, и пр. кроме того страница может быть ценна именно своим скриптом, например: http://dark-demon.nm.ru/web/samples/sub_resync.htm - ресинхронизация субтитров, пользователь может сохранить страницу, и пользоваться ею не зависимо от работоспособности сайта.
да, для конкретного сайта это всё может быть и не важно, но стоит ли вносить такие ограничения в фреймворк, экономя жалкие 5 килобайт, намертво оседающие в кэше? 
всякие prototype.js ведь весят столько не потому, что кроссбраузерны, а потому, что туда много чего напихали и сильно намудрили. взять тот же аякс - 300 строчек кода. это при учёте, что простейшая реализация - порядка 10.

Это сообщение отредактировал(а) cruelangel - 23.9.2007, 12:17

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

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

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

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


 

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



это было очень справедливо замечено! в самом деле, это так и есть. но зачем пихать эти проблемы на другую сферу? сначала нужно полностью разобраться со скриптами, потом можно и о графике поговорить.



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



я столкнулся с тем, что написания компилятора, надо точно определить структуру классов. критика каждого человека в этой теме учитывается и приводит не к отказу от написания фреймворка вообще, а именно УТОЧНЕНИЮ спецификации.


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

Это сообщение отредактировал(а) JSman - 23.9.2007, 23:13

для начала стоит определиться: чем данный фреймворк будет лучше уже существующих? почему разработчики должны бросить другие фреймворки и перейти на этот?
размер? тот же jquery весит чуть более 20 килобайт в пакованном виде. а это, подчеркну, достаточно мало и ужимать ещё больше есть смысл только если ужатие даётся даром.
может быть этот "компилятор яваскрипт" проще прикрутить к какому-нибудь prototype.js и тем самым пренепременно осчастливить многотысячную толпу веб-разработчиков?

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

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

 не решаются вопросы как компонент должен отображаться у пользователя при сохранении страницы или должен ли он вообще отображаться.



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

http://mootools.net/download - можно выбрать только те модули, которыми собираешься пользоватсься

одна из лучших библиотек, в самом деле. прекрасные решения! =) 

маленькие недостататки есть...
все модули могут основываться только на ядре библиотеки: компоненты не могут использовать другие модули.
нет режима управления компонентами при сохранении.

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

но все-таки почему не расширить возможности разработки скриптов путем "закоса" под другие средства типа си++ или дельфи?

в каком смысле?

видимо он хочет написать "delphy for javascript" 

))) имеется в виду компиляция + возможность импортирования одних модулей в другие ( юзаем $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 библиотек щас в изобилии.
А насчет размера я бы не переживал - один раз загрузить, а потом браузер берет из кеша и всё. плюс можно посжимать пооптимальней. проблема, как мне кажется, надумана.