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

ну и к чему это приведёт?
приведет к тому что вместо 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"