На работе иногда устраиваем с коллегой словесные перепалки по поводу современного программирования вообще (C++ отстой и Java – наше все, естественно :), и о Web-программировании в частности. Разговоры о Web-программировании меня особенно радуют – поскольку к Web-у я отношения не имею и наблюдаю за всем происходящим со стороны.
Лично я распространение Web-приложений считаю штукой очень неоднозначной. Имхо, это какой-то маразм. В обычных Web-приложениях раздражает постоянное смаргивание экрана и тормознутость. В AJAX-овских приложениях этого нет, зато есть большие объемы насыщенных JavaScript-ом страничек (помню, как я был поражен, когда обнаружил, что странички в нашем корпоративном Confluence весят более мегабайта).
Когда я десять лет назад оказался в Web-проекте (после многих лет программирования GUI под DOS-ом, Windows и OS/2), я был поражен примитивностью возможностей тогдашнего инструментария и жуткой смеси разных технологий на одной страничке: HTML+Java (которое JSP) + CSS + JavaScript + пляски с бубном для унификации поведения странички под разными браузерами. Сейчас, говорят, дело наладилось, но все равно с моей колокольни все это выглядит примитивно. Еще 20 лет тому в DOS-овских Norton-овских утилитах и MultiEdit-е были многоэтажные менюшки, накладывающиеся друг на друга модальные диалоговые окна и везде были горячие клавиши. Повторение всего этого сейчас под Web-технологиями вряд ли вообще возможно. Может быть, лет через несколько :)
Собственно, насколько я могу судить, процесс по наращиванию возможностей Web-приложений идет в сторону отказа от текстово-разметочной структуры в сочетании с JavaScript-ом в пользу Flash-евых апплетов. Вот там простор для разработчика, достаточно посмотреть на то, что вытворяют создатели Flash-евых игр (из последнего увиденного впечатлила вот эта: SteamBird). И если уж динамичные игры Flash-евых возможностей достаточно, по почему бы не делать на Flash-е нормальные GUI-интерфейсы для Web-приложений (с менюшками, диалоговыми окнами, горячими клавишами и пр.)?
Но если Flash – это такая удобная штука для Web-программирования, то лично у меня возникает вопрос – а почему Flash, а не Java-апплеты? Ведь когда-то давным-давно, когда Sun представила Java широкой публике, Java-апплеты были главным местом приложения самой Java. Но почему-то не срослось…
Десять лет назад я спрашивал у коллег, а почему Web-приложения разрабатываются в виде JSP-страничек с JavaScript-ом внутри, а не в виде Java-апплетов. Не помню уже всех деталей, но история была такой – мои коллеги до этого писали программулину на Java-апплетах и апплеты получались очень большими по тем временам – около 500Kb и более. По сравнению с загрузкой 10Kb страничек загрузка на машину Java-апплета была гораздо более долгой операцией. Ну и плюс к тому, из Java-апплетов, насколько я помню, было неудобно взаимодействовать с серверной частью, поскольку AJAX-а тогда не было.
Но сейчас-то ситуация иная. 500Kb апплет – это очень немного (стартовая страница международной федерации биатлона весит больше (редиски!), а это всего лишь стартовая страница). Плюс Java работает гораздо быстрее, чем в 90-х годах, да и техника сейчас гораздо мощнее. Плюс взаимодействие с сервером практически стандартизировано для Web-приложений.
Казалось бы, сделать кэширование Java-апплетов на стороне клиента, чтобы не грузить его лишний раз, если его версия с прошлой загрузки не изменилась – и вообще всеобщее шасте будзе :) Как раз главный аргумент приверженцев Web-программирования – централизованное распространение новых версий приложения – сработает и здесь. Можно было бы пойти и дальше – браузер выбросить! В JDK входит appletviewer, который позволяет автономно воспроизводить апплеты. Вот развили бы его и сделали бы из него среду для работы апплетных приложений. Даешь ему URL-ик приложения, он проверяет кэш, и запускает либо ранее загруженный апплет, либо скачивает новый. В него же можно будет добавить и необходимые средства для обеспечения оффлайновой работы приложения (например, для сохранения данных на машине пользователя).
Но этого не происходит. Вместо этого все идет к тому, что на обычной машине будет две операционки – одна работает на голом железе и обеспечивает запуск десктопных приложений и браузера. А второй операционкой будет сам браузер – он будет средой для работы Web-приложений. В случае же Chromium OS нас вообще заставят забыть о том, что есть еще какая-то другая операционка, кроме браузера.
Не знаю, может кому-то все это кажется логичным, но не мне.
8 комментариев:
жуткой смеси разных технологий на одной страничке: HTML+Java (которое JSP) + CSS + JavaScript + пляски с бубном для унификации поведения странички под разными браузерами.
Да, есть такое. Но в противном случае потребуется установка дополнительного программного обеспечения (плагина для браузера), которое будет отвечать за визуализацию и исполнение кода на клиентской машине. В качестве примера можно привести технологию Curl (www.curl.com), про которую Вы когда-то писали в своем блоге. Никаких плясок с бубном плюс унифицированный язык для описания разметки страницы и поведения.
многоэтажные менюшки, накладывающиеся друг на друга модальные диалоговые окна и везде были горячие клавиши. Повторение всего этого сейчас под Web-технологиями вряд ли вообще возможно.
Если воспользоваться каким-нибудь мощным Javascript фреймворком, то вполне может получиться. В свое время я немного работал с YUI Library (http://developer.yahoo.com/yui/), никаких проблем с виджетами там нет. Но скорость развития этой библиотеки не слишком впечатляет, так как разработчикам приходится разбираться с несовместимостью браузеров, проводить большое количество тестов (для каждого сочетания браузера и ОС) и т.д.
>Никаких плясок с бубном плюс унифицированный язык для описания разметки страницы и поведения.
Ага, что-то вроде этого. Но у Curl-а изначально шансов было мало, никто крупный его не толкал. В отличии от Java. Ведь поддержка Java-апплетов была встроена чуть ли не в каждый браузер.
Теперь тоже самое происходит с Flash-ем -- редко у кого Flash-плагин для браузера не установлен.
>Если воспользоваться каким-нибудь мощным Javascript фреймворком, то вполне может получиться.
Ну и хорошо, наверное. Дальше будет еще более функциональные инструменты. Но маразм для меня в том, что еще 20 лет назад все это было, причем в очень продвинутых формах (взять, скажем TurboVision или Zinc Interface). Т.е. на наших глазах происходит простое переизобретение велосипеда. А говорят -- прогресс в ИТ, прогресс в ИТ... :)
Вот самого когда-то беспокоил этот вопрос :)
Для себя решил так, что java не используется в этой области потому, что не имеет удобных средств, позволяющих быстро сделать красивый и функциональный сайт. То есть мне кажется, что развитие java в этом направлении остановилось очень давно, и flash предоставляет куда больше удобств.
Кроме того, возможно я не прав, но есть ощущение, что использование java предполагает несколько больших знаний или способностей, чем использование flash. То есть далеко не каждый школьник налабает что-то вменяемое на java.
Вообще же всё не так страшно, имхо, как у вас написано :) По-крайней мере есть чёткое разделение труда - дизайнер, верстальщик, программист - и то, что используется целая куча технологий, никого не тревожит. Унификация же под разные браузеры это хитрая вещь. Во-первых, использование js библиотек (упомянутый yui, jquery и т.п.) решает эту проблему почти полностью, во-вторых - ну кому она реально нужна, эта поддержка во всех браузерах? :)
В проекте, которым я сейчас руковожу, для т.н. подсистемы доступа, являющейся торчащим в web интерфейсом для поиска по системе документооборота, в тз чётко прописано - только ie 6 и выше и ff 3 и выше. Пользователями opera и chrome было решено пожертвовать, хотя фактически и у них всё работает, но с некими небольшими ошибками вёрстки.
>То есть мне кажется, что развитие java в этом направлении остановилось очень давно, и flash предоставляет куда больше удобств.
Даже у меня, очень далекого от каких-либо web-проектов, сложилось впечатление, что Sun забила болт на Java-апплеты очень и очень давно. Наверное, когда в конце 90-х Java стала окупировать server-side.
>То есть далеко не каждый школьник налабает что-то вменяемое на java.
Тут мне сложно судить. Краем глаза глянул на ActionScript 3 -- имхо, те же яйца, что и Java. Мозги ломать как в случаях с Scala, OCaml/F# или Haskell точно не приходится.
>Вообще же всё не так страшно, имхо, как у вас написано :)
Вот и здорово :)
>В проекте, которым я сейчас руковожу, для т.н. подсистемы доступа, являющейся торчащим в web интерфейсом для поиска по системе документооборота, в тз чётко прописано - только ie 6 и выше и ff 3 и выше.
Вот здесь у меня так же непонимание возникает. Когда разрабатывается продукт для конкретного клиента, ну или просто для ограниченного контингента, то какой смысл в Web-приложениях вообще? Вот, скажем, у нас разрабатывается специализированный софт. К нему идет Web-консоль для управления и статистики. Эта Web-консоль используется, ну в пределе, несколькими сотнями пользователей. Зачем здесь вообще Web, браузеры, HTML-странички с тонами js-кода внутри? Для таких целей какой-нибудь Curl, а еще лучше appletviewer -- самое оно.
> Когда разрабатывается продукт для конкретного клиента, ну или просто для ограниченного контингента, то какой смысл в Web-приложениях вообще?
Ну у нас проект именно в этой его части не только для конкретных пользователей. Доступ будет у всех, это система документооборота в сфере законодательства.
Но и в случае других проектов я вижу преимущество использования такого подхода: полная кроссплатформенность.
Браузеры сейчас есть и в мобильниках. И обеспечение работы под разными платформами вообще не проблема, не смотря на все возникающие при таком подходе сложности.
curl, appletview могут этим похвастаться?
P.S. Это я, murzilka17
>Браузеры сейчас есть и в мобильниках. И обеспечение работы под разными платформами вообще не проблема, не смотря на все возникающие при таком подходе сложности.
Вот у моего ADSL модема настройка делается через Web-интерфейс. Вроде бы разработчикам удобно - написали один раз и им пофигу, из-под Windows я его конфигурирую, из-под Unix-а какого-нибудь, или с мобилки. Только вот мне, как пользователю, работать со всем этим убожеством (с нормального компьютера) неприятно. Вспоминается, как в 90-х какая-нибудь железяка сопровождалась софтом для свой настройки. Этот софт был не лучше и не хуже нынешних, но он не тормозил и не перерисовывал полностью экраны (как это делается сечас при смене содержимого страницы).
Лет через несколько и дешевые ADSL-модемы, вероятно, будут комплектоваться Web-консолями на AJAX-е, и там такие проблемы не будут бросаться в глаза. Но ведь не сегодня и не сейчас.
>curl, appletview могут этим похвастаться?
Curl -- вряд ли. А appletviewer есть там, где есть Java SDK.
Я чего хочу сказать: сейчас браузеры превращаются в среду для исполнения Rich Internet Application. Вот это мне кажется неправильным. Браузеры пусть показывают HTML-странички, а для RIA пусть развиваются автономные и специализированные RIA-лаунчеры. Вот, например, выпускает Adobe FlashPlayer не в виде плагина к браузерам, а в виде автономного приложения и все! Flash-приложение лежит на сервере, грузится по запросу, имеет возможность общения с сервером но HTTP. И про пляски вокруг HTML+CSS+JS можно забыть.
Похоже, что прообраз того, о чем я говорю, уже пытаются развивать и продавать: http://en.wikipedia.org/wiki/UltraLightClient
Отправить комментарий