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

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

ну вот.

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

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

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

итак, начну.
первое, что приходит в голову:
хотелось бы
1. цикл с возможностью задания паузы между единичными выполнениями, который мог бы возвращать результат после каждого из своих выполнений
как обходим: используем в качестве цикла функцию, в которой указываем счетчик и вызываем её с помощью setTimeout() или setInterval().
Добавлено @ 17:54
1. HTML: <SELECT> с возможностью ввода текста + подбор из опций соотвутствующих записей.
Добавлено @ 17:56
так же предлагаю договорится, что сюда НЕ пишем только то, что одинаково правильно функционирует в трех браузерах - MSIE, Firefox и Opera.

Это сообщение отредактировал(а) Alx - 9.2.2006, 17:51

Это называется не уязвимости, а недостатки или баги (или-или).

3. Медленное быстродействие как в вычислениях, так и в доступе к объектам.

4. Утечка памяти в анонимных функциях в ie.

5. неуклюжесть в определении свойств - margin - border - padding и очень оригинальное определение width c учётом этих свойств.

6. и там - и там - одни враги.

А давай потом организуем W3C 2.0, в котором этот список будет руководством к действию. Будем мировую моду определять, чем плохо?

По 1-му: здесь 2 подхода к описанию программ. Первый: сопрограммы - процесс описан в виде цикла с паузами. Это то же, что вместо пауз будут запросы на обмен с соседними процессами. Второй: пишем всё как программы, которые в идеале стремятся к нулевому времени исполнения. В JS реализован 2-й, а в других языках непоследовательно - элементы 1-го - паузы, например. Поэтому загвоздка не в паузах, а в чистом 1-м подходе - нигде не писать в стиле сопрогамм. Язык с сопрограммами - будет совсем другой язык.

По 2-му пункту (select, точнее, combo-box): с ним чаще вспоминается не отсутствие комбобокса, а особые функции добавления/убирания опций. В своё время их было сложно реализовать в общем порядке, сделали специальные add(). А в IE до сих пор все стили неприменимы к объекту select.

В общем - недостатков - сотни, их как раз хватит на нашу плодотворную работу в комитете W3C 2.0 в течение пары-тройки лет

Скудная работа с картинками
Практически отсутсвие работы с файлами
Open-source
Кроссбраузерность

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

а с w3c это ты классно придумал

Этого на толстую книгу хватит. Которые почти так и пишутся (Гудман - библия) - свойство - применимость в версиях и с какой версии. Пройтись по форумам - таких данных много наберётся, и работы много. Я тоже подумывал над тем, как это всё систематизировать, чтобы росла коллективная база знаний. Но не текстовая - книги писать некому, а некий движок IDE с контекстными подсказками. Пишешь метод в одном стиле - тебе подсказки совместимых подобных методов. Как бы туда ещё включить наводящие ключевые слова? Типа. сохранение в файл - > FileSystemObject

Давайте, давайте больше недостатков. Я их в свою статью вставлю ;)

(Хотя, по моему, весь JS-это один большой недостаток... но это мое ИМХО)

По поводу отсутствия delay (или чего-то в этом роде): это, по-моему, вполне намеренная фича. Скрипт не должен захватывать управление (по кр. мере, на продолжительное время) -- соответственно, весь тайминг может быть реализуем только через setTimeout() / setInterval().

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

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

Откуда такая уверенность?

А эти недостатки будут услышаны людьми свыше?

Я напишу не недостаток языка, а такую штуку:
так как пишем мы это дело в блокноте (ну или другом редакторе) возникают часто проблемы с кодом, и их бы проследить, а такой возможности нету. То есть Отладка программы... (Debug вроде называется). Может я конечно ошибаюсь- в некоторых редакторах это есть, ноя не видел...
А то иногда в циклах путаешься (когда они громоздкие) а следиьт одними alert'ами не удобно

Innuendo,
ну, может, просто смотреть на какой строке ошибка и исправлять?
а то ведь с дебагером и писать не интересно...

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

Берёшь Firefox, ставишь плагин venkman и вот тебе полноценный дибагер
Добавлено @ 00:11

Саня, ты прикалываешься ))) Не интересно, когда 10 строк, а если 20 кБ кода, то с распечаткой с ума сойти можно.

ну не наю)))
я как-то всю жизнь пока обходился...)

можн и дальше обходится.. зато с ней можно скэономить время поиска ошибки.

Очень хочеться поддержки многозадачности, что то типа:

Возникнет масса проблем с синхронизацией, для решения можно ввести synchronized ключевое слово. Dead lock'и можно отследить, хотя если копнуть глубже можно найти кск другие скрипты поддерживающие треды решили сии проблемы. В любом случе множество тредов просто необходимо в AJAX приложениях, уже сейчас сам XMLHttpRequest и его события отрабатываються в отдельном треде.


Это не задача JS, а компонент браузера. Стили, разметку, фичи, всё это к JS не приписываем, язык только управляет этими обьектами


В смысле? В CSS стилях названия содержат '-' что являеться оператором в JS, потому именование типа backgroundColor ИМXО очень даже подходящее. Если ты о формате общих свойств border, margin и т.д., то это не к JS, а к спецификации CSS


Это опять же браузерный обьект Мозилла(Gecko) и Safari имеют canvas, очень даже удобно рисовать. Xотя когдабраузеры начнут свободно понимать SVG и подключат API к JS, то можно будет из JS работать с SVG примитивами, вот это будет действительно "Флешевая анимация"

От себя добавлю:

• скудный язык, приходиться много работать с DOM коллекциями, а удобных итераторов нет. Самая плохая реализация for in тоже в JS, т.к. не удобно, перечисляет всё, что правильно для JS, т.к. у обьектов и методы и поля это одно и тоже.
• нет хороших коллекций, всё что имеем это массивы и обьекты. Обьекты наследуют прототип Object, так что даже пустой обьект полон всего, отсюда понимаем почему for in не удобно. Требуеться словарь (ключь=>значение), множества, кортежи и другое.
• нет человеческого API у существующих коллекций, в языке где в основе лежат closures пользуем for(var i; i<length; i++) для перебора, а с ключами вообще лажа. Вообще это позорно...
• нет пространств имён/пакетов/модулей или любого другого механизма контроля видимости кода. Сейчас ещё не актуально, но в будущем может понадобиться. Сюда хорошо бы дополнить загрузку кода с сервера (только с домена страницы) нормальным API, а не создаванием скриптов в ручную, что не везде работает, да и "грязно"

В целом язык уже не молод, но ещё сырой на текущее время, а учитывая что вводиться он везде и повсеместно (вернее ECMA Script или pure JS без браузерного API), то требуеться под шумок его расширить JS 2.0 ИМXО лажа, полная. Не хочу видеть видеть классы в языке без типов, это провал, притянуто за уши под моду. Читаем Fortress и traits, почти это реализовано уже в JS, осталось ввести контроль импорта окружения в функции, так что бы не приходилось "извращаться" делая "приватные" переменные. Xотя текущие подходы извратами не нахожу. Xочеться что бы JS начал по своей гибкости напоминать Python

Это сообщение отредактировал(а) Destruction - 12.2.2006, 21:28