Техническая библиотека CITForum.ru CITKIT.ru - все об Open Source Форумы Курилка
Все новости / Все статьи Деловая газета - шквал(!) IT-новостей :: CITCITY.RU
Первая полоса ИТ-Инфраструктура Телекоммуникации Безопасность BI Интеграционные платформы КИС IT-бизнес Ширпотреб Точка зрения

21.11.2017

Новости:


Все новости

Обсуждение статьи «JavaScript: создаем Человека»

Статья «JavaScript: создаем Человека» опубликована в библиотеке CITForum.ru. Эта страница создана специально для обсуждения статьи.


Комментарии

Страницы комментариев: 1 :: 2 :: 3 :: следующая

Nick Pepper, Mon Oct 26 16:00:08 2009:
Спустя два года(!) вновь перечитал и саму статью и комментарии.
Позволю себе поделиться свежими ощущениями и мыслями, намеренно откинув в сторону конкретный вариант, которым автор предлагает решить существующую и актуальную проблему. А кстати, в самой статье почему-то предлагаемый способ решения застит саму формулировку проблемы, позволю себе даже сказать, что проблема сформулирована не четко - отсюда и мощный "наезд" читателей на автора ;)

1) на сегодняшний день, увы, очевидно, что это "мёртвому припарки" - пытаться решить проблему узкого канала связи, который, несмотря на все усилия веб-провайдеров и иже с ними, ВСЕГДА останется слишком узким для web'a, пробуя с очередным бубном как-то по-новому связать пучок имеющихся в распоряжении веб-разработчика "технологий" (за редчайшими исключениями абсолютно каждая из которых во-первых - так и не стандартизирована, а значит, нет настоящей "кросс-"ности, а, во-вторых, тоже, как правило, является отзвуком ударов отдельных энтузиастов в шаманские бубны различной племенной принадлежности).

2) ваш покорный слуга же за прошедшие два года собственноручно написал и внедрил в крупный веб-проект некую систему компрессии трафика (на сервере Java, на клиенте JavaScript). Побочно открылась очевидная возможность передавать от сервера клиенту и обратно некий байт-код - т.е., речь пошла о компилируемом JavaScript, о некоей RTE в вебе, а не об очередном proxy. При этом в отдельных браузерах за счёт существующих в них гибких механизмов расширения технических препятствий для такой реализации нет вообще. Единственное условие, как и всегда - чтобы пользователь этой очередной новой "панацеи" предварительно установил некий модуль(плагин аддон), который при этом чаще всего совершенно не поддерживается броузерами других производителей - знакомая ситуация, не так ли? ;) Мечтать же о том, что производители броузеров возьмут и включат такой механизм в свои шедевры программирования - как говорится, не вредно :)

3) одновременно выяснилось, что корпорация Мозилла во главе с "отцом Жабоскрипта" Бренданом Эйхом уже практически имеет готовую рабочую модель именно компилируемого JavaScript,для клиент-серверного обмена данными при этом используется промежуточный байт-код (очевидно, немалую роль в столь широком употреблении старой доброй идеи философии Java сыграло открытие исходных кодов VM корпорацией Sun). Поэтому автор этих строк свои работы прекратил за ненадобностью изобретения велосипеда.

4) на горизонте, естественно (как и всегда при появлении чего-то ещё непротухшего), возник страшный призрак... не коммунизма, а Мелкософта; и молвил призрак - "все исходники отдать нам, работы приостановить вплоть до высочайшего распоряжения нашего..." и т.д. и т.п., всё как обычно (вышеупомянутый Брендан Эйх даже обратился с открытым воззванием и стенаниями к читателям своего блога, будучи откровенно "кинутым" Великой Индусской Корпорацией при выпуске очередного "самого..." веб-броузера всех времен и народов под релиз-номером 8 - исходники революционного JavaScript-механизма БЕСПЛАТНО взяли, обещали в свой новый пепелац внедрить, но продинамили и не внедрили)... Непокорный непоседливый Google, заручившись поддержкой даже Билла не боящихся организаций, при этом не преминул по-быстрому тиснуть на рынок свой явно демонстрационный броузер Chrome, в котором уже реализована "JIT-компиляция" от "папы Брендана & Co." и даже мои собственноручные придирчивые тесты убедительно показали, что при JIT-компиляции больше нет совершенно никакой проблемы с оптимизацией кода того же JavaScript - на скорость исполнения и компактность упаковки это совершенно не влияет (да, в Мозилле и Гугле работают далеко не дураки, в чем, надеюсь, никто никогда не сомневался). Итак, публичная демонстрация нового вооружения массового поражения в войне за великое веб-пространство состоялась. И потянулись хитровыдранные и не доходящие ни в одном случае до конца судебные процессы и перекрестные политические переговоры о разоружении, об отводе войск и прочая муть; зашевелились спецслужбы всех сторон и потекли огромные взятки из всевозможных швейцарских "фондов" в карманы "нужным людям" из вражеских станов. Всё как обычно.

Прощу прощения за многословность.
Теперь попытаюсь собрать всё вышенаписанное в краткое резюме.

1) очевидно, что первая и важнейшая проблема веба всегда была, есть и будет в отсутствии действительно эффективных (да еще и стандартизованных при том) протоколов связи. Сколько лет уже мы сидим на дырявом как старое ведро TCP/IP, все помнят? И будем сидеть до скончания если не века, то веба, господа ;)
2) пытаться в очередной раз под звуки бубна извернуться как-то так, чтобы что-то где-то в вебе улучшить для пользователя, во-первых, подобно движениям медведя в тесной клетке советского зоопарка (и имеет ровно тот же эффект), а во-вторых - противоречит объявленному в самом начале весьма неплохо с точки зрения беллетристики написанной уважаемым Navigator'ом статьи (я имею в виду мысли об оплате всех "благ" ценой бесценного времени собственной жизни)

Вспомните старый одесский анекдот: Сара говорит супругу Изе, который потерял сон от того, что должен соседу Абраму - "Ты ему ничего не отдавай и спи спокойно, Изя, пусть таки теперь Абрам мучается" :)
Так что давайте расслабимся, коллеги, и поедем лучше на рыбалку :) Пусть о благе Абрамов, т.е., пардон - пользователей - позаботится та же Micro$oft.
Cy1on, Tue Aug 11 10:30:21 2009:
Ув. Автор! Вас наверное так и создали. Жаль потраченного не это времени.
Neformal, Fri Mar 14 17:44:17 2008:
Статья не заслужывает чтоб ее читать.
Абсолютно неаргументиронные высказывания, и беспредельно тупой вариант решения поставленой задачи.
Yuri, Fri Feb 15 09:20:19 2008:
Таблицы какие-то :)
Это такой тэг, который лет 5 назад в HTML использовали? :)

Да и идея псевдозапаковки в век аякса довольно старинно выглядит :)

Удачи автору в изучении современных технологий и тенденций :)
Алексей, Thu Dec 6 18:48:22 2007:
Очень прикольная статья. На базе этой идеи запросто можно сделать отличный web-proxy с упаковкой трафика. И вполне возможно подобрать хорошую нишу для такого сервиса.

PS. Глядя на некоторые комментарии, невольно вспоминаю фразу из АБС: "Слушатели глядели ему в рот и задавали вопросы, свидетельствующие о дремучем невежестве". Относится не ко всем, конечно же.
Программэр, Wed Oct 31 13:26:24 2007:
Занимаюсь Вэб-программрованием больше 10 лет. Мои выводы по поводу статьи:
1.Загрузка Вэб-сервера дополнительной архивацией и разархивацией непозволительна. При большом количестве посетителей или при атаке на отказ в обслуживании он рухнет.
2.Время отображения страницы у клиента очень сильно зависит не только от канала связи, но и от вычислительной сложности сайта. Поэтому излишне загружать клиента то же не стоит.
3.XML при постройке обычных информационных сайтов практически не нужен.
Navigator, Thu Oct 25 16:56:58 2007:
2 Nymphomaniac:
Могу только поблагодарить за Вашу внимательность: так оно и есть, "автор долгие годы посвятил написанию драйверов и низкосистемных утилит, а потом, вдруг резко переключился на веб-программирование." :) Только не переключился, а несколько лет назад стал заниматься и...
Попробую ответить на Ваш подразумеваемый вопрос. Нет, я понимаю, что это разные вещи с разными требованиями.
Но раз уж web-программирование из рисования завитушек в смотрелках потихоньку становится программированием, то оно должно подчиняться общим правилам. А сейчас web наступает на все известные 50 лет грабли.

Вообще, у меня малость странное чувство. Вроде бы совершенно очевидно, что раз в обозримом будущем канал останется самым слабым местом, значит, канал и надо разгружать всеми способами.
Если канал по быстродействию на три порядка меньше, чем сервер и клиентский комп, то любые наши телодвижения на сервере или у клиента могут повысить эффективность не больше, чем на 0.1% - это просто арифметика.
Я предложил для передачи по каналу написать архиватор на серверных скриптах (который будет брать готовую к отдаче страницу и паковать примерно так, как показано на примере) и потом распаковывать на месте javascript-ом. Что может быть банальней и очевидней?
А почитайте комментарии. Половина отписавших вообще почему-то решила, что я предлагаю так вот писать сайты!
Большинство оставшихся говорит вещи, честно говоря, странные.
Например, что атрибуты не поддаются упаковке. Запакуйте gzip-ом или winrar-ом html-файл. Загляните в архив, и увидите, что ничего сакрального в атрибутах нет, они пакуются как и все остальное.
Многим не понравилось, что результат не шибко "хуман-ридли". А с чего ему таким быть? Загляните в mp3-файл. Много вы там поймете? От этого mp3 становится хуже?
Несколько человек углядели в статье какой-то код и рассказывают, какой он фиговый. Да нет там вообще никакого кода! Там есть только пример - демонстрация того, как легко html/xml/json файл может быть сжат в несколько раз.

2 sergo:
Да не предлагаю я сайты на С писать! :)
Хотел только обратить внимание на то, что громоздкость html/xml ничем не оправдана.
Хорошо, давайте простейший пример. Только, наученный горьким опытом, обращаю внимание: это НЕ предложение нотации, это просто ПРИМЕР!
Вот два варианта синтаксиса (замените скобки на угловые):

[tag atr...] value [/tag]
tag [atr... [ value]

Вы согласны, что они равнозначны? Какой из них компактнее? Так скажите, почему на xml пишется:
[BookWithPictures author='Vasya']Sun[/BookWithPuctures],
а не:
BookWithPictures[author='Vasya'[Sun]
Подумайте сами, сколько еще такой неоправданной избыточности в html/xml? У Вас есть этому разумное объяснение?
Savelskiy, Wed Oct 10 14:31:21 2007:
Совершенно некоректная статья.
Код бесполезен, кросплатформенность ноль и вообще..
до какикх пор на ЦИТе будут постить всякое говно?
terr0rist, Thu Oct 4 17:43:46 2007:
Ключевые слова - в конце статьи:
"в процессе разработки всплыло столько неочевидных тонкостей, что их рассмотрение вышло бы далеко за пределы этой статьи."
Эта идея такой же, к сожалению, дохлорожденный труп, как и связка XML+XSL. Тонкостей столько, что заставить сайт выглядеть одинаково (безглючно) во всех браузерах просто НЕВОЗМОЖНО. Не говоря уже о том, что автор не первый, кто такую идею придумал. Да и со временем опоздал он немного: в эпоху широкополосного доступа в инет на первое место выходит не скорость передачи по сети, а внешняя привлекательность сайта.
sergo, Mon Sep 17 13:33:40 2007:
Сравнивать C с XML это просто какой то нонсенс...
Раз автор утверждает, что C круче (с точки зрения описания структур данных), пожалуйста докажите.

Возьмем простейшую структуру данных: таблицу например, лучше конечно две, но для простоты одной достаточно. Как вы собираетесь описать таблицу с полями ID, Field1, Field2 в языке C? Структурами? Классами? А как забьете контент туда? А как будуте обращаться к произвольной строке? делать поиск по полям? (аналог XPath в студию).
Сколько времени уйдет чтобы описать это все?
Более того, вот необходимо передать эти данные кому то - как вы это сделаете? Перешлете исходники на сях? Он будет парсить Си и доставать от туда информацию? Смешно, ей богу

Страницы комментариев: 1 :: 2 :: 3 :: следующая

Комментарии заморожены.

Последние комментарии:

Самое интересное:


© 2004–2009 Проект CITCITY.ru