май    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

показать все 

27.04.2024

RAMAX Group рассказала на Smart Mining & Metals об особенностях пилотирования ML-проектов

Читать далее 

22.04.2024

Сообщество цифровых управленцев «я-ИТ-ы» проводит ЗАКРЫТУЮ встречу в рамках выставки «Связь-2024»!

Читать далее 

18.04.2024

Ассоциация разработчиков «Отечественный софт» отметила 15-летие

Читать далее 

17.04.2024

РДТЕХ представил Технологическую карту российского ПО 2023

Читать далее 

показать все 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

18.04.2024

Цифровая трансформация в энергетике: как запустить проект с максимальным финансовым эффектом?

Читать далее 

05.04.2024

Мотивируй, не то проиграешь!

Читать далее 

22.03.2024

В 2024 году в России и мире вырастут объемы применения AR/VR 

Читать далее 

25.02.2024

Цифровые технологии: надежды и риски

Читать далее 

05.02.2024

Будут ли востребованы услуги технической поддержки софта Oracle в России в ближайшие годы?  

Читать далее 

31.01.2024

Здания с признаками интеллекта. Как Сергей Провалихин автоматизирует дома и производства

Читать далее 

показать все 

Главная / Архив номеров / 2024 / Выпуск №01 (134) / Будущее Web-разработки

Рубрика: Мнения

 Артур Ампилогов, архитектор, программист, консультант по построению ИТ-решений

Рой Томас Филдинг, один из создателей HTTP-протокола, придерживается другого мнения. В его известной диссертации пятая глава посвящена «Передаче состояния представления» (REST), где представлены идеи коммуникации на заре Интернета.

Так браузеры или программы-утилиты, которых далее будем называть Web-клиентами, общаются с серверами. Важным пунктом диссертации обозначено, что Web-клиент должен уметь обрабатывать ресурс, который запрашивает с сервера. Это может быть изображение в формате PNG, видеофайл в WebM, PDF-файл, или HTML-веб-страница.

Заметьте, чтобы показать картинку в формате PNG или JPEG, браузеры не скачивают дополнительную библиотеку или код, а такая возможность уже встроена в сам браузер. Клиент и сервер договариваются о поддерживаемых форматах ресурса через общепринятые медиатипы (Media Type). HTML-страница имеет свой тип «text/html», и является всего лишь одним из ресурсов. На странице в формате HTML должен располагаться основной функционал, например, выдача результата в поисковых системах или возможность войти в электронный почтовый ящик. Дополнительно, согласно Рою, на странице могут быть сделаны улучшения путем загрузки кода, или библиотек, но это не должно быть обязательными. Web-клиент должен иметь возможность работать с сайтами без скриптов JavaScript. При этом поиск может быть опционально улучшен скриптами, например, в виде автодополнения при вводе запроса.

На мобильные устройства сегодня приходится 57% трафика всего Интернета. Обязательное исполнение JavaScript-кода несет излишнюю нагрузку на устройства конечных пользователей.

Существует еще одна концептуальная проблема, не столько с JavaScript, сколько с современным подходом в передаче данных. Программисты привыкли работать с форматом JSON.

Для страницы учетной записи это может выглядеть следующим образом: Web-client скачивает первоначально страницу HTML, далее скачивает JavaScript код, который подгружает данные в JSON-формате с сервера, например, «{ profile: { name: «Artur» }}».

Получается, что публичные интерфейсы сервера должны быть привязаны к конкретной Web-странице, отдавая данные с определенной структурой. При этом и сама страница должна знать точно об этой структуре и как ее использовать для обновления интерфейса. Команды, где идет разделение на Frontend-и Backend-программистов, несут дополнительные затраты на поддержку таких связей между серверным API и Web-страницами. Более того, Backend-программисты делают проверки безопасности на действия пользователя, так еще и Frontend-программистам необходимо продублировать некоторые из проверок, например, пряча или показывая тот или иной функционал, или запрещая действия пользователю.

Если же сервер возвращает данные в формате HTML, то браузеру не нужно знать что есть определенный путь к специфичным данным, таким как profile.name, или user.name, или account.name. Все данные уже отображены через представление в общепринятом HTML, и браузер знает как это обработать.

Проверка безопасности и возможностей действия пользователей располагается в едином месте – Backend. Представьте если бы вы скачали PDF-или Word-файл, а там вместо текста стояли пропуски. Далее бы скачивался специальных скрипт, на Visual Basic или Python, и специальный интерпретатор обрабатывал скрипт, затем скачивал текст с определенной структурой, распознавал структуру, вытаскивал текст и вставлял его в нужные пропуски. Более того, если бы на сервере программист чуть-чуть поменял структуру возврата текста, то вы бы его вообще не увидели пока не обновили PDF. Это реальность, которую мы сегодня имеем в Web-приложениях.

Как же так получилось, что JavaScript стал необходимостью при посещении Web-страниц? На это есть две главные причины.

Первая причина – это медленное развитие стандарта HTML. Последняя версия HTML 5 в формах ввода поддерживают только GET-запрос на чтение ресурса и POST-запрос на модификацию ресурса. При этом вся страница будет перезагружена в Web-клиентах после обработки такого запроса. С помощью JavaScript можно обновлять части страницы без полной перезагрузки, при этом в ответ почти на любое событие или в необходимое время.

Вторая причина – это пользователи, ради которых программисты стараются улучшить работу с интерфейсом страницы. Современные JavaScript-библиотеки, такие как React.JS и Next.JS, Vue.JS и Nuxt.JS, Angular, Svelte Kit, Qwik, а также такие UI-библиотеки как Bootstrap, Daisy UI, Radix, Material UI, Chakra UI, позволяют с легкостью менять интерфейс страницы. Современный HTML предоставляет многие элементы. Например, модальные окна с тэгом <dialog>, а CSS дает широкие возможности в применении стилей, включая анимационные эффекты, и все это без использования JavaScript. В тоже время программистам легче использовать готовые и проверенные решения с JavaScript.

Вернуться к ранним идеям создания Web-приложений призывает Карсон Гросс, автор проекта HTMX. Он предлагает расширить HTML с помощью дополнительных атрибутов.

Так, «hx-target» позволяет заменять конкретную часть страницы HTML-ответом с сервера, без полной перезагрузки страницы. И при этом никаких JSON -данных. Современный HTML позволяет сделать запрос изменения на сервер только через тег <form>.

Карсон предлагает расширить не только элементы, которые смогут отправлять запросы, но и события, по которым это может происходить, например, <body hx-trigger=«load»> при загрузке страницы.

К сожалению, единственный способ сегодня работать с таким HTML-расширением это опять же использовать JavaScript. Стандартизация HTML – медленный процесс, но скорее всего W3C-консорциум предоставит аналогичный функционал в будущем.

Язык JavaScript был создан в 1995 году всего за 10 дней Бренданом Айком, который работал над улучшением возможности браузера Netscape. Первоначально Брендан думал встроить в браузер поддержку его любимого функционального языка Scheme. Но менеджмент из-за огромной конкуренции на рынке потребовал сделать что-то похожее на «Java для домохозяек».

Новый язык должен был иметь максимально возможную поддержку виртуальной машины Java: совместимую типизацию примитивных данных, создание объектов, сборщик мусора. Предполагалось что виртуальная машина JVM будет или встроена в браузер, или установлена как дополнение. Профессионалы будут писать код на Java, а любители – на JavaScript, предоставляя улучшения Web-страницы.

Конечно, при таком стрессовом и быстром подходе к созданию языка ничего хорошего выйти не могло, и язык имеет множество недостатков. Тем не менее JavaScript своей простотой победил в Web-пространстве не только саму Java и ее «апплеты», но и Microsoft с Visual Basic и ActiveX, а также конкуренцию с ActionScript от Macromedia Flash, Microsoft Silverlight.NET и Google Dart.

После затянувшихся на десятилетия браузерных войн и недостатков JavaScript, корпорации пришли к выводы, что пора вернуться к идеи общей виртуальной машины, которая не будет зависеть от языков программирования.

Так официально в 2017 году появился проект WebAssembly, или WASM – стандартизованный байт-код для виртуальной стэк машины. Это упрощенный аналог JVM и .NET. Современные браузеры имеют супербыстрые «движки» для запуска программ. При этом язык JavaScript динамический. В функцию могут быть переданы любые типы аргументов, будь то число, строка или большой объект, из-за этого многие оптимизации не могут быть использованы в браузерах, делая выполнения кода медленным. Главная идея проекта WASM – предоставить программистам доступ к быстрым браузерным «движкам».

Все современные браузеры поддерживают WASM. Многие языки программирования уже можно компилирать в WASM байт-код. Появилась возможность писать программы для клиентской части на C++, Rust, C#, Kotlin, Python и других языках. Но здесь кроется проблема – развитие проекта идет очень медленно и находится в странном состоянии.

В WASM еще не включили поддержку сборщика мусора. И такие проекты как Blazor на языке как C# вынуждены компилировать сборщик мусора и поставлять его в огромном модуле вместе с функционалом. При этом «движки» браузеров работает с моделью объектов интерфейса страницы (DOM), и внутри все заточено на работу со сборщиком мусора для JavaScript. А такие проекты как Rust2Wasm вынуждены создавать свой дополнительный блок линейной памяти, т.к. из-за отсутствия аналогичного сборщика мусора в Rust, доступа напрямую к собираемым WASM объектам нет.

Получается, что Rust, скомпилированный в WASM, запрашивает значение input-элемента из браузерного мира JavaScript в виде байтов строки, а потом вынужден дублировать байты в свою отдельную память и декодировать данные в свой формат строки. После обработки cтроки в WASM повторить все наоборот. К тому же программисту необходимо указать, сколько памяти нужно выделить перед началом работы с линейной моделью Rust в WASM, даже если вся память не используется.

В скором времени в WASM обещают открыть доступ к памяти DOM-модели браузера, более простую работу со строками, а также поддержку сборщика мусора. Тогда для обновления HTML-интерфейса выиграют языки программирования уже имеющие платформы со сборщиками мусора: C#, Dart, Go, Java и Kotlin.

Основные поставщики браузерных «движков», Google и Microsoft, заинтересованы в таком развитии сценария. Языковые модели Rust и C++ не смогут предоставить легкость работы с автоматически собираемыми объектами в браузерах. Их плюсом будет компиляция существующих игр, переиспользования алгоритмов обработки видео и изображений. И это уже успешно делается. Так, Adobe, AutoCAD и Figma используют WASM для предоставления возможностей дизайна и проектирования в браузерах, а игровой «движок» Unreal Engine позволяет компилировать игру в WASM.

Существующие языки программирования несут в себе исторические ограничение и привязанность к своим платформам. Я считаю, что появится новый язык, который будет компилироваться ближе к байт-формату WASM, и в конечном итоге, он станет языком Всемирной сети. 

Подпишитесь на журнал

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи