- PVSM.RU - https://www.pvsm.ru -

На пути к замене HTML+JS

На пути к замене HTML+JS

Проблема

Большую часть моей роботы с технологиями большой тройки (HTML, CSS, JS) составляет создание простых страниц вроде документации к приложению, визитки для предприятия, и тд. Для таких мелких целей текущая тройка подходит почти идеально. Однако, что если подумать о современных сайтах вроде Facebook, VK, Google Docs, Twitter, Stack Overflow? Они являются скорее полноценными приложениями, чем страницами. В таком случае можно рассматривать эту тройку как тулкит для создания графических приложених, вроде GTK+ или Java AWT. Однаок если открыть код упомянутых выше веб-приложений, можно увидеть кашу из прямолинейного, повторяющегося HTML-кода, неясной JS логики и CSS хаков. Разве это сравнимо с ООП кодом, ответственного за отображение графики, в любом более менее нормальном desktop-приложении? В любом тулките создание меню — вопрос пары строк кода. Переиспользование одного и того же кода? Проще простого! А как насчет большой тройки? С этой точки зрения тройка не выдерживает никакой критики. Она не расчитана на веб-приложения, которые характеризуется нелинейной структурой экрана, высокой динамичностью содержания, требовательностью к ресурсам. Я считаю, что именно с веб-приложениями тройка справляется плохо. Эти технологии были созданы для простых, линейных, статических страниц.

Я решил подумать немного над этим вопросом. Почему в мире desktop программирование есть такие удивительно-функциональные фреймворки, а программисты веб-приложений давятся из рук вон ужасным стандартом? После нескольких дней размышления я решил изложить свои идеи на, как говорится, бумаге. В этой статье я хотел бы очертить стандарт, который мог бы послужить основой замены упомянутой выше тройки. Статья лишь претендует на попытку описать то, как замена тройки может выглядеть. Конструктивная критика и комментарии очень ожидаемы. Кодовое название — JAW, JAW's an Application for Web.

Идеи

После недолгого размышления я определился с основными идеями данной технологии:

  • Декларативный подход. Написание простых страниц остается простым при помощи XML.
  • ООП подход. Классы, энкапсуляция, наследование и абстракция создают условия для удобного переиспользования одного и того же кода в комплексных веб-приложениях.
  • Java байт-код. Классы могут быть описаны при помощи байт-код, что позволяет добавлять комплексную логику и обработку данных.

Страницы веб-приложения

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

Расмотрим пример простой HTML и JAW веб-страницы:

<html>
 <body>
  Hello, world!
 </body>
</html>

<?xml version="1.0" encoding="UTF-8"?>
<page> <!-- page это корневой элемент XML файла. -->
 <canvas> <!-- canvas содержит корневой компонент страницы -->
  <block>Hello, world!</block> <!-- block позволяет простой вывод текста и других компонентов -->
 <canvas>
</page>

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

Компоненты

Для начала определим, что компонент — это экземпляр (instance) некого класса, который можно отобразить на странице. Каждая страница имеет ровно один корневой компонент, который описывается единственным дочерним элементом элемента canvas. В предидущем примере корневой компонент имеет класс block, встроенный класс имеющий поведение схожее с тегом div. JAW, как и HTML, поддерживает множество базовых классов. Преимущество использования классов заключается в повторном использовании кода. К примеру:

<html>
 <body>
   <div>Apple</div>
   <div>$10</div>
   <div>Orange</div>
   <div>$5</div>
 </body>
</html>

<?xml version="1.0" encoding="UTF-8"?>
<page> <!-- page это корневой элемент XML файла. -->
 <classes>
  <class name="product" >
    <template> <!-- Здесь мы задаем шаблон компонента. Код, создающий экземпляр этого класса, должен будет предоставить значения этих свойств. Свойства могут быть обычным тексом, а могут быть и компонентами. -->
     <block><property type="text" key="title"></block>
     <block><property type="text" key="price"></block>
   </template>
  </class>
 </classes>
 <canvas>
  <block>
   <product>
    <property key="title" value="Apple"> <!-- Первый способ создания компонента. Здесь property - это не дочерний компонент, а специальный элемент. -->
    <property key="price" value="$10">
   </product>
   <product title="Orange" price="$5"> <!-- Второй способ создания компонента, более короткий, но не удобный для большого кол-ва свойств. -->
  </block> 
 </canvas>
</page>

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

<?xml version="1.0" encoding="UTF-8"?>
<page>
 <classes>
  <class name="product" >
    <template>
     <block><property type="component" key="title"></block>
     <block><property type="component" key="price"></block>
   </template>
  </class>
 </classes>
 <canvas>
  <block>
   <product>
    <b key="title">Apple!!!</b> <!-- Здесь b делает текст жирным, как и в HTML. -->
    <i key="price">$10</i> <!-- Аналогично. Аттрибут key указывает название свойства, которым станет этот компонент. -->
   </product>
   <!-- Второй способ создания компонента в данном случае невозможен. -->
  </block> 
 </canvas>
</page>

Определять класс можно и программно в байт-коде, о чем также позже. JAW код получился длиннее, однако у нас используется шаблон, а значит замена структуры продукта займет меньше времени. Более того в данном случае при использовании второго способа создания компонента JAW код, ответственный за вывод product, будет меньше HTML кода уже при 7 продуктах.

Client-side программирование

Продлогаемую мной идею можно описать следующим образом. Страница может использовать некий класс A, но вместо того, чтобы определять его, она может сослаться на файл содержащий Java байт-код класса А. Веб-браузер в свою очередь будет содержать JVM (Java Virtual Machine) для выполнения этого байт-кода.

Код страницы может содержать код вроде:

<?xml version="1.0" encoding="UTF-8"?>
<page>
 <include url="./MyMenu.class" /> <!-- Подключаем класс MyMenu, указывая URL, по которому его можно найти -->
 <include url="./myappclasess.jar"/> <!-- Подключаем целый архив классов, запакованых в Java Archive -->
 <canvas>
  <MyMenu>
    <!-- ... --> 
  </MyMenu>
 <canvas>
</page>

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

Байт-код содержит код отображения класса, а так же логику, вроде обработки нажатий мышки в пределах данного компонента, срабатывания таймеров, подсчет неких значений, изменение дочерних компонентов и тд. Стандартная библиотека Java достаточно богата для легкого создания фрейморка работы со страницей. К примеру, AWT уже содержит множество Java классов для работы с компонентами, графикой, событиями. Необходимости писать API фреймворка с нуля не будет. Более того Java библиотека поддерживает работу с массивами, интернет протоколами, XML файлами, процессами, потоками и тд. Это позволит перенести массу кода с сервера на клиент, что улучшить производительность веб-приложений, их гибкость и функционал. Именно байт-код является основным новшеством JAW. Файлы страниц нужны только для декларативного создания простых страниц и точек начала работы с веб-приложением.

Из всех существуещих на сегоднешний день байт-кодов самыми развитыми являются .NET управляемый код и Java байт-код. Поскольку .NET не портирован на другие платформы кроме Windows, его использование становится не возможным в JAW. Единственным вариантом остается Java. Стоить сказать, что существует не малое количество языков [1], которые можно компилировать в Java байт-код. Среди них C, Ruby, Python, Lua, Pascal, PHP, Scheme, Google Go, Lisp и другие. Не плохой набор для замены JavaScript, не правда ли?

Что дальше?

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

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

Автор: Ganga

Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/javascript/15764

Ссылки в тексте:

[1] не малое количество языков: http://en.wikipedia.org/wiki/List_of_JVM_languages