Часть 2. Возможности и ограничения современных веб-платформ
SPA (Single-Page Application) весьма сильно изменили архитектуру веб-приложений. Если говорить кратко - архитектура SPA гораздо проще традиционных, и по характеру ограничений практически ничем не отличается от традиционных клиент-серверных приложений. С поправками на веб-технологии, конечно. Остановимся поподробнее на принципиальных возможностях и ограничениях современных веб-платформ - что поменялось с архитектурной точки зрения.
Первое, и, возможно, самое важное. JavaScript в современных браузерах невероятно быстр. Виртуальные машины во всех основных браузерах полагаются на JIT-компиляцию. Помимо JIT, в современном JS есть unboxed-массивы, а также возможности работы с бинарными данными. В целом, можно считать, что JS примерно вдвое медленнее .NET и Java, и вчетверо медленнее С++.
Вместо отсылок к тестам, я покажу вам в качестве иллюстрации вот это. Это декодер видео H.264, написанный на JS. Там есть ссылка на демо-страницы, посмотрите. Сколько кадров в секунду это будет выдавать, как вы думаете? Проверять надо в Chrome и в Firefox. Вы будете удивлены.
https://github.com/mbebenita/broadway
Для тех, кому влом открывать ссылку - браузер в состоянии играть *несколько* видео одновременно с полным фреймрейтом. Программно декодируя видео, на чистом JS.
Итак, современный JS в состоянии экономно работать с памятью. Он имеет полный доступ к canvas, для рисования там чего угодно. Он имеет досуп к видеоускорителю через WebGL API, к потокам через WebWorker API, а также к файлам, аудиоустроуству, и к сети.
Все это с рядом ограничений из-за соображений безопасности, конечно. Например - из браузера есть доступ не ко всем сетевым протоколам, а только к HTTP, WebSocket, и SCTP (через WebRTC API, с возможностью устанавливать прямые соединения между браузерами).
Помимо этого, JS в браузере имеет доступ к нативным кодекам видео и аудио, и имеет возможность управлять входными буферами. То есть, возможности современного браузера вполне достаточны, например, чтобы сделать клиента для видео-конференций.
Если мы добавим к этому nodejs, который представляет собой JS движок, выпиленный из Chrome для использования на серверах (со снятыми ограничениями безопасности), и заглянем в статистику проектов на github по языкам (JavaScript будет на первом месте), то станет очевидным невероятное еще 3 года назад. JavaScript сейчас представляет собой универсальную, практичную, безопасную, и популярную платформу, в рамках которой можно сделать почти все, что в принципе делается на managed-языках.
Звучит хорошо, так что с этого момента, и до конца изложения, мы принимаем следующее правило проектирования:
- Наше приложение работает в браузере.
Но стоп. Давайте проверим это правило.
- Его надо довести до всех. Ок, допустим сделали, это не сложно.
- Оно должно быть простое, штоб до всех дошло. Да куда уж проще, ну?
- Следование ему не должно быть слишком утомительным занятием...
Так, стоп, секундочку. Как мы знаем из предыдущей части, у нас сотни JS фреймворков, и никто в мире толком не знает, как такие приложния писать. Во всяком случае, договорится об этом не могут точно.
Это ж-ж-ж не спроста. Звучит так, как будто у нас проблемы.
- Следование правилу должно приносить неиллюзорную пользу.
Ну ок, а что мы хотя бы за это получим? Вдвое медленнее чем Java с C# - звучит не как польза, а самый что ни на есть вред. Так в чем польза?
- Веб-приложения не требуют установки, и доступны немедленно любому пользователю глобальной сети.
- У веб-приложений короткий цикл обновления, их можно обновлять хоть каждый день, не создавая пользователю неудобств.
- Веб-приложения по настоящему кроссплатформены, они работают везде, включая мобильные устройства.
Если мы добавим, что для всего перечисленного почти не надо ничего специального делать, так как это базовые свойства платформы, и поймем, насколько радикально это меняет ситуацию, то станет ясно, что есть за что бороться.
Остается как-то разобраться с досадной мелочью. Как же все-таки их правильно готовить, этих невкусных кошек.