Приручаем JavaScript или очередной велосипед для frontend-приложений

На «Хабре» всё чаще и чаще появляются статьи про разработку фронтенда на JavaScript. Рассматриваются тяжёлые библиотеки от Google и Facebook, не прекращаются холивары на тему какой фреймворк лучше использовать. Но не задумывались ли вы, что все эти фреймворки невозможны или абсолютно нелепы на других языках программирования? По моему субъективному мнению, это всё от того, что во главе угла DOM модель — HTML-тег, а не компонент. Но вернёмся к JavaScript.

Что мне в нём не нравится

• Отсутствие типизации;
• Прототипное наследование;
• Логическое разделение на файлы сопровождается головной болью;
• Взаимодействие с DOM деревом — это отдельная тема;
• Не гибкая событийная модель;
• Отсутствие удобного редактора кода.

У меня имеется большой опыт программирования на ActionScript 3. На мой взгляд — это идеальный язык программирования. Казалось бы, он как и JavaScript является приемником ECMAScript и проблем при переходе с одной технологии на другую возникнуть не должно. Однако это не так, и придумать архитектуру приложения на чистом JavaScript достаточно проблематично. Использование библиотек сначала вызывает радость: ура, наконец-то мне открылся дзен написания web-приложений; а потом сменяется тревогой, когда на решение задачи, не описанной на сайте фреймворка, тратится больше дня.

Производительность для мобильных приложений становится критической. И подход two-way binding'a уже не кажется решением всех проблем (AngularJs). Как и генерация страницы целиком на стороне клиента (ReactJs) у меня по прежнему вызывает лишь один вопрос — зачем? Зачем мне виртуальный DOM?

Эта статья про очередной велосипед от неизвестного автора желающего прославится, написав что-нибудь, что понравится разработчикам. Велосипед как по мне пока сыроват, но на его квадратных колёсах уже можно передвигаться. Прошу любить и жаловать сильно не пинать — Scooby!

Принципы

1. Объектно-событийная модель, максимально приближенная к модели ActionScript 3;
2. Контроль над уничтожением объектов;
3. Типизация, там где это возможно;
4. На выходе один JS файл с логикой, CSS с оформлением;
5. Работа только с компонентами, никаких получений ссылки на объект по его айди или классу.

Выбор технологий, или то, что нужно установить перед началом работы

LESS
lesscss.org ^[1]
LESS облегчает написание стилей, может собираться из нескольких файлов в один, следуя импортам. Для его установки вам понадобится Node.js.

Haxe
haxe.org ^[2]
Я рассматривал много технологий-обёрток вокруг JavaScript для типизации и объектного наследования. CoffeeScript, Dart, TypeScript. Но все они очень сырые или неудобные. Haxe в этом плане на голову выше, странно, что он не имеет большой популярности у frontend-разработчиков. Объектное наследование, удобные импорты в сравнении c TypeScript. Не нужны grunt файлы для сборки проектов, в общем, всё как я люблю. Так ещё и полная поддержка FlashDevelop IDE — моей любимой среды разработки для ActionScript.

FlahDevelop
flashdevelop.org ^[3]
Очень удобный редактор. Жаль, что он только под Windows. Тем, кто никогда не работал с ним — несколько сочетаний клавиш, делающих написание кода приятным и простым:

• ctrl+alt+пробел — Расширенный автокомплит, полезен когда класс ещё не импортирован;
• ctrl+shift+1 — выделяете функцию, а затем нажатием этого сочетания клавиш Вы можете сгенерировать слушатель события со всеми параметрами.

Результат

Библиотеку и демо-приложение вы можете найти по ссылке: https://github.com/rzer/Scooby ^[4]

src — исходники
bin — скомпилированное приложение

Выполнение кода начинается с класса Main:

static function main() {
	var main:Main = new Main();
	main.setView(Browser.document.body);
}

Дальше всё как в ActionScript: создаём объекты, добавляем их на сцену. Из базовых возможностей AS3 реализовано:

• Модель вложенных в друг друга визуальных объектов. Объекты, у которых не может быть детей должны наследоваться от scooby.display.DisplayObject. Аналогом Sprite выступает DisplayContainer. Важное отличие: в конструкторе в super нужно передавать имя класса объекта — этот класс будет автоматически присвоен DOM ветке.
• Событийная модель с баблингами по дереву. Важное замечание: при написании своих компонентов для подписки к нативным событиям DOM нужно вызвать функцию nativeEvent(«имя»). Только после этого событие будет отправляться. Также объект Event обладает полем data по умолчанию. Туда например, записывается нативное событие при отправке в нашу событийную модель. Да и в большинстве случаев этого поля достаточно, чтобы не плодить классы разнообразных событий.
• Некоторые из компонентов, которые понадобились мне в своём приложении. Поля ввода, кнопки, деревья, группы кнопок (меню, выбор одного из списка), разнообразные панели.

Жду критику.

Автор: rzer

Источник ^[5]