Алик Кириллович

Закат Веба?

07 июля 2008 г.

7 марта прошлого года W3C, после 10-летнего перерыва, возобновила работу над HTML.

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

Спустя год с интересом перечитал свои предположения: во многом я оказался прав, хотя, кое-где и ошибался.

Я решил выложить их здесь в виде статьи, переработав и снабдив иллюстрациями и примечаниями.

 

В настоящий момент мир вступает в эпоху расцвета богатых web-приложений.

Программы, работающие через Веб, всё больше вытесняют традиционные десктопные приложения. Gmail, Google Map, online-офис, даже web-операционные системы… Список можете продолжить сами.

Однако, по мере продвижения web-приложений, всё больше возрастают требования к основным клиентским web-технологиям: xHTML, CSS, JavaScript.

И, если эти технологии не будут поспевать за всё более возрастающими требованиями, это приведёт к их медленному закату…

Сценарии гибели:

Гибель ментальная, или HTML — новый ассемблер

Ассемблер На заре IT все программы писались на ассемблере.

Программисты вылизывали свой ассемблерный код, стараясь сделать его красивее, понятнее и эффективнее.

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

Однако, ассемблер был низкоуровневым языком: в нём отсутствовали порой даже такие элементарные команды, как умножение и деление, которые разработчикам приходилось описывать вручную с помощью низкоуровневых команд.

Поэтому, на смену ассемблеру пришли языки высокого уровня. Ассемблер при этом физически никуда не делся — все программы на высокоуровневых языках компилируются во всё тот же ассемблерный код [1]. В уродский неэффективный (по сравнению с написанным вручную) ассемблерный код.

C++ Тем не менее, ассемблер исчез [2]. Исчез из сознания программистов. Они стали писать на высокоуровневых языках, уже на этих языках вылизывать код программы и доводить его до совершенства. А то, что красивая программа на C++ компилируется в уродский ассемблерный код, совершеннго справедливо, никого не волнует.

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

Таким образом, никуда не деваясь физически, ассемблер исчез из прикладной IT индустрии.

 

Подобная судьба может ждать и xHTML/CSS/JS.

HTML За всё время существования Веба, основной web-технологией был xHTML.

Web-разработчики довели эту технологию до совершенства: научились отделять представление от содержания посредством CSS, применять бестабличную и семантическую вёрстку, использовать микроформаты…

Но, в xHTML нет столь нужных для современных web-приложений тегов, таких как вкладки, меню, деревья, календари и т.д.

Чем удачно воспользовалась корпорация Микрософт. У Микрософта давний зуб на web-технологии, ведь будучи открытыми стандартами, они (в отличие от Windows API) не подчиняются микрософтовской власти. С этим надо было что-то делать, и раз Микрософт не могла уничтожить xHTML физически, надо было, чтобы он исчез хотя бы в сознании разработчиков.

ASP.net Так появилась клиентская концепция ASP.NET [3]. В ASP.NET работа идёт с высокоуровневым серверными контролами (меню, вкладками, деревьями), которые затем «компилируется» [4] в HTML, CSS и JavaScript, так же как программа на C++ компилируется в машинный код или ассемблер.

xHTML/CSS/JS исчезает из сознания web-разработчиков; более того, они в какой-то мере перестают быть web-разработчиками, возвращаясь в привычную Windows forms / Delphi / Visual Basic парадигму, к «старым добрым Windows API».

В ASP.NET обесценивается то, что мы так долго учили: умение писать понятный xHTML код, бестабличная и семантическая вёрстка и т.д. Обесценивается даже одна из основ Веба — CSS, ведь оформление сайта можно задавать при помощи ASP.NET тем (themes), идеология которых сильно отличается от каскадной модели CSS.

Script# Для того, чтобы разработчики забыли и про JavaScript, Микрософт собирается выпустить Script# — компилятор, позволяющий писать клиентские скрипты на C#, а затем компилировать их в JavaScript.

Многие разработчики не любят ASP.NET [5]. Он заточен под быстрое и удобное решения типовых задач. Но сделать что-то нетривиальное гораздо красивее на чистом HTML, CSS и JavaScript.

Однако нетривиальные задачи встречаются, может быть только в 1% случаев, а оставшиеся 99% типовых задач быстрее решить на ASP.NET. Быть может, это не так красиво, но бизнес требует скорости разработки…

Delphi for PHP Другим web-технологиям уже сложно конкурировать с ASP.NET. Недавно появился продукт Delphi for PHP, с помощью которого PHP разработчики начинают думать в рамках Windows парадигмы Delphi [6].

Если дело пойдёт дальше, web-технологии ждёт судьба нового ассемблера. HTML/CSS/JS физически по-прежнему оставаясь основными web-технологиями, могут стать низкоуровневыми языками и исчезнуть из сознания разработчиков.

Гибель физическая, или HTML — новый Turbo Pascal

Вы наверно помните среду разработки Turbo Pascal. Это была консольная программа с текстовым псевдографическим интерфейсом. Всё, что было у разработчиков оболочки Turbo Pascal — это матрица из 80 × 25 символов ASCII, их цвет и фон. Всё!

Turbo Pascal И из этих текстовых символов они сделали невозможное: реализовали многооконный интерфейс, с главным и контекстным меню, псевдо-трёхмерными нажимающимися кнопками, технологией перетаскивания окон… В общем, почти всё, что сейчас есть в современной графической Windows’овской программе.

Однако, перепрыгнуть ограничения таблицы из 80×25 символов было невозможно. Как ни старайся, нельзя нарисовать объект тоньше одного символа или провести диагональную, а тем более изогнутую линию. Интерфейсы наподобие Turbo Pascal ушли в историю, уступив место графическим интерфейсам Windows…

 

И опять, история может повториться. Призрак Turbo Pascal’я витает над xHTML…

Основа Веба — язык HTML не предназначался даже для создания сайтов (в современном их понимании), а тем более web-приложений. Тим Бернерс-Ли создал его для простой разметки научных документов, наподобие Word.

GMail И вот, на основе языка разметки научных статей + языка скриптов разработчики Gmail создали полнофункциональный почтовый клиент, не уступавший по интерфейсным возможностям классическим оконным программам, а порой даже превосходящий их.

Однако у web-технололгий есть ограничения, которые, как ни старайся, перепрыгнуть не удастся. Средствами чистого xHTML/CSS/JS нельзя создать 3D графику, векторную анимацию, управлять звуком, хранить большие объёмы данных на стороне клиента…

Silverlight Смена не заставит себя долго ждать. В качестве основы «богатых интернет приложений» компания Macromedia (сейчас Adobe) уже много лет продвигает Flash/Flex. Микрософт относительно недавно, но с удвоенным рвением продвигает WPF/Silverlight [7].

И если xHTML не изменится, он может повторить судьбу псевдографического интерфейса Turbo Pascal, навсегда исчезнув из IT-индустрии.

Всё ли так серьёзно?

Итак, клиентские web-технологии могут ждать две трагические судьбы:

Ментальной гибели не будет, если web-технологии будут правильно поняты

В отличие от ассемблера, который объективно был низкоуровневым языком, xHTML/CSS/JS лишь воспринимаются как низкоуровневые из-за неправильного их понимания разработчиками. Попробую показать, почему.

Ещё раз повторю:

Причина, по которой столь популярны серверные ASP.NET контролы (вкладки, деревья, меню, календари и т.д.), состоит в том, что в самом xHTML нет тегов для этих высокоуровневых интерфейсных элементов.

И поэтому, разработчикам приходится вручную описывать эти вкладки, меню и деревья с помощью мешанины низкоуровневых xHTML тегов: таблиц со сложными объединёнными ячейками, внутри которых вложенные таблицы с большим количеством тегов <font> и декоративных картинок для обрисовки веток. Примерно также, как много лет тому назад ассемблерные программисты описывали операцию деления с помощью мешанины низкоуровневых команд сложения и сдвига регистра.

ASP.net контролы в Visual Studio Все «прелести» низкоуровневого xHTML программирования налицо. Поэтому, гораздо проще выбросить из головы низкоуровневый xHTML код и работать с высокоуровневым ASP.NET контролом, который затем автоматически «скомпилируется» в xHTML, также как программа на C++ скомпилируется в ассемблер. Пусть получившийся xHTML негибок и уродлив [8], пусть нетривиальные вещи на ASP.NET сделать невозможно, но зато в оставшиеся 99% тривиальных задач решаются быстро и привычно.

Так вот:

Такой подход возникает, если относиться к xHTML как к языку визуальной разметки. Секрет же в том, что xHTML является языком не визуальной, а логической разметки, т.е. описывает не то, как должен выглядеть документ, а то, какие данные он содержит. И поэтому, он и не должен содержать теги, описывающие конкретные визуальные интерфейсные элементы. Вместо внешнего вида, xHTML описывает данные, которые содержит тот или иной интерфейсный элемент. А уже с помощью CSS соответствующий элемент «разукрашивается», так, чтобы выглядел как меню, вкладка или дерево; а JS придаёт ему требуемую функциональность.

Пример 1:

При высокоуровневом подходе:

Дерево — это не мешанина таблиц, вложенных таблиц, тегов <font> и картинок.

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

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

JavaScript придаёт списку функциональность дерева — открытие/закрытие узлов, выделение, перетаскивание и т.д.

Пример 2:

Меню, также, также как и дерево — это иерархическая структура. И оно, также, создаётся с помощью многоуровневого списка.

Просто потом, к этому списку применяется уже другой CSS и JS, придающий списку внешний вид и функциональность именно меню.

Пример 3:

Вкладки, по сути своей — это несколько разделов документа со своим заголовком. Поэтому, в xHTML, вкладки прекрасно описываются как несколько блоков <div>, каждый со своим заголовком <h2>.

А уже потом, JavaScript придаёт этим блокам функциональность вкладок, скрывая или показывая блоки в зависимости от действий пользователя.

Соответствующий CSS и JS код легко вынести во внешний компонент, позволяя тем самым программисту не думать об оформлении и работать только с данными интерфейсного элемента, сосредоточенными в xHTML коде.

При таком высокоуровневом подходе можно прекрасно обойтись без разных псевдо‑высокоуровневых надстроек, вроде серверных контролов ASP.NET.

Более того, xHTML является даже более гибким и высокоуровневым языком построения интерфейса, чем многие другие. Ведь именно потому, что xHTML хранит лишь данные, а не внешний вид и функциональность интерфейсного элемента, делает интерфейсы гораздо более универсальным. Т.е., в одной ситуации, один и тот же элемент ведёт себя как дерево, в другой — как меню, в третьей — как обычный список. При этом, xHTML код интерфейса остаётся неизменным. Мы даже можем превратить дерево в контекстное меню, а контекстное меню в список прямо на лету, без перезагрузки страницы! В каком ещё языке разметки интерфейса так можно?!

Но такой «высокоуровневый» подход сильно отличается от традиционного оконного Windows-подхода, и поэтому, непривычен и непонятен многим разработчикам. ASP.NET не является в полной мере более высокоуровневой, чем xHTML. Она скорее, больше пытается применить к Веб Windows-парадигму, чем перейти на более высокий уровень абстракции. А web-парадигма не всегда хорошо соотносится с парадигмой Windows, например, модель тем (themes) оформления в ASP.NET плохо соотносится с каскадной моделью CSS.

 

JSON Ещё одна непривычная и малопонятная для многих разработчиков web-технология — это JavaScript (который даже прозвали СНЯП (или СНЯПМ) — Самый Недооценённый Язык Программирования в мире).

JavaScript — удивительно мощный, гибкий и красивый язык, превосходящий в ряде случаев по гибкости и функциональным возможностям таких монстров, как Java или C#.

Однако, многие особенности JavaScript, придающие ему такую мощь и гибкость: ООП на основе прототипов, объекты-как-хеши, функциональное программирование, замыкания и т.д. оказались недопоняты разработчиками, привыкшими к классическим языкам, вроде C++, Java, Delphi или VB. Из-за этого, JavaScript стал восприниматься как детский, «игрушечный» недоязык для скрипткидди.

Не язык это, а скрипт. Даже классов нормальных в нём нету…

— не помню, откуда

Prototype.js Хуже всего, часть разработчиков даже не желают понять JavaScript, а пользуются библиотеками, вроде Prototype.js, или недавно вышедшей Microsoft Ajax Library (бывшая Atlas), в которых эмулируется классическое классовое ООП, что является страшным надругательством над JavaScript, лишающим его такой красоты и гибкости.

Prototype.js был написан теми, кто не знает JavaScript, для тех, кто не знает JavaScript

— Richard Cornford

 

Итак, первая причина потенциальной «гибели» xHTML/CSS/JS — превращения их в новый ассемблер, состоит в недопонятости этих технологий. Но, я надеюсь, в скором времени, большинство разработчиков лучше поймут философию web-технологий и научатся обходиться без псевдо-высокоуровневых костылей.

Физической гибели не будет, если web-технологии будут развиваться

С «физической гибелью» всё серьёзнее.

В web-технологиях сейчас действительно отсутствует ряд возможностей, необходимых для создания полноценных web-приложений: работа с 2D и 3D графикой, векторной анимацией, управление звуком, хранение большие объёмы данных на стороне клиента…

И поэтому, угроза со стороны Flash/Silverlight сильна как никогда.

Для того, чтобы не исчезнуть из IT-индустрии и не повторить судьбу Turbo Pascal, эти технологии должны развиваться и преодолевать собственные ограничения.

Надо заметить, что xHTML, CSS и JavaScript никогда не переставали развиваться.

W3C Однако, под руководством W3C, они развивались как средства представления информации, а не как технологии создания web-приложений.

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

W3C Была проделана огромная работа по созданию технологий Semantic Web: RDF, OWL и SPARQL. Semantic Web позволит сделать информацию в Вебе понятной не только человеку, но и компьютеру. Это, например, даст возможность строить SPARQL-запросы «ко всему интернету», вроде такого: «Сколько щенков у собаки 2-го президента России?»

Но, скажем, web-формы так и остались на уровне 1995 года [9].

И, похоже, на W3C надежды было мало.

WHATWG К счастью, нашлись те, кто осознал проблему. Ими стали фирмы-разработчики трёх основных «нормальных» браузеров: Mozilla Foundation, Opera Software и Apple, которые организовали рабочую группу WHATWG, предназначенную для развития web-технологий, как технологий создания web-приложений.

И вот, 7 марта произошло, историческое событие: WHATWG официально вошла в состав W3C. В настоящий момент ведётся работа над спецификацией HTML5 (или Web Applications 1.0) [10], которая:

Так что HTML5 — это не ещё одна ненужная версия HTML, а жизненно необходимое направление развития web-технологий.

Заключение

Таким образом, xHTML/CSS/JS выживут, если:

Примечания

  1. ↑ Обычно программы компилируются не в ассемблерный код, а сразу в машинный. Но, для удобства, в пределах этой статьи будем считать, что это одно и то же.

  2. ↑ В системном программировании ассемблер, разумеется, используется. Однако, оно не является определяющим в IT-индустрии.

  3. ↑ Микрософт косвенно признала, что модель серверных контролов далека от совершенства и собирается выпустить ASP.NET MVC Framework.

    ASP.NET MVC — это огромный шаг вперёд: она даёт почти полный контроль над HTML и в ней нет этих ужасных серверных контролов, __VIEWSTATE и Page Livecicle.

    Но, знаете, я очень не уверен, что все ASP.NET разработчики перейдут на MVC. Ведь модель ASP.NET контролов является настолько родной, привычной и понятной для тех, кто привык к Visual Basic / Delphi парадигме: кинул контрол на форму → щёлкнул два раза мышкой → написал обработчик и все дела…

  4. ↑ Речь идёт не о компиляции в узком смысле (генерации машинного кода на основе исходника), а о «компиляции» в широком смысле (генерация низкоуровневого HTML-кода на основе высокоуровневого ASP.NET-контрола)

  5. ↑ Конечно, ASP.NET не ограничивается одними серверными контролами. ASP.NET — очень могучая, производительная, надёжная технология, использующая всю мощь .NET Framework. Однако, многие разработчики используют ASP.NET именно из-за серверных контролов.

  6. ↑ Насчёт «Delphi for PHP», я, похоже, ошибся. Прошёл уже почти год, а о «Delphi for PHP» мало что слышно.

  7. ↑ А вот насчёт Silverlight, я оказался прав. Он получает всё большее и большее распространение.

  8. ↑ Надо признать, Микрософт очень старается. От версии к версии, генерируемый ASP.NET’ом xHTML код становится всё менее уродливым, более валидным и семантичным.

  9. ↑ Предложенная W3C технология xForms не обладает обратной совместимостью и практически не поддерживается браузерами. Даже Mozilla Firefox, в котором реализованы почти все современные стандарты, поддерживает xForms только с помощью специального плагина.

  10. ↑ Помимо технологии создания web-приложений, стандарт (x)HTML5 призван:

    • обеспечить обратную совместимость с HTML4/xHTML1;

    • определить единый для всех браузеров механизм обработки ошибок;

    • и не забыть о первоначальном предназначении языка HTML — средства представления информации. В HTML5 вводятся новые элементы для более семантической разметки документа: <section>, <article>, <header>, <footer> и др.

При подготовке статьи были использованы изображения с сайта www.wikimedia.org, а также: www.codegear.com, www.microsoft.com, www.w3c.org, www.json.org, www.whatwg.org, www.gmail.com, www.dotnetheaven.com, idesisnery.blogspot.com

43 комментария:

  1. Jifeon
    08.07.2008, 00:55

    Молимся и ждем HTML5, потому что Вы чертовски правы. Особенно по поводу ASP.NET Конечно не все, но большинство тех самых обычных разработчиков, которые пишут на аспдотнет, не представляют даже примерно, как всё работает изнутри, и как криво выглядит конечный результат с точки зрения более "низкоуровневых" технологий.

    На счет 3D и флеш: во флэше уже сделали 3д апи, но надеюсь опера и фаерфокс подоспеют вскоре с нативно всроенным 3д ускорением, использующим openGL, и будут всем красивющие сайты с настоящей 3d графикой.

  2. jek
    21.10.2008, 15:59

    Отличная статья. Маленькое историческое уточнение по Turbo Pascal: режим текста 80*25, а не 80*24. Можно было также работать в режиме 80*50.

  3. Алик Кириллович
    22.10.2008, 01:32
    Маленькое историческое уточнение по Turbo Pascal: режим текста 80*25, а не 80*24

    jek — спасибо за уточнение! Исправил.

  4. dP
    10.11.2008, 11:00

    Ага 80х50, а еще можно было переопределить таблицу символов... Лично рисовал в текстмоде округлые окошки)

  5. DOKA
    19.11.2008, 15:36

    То, что С компилиться в "уродский ассемблер" (на самом деле машинные коды) - вовсе не зло. Никого не интересуют особенности реализации на уровне процессора, на уровне исходного кода выглядит это красиво. Оставаться на асме - это не вариант.

    А что до того, что HTML&JS могут умереть - это да, и туда ему и дорога. Как бы там что не было красиво, но на каждом броузере под каждый чих приходится тут и там ставить хаки, чтобы это просто работало одинаково на всех броузерах или просто работало.

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

  6. Алик Кириллович
    19.11.2008, 16:43

    @ DOKA

    То, что С компилиться в уродский ассемблер - вовсе не зло. Никого не интересуют особенности реализации на уровне процессора, на уровне исходного кода выглядит это красиво. Оставаться на асме - это не вариант.

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

    Другое дело, xHTML/CSS/JS. Они лишь воспринимаются многими разработчиками как низкоуровневые. При правильном высокоуровневом их восприятии разработчиками, нужда в «псевдовысокоуровневых» ASP.NET серверных контролах пропадает.

     

    А что до того, что HTML&JS могут умереть - это да, и туда ему и дорога. Как бы там что не было красиво, но на каждом броузере под каждый чих приходится тут и там ставить хаки, чтобы это просто работало одинаково на всех броузерах или просто работало.

    <...>

    Так что веб-программирование ещё некоторое время будет оставаться адом.

    Хаки, главным образом, приходится использовать ради совместимости с IE6.

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

    Я надеюсь, что с распространением IE8, web-программирование перестанет «быть адом».

  7. Дмитрий Анатольевич
    19.11.2008, 18:02

    А может предложите на перфокартах работать? =))

    Я вообще не веб-разработчик, а десктопный, но я хоть убей не могу понять, вы что же хотите сказать, было бы лучше, если бы сейчас все до сих пор писали на ассемблере? Далеко бы мы уехали тогда, без процедурного, и уж тем более ООП. Это же даже не смешно... То же самое и с веб-технологиям. Станут они новым IL для веба, и слава богу, туда им и дорога. Это не гибель, как вы говорите, а переход на новый уровень. И никто от их ухода плакать не будет. А сильверлайт - как раз и может легко стать тем самым, что наконец сделает настоящие полноценные веб-приложения, а не полудохлые редакторы гугла, настоящей реальностью. (Это еще кстати к теме о том, что МС проводят диверсию против веба)

    Кстати WPF - это нереально круто, я вам серьезно говорю. Такой гибкости в создании интерфейсов себе представить даже сложно. Одна беда, пока совсем мало людей себе представляют, как это использовать по-настоящему.

    Ну да, ну да, я дотнетчик, поэтому конечно же из стана врага, то да се, все понимаю...

  8. Дмитрий Анатольевич
    19.11.2008, 18:05

    а вообще, судя по этой статье и про ИЕ6, вы обычный микрософтоненавистник... по опыту знаю, это не лечится никак...

  9. Алик Кириллович
    19.11.2008, 19:12

    @ Дмитрий Анатольевич

     

    А может предложите на перфокартах работать? =))

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

    Еще раз повторю: я не считаю, что было бы лучше, если мы до сих пор писали на ассемблере.

    Ассемблер объективно был низкоуровневым языком и должен был исчезнуть (в прикладной области), уступив место высокоуровневым языкам.

     

    То же самое и с веб-технологиям. Станут они новым IL для веба, и слава богу, туда им и дорога. Это не гибель, как вы говорите, а переход на новый уровень.

    Языки web-програмирования являются низкоуровневыми лишь в сознании некоторых разработчиков.

    При правильном восприятии, xHTML/CSS/JS являются прекрасными высокоуровневыми технологиями создания web-интерфейса. В некоторых случаях, они являются даже более высокоуровневыми: см. пример, где мы можем на лету превратить список в дерево, дерево в контекстное меню, а в режиме печати снова представит его в виде списка и скопировать в виде списка в Word, просто подменив CSS и JS-класс!

    Поэтому, использование псевдовысокоуровневых надстроек, вроде серверных контолов ASP.NET — это не переход на новый уровень, а попытка заменить мощную, но непонятную парадигму Web на понятную десктопную Windows-парадигму.

     

    Кстати WPF - это нереально круто, я вам серьезно говорю.

    Да, WPF — лучшее средство для создания десктопных интерфейсов, пожалуй из всего, что было создано на сегодняшний день. Но не web-интерфейсов.

     

    а вообще, судя по этой статье и про ИЕ6, вы обычный микрософтоненавистник...

    Вообще-то, свою заметку про IE6 я начал с фразы: «Сразу скажу: я очень уважительно отношусь к компании Микрософт и ее продуктам. Времена Windows Me давно прошли, и теперь Windows Server 2003 действительно является одной из надежных серверных ОС; MS SQL Server — одним из мощнейших коммерческих СУБД, а C# — одним из лучших нединамических языков программирования».

    Я считаю, что Микрософт создала лучшую на сегодняшний день технологию для десктопов. Но я не считаю правильной попытку применить к Web десктопную парадигму.

  10. Mike Borozdin
    19.11.2008, 19:53

    >Так появилась ASP.NET.

    Как так? "Имея зуб на web-технологии", MS выпустили ASP.NET? А про классический ASP автор слышал?

    >В ASP.NET работа идет с высокоуровневым Windows API

    С чем-чем простите? С Windows API :D?

    Темы ASP.NET все-равно используют CSS. Любому контролу можно присвоить стиль, более того, HTML представление любого контрола можно переопределить.

    А еще есть ASP.NET MVC Framework, который дает полный контроль над HTML.

    Script# призван избавить разработчиков от головной боли от непривычности ОО синтаксиса JS. Google между прочим выпустили такую же штуку. Вы о ней почему-то не упомянаете.

  11. Алик Кириллович
    19.11.2008, 20:59

    @Mike Borozdin

     

    А про классический ASP автор слышал?

    Вы не поверите, но движок этого сайта я написал именно на классическом ASP! Можете проверить по ответам сервера :-)

    Да, я 5 лет работал с классическим ASP. Правда, в качестве языка я использовал не этот ужасный VBScript, а JScript и применял возможности, не доступные в VBScript, PHP, JSP и др.: прототипное ООП, функциональное программирование, замыкания и др.

     

    Script# призван избавить разработчиков от головной боли от непривычности ОО синтаксиса JS.

    Ключевое слово здесь — «непривычность».

    Клиентская концепция ASP.NET (серверные контролы, Script#) не является лучшей по сравнению с классическими xHTML/CSS/JS. Она просто является привычной десктопным разработчикам Delphi/Visual Basic.

     

    Google между прочим выпустили такую же штуку.

    Вы, видимо, имели в виду Google Web Toolkit.

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

    Но сам Google в своих проектах использует xHTML/CSS/JS. Иначе он не смог бы сделать прорывные в свое время GMail, GMaps и др.

     

    А еще есть ASP.NET MVC Framework, который дает полный контроль над HTML.

    Но на момент написания тезисов статьи (а они были приурочены к началу работы над HTML5, см. аннотацию), ее еще не было.

    Да, ASP.NET MVC Framework — это большой шаг вперед!

    Но, знаете, я очень не уверен, что все ASP.NET разработчики перейдут на MVC. Ведь модель ASP.NET контролов настолько является настолько родной, привычной и понятной для тех, кто привык к Visual Basic / Delphi парадигме: кинул контрол на форму → щелкнул два раза мышкой → написал обработчик и все дела…

  12. UX
    23.11.2008, 03:00
    во-первых, является развитием HTML4/xHTML1.1 и включает многие теги, столь необходимые для web-приложений: <canvas> — тег для рисования графики, <video> — для видеоконтента, высокоуровневые элементы формы и т.д.
    - неверно, так как задание HTML - это логическое представление данных, а не рисование картинок на канвасе…
  13. Алик Кириллович
    23.11.2008, 04:06

    @UX

    задание HTML - это логическое представление данных, а не рисование картинок на канвасе...

    Не совсем понял Ваше замечание.

    Картинки на canvas-е: графики, схемы, изображения — являются неотъемлемой частью логического представления данных.

  14. McWild
    26.11.2008, 19:48

    Насчет 3D графики всё не совсем так.

    -3D HTML JS

    http://www.uselesspickles.com/triangles/demo.html

    http://nihilogic.dk/labs/wolf/

    -VRML

    http://ru.wikipedia.org/wiki/VRML

  15. antalika
    28.11.2008, 02:21

    Да а накой хрен возиться с этими JS/css/html?

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

    вре развивается - это понятно, а чего стоять на месте и писпать на асме?

    слава Богу - не писал ниразу.

    имхо- меньше рутины и возни будет в вебе.

    вот только интересно: насколько производительны эти решения?

    не тормозит ли нагенеренный код потом?

    в Java вроде тоже есть Facelets - тоже контролы и т.п..

  16. Евгений
    01.12.2008, 03:08

    HTTP/HTML/CSS/JS не вымрут до тех, пока их не вытеснит принципально новое поколение технологий(такие как, например, голографические дисплеи, семантический веб, естественно-языковые интерфейсы и т.п.)

  17. Алик Кириллович
    01.12.2008, 04:15

    @ Евгений

    HTTP/HTML/CSS/JS не вымрут до тех, пока их не вытеснит принципально новое поколение технологий(такие как, например, голографические дисплеи, семантический веб, естественно-языковые интерфейсы и т.п.)

     

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

    Только примеры этих технологий Вы подобрали не совсем удачно:

    • «Голографические дисплеи» и «естественно-языковые интерфейсы» — прекрасные альтернативные средства представления информации. Для них надо только создать таблицу стилей, как это уже было сделано для «синтезатора речи», «шрифта брайля», «интерактивного телевидения» и т.д.
     
    • «Семантический веб» — средство представления информации в виде, понятном для компьютера. И он никак не помешает технологиям представления информации для человека. Кстати, элементы семантического веба можно использовать прямо в xHTML посредством RDFa.
  18. Pash
    17.12.2008, 17:48

    ИМХМО HTML/CSS/JS не вымрут пока поисковики не смогут корректно индексировать инфу в "богатых приложения" (аля Flesh/Flex/Silverlight и т.д.).

  19. Snowcore
    17.12.2008, 19:06

    Native веб технологии (HTML/CSS/JS) будут вечно жить! Какой тут разговор о вымирании!

  20. Владимир
    02.01.2009, 16:10

    >> Prototype.js был написан теми, кто не знает JavaScript, для тех, кто не знает JavaScript

    Может быть... спорить не буду. Мне в любом случае больше jQuery нравиться :)

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

  21. Алик Кириллович
    06.01.2009, 03:32

    @Владимир

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

    Так никто и не выступает против всех JavaScript-библиотек.

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

    Не все со мной согласны, но я считаю — Ричард Корнфорд прав: «Prototype.js был написан теми, кто не знает JavaScript, для тех, кто не знает JavaScript».

    А jQuery, с моей точки зрения — как раз пример отличной библиотеки, которая развивает возможности JavaScript, не искажая его сути.

  22. niceman
    14.01.2009, 16:49

    Все в нашей жизни периодично!

  23. Павел
    22.01.2009, 14:47

    Даже, если прийдут новые технологии на смену старым, но в основе то останутся предыдущие наработки!

  24. MX
    22.02.2009, 05:35
    Однако, перепрыгнуть ограничения таблицы из 80*24 символов было невозможно. Как ни старайся, нельзя нарисовать объект тоньше одного символа или провести диагональную, а тем более изогнутую линию.

    Вообще-то, это не совсем так: поднимите последнюю версию Norton Utilites for DOS и посмотрите, какой там был интерфейс ;-)

  25. Роман
    16.05.2009, 10:50

    Спасибо за статью!

    Алик я с вами согласен, сам писал проект на ASP.NET 1,5 года, скорость создания форм велико плюс всё родное с WinForms, но потом когда приходилось оптимизировать размер страниц, пришлось познакомится с разметкой, и потом был только ужас...

    PS Теперь у меня к ASP.NET никаких положительных эмоций, сижу углубленно изучаю HTML, CSS, jQuery(тут мне проше, javascript в планах) и смотрю в сторону ASP.NET MVC ну и конечно же Silverlight.

  26. Alex Savochkin
    16.05.2009, 23:11

    Прочитал комментарии и задумался вот о чём. Не знаю, много ли смысла спорить о том, что хорошо или плохо. Мне кажется более правильным подход, в котором выбор происходит между "уместно" и "неуместно". Меня как юзабилиста в своё время просто бесила необходимость использовать багтрекер на основе MS SharePoint, который, по-моему, вообще ни для чего полезного не пригоден. Я до сих пор не понимаю, почему веб-оболочка какой-то бизнес-логики должна быть заточенной сугубо под IE, а под FF отказывалась работать полноценно. С одной стороны, можно обвинять Microsoft в том, что они-де нехорошие человеки, придумали такую заточенную среду под такой заточенный браузер. Можно обвинять дядю Костю за то, что он продавил тему использовать корпоративный портал на SharePoint, который по мне (с точки зрения юзабилиста) не более чем костыль для всего, что на нём хотят сделать. Это утверждение не случайно, я могу объяснить несколько моментов, по которым мне SharePoint не нравится.

    Однако интересен тот факт, что использовать SharePoint в данных конкретных условиях было (кстати, вполне объективно) признано уместным, и его использовали. Я полагаю, что этот же принцип применим и во многих других случаях, и не только в программировании. Можно бесконечно долго утверждать, что Flash - это зло, SharePoint - это костыль, и так далее, но использовать (и покупать) всё равно будут даже очень нехорошие технологии. Весь вопрос в том, как и для чего эти технологии выбираются.

  27. Алик Кириллович
    17.05.2009, 19:35

    @MX

    На сколько я помню, последние версии Norton Utilities for DOS работали в графическом режиме.

    В текстовом псевдографическом режиме с матрицей из 80×25 символов подобной красоты с тонкими изогнутыми линиями добиться было невозможно.

  28. Алик Кириллович
    17.05.2009, 19:57

    @Роман

    Рад, что Вы почувствовали красоту и преимущества классических web-технологий: xHTML/CSS/JS.

    Если Вы работали с ASP.NET, то, я согласен, ASP.NET MVC — для Вас действительно лучший выбор.

    При этом Вы сохраняете весь опыт работы с такой мощной платформой как .NET, но избавляетесь от уродливых серверных контролов и получаете полный контроль над xHTML/CSS/JS-кодом.

    Поддерживаю также Ваш выбор jQuery. Это — одна из лучших JS-библиотек, которая гармонично сочетается с его прототипный парадигмой и не навязывает совершенно не свойственный JavaScript-у классовый подход (например, как Microsoft Ajax Library). К тому же, jQuery хорошо интегрирована с ASP.NET MVC.

    Правда, все таки посоветую сначала изучить JS, а уже потом — jQuery. Дело в том, что изучив JS, понять jQuery совсем не сложно. А вот если сначала изучить jQuery, то с пониманием JS могут быть проблемы. Но это только мой совет.

  29. Alex
    19.05.2009, 15:38

    > Дмитрий Анатольевич +1

    >Да, к сожалению, Google вынужден конкурировать с производителями инструментов, предназначенных для разработчиков, не желающих понять JavaScript.

    Я тоже со стороны MS и честно говоря очередной раз поражаюсь высказываниям "MS (IE) - зло", в Google "вынужден" что-то разрабатывать. Это действительно не лечиться :(

    >Микрософт косвенно признала, что модель серверных контролов далека от совершенства и собирается выпустить ASP.NET MVC Framework.

    При этом в сноске не написано, что MVC - это гораздо сложнее чем WebForms и абсолютно "не уместно" для небольших проектов.

    А в целом, не хочу я знать, как там модальное окно реализовано, не хочу очищать ручками память, и тем более не хочу разбираться в javascript (хотя более менее его знаю). Хочу свое время тратить на то, что я ХОЧУ сделать, а не на то, КАК это сделать.

  30. Алик Кириллович
    20.05.2009, 20:00

    @Alex

     

    очередной раз поражаюсь высказываниям "MS (IE) - зло"

    Ну кто здесь говорит, что Микрософт — зло?! Все зависит от ее продуктов:

    • C# — действительно самый лучший «классический» (нединамический) язык программирования;
    • .NET — одна из мощнейших платформ;
    • MS SQL Server — одна из лучших коммерческих СУБД; его превосходит, разве что, Oracle;
    • Internet Information Server — хороший web-сервер;
    • ASP.NET MVC Framework — хорошая, мощная и красивая платформа для web-приложений;
    • IE 8 — не такой уж и плохой браузер;

    Однако:

    • IE 6 (последние 5 лет) — несомненно зло: не поддерживает огромное количество web-стандартов, неправильно поддерживает половину от оставшихся, глючный и дырявый.
    • ASP.NET WebForms — уродливы.

     

    При этом в сноске не написано, что MVC - это гораздо сложнее чем WebForms
    и тем более не хочу разбираться в javascript

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

    Модель MVC, JavaScript, или xHTML/CSS не являются более сложными. Просто они непривычны для десктопных/WinForms/Delphi/VB/... - разработчиков.

    Если Вы выучите и полюбите JavaScript (причем не просто изучите синтаксис, но и прочувствуете его прототипно ориентированную, функциональную и динамическую парадигму), возможно, Вы измените свое мнение.

  31. Руслан
    09.06.2009, 11:31

    Microsoft со своими некоторыми продуктами, любит сильно упрощать жизнь своих пользователей. Я некогда не забуду как увидел первый и последний :) сгенерированный html при экспорте из word в html. Считаю конечно что в совершенстве все надо писать и делать ручками и головой.

  32. Фархад
    20.06.2009, 09:05

    Очень мощная статья! Ваши рассуждения о прелестях js, который я считаю сложным и запутанным для себя, честно меня вдохновили:) Буду разбираться, спасибо!

  33. Олег
    24.07.2009, 18:41

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

  34. kep
    22.08.2009, 17:25

    Без сомнения для тривиальных задачь подходит все что является надстройкой над "html/js/css"...

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

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

    Самое интересное рождается в глубине!

    И надо как следует в этом разбираться, чтобы двигаться вперед!

    "html/js/css" - руль, и безграничные возможности!

  35. iceek
    04.09.2009, 14:19

    Мои первые шаги в сайтосторении начинались с html. html - это руль!!!

  36. Константин
    14.12.2009, 04:57

    "HTML - язык разметки документов".

    Не "верстки", не "GUI", не "программирования".

    Он никуда не денется.

    Так же, как и CSS. Web-Fonts Module уже принесет новое лицо вебу, где кроме Ариала появятся сотни других, красивых шрифтов. Flex-Box, потенциально может решить проблему резиновых лейаутов.

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

    п.с.: а с появлением для веб-верстки тулзов уровня современного Adobe InDesign или хотя бы даже QuarkXPress 90х годов в полиграфии, думаю начнется не закат Веба, а наоборот, очередной его подъем.

  37. Михеев
    26.03.2010, 15:05

    Почему закат? - просто видоизменение!

  38. Vitaliy
    27.03.2010, 15:00

    Скорее диалектическое развитие. Отмирающие старое, это почва для нового. Но это всё философия.

    xHTML вытесняется, т.к интернет перестаёт быть "страничками", к нему прилипают видео, фото, аудио.

    Даже CMS системы управления контентом играют против xHTML, тот же движок WP, отбросил надобность изучать языки блогерам, достаточно знать знакомый интерфейс.

  39. Курдль
    31.03.2010, 17:34

    Много лет назад, когда я был начинающим программистом и писал драйверы, резиденты (крутое слово!) и программы с расширением .com, меня до глубины души задел один фантастический рассказ про программистов. Там была фраза, что программа, написанная гением, может быть вся в заплатках, безобразно скомпонована, создана с нарушением всех мыслимых стандартов и правил. Но, в отличие от программы "середнячка", делает она ровно то, что от нее просят, к тому же быстро, качественно и не ломается. А я-то, дурень, вылизывал свои asm коды, любовался ими, экономил микросекунды...

    Так к чему это я? К тому, что не все мы гении!

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

    Но ни одним словом не обмолвился о ПРОИЗВОДСТВЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ!

    Я понимаю, что мы - программисты - люди творческие. Но на производстве существуют требования, сроки и точность их выполнения а также трудозатраты. Если я могу одного и того же специалиста легко переучить с форм на WEB (напр. ASP.NET) или купить такого готового многостаночника на рынке труда, то это значит, что я в СРОК и без дополнительных РАСХОДОВ выполню ТРЕБОВАНИЯ заказчика. В результате заказчик увидит на своем экране ровно то, что просил и нам с ним не будет никакой разницы, какой безобразный HTML получил браузер и насколько при этом попрана парадигма JS.

    Алик Кириллович, не пробовали взглянуть на проблему с этого ракурса?

  40. Alexandr
    25.04.2010, 21:27

    Добрий день!

    Я шукаю відповідь з приводу майбутнього до якого слід прагнути.

    Я вважаю, що краса у простоті й довершеності.

    Я переконаний, що лише прагнення досконалості робить людину ближчою до бога.

    Дякую Алик за висловлення бачення краси!

  41. IT
    01.07.2010, 03:29

    Ну а разве HTML не планируют усовершенствовать?

    Например пару лет назад вообще никто не думал страницы без перезагрузки менять, а тут на тебе... Дикая истерия по jQuery...

  42. CSRedRat
    10.07.2010, 12:12

    Всё хочу посмотреть на гугл вейв - вот это действительно интересно

  43. zusicks438
    08.08.2010, 12:44

    Глобальная статья...Действительно, поигравшись с ASP.NET понял, что для крупных веб-приложений, не требующих суперкода, это гораздо более интересное решение...

Добавить комментарий

Имя:
E-mail (не публикется):
Веб-сайт (ссылки не «глушатся» nofollow):
Текст:
Вы можете использовать BBCode:
[b]жирность[/b]
[i]курсив[/i]
[u]подчеркивание[/u]
[s]перечеркивание[/s]
[url]http://www.example.com[/url]
[url=http://www.example.com]Текст ссылки[/url]
[quote]Цитата[/quote]
[code]
код на
  языке
программирования
[/code]
[list]
* Список
* Список
* Список
[/list]

Статьи

About

Подписка

Ждите...

Valid XHTML 1.0 Strict © Алик Кириллович, 2008—2010