Консольная библиотека для построения интерфейсов, которая использовалась в продуктах Borland, называлась Turbo Vision.
Да. Я упомянул «Turbo Vision» в тегах к статье.
Очень неплохая ООП библиотека
«Turbo Vision» — не просто неплохая библиотека, «Turbo Vision» была гениальной!
Все, что было в распоряжении «Turbo Vision» — это текстовая матрица из 80 * 25 символов ASCII, их цвет и фон. Все!
Из этих текстовых символов она сделала невозможное: реализовала многооконный интерфейс, с главным и контекстным меню, псевдо-трехмерными нажимающимися кнопками, технологией перетаскивания окон… В общем, почти все, что сейчас есть в современной графической Windows'овской программе.
Однако, несмотря на свою гениальность; она выжала из текстовой матрицы ВСЕ, и преодолеть фундаментальные ограничения текстового интерфейса была не в состоянии. Как ни старайся, нельзя нарисовать объект тоньше одного символа или провести диагональную, а тем более изогнутую линию.
Поэтому, «Turbo Vision» ушла в историю, уступив место графическим библиотекам Windows.
Тоже самое может ожидать и xHTML. Несмотря на невероятную изобретательность ряда web-разработчиков, сумевших выжать из xHTML невозможное; в xHTML сейчас есть фундаментальные ограничения, которые не позволяют реализовывать некоторые интерфейсные возможности. И, если xHTML перестанет развиваться как технология создания web-приложений, то она может исчезнуть, уступив место Flex или Silverlight, подобно тому, как «Turbo Vision» ууступила место графическим библиотекам Windows («гибель физическая»).
Однако, я уверен, под руководством WHATWG, развитие xHTML/CSS/JS как технологий создания web-приложений будет продолжено, ит HTML5 — хороший тому пример.
HTML уже превратился в ассемблер.
А вот с этим я совсем не согласен.
Действительно, для разработчиков ASP.NET, GWT, JSF — xHTML действительно, во многом, стал ассемблером. Но, есть также и большое число разработчиков, использующих xHTML/CSS/JS на высоком уровне.
И не только для создания сайтов (язык разметки), но и для создания web-приложений (язык построения богатых интерфейсов). В xHTML/CSS/JS (особенно с учетом их развития) есть для этого все возможности. И надо только правильно понять и воспользоваться ими…
От физической гибели технологий xHTML/CSS/JS уже давно спасают поисковики
Да, действительно, неумение поисковиков индексировать Flash, PDF и т.д. сыграло xHTML на пользу.
Но, все же, хотелось, что бы разработчики использовали xHTML/CSS/JS не вынужденно, «из под палки» поисковика, а добровольно — осознав его возможности для построения богатых web-интерфейсов.
Еще один момент против использования большинства новх технологий — скорость.
А вот здесь я не совсем согласен…
Уменьшение производительности и скорости работы при переходе на новый уровень абстракции — неизбежность. Но, которая, благодаря увеличению мощности железа, в большинстве случаев (за исключением маломощного железа, вроде микроволновок, для которых до сих пор пишут на ассемблере), не мешает переходу на новый уровень.
И, поэтому, xHTML/CSS/JS останутся на плаву не потому, что они низкоуровневы (и соответственно, быстрее работают), а потому что они — очень мощные и гибкие технологии создания web-интерфейсов.
Я не думаю, что xHTML может не угнаться за ходом технологий. Это ведь частный случай XML, а значит в любой момент можно добавить элементы разметки для медиа-контента, розширить инструментарий для структурирования данных и т.д.
Конечно, xHTML — это подмножество XML и чисто теоретически ничего не стоит добавить в него новый элемент (для контрола, медиаконтента и т.д.)
Но:
— Кто придумает этот элемент?
— Кто заставит производителей браузеров (особенно самого распространенного) поддерживать этот элемент?
Я полностью с Вами согласен. Усиление уровня абстракции — фундаментальный процесс.
Да, он сопровождается потерей производительности. Но зато он увеличивает скорость и качество разработки; увеличение мощности железа нивелирует потери в производительности.
Да, сгенерированный низкоуровневый код часто выглядит уродливо, что приводит в ужас разработчиков с предыдущего уровня абстракции. Но более высокоуровневые программисты пишут код на высокоуровневом языке и именно на нем вылизывают его, делают более красивым и лаконичным. Поэтому, несмотря, на уродство низкоуровневого кода, код на высокоуровневом языке выглядит красиво… до тех пор, пока не появится новый уровень абстракции…
Поэтому, процесс усиления абстракции необратим.
НО! В этой статье я хотел показать следующее:
Ассемблер объективно был низкоуровневым языком, поэтому его замена языками высокого уровня была правильной и неизбежной.
Однако, xHTML/CSS/JS на самом деле являются высокоуровневыми языками построения интерфейсов; и лишь воспринимаются разработчиками как низкоуровневые.
Поэтому, их замена «псевдовысокоуровневыми» серверными контролами не является обязательной, и ее можно (и нужно) избежать.
Пожалуйста, не пишите, что разработчики выбирают ASP.NET из-за " «псевдовысокоуровневые» серверные ASP.Net-контролы."
См. 3-ю сноску.
Я не утверждаю, что все разработчики используют ASP.NET только из-за серверных контролов.
Но, я говорю, что есть разработчики, которые не хотят осваивать web-парадигму, и, поэтому, выбирают привычную им с со времен Delphi и Visual Basic модель серверных контролов…
Традиционное ASP.NET меня сильно раздражает — впечатление такое, что старались переманить разработчиков GUI-приложений, делая вид, что веб ничем не отличается.
Полностью согласен.
Сама по себе ASP.NET и .Net вообще — очень мощная технология.
Но попытка применить к web десктопную windows-овскую GUI парадигму с помощью ASP.NET контролов — это выглядит ужасно!
Поэтому, ASP.NET MVC Framework — это большой шаг вперед!
Но, знаете, я очень не уверен, что все ASP.NET разработчики перейдут на MVC. Ведь модель ASP.NET контролов настолько является настолько родной, привычной и понятной для тех, кто привык к Visual Basic / Delphi парадигме: кинул контрол на форму → щелкнул два раза мышкой → написал обработчик и все дела…
Автор прав в том, что HTML/CSS/JS — это устаревшая технология. Не фактически, но морально.
Я рад, что Вы со мной согласились, но я имел в виду как-раз противоположенное :-)
Я считаю, что HTML/CSS/JS — не являются устаревшей технологией! И они лишь воспринимаются многими разработчиками как устаревшие, из-за недооценки заложенных в них гибкости и мощи.
Другое дело, что эти технологии, перестав развиваться как технологии развития web-приложений, действительно могут устареть, и уйти со сцены, уступив место Flex или Silverlight. Подобно тому, как интерфейсы на основе Turbo Vision уступили место windows'овским интерфейсам («гибель физическая»).
Но, именно для того, чтобы, чтобы HTML/CSS/JS не прекращали развиваться, как технологии создания web-приложений, и была создана WHATWG. И HTML5 — один из шагов такого развития.
Будущее всё-таки за виртуальными машинами — будь то .NET или JVM или аналогичное решение от Adobe
Полностью согласен. Но, пусть этой виртуальной машиной будет браузер!
И это я уже не говорю об антимайкрософтовской идеологии
В статье нет никакой «антимайкрософтовской идеологии».
Я считаю классические xHTML/CSS/JS замечательными и удивительно гибкими технологиями построения интерфейса; и выступаю против отказа от их использования не только в сторону микрософтовских ASP.NET-контролов и Silverlight, но и Flex от Adobe и JSF от SUN.
К самой же Микрософт и, даже, «чистой» ASP.NET (без учета контролов), я отношусь с большим уважением.
См. 3-ю сноску:
Конечно, ASP.NET не ограничивается одними серверными контролами. ASP.NET — очень могучая, производительная, надежная технология, использующая всю мощь .NET Framework. Однако, многие разработчики используют ASP.NET именно из-за серверных контролов.
Имитация стека и вызов функций относятся не к епархии ассемблера, а к архитектуре. В процессорах Intel, начиная с 8086, стек присутствовал, и были соответствующие инструкции для работы с ним.
Стек присутствует не во всех процессорах. В старых процессорах Intel и Motorolla стека не было. Однако, потом для этих процессоров были созданы ассемюлеры, в которых стек эмулировался, позволяя программисту писать код так, как будто в процессоре стек есть. Поправьте меня, где я не прав.
Насчет вызова функций я точно не уверен. Но, по-моему, команды CAL и RET были чисто ассемблерными командами, и не для всех процессоров имели аналог в машинных кодах.
Но, на всякий случай, пока заменил другой «фишкой» продвинутого ассемблера — использованием макросов. «Фишкой», которая стала не нужной высокоуровневым разработчикам. Также, как станут не нужными многие «фишки», облегчающие разработку front-end разработчикам, если xHTML/CSS/JS-код будет генерироваться автоматически…
отличный оптимизированный код, который в большинстве случаев будет лучше того, что напишет средней руки программист.
Когда я смотрю на HTML/CSS/JS-код сгенерированный ASP.Net (особенно ранних версий), мне становится страшно :-) Чего только __VIEWSTATE стоит!
Но, надо отдать Микрософту должное: от версии к версии, генерируемый ASP.NET-контролами xHTML код становится все менее уродливым. В последней версии код уже является полностью валидным, и довольно семантичным. Я написал об этом в 6-й сноске.
тем более нет никакой «компиляции в HTML, CSS и JavaScript»
Генерация низкоуровневого кода (HTML/CSS/JS) на основе высокоуровневого (ASP.NET) — это и есть «компиляция» (или «трансляция», если быть пуристом). Разве не так?
про mvc framework в котором вообще нет серверных контролов вы видимо не знаете вовсе
Конечно, я знаю про ASP.NET MVC Framework :-) Но на момент написания тезисов статьи (а они были приурочены к началу работы над HTML5, см. аннотацию), ее еще не было. Но, опять же, ASP.NET MVC говорит о том, что модель ASP.NET контролов не идеальна…
какой Windows API?
Речь идет не о Win16/Win32/Win64 API. Речь идет о том, что web-разработчики ASP.NET используют тот же самый API (базовые классы .Net Framework), что и Windows-разработчики .Net. Но, согласен, сформулировано некорректно. Убрал, пока не переформулирую.
Поскольку Ruby поддерживает класс-ориентированное ООП (хотя, как и в Python (см. комментарийdsCode ), близкое к прототипному ОПП JavaScript'а), использование Prototype.js как часть Ruby on Rails гармонично и красиво.
Но, использование класс-ориентированного ОПП в самом JavaScript'е является, как я считаю большим «надругательством» над прототипной идеалогией JavaScript.
Что, конечно, не отменяет достоинств Prototype.js, как одной из первой библиотеки для упрощения работы с DOM.
> Я просто не согласен с той фразой, что переход на новый уровень происходит совсем без увеличения накладных расходов.
а кто это говорил? я не видел; в любом случае — это глупость ...
Я спорю с superhabra, который утверждает, что программы на высокоуровневых языках всегда более эффективны, чем низкоуровневые ассемблерные:
>[программа на высокоуровневом языке компилируется] в неэффективный ассемблерный [или машинный] код.
Похоже о ассемблере вы знаете только название
Я же утвержаю, что в большинстве случаев (хоть и не всегда), программа, написанная на высокоуровневом языке менее эффективна, чем низкоуровневая; т.к. накладные расходы перехода на новый уровень абстракции снижают эффективность.
Если бы это всегда было не так, то никто бы не писал ассемблерные программы для маломощных устройств.
Но, то что во многих случаях программы для устройств с малой производительностью пишут именно на ассемблере, а не на высокоуровневых языках, говорит о том, что накладные расходы при переходе на новый уровень абстракции приводят к уменьшению эффективности (несущественного для современных компьютеров, но критичного для маломощных устройств).
Почему? Действительно, если клиентские языки разработки (xHTML/CSS/JS) перестанут развиваться, то их могут ждать две трагические судьбы:
Ментальная гибель: останутся физически, но исчезнут из сознания разработчиков, накрывшись высокоуровневыми абстракциями, став низкоуровневыми языками — новым ассемблером;
Физическая гибель: исчезнут полностью, уступив место Silverlight или Flex.
Так что «Закат Веба» действительно может наступить…
«Turbo Vision» — не просто неплохая библиотека, «Turbo Vision» была гениальной!
Все, что было в распоряжении «Turbo Vision» — это текстовая матрица из 80 * 25 символов ASCII, их цвет и фон. Все!
Из этих текстовых символов она сделала невозможное: реализовала многооконный интерфейс, с главным и контекстным меню, псевдо-трехмерными нажимающимися кнопками, технологией перетаскивания окон… В общем, почти все, что сейчас есть в современной графической Windows'овской программе.
Однако, несмотря на свою гениальность; она выжала из текстовой матрицы ВСЕ, и преодолеть фундаментальные ограничения текстового интерфейса была не в состоянии. Как ни старайся, нельзя нарисовать объект тоньше одного символа или провести диагональную, а тем более изогнутую линию.
Поэтому, «Turbo Vision» ушла в историю, уступив место графическим библиотекам Windows.
Тоже самое может ожидать и xHTML. Несмотря на невероятную изобретательность ряда web-разработчиков, сумевших выжать из xHTML невозможное; в xHTML сейчас есть фундаментальные ограничения, которые не позволяют реализовывать некоторые интерфейсные возможности. И, если xHTML перестанет развиваться как технология создания web-приложений, то она может исчезнуть, уступив место Flex или Silverlight, подобно тому, как «Turbo Vision» ууступила место графическим библиотекам Windows («гибель физическая»).
Однако, я уверен, под руководством WHATWG, развитие xHTML/CSS/JS как технологий создания web-приложений будет продолжено, ит HTML5 — хороший тому пример.
А вот с этим я совсем не согласен.
Действительно, для разработчиков ASP.NET, GWT, JSF — xHTML действительно, во многом, стал ассемблером. Но, есть также и большое число разработчиков, использующих xHTML/CSS/JS на высоком уровне.
И не только для создания сайтов (язык разметки), но и для создания web-приложений (язык построения богатых интерфейсов). В xHTML/CSS/JS (особенно с учетом их развития) есть для этого все возможности. И надо только правильно понять и воспользоваться ими…
хаброчеловеку!Но, все же, хотелось, что бы разработчики использовали xHTML/CSS/JS не вынужденно, «из под палки» поисковика, а добровольно — осознав его возможности для построения богатых web-интерфейсов.
И появление HTML5 здесь очень кстати.
Так что компилирование программы на высокоуровневом языке в ассемблерный код (а не сразу в машинный) — не такая чушь, как меня пытаются упрекнуть :-)
Хотя, конечно, сейчас это используется не часто.
Так вот, я считаю, что xHTML/CSS/JS — это очень хорошие технологии именно для создания RIA интерфейсов web-приложений.
И, HTML5 не продолжит агонию Веба, а будет одним из шагов развития xHTML/CSS/JS как технологий создания web-приложений.
Уменьшение производительности и скорости работы при переходе на новый уровень абстракции — неизбежность. Но, которая, благодаря увеличению мощности железа, в большинстве случаев (за исключением маломощного железа, вроде микроволновок, для которых до сих пор пишут на ассемблере), не мешает переходу на новый уровень.
И, поэтому, xHTML/CSS/JS останутся на плаву не потому, что они низкоуровневы (и соответственно, быстрее работают), а потому что они — очень мощные и гибкие технологии создания web-интерфейсов.
Но, все равно, спасибо за замечание.
Переход «Ассемблер → C» — это переход на новый уровень абстракции.
Переход «xHTML/CSS/JS → серверный контрол» — это не переход на новый уровень, а замена парадигмы web на десктопную Delphi / Visual Basic парадигму.
Но:
— Кто придумает этот элемент?
— Кто заставит производителей браузеров (особенно самого распространенного) поддерживать этот элемент?
В этом и вся проблема :-)
Я полностью с Вами согласен. Усиление уровня абстракции — фундаментальный процесс.
Да, он сопровождается потерей производительности. Но зато он увеличивает скорость и качество разработки; увеличение мощности железа нивелирует потери в производительности.
Да, сгенерированный низкоуровневый код часто выглядит уродливо, что приводит в ужас разработчиков с предыдущего уровня абстракции. Но более высокоуровневые программисты пишут код на высокоуровневом языке и именно на нем вылизывают его, делают более красивым и лаконичным. Поэтому, несмотря, на уродство низкоуровневого кода, код на высокоуровневом языке выглядит красиво… до тех пор, пока не появится новый уровень абстракции…
Поэтому, процесс усиления абстракции необратим.
НО! В этой статье я хотел показать следующее:
Ассемблер объективно был низкоуровневым языком, поэтому его замена языками высокого уровня была правильной и неизбежной.
Однако, xHTML/CSS/JS на самом деле являются высокоуровневыми языками построения интерфейсов; и лишь воспринимаются разработчиками как низкоуровневые.
Поэтому, их замена «псевдовысокоуровневыми» серверными контролами не является обязательной, и ее можно (и нужно) избежать.
См. 3-ю сноску.
Я не утверждаю, что все разработчики используют ASP.NET только из-за серверных контролов.
Но, я говорю, что есть разработчики, которые не хотят осваивать web-парадигму, и, поэтому, выбирают привычную им с со времен Delphi и Visual Basic модель серверных контролов…
Сама по себе ASP.NET и .Net вообще — очень мощная технология.
Но попытка применить к web десктопную windows-овскую GUI парадигму с помощью ASP.NET контролов — это выглядит ужасно!
Поэтому, ASP.NET MVC Framework — это большой шаг вперед!
Но, знаете, я очень не уверен, что все ASP.NET разработчики перейдут на MVC. Ведь модель ASP.NET контролов настолько является настолько родной, привычной и понятной для тех, кто привык к Visual Basic / Delphi парадигме: кинул контрол на форму → щелкнул два раза мышкой → написал обработчик и все дела…
Я считаю, что HTML/CSS/JS — не являются устаревшей технологией! И они лишь воспринимаются многими разработчиками как устаревшие, из-за недооценки заложенных в них гибкости и мощи.
Другое дело, что эти технологии, перестав развиваться как технологии развития web-приложений, действительно могут устареть, и уйти со сцены, уступив место Flex или Silverlight. Подобно тому, как интерфейсы на основе Turbo Vision уступили место windows'овским интерфейсам («гибель физическая»).
Но, именно для того, чтобы, чтобы HTML/CSS/JS не прекращали развиваться, как технологии создания web-приложений, и была создана WHATWG. И HTML5 — один из шагов такого развития.
Полностью согласен. Но, пусть этой виртуальной машиной будет браузер!
В статье нет никакой «антимайкрософтовской идеологии».
Я считаю классические xHTML/CSS/JS замечательными и удивительно гибкими технологиями построения интерфейса; и выступаю против отказа от их использования не только в сторону микрософтовских ASP.NET-контролов и Silverlight, но и Flex от Adobe и JSF от SUN.
К самой же Микрософт и, даже, «чистой» ASP.NET (без учета контролов), я отношусь с большим уважением.
См. 3-ю сноску:
Насчет вызова функций я точно не уверен. Но, по-моему, команды
CALиRETбыли чисто ассемблерными командами, и не для всех процессоров имели аналог в машинных кодах.Но, на всякий случай, пока заменил другой «фишкой» продвинутого ассемблера — использованием макросов. «Фишкой», которая стала не нужной высокоуровневым разработчикам. Также, как станут не нужными многие «фишки», облегчающие разработку front-end разработчикам, если xHTML/CSS/JS-код будет генерироваться автоматически…
Очередь — эта такая структура, элементы которой добавляются в конец и извлекаются из начала.
Ни какого «вытягивания элементов из середины очереди» быть не может! Во всяком случае, это уже будет не очередь…
__VIEWSTATEстоит!Но, надо отдать Микрософту должное: от версии к версии, генерируемый ASP.NET-контролами xHTML код становится все менее уродливым. В последней версии код уже является полностью валидным, и довольно семантичным. Я написал об этом в 6-й сноске.
Генерация низкоуровневого кода (HTML/CSS/JS) на основе высокоуровневого (ASP.NET) — это и есть «компиляция» (или «трансляция», если быть пуристом). Разве не так?
Конечно, я знаю про ASP.NET MVC Framework :-) Но на момент написания тезисов статьи (а они были приурочены к началу работы над HTML5, см. аннотацию), ее еще не было. Но, опять же, ASP.NET MVC говорит о том, что модель ASP.NET контролов не идеальна…
Речь идет не о Win16/Win32/Win64 API. Речь идет о том, что web-разработчики ASP.NET используют тот же самый API (базовые классы .Net Framework), что и Windows-разработчики .Net. Но, согласен, сформулировано некорректно. Убрал, пока не переформулирую.
Да, полностью согласен.
Поскольку Ruby поддерживает класс-ориентированное ООП (хотя, как и в Python (см. комментарий dsCode ), близкое к прототипному ОПП JavaScript'а), использование Prototype.js как часть Ruby on Rails гармонично и красиво.
Но, использование класс-ориентированного ОПП в самом JavaScript'е является, как я считаю большим «надругательством» над прототипной идеалогией JavaScript.
Что, конечно, не отменяет достоинств Prototype.js, как одной из первой библиотеки для упрощения работы с DOM.
Я спорю с superhabra, который утверждает, что программы на высокоуровневых языках всегда более эффективны, чем низкоуровневые ассемблерные:
Я же утвержаю, что в большинстве случаев (хоть и не всегда), программа, написанная на высокоуровневом языке менее эффективна, чем низкоуровневая; т.к. накладные расходы перехода на новый уровень абстракции снижают эффективность.
Если бы это всегда было не так, то никто бы не писал ассемблерные программы для маломощных устройств.
Но, то что во многих случаях программы для устройств с малой производительностью пишут именно на ассемблере, а не на высокоуровневых языках, говорит о том, что накладные расходы при переходе на новый уровень абстракции приводят к уменьшению эффективности (несущественного для современных компьютеров, но критичного для маломощных устройств).
Ментальная гибель: останутся физически, но исчезнут из сознания разработчиков, накрывшись высокоуровневыми абстракциями, став низкоуровневыми языками — новым ассемблером;
Физическая гибель: исчезнут полностью, уступив место Silverlight или Flex.
Так что «Закат Веба» действительно может наступить…