Сразу оговоримся, что в этой публикации мы не будем затрагивать вопросы подходов к созданию полномасштабных приложений для Web, подразумевающих наличие крупной кодовой базы, заставляющей функционировать её серверную часть. Как-то исторически сложилось так, что клиентская часть подобных приложений, как правило, реализуется на JavaScript и производных от него языках и фреймворках, а серверная – уж на чём придётся... В конце концов, не столь уж это и важно – главное, чтобы соответствующая программная среда была поднята на сервере и реализованный в ней код спокойно выполнял свою задачу. Вместе с тем со временем всё чаще стала возникать потребность в написании монолитных – как правило, простых и непритязательных веб-приложений, не требующих для работы серверной части. Естественно, с широким распространением HTML5 подобные приложения начали обретать весьма богатый функционал, однако... Однако же не все разработчики были готовы смириться с существующим положением вещей, когда все доступные им решения, по сути, имели своим краеугольным камнем всё тот же пресловутый JavaScript. В конце концов, многие, что называется, “с младых ногтей” привыкли к другому подходу к проектированию и созданию приложений широкого профиля. Это, в первую очередь, различные RAD-среды, среди которых в нашей стране наибольшей популярностью (по крайней мере, в академической среде), всегда пользовалась Delphi. Натянул пару кнопок на форму, прописал нужные обработчики событий на привычном языке Pascal – красота!.. Чего ещё можно желать, в особенности если вы сосредоточены на реализации каких-то нужных вам алгоритмов, а интерфейс для вас не играет такой уж принципиальной роли? При традиционном дизайне и проектировании веб-приложений всё совсем не так. Тут тебе бы неплохо помнить и все основные детали описаний различных тэгов HTML-разметки и атрибутов CSS-стили, и уметь сверстать всё это дело воедино, да ещё и “оживить” интерактивными сценариями, реализованными на JavaScript. Очевидно, что такой подход, ориентированный в первую очередь на дизайн, а не на саму разработку как таковую, вряд ли устроит нашего традиционного разработчика, воспитанного на классических алгоритмах и структурах данных, с возможным вкраплением зачатков объектно-ориентированного подхода. (Напоминаем, что речь идёт в первую очередь о разработчиках небольших приложений, где теоретически мог бы управиться и один человек.) Выход из подобной ситуации пытаются найти уже довольно длительное время. Когда-то возможным решением проблемы считались расширения для популярных браузеров, позволяющие создавать в них виртуальное окружение для создания приложений с функционалом, основанным на более привычных языках программирования. В разное время ряд компаний предлагали свои собственные разработки, базирующиеся на продвигаемых ими языках: Sun со своей Java (на нём были основаны приложения специального вида, предназначенные для запуска в браузере, – сервлеты), Adobe – c языком ActionScript (в составе технологии, известной всем как Adobe Flash, а ранее – Macromedia Flash), Microsoft – со своей реализацией .NET Framework для веба (Silverlight). Все они к настоящему моменту благополучно канули в Лету. Формально дольше всех продержался AdobeFlash, окончательно “похороненный“ лишь в январе 2021 г. При этом, что характерно, про Silverlight или другие подобные разработки многие из нынешнего поколения айтишников уже и вообще редко когда слышали. Так что и мы не будем подробнее их затрагивать. Каждой технологии – своё время, что называется. Сейчас нас интересуют не столько окончательно отжившие своё разработки, сколько те более современные инструменты, которые пришли им на смену. Надо сказать, что тенденции придать веб-разработке некоторые черты RAD-технологии (Rapidapplicationdevelopment, т.е. дословно “быстрой разработки приложений” – именно так принято именовать подход к разработке приложений, реализованный, в частности, в BorlandDelphi) существуют уже достаточно давно. Здесь нельзя не упомянуть хотя бы о DHTML (или Dynamic HTML) – подходе, так же позволяющем придавать некоторую интерактивность самим приложениям и, в частности, используемым в них элементам пользовательских веб-форм, – интерактивность, похожую на то, что мы можем видеть в Delphi, VisualBasic и прочих RAD-средах проектирования традиционных приложений. DHTML-приложения подразумевали полноценную автономную браузерную реализацию, без какой-либо поддержки со стороны сервера – именно то, что сейчас известно как Richwebapplication (ранее –RichInternetapplications, RIA) и тесно соприкасающиеся с ними SPA (Single-page applications– одностраничные веб-приложения). Однако сама по себе технология DHTML  так и не оправдала возложенных на неё надежд, и была вытеснена всё теми же альтернативными подходами, требующими установки автономных плагинов, – такими, как AdobeFlash или JavaServlet (позднее – JavaFX). В то же время она в числе прочих компонентов составила прочную основу, на которой базируется такой широко известный в веб-разработке подход, как AJAX (где уже широко задействуется и серверная часть). Какие-то весточки вновь намечающихся позитивных сдвигов в отношении упрощения создания RIA- и SPA-приложений начали проявляться только где-то с принятием WebAssembly (или просто WASM) в качестве нового промышленного стандарта для веба. Именно с подходом, заложенным в самой основе WASM, связана поддержка расширений, позволяющих отныне использовать для написания кода, выполняемого в браузере, более привычный для программистов “старой закваски“ бинарный формат -- именно в него в свою очередь могли транслироваться программы, написанные на самых разных языках, в том числе и тех, с которыми они уже имели дело раньше (например, даже C++, если использовать такой инструмент, как Emscripten). Но, что самое характерное, теперь всё это богатство стало разом доступно во всех браузерах (включая и мобильные), и больше не требовало, как раньше, установки каких-либо дополнительных сторонних расширений! Разумеется, многие уже наслышаны и о Blazor – проекте, который Microsoft довольно быстро “подмяли” под себя, выдвинув его в качестве своеобразного аналога для их же собственного, ныне почившего проекта Silverlight. Ура, отныне все желающие снова могут разрабатывать свои веб-решения, пользуясь лишь традиционными средствами, основанными на использовании VisualStudio и языков .NET-семейства (в первую очередь – C# и VB.NET)! И никакого вам больше Джаваскрипта... Нет, на самом-то деле при желании JavaScript тоже вполне можно интегрировать с этими решениями, как и все порождённые им фреймворки. Более того, при отсутствии поддержки WASM со стороны используемого вами браузера первые же версии Blazor умели налету конвертировать код в JavaScript (используя для этого более раннюю технологию под названием asm.js). В настоящий момент Blazor активно развивается. Если его предшественник – технология MicrosoftSilverlight – пребывает в стагнации уже как минимум с 4-й версии (первоначально выпущенной аж в 2010 г.), то сам Blazor всего за два года активного применения “дорос” уже до 5-й версии. Всё это, бесспорно, не может не радовать. Но мы сейчас хотели поговорить и о менее распространённых альтернативах последних из названных нами технологий для реализации подходов к созданию RIA- и SPA-приложений, заставляющих вспомнить привычный для кого-то RAD-подход. Мы отнюдь не случайно уже упомянули здесь Delphi. И пусть сама эта среда (а в случае с Delphi можно говорить и о среде, и о положенном в её основу языке как о едином целом) и не обеспечила нас широко доступными средствами для создания подобных веб-приложений. В конце концов, нашлись другие разработчики, которые это сделали! В первую очередь на память здесь приходят создатели SmartMobileStudio – это такая альтернативная инструментальная среда программирования на Delphi, позволяющая реализовывать различные кросс-платформенные проекты (о современном уровне развития инструментов разработки кросс-платформенных решений в целом можно почитать, например, в этом обзоре: https://habr.com/ru/post/528614/). Причём под кросс-платформенностью в данном случае понимаются именно мобильные разработки (отсюда и название – Smart MobileStudio), в числе которых поддерживаются и -- внимание, - веб-приложения! Разработчики сумели в данном случае добиться прямой трансляции кода на Delphi в аналогичный код JavaScript, исполняемый прямо в браузере. Закоренелые “паскалисты” могут торжествовать. Надо сказать, что и приверженцы других кросс-платформенных языков и фреймворков тоже не остались в стороне. Например, возвращаясь к тому же миру .NET, следует отметить, что в настоящий момент имеется уже как минимум несколько попыток портирования популярных инструментов и фреймворков, ориентированных на создание кросс-платформенных приложений, для работы чисто в веб-среде. Среди них сразу же вспоминаются такие проекты, как Ooui (задавшийся целью перенести такой популярный мобильный фреймворк, как Xamarin, в приложения, исполняемые исключительно в браузере) или UnoFramework (авторы которого пытаются продвигать в веб идеологию UWP-приложений). Основная провозглашаемая авторами подобных оригинальных разработок цель -- добиться того, чтобы проектируемые нами приложения по возможности выглядели одинаково что под iOS и Android (либо, как вариант, – Win, Mac и Linux), что и непосредственно в браузере. Правда, такие приложения уместнее сравнивать скорее с создаваемыми посредством майкрософтовской технологии ASP.NET Вспомним заодно уж и о Xojo – кросс-платформенной объектно-ориентированной среде программирования, основанной на языке REALbasic (своеобразном аналоге VisualBasic– почти как Lazarus по отношению к BorlandDelphi; правда, на сей раз речь идёт о коммерческом продукте). Она тоже в настоящий момент позволяет создавать код не только для Windows, macOS или Linux, но и напрямую для веба – используя для этого всё те же принципы проектирования RAD. Правда, такие приложения уместнее сравнивать скорее с создаваемыми посредством майкрософтовской технологии ASP.NET – в последних, конечно же, тоже широко используются принципы проектирования RAD, но тем не менее требуют для своего развёртывания веб-сервер. Наконец, нельзя не упомянуть под конец и о другой, скорее прямо противоположной описанным здесь ранее подходам, но не в пример более модной тенденции последних лет – желании по возможности полностью упаковать проектируемое приложение в свой собственный контейнер веб-браузера, в котором и будет реализована вся программная логика и пользовательский интерфейс с применением технологий HTML5 (вспомнить хотя бы те же средства для разработки UWP, на которых зачастую и основаны приложения, похожие на те, что принято именовать “прогрессивными” – progressivewebapplications, PWA, – которые выглядят почти как чисто браузерные, но при этом ведут себя подобно другим приложениям для соответствующих устройств). Возможно, это явные признаки того, что на смену разработчикам старой формации (“кнопкодавителям“, “клепателям формочек” - как их иногда пренебрежительно именуют) уже пришло новое поколение, для которого все эти веб-стандарты и принципы разметки уже, что называется, прочно вошли в подкорку. Равно как и по-прежнему отталкивающий многих синтаксис JavaScript и базирующиеся на нём принципы построения приложений. Хорошо это или плохо – покажет время... Возможно, пройдёт ещё несколько лет, и в моду начнёт постепенно входить уже какой-нибудь совершенно новый подход в плане дизайна и компоновки приложений, не имеющий ничего общего с прежним структурированием на базе HTML-тэгов. Не сразу, но по мере своей естественной эволюции он начнёт занимать всё более прочные позиции в тех областях, где пока ещё безраздельно правят HTML5 и JavaScript. Поживём – увидим.  Пусть другие теперь строят прогнозы, мы же лишь попытались дать краткий сравнительный обзор технологий для построения приложений, работающих прямо в браузере пользователя (что называется, “из коробки”) – как имеющих на данный момент скорее историческое значение, так и пока ещё актуальных. Тренер Битрикс