WEB - как стандартный интерфейс программы?

← →
Piter © (2008-01-20 16:12) [0]

Все чаще встречаюсь с тем, что в программе данные наиболее просто отображать в HTML-виде через TWebBrowser. Это ведь и логично - данный язык разметки специально создавался, чтобы выводить различную информацию на экран. Плюс сам WEB все больше входит в жизнь, для многих сайты становятся родными и в браузере они проводят куда больше времени, чем просматривая классические GUI-приложения.
Сама технология очень богатая и снимает множество проблем, многие грамотно написанные сайты куда проще в нагляднее в ориентировании, чем windows-приложения.

Мысль наверняка не новая, но хотелось бы это обсудить. Ведь по сути все идет к тому, что не будет в программах привычных нам GUI-элементов, все вытеснит WEB, то есто визуально вся программа - это растянутый на всю область компонент TWebBrowser, а уж там внутри интерфейс программы, реализованный на HTML, Java Script, Flash и прочее.

Такой подход на мой взгляд дает много плюсов. Язык HTML - стандартный, понимаемый многими, возможна простейшая технология изготовления скинов-шаблонов для программы (есть ограничения, но все же) любому, кто хоть немного разбирается в HTML и в стилях CSS. Легко изготовляемый интерфейс программы, без излишней работы по позиционированию элементов на экране - все это сделает движок браузера при правильно заданных параметрах тегов. И остальные богатейшие возможности, получаемые при данном подходе.
Опять же легкая модернизация приложения для сетевой работы, клиентом к программе может выступать любой браузер.

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

Кто что думает по этому поводу?

← →
DrPass © (2008-01-20 16:18) [1]

> Мысль наверняка не новая, но хотелось бы это обсудить

Мысль настолько не новая, что уже душком недобрым попахивает

> Все чаще встречаюсь с тем, что в программе данные наиболее
> просто отображать в HTML-виде через TWebBrowser

Скажем так, в ряде случаев это действительно просто и удобно. В других случаях - не просто и неудобно.

> Ведь по сути все идет к тому, что не будет в программах
> привычных нам GUI-элементов, все вытеснит WEB,

Это вряд ли. Данный подход плохо подходит для создания действительно интерактивных приложений. Грубо говоря, веб-приложения хороши там, где надо много читать, но плохи там, где надо много нажимать и вводить.
Нет, конечно, с помощью современных технологий вроде тотально разрекламированной AJAX можно сделать тот же GUI в окне броузера... но цена разработки и сопровождения не стоит результата, чесслово.

← →
DrPass © (2008-01-20 16:22) [2]

Ах да, есть еще Сильверлайт 1.1, там нам обещают слегка кастрированное, но зато производительное и удобное дотнет-ядро для использования на страничках вместо несчастного ДжаваСкрипта... ну, посмотрим, что у Майкрософта получится... Хотя это будет тот же самый GUI, только форма встроена в виде объекта в окошко броузера...

← →
Piter © (2008-01-20 16:22) [3]

DrPass © (20.01.08 16:18) [1]
В других случаях - не просто и неудобно

приведи пример?

DrPass © (20.01.08 16:18) [1]
но плохи там, где надо много нажимать и вводить

опять не понял. Можно пример? Вводить данные в WEB-среду ничуть не сложнее и менее эффективно, чем в GUI. И как ты сам правильно заметил, в крайнем случае на WEB можно сделать практически полную аналогию GUI, только зачем?

Я не вижу разницы между тем, чтобы ввести строчку в TEdit или в такой же WEB-элемент.

← →
DVM © (2008-01-20 16:24) [4]

Тормозно это и монстуозно. Запускать IE и отжирать 50 мег. ОЗУ для того чтобы отобразить интерфейс блокнота, который сам по себе может раз в 20 меньше памяти потреблять.

← →
DrPass © (2008-01-20 16:29) [5]

> Piter © (20.01.08 16:22) [3]

> Вводить данные в WEB-среду ничуть не сложнее и менее эффективно,
> чем в GUI

Я написал, что
> сделать тот же GUI в окне броузера... но цена разработки
> и сопровождения не стоит результата

Т.е. сделать удобный интерактивный интерфейс можно, но слишком сложно. Нет для ДжаваСкрипта полноценных инструментов разработки. И не может быть, ввиду ограниченности самого языка. Про остальные характеристики молчу.
Простой пример - на презентухе Майкрософта демонстрировалась JavaScript-программа, которая играла в шахматы. Компьютер был обычный, в корпус я там не заглядывал, но думаю, какой-нибудь КореДуо. Он в секунду перебирал порядка 700 ходов.
Так вот, у меня в юности было чудо советской электроники "Поиск 1.04". 16-битный процессор 4.77 МГц, по тестам в два раза медленнее РС ХТ. Я с ним тоже играл в шахматы. Он перебирал в секунду около 1000 ходов...

← →
Piter © (2008-01-20 16:38) [6]

DVM © (20.01.08 16:24) [4]
Запускать IE и отжирать 50 мег

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

DVM © (20.01.08 16:24) [4]
Тормозно это и монстуозно

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

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

DrPass © (20.01.08 16:29) [5]
Т.е. сделать удобный интерактивный интерфейс можно, но слишком сложно

ладно, переформулирую вопрос.

Вводить данные в TEdit проще, чем в:

<input type="text" name="text">

Прошу объяснить чем проще?

← →
kaif © (2008-01-20 16:38) [7]

Я думаю, что ты прав.

По крайней мере приложения масштаба предприятия все чаще строят на основе взаимодействия клиента с системой на своем рабочем месте через браузер. Я лично знаю места, где используют ASP + IIS (например вчера я видел такое решение в страховой компании "Спасские ворота") или же JAVA + JSP + контейнер сервлетов (эта технология используется, например, администратором торговой сети РАО ЕЭС). Возможно, что народ уже где-то реально использует и ASP.NET (который я сейчас пытаюсь изучить).

При таком подходе проще развертывать системы и эксплуатировать клиентские компьютеры, проще эти системы администрировать, поддерживать и развивать. А самое главное - проще интегрировать разные элементы системы, базирующиеся территориально в самых разных местах. Например, офис, склад и интернет-магазин.

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

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

← →
Piter © (2008-01-20 16:43) [8]

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

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

Используются сотни компонент от различных разработчиков, частенько глючных - чтобы красиво выводить на экран информацию. Но зачем, когда есть целая ТЕХНОЛОГИЯ по отображению данных, и по возможностям с этой технологией не сравнится ни один элемент.

← →
Virgo_Style © (2008-01-20 16:48) [9]

Ну делай web-интерфейс, кто ж тебе мешает-то...

← →
DrPass © (2008-01-20 16:51) [10]

> Piter © (20.01.08 16:38) [6]

>
> Вводить данные в TEdit проще, чем в:
>
> <input type="text" name="text">
>
> Прошу объяснить чем проще?

Ммм... ладно, давай крупными буквами напишу, так может быть, будет понятнее. ВВОДИТЬ ТУДА ОДИНАКОВО. А РЕАЛИЗОВАТЬ УДОБНУЮ ДЛЯ ПОЛЬЗОВАТЕЛЯ ЛОГИКУ РАБОТЫ ДЛЯ ВЕБ-ИНТЕРФЕЙСА НАМНОГО СЛОЖНЕЕ.
Ну-ка, прикрути к этому <input type="text" name="text"> проверку орфографии. Получилось?
А теперь сделай хотя бы автоматический переход на другой контрол. А сделай автоматический поиск и выбор значения в гриде по фильтру, значение которого ты только что ввел в <input...>

> По крайней мере приложения масштаба предприятия все чаще
> строят на основе взаимодействия клиента с системой на своем
> рабочем месте через браузер

Вот. Вот одно из тех применений, где веб-приложения действительно могут быть к месту.
Хотя мы нашли более эффективный способ и для энтерпрайз-решений. RDP-терминалы + виндовые терминальные серверы + обычные виндовые приложения. При сотне пользователей на сервере производительность в разы выше, чем для веб-приложений.

← →
DrPass © (2008-01-20 16:54) [11]

> и опять насчет отжираемой памяти - народ, это давно не аргумент

Это еще какой аргумент. Сколько у тебя там памяти? 2 Мб? 4Мб? А если твое приложение запущено на сервере (надеюсь, ты ж имеешь в виду работу с серверным веб-приложением, а не локальный веб-сервер на своей машине), и там таких как ты пользователей пара сотен сидит?

← →
Petr V. Abramov © (2008-01-20 16:54) [12]

> kaif © (20.01.08 16:38) [7]

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

HTML и браузеры изначально предназначены для просмотра информации, потом за уши прикрутили простейшие возможности ввода. Поэтому сделать что-нибудь типа 1С, предназначенное для размеренной неторопливой работы - можно, примеров полно. А вот что-нить типа R-Keeper - я примеров не видел, хотя тоже, наверное, можно, если задаться целью, только зачем использовать несвойственные задаче технологии?

← →
Eraser © (2008-01-20 16:54) [13]

> Piter ©

MS VS2008 поддерживает такую штуку, как WPF, возможно заинтересует.

← →
kaif © (2008-01-20 16:58) [14]

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

Хотя мы нашли более эффективный способ и для энтерпрайз-решений. RDP-терминалы + виндовые терминальные серверы + обычные виндовые приложения. При сотне пользователей на сервере производительность в разы выше, чем для веб-приложений.

Интересно, что Вы будете делать, когда фирма откроет филиал в Нью-Йорке и захочет, чтобы "там на экране было все то же самое". Боюсь. что "производительность на сервере" - это лишь цена вопроса, а вот плохая масштабируемость в эпоху глобализации может стать смертным приговором.

← →
boa_kaa © (2008-01-20 17:02) [15]

А слабо веб-интерфейс к экселю прикрутить?
ИМХО: кесарю - кесарево, а богу - богово.

← →
DrPass © (2008-01-20 17:02) [16]

> Интересно, что Вы будете делать, когда фирма откроет филиал
> в Нью-Йорке и захочет, чтобы "там на экране было все то
> же самое".

При нашем подходе у них на экране будет то же самое. Не вижу никаких препятствий, особенно если учесть, что RDP-терминал куда менее требователен к качеству канала, чем броузер.

> В любом случае значение будет иметь не то, насколько все
> это удобно программисту, а то, насколько это удобно, дешево
> и масштабируемо для пользователя

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

← →
DVM © (2008-01-20 17:03) [17]

> Piter © (20.01.08 16:38) [6]

> а для него в память уже обычно все давно загружено.

Специально сравнил. Пустой проект без WebBrowser но с полем Memo 5 мб в памяти. Тот же проект с WebBrowser и полем для ввода текста на загруженной странице 25 мб. При этом IE загружен уже и занимает сам по себе 40 мб.

> Piter © (20.01.08 16:43) [8]

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

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

← →
kaif © (2008-01-20 17:05) [18]

Petr V. Abramov © (20.01.08 16:54) [12]

> kaif © (20.01.08 16:38) [7]

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

Где ты видишь два сервера?

Берем IIS, приложение ASP.NET и сервера баз данных. Хочешь, обращайся из приложения к 1С через COM, хочешь - к web-сервису курсов валют, хочешь - к web-сервисам метерологических служб. Соединяй любую информацию на уровне ASP.NET приложения.

О каких двух серверах идет речь?

И еще такой момент. Ты знаешь, сколько стоит обучение людей работе в каждой новой системе? А с браузером почти все умеют работать.

Впрочем, никто ведь не отменяет обычные Windows-приложения. Они тоже нужны. Просто они вряд ли в состоянии в ближайшее время решить ту лавину проблем, которая стала возникать у компаний в связи с глобализацией бизнеса.

← →
Petr V. Abramov © (2008-01-20 17:09) [19]

> Интересно, что Вы будете делать, когда фирма откроет филиал
> в Нью-Йорке и захочет,

а чем это отличается установки компа в соседней комнате? В Нью-Йорке, говорят, со связью все нормально. А вот на окраине Урюпинска, где единственная связь - модем через АТС 60-х годов, может оказаться, что трехзвенка медленнее грамотно написанной двузвенки, примеры видел.

← →
NailMan © (2008-01-20 17:10) [20]

[15] boa_kaa ©
у Google такая есть функция. и Ворд и Эксель и аналог Поверпоинта

---
P.L.U.R. and WBR, NailMan aka 2:5020/3337.13

← →
kaif © (2008-01-20 17:11) [21]

DrPass © (20.01.08 17:02) [16]
При нашем подходе у них на экране будет то же самое. Не вижу никаких препятствий, особенно если учесть, что RDP-терминал куда менее требователен к качеству канала, чем броузер.

Я просто не знаком с этой технологией.
Возможно, она прекрасна.
Победит то, что будет распространено повсеместно.
Важно не то, лучше MySQL, чем Firebird или хуже. Важно то, сколько провайдеров его поддерживают и насколько хорошо поддерживают.
Этот принцип и определяет вектор развития любой технологии в наши дни. 1С - не лучшая бухгалтерия. Однако она повсеместно распространена. Поэтому тот, кто может с ней взаимодействовать, выиграет у того, кто с ней взаимодействовать не желает. Такова природа программного продукта. Большинство коммерческих программ пишутся на Visual Basic. Как это не смешно звучит, но это так.

← →
Petr V. Abramov © (2008-01-20 17:15) [22]

> kaif © (20.01.08 17:05) [18]
> О каких двух серверах идет речь?

об IIS + сервере БД
> Ты знаешь, сколько стоит обучение людей работе в каждой
> новой системе?

а что, если система свои едиты и гриды рисует в браузере, а не на форме, с ней обучать работать не надо? что-то компании, обучающие OEBS и прочим SAP`ам не бедствуют, хоть продукты трижды WEB`ные.

← →
Piter © (2008-01-20 17:19) [23]

DrPass © (20.01.08 16:51) [10]
Ну-ка, прикрути к этому <input type="text" name="text"> проверку орфографии. Получилось?

да легко. А что тут сложного? Почему ты уперся, что делать это надо средствами JavaScript? Море разнообразия, хочешь конечно - можешь JS, а можешь просто повесить событие OnChange на этот элемент и как тебе угодно обработать в программе сие действие. В чем проблема?
В том, что на обработку события в Delphi надо вызвать инспектор объектов, а в WEB подходе написать пару строчек, и то только потому, что Delphi-среда поддерживает VCL, а WEB не умеет. Но имхо и эта проблема временная, да и не проблема особенно.

DrPass © (20.01.08 16:51) [10]
А теперь сделай хотя бы автоматический переход на другой контрол

автоматический это как? Но в любом случае сделаю, если ты это сделаешь в D. Хоть на JS, хоть на самом дельфи, ты забываешь что к КАЖДОМУ элементу страницы можно обратиться как к объекту.

DrPass © (20.01.08 16:54) [11]
А если твое приложение запущено на сервере (надеюсь, ты ж имеешь в виду работу с серверным веб-приложением, а не локальный веб-сервер на своей машине

я вообще про серверы не упоминал, я говорил про интерфейс программа основанный на HTML, а не на стандартных GUI-элементах. А сервер ли это, отдающий данные по HTTP или локально в элемент типа TWebBrowser - не так важно.

boa_kaa © (20.01.08 17:02) [15]
А слабо веб-интерфейс к экселю прикрутить?
ИМХО: кесарю - кесарево, а богу - богово.

естественно. Никто не говорил про полную замену WEB"ом.
Сложно представить word, excel, Photoshop, 3D Studio Max написанный на WEB, игра не стоит свечь.

Но в обычных бизнесс-приложениях - самое то.

← →
Piter © (2008-01-20 17:19) [24]

kaif © (20.01.08 16:58) [14]
Боюсь. что "производительность на сервере" - это лишь цена вопроса, а вот плохая масштабируемость в эпоху глобализации может стать смертным приговором.

полностью согласен.

← →
Petr V. Abramov © (2008-01-20 17:24) [25]

> Сложно представить word, excel, Photoshop, 3D Studio Max
> написанный на WEB, игра не стоит свечь.
> Но в обычных бизнесс-приложениях - самое то.

обычнее Екселя бизнес-приложение представить сложно :)

← →
ketmar © (2008-01-20 17:25) [26]

>[5] DrPass©(20.01.08 16:29)
>ввиду ограниченности самого языка.
благодарю, посмеялся. не будет ли благородный дон столь любезен повторить на Delphi нижеследующее (пример специально урезан до максимума):
var a = function () { print(arguments.callee.n++); }; a.n = 5; a(); a(); a();

пояснение: print() тупо выводит аргументы на какой-нибудь stdout.

зыж в оригинале это использовалось в js-коде. не моём. код весьма умно написан.

← →
Petr V. Abramov © (2008-01-20 17:27) [27]

> а вот плохая масштабируемость в эпоху глобализации может
> стать смертным приговором.

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

← →
Piter © (2008-01-20 17:36) [28]

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

Просто это средство визуального проектирования, так сказать. Сюда относится Word, Excel, PowerPoint. На мой взгляд обычные бизнесс-приложения не таковы, у них не очень то сильно развита визуальная частьи, они обычно заточены под конкретный вид деятельности или даже конкретную фирму.

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

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

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

ниасилил, но судя по всему это неважно ;)

>[28] Piter ©(20.01.08 17:36)
>любом случае я имел бизнесс-приложения, которые пишутся обычно внутри
>самой фирмы ее IT-отделом, а не мультифункциональные программные продукты
>для всех.
я тоже имел всякие наколенные поделки. в необычных позах имел.

← →
Черный Шаман (2008-01-20 17:54) [32]

> DrPass © (20.01.08 16:22) [2]
>
> Ах да, есть еще Сильверлайт 1.1, там нам обещают слегка
> кастрированное, но зато производительное и удобное дотнет-
> ядро для использования на страничках вместо несчастного
> ДжаваСкрипта... ну, посмотрим, что у Майкрософта получится.
> .. Хотя это будет тот же самый GUI, только форма встроена
> в виде объекта в окошко броузера...

реинкарнация ActiveX?

Как много вирусов нам разных
Сулят творения Microsoft... (c) почти поэт

Проблем web-like интерфейсов в кнопке back. Не всегда в десктопных приложениях можно интуитивно понять ее поведения.

TWebBrowser - это немного не то, ибо есть HTMLLayout

Вопрос ОДИНАКОВОГО интерфейса везде действительно стоит. Вопрос не в веб-, невеб-, а в одинаковости.

> Piter © (20.01.08 17:19) [23]

> да легко. А что тут сложного? Почему ты уперся, что делать
> это надо средствами JavaScript? Море разнообразия, хочешь
> конечно - можешь JS, а можешь просто повесить событие OnChange
> на этот элемент и как тебе угодно обработать в программе
> сие действие. В чем проблема?

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

> Хоть на JS, хоть на самом дельфи, ты забываешь что к КАЖДОМУ
> элементу страницы можно обратиться как к объекту.

Я знаю JS :))) Не гуру, но делал довольно сложные вещи. Поэтому знаю, что если в Delphi или в любой другой подобной среде это делается парой строк, дергающих функции стандартных библиотек, то в JS... у тебя просто не будет таких библиотек. Тебе надо будет написать полотенце трудно отлаживаемого кода.

> я вообще про серверы не упоминал, я говорил про интерфейс
> программа основанный на HTML, а не на стандартных GUI-элементах.
> А сервер ли это, отдающий данные по HTTP или локально в
> элемент типа TWebBrowser - не так важно.

ОК. Ну наверное, локально пихать документ в элемент типа TWebBrowser - занятие интересное только с точки зрения изучения TWebBrowser, не так ли? Ты ж надеюсь не рассматриваешь всерьез полезность написания виндового приложения, которое формирует свою морду в броузере? %)
Т.е. веб-приложения однозначно подразумевают наличие веб-сервера и серверной технологии построения страниц, будь-то ASP [.NET], PHP, Perl и иже с ними.

> ketmar © (20.01.08 17:25) [26]

Легко.
var a = class n: integer; procedure print; end; procedure a.print begin writeln(n); inc(n); end;

А ты теперь попробуй освободить однажды созданный в JavaScript СОМ-объект ДО того, как отработает весь скрипт :)

> Проблем web-like интерфейсов в кнопке back

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

http://docs.google.com
тут вам и эксель, и ворд, и поверпоинт

← →
Черный Шаман (2008-01-20 18:04) [37]

> Piter © (20.01.08 16:12)
> Проблемы обычно возникают с нестандартными графическими
> элементами, но таких элементов все меньше, уже давно наладили
> вывод и звука, и видео даже.
>
> Кто что думает по этому поводу?

Подойдёт только для business-only приложений, так как тот же векторный/растровый редактор (которым будут пользоваться) через Web ты не напишешь.

Гораздо умнее использовать WEB для онлай-загрузки приложений. Технология Java Web Start когда приложение запускается через web и инсталлирует и поддерживает нужные пакеты через Web-сервер, а потом стартует на обычной машине. Нечто вроде автоматического SVN, но для исполняемых программ.

>[34] DrPass©(20.01.08 17:58)
>Проблема в том, что на JS ты не сможешь написать работающий в реальном
>времени алгоритм проверки орфографии, даже на самом навороченом компе.
4.2

>взаимодействие со страницей в броузере
и таки я вас спрошу: при чём тут браузер? O_o

>то в JS… у тебя просто не будет таких библиотек.
мне кто-то мещает их написать/использовать готовое?

ещё раз: JavaScript != DHTML. я вот отлично использую сейчас js заместо bash. и обёртки для библиотек нужных у меня есть.

ты говорил про язык, а теперь приплёл зачем-то конкретную платформу…

>[37] Черный Шаман (20.01.08 18:04)
весь ваш JWS накрывается медным тазом, ежели нет самой жабы. а браузер — он того… на любом практически десктопе есть. в 99.99% случаев. и ему тоже плевать на платформу.

← →
Черный Шаман (2008-01-20 18:13) [40]

> ketmar © (20.01.08 18:08) [39]
>
> >[37] Черный Шаман (20.01.08 18:04)
> весь ваш JWS накрывается медным тазом, ежели нет самой жабы.
> а браузер — он того… на любом практически десктопе есть.
> в 99.99% случаев. и ему тоже плевать на платформу.

Ты напиши любой более-менее нормальный скрипт на JS который нормально работает на ВСЕХ броузерах.

WEB - как стандартный интерфейс программы? Найти похожие ветки