Сложность - это плохо: Интервью с создателем HTMX Карсоном Гроссом

Карсон Гросс - создатель HTMX и Hyperscript, автор книги The Grug Brained Developer, профессор программной инженерии в Университете штата Монтана и соавтор книги Hypermedia Systems.

Было очень приятно побеседовать с Карсоном о том, что послужило толчком к созданию таких проектов, как HTMX и Hyperscript, о неудачах REST, о том, почему JavaScript останется, и о многом другом.

Тайсон: Трудно выбрать, с чего начать, поэтому я остановлюсь на Grug Brained Developer. Мне кажется, что я мог бы просто направить туда всех желающих по всем вопросам, связанным с программированием.

Гросс: Ха, я ценю это. Я думаю, ее стоит прочитать большинству разработчиков. Хотя я в какой-то степени ориентировал ее на молодых разработчиков. Она, конечно, не идеальна - трудно быть идеальным, когда ты используешь голос пещерного человека и пытаешься быть смешным, - но я думаю, что большинство советов вполне разумны.

Тайсон: Это правда, что большинство проблем с кодингом, в которые я когда-либо попадал, были в основном результатом того, что я считал себя умным.

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

Тайсон: Это так верно насчет атмосферы, царящей вокруг признания того, что это слишком сложно. Однажды я сказал другу в чате: "JavaScript такой гибкий, что на нем можно найти выход из любой ситуации", а он в ответ: "Хаха, это опасный разговор". Он был прав.

Есть ли у вас какие-нибудь мысли по поводу JavaScript как языка?

Гросс: Я думаю, что JavaScript - это хороший скриптовый язык. На мой взгляд, это не лучший язык общего назначения. В каком-то странном смысле он напоминает мне C++: у него слишком много возможностей и способов делать что-то. С другой стороны, у JavaScript есть одна невероятная особенность: он здесь, в браузере. И это, на мой взгляд, сделает его главным скриптовым языком для веба в обозримом будущем.

Тайсон: Я впечатлен Hyperscript, но у меня такое чувство, что для вас это своего рода забавная побочная линия. Не могли бы вы рассказать нам о техническом опыте реализации парсера и так далее?

Гросс: Конечно. Hyperscript - это скриптовый язык, который "конкурирует" с JavaScript в качестве варианта внешнего скриптинга. Он основан на HyperTalk, языке сценариев для HyperCard, и имеет особенности, которые, на мой взгляд, делают его более удобным при создании сценариев на веб-странице. Например, среда выполнения Hyperscript автоматически разрешает встречающиеся Promises, поэтому авторам сценариев не нужно с ними возиться. У него естественный, англоподобный синтаксис, который некоторые любят, а многие ненавидят. Это определенно мой страстный проект, но я надеюсь довести его до версии 1.0 в этом году, после выхода HTMX 2.

Что касается его реализации, то да, он реализован на JavaScript как лексер, парсер и время выполнения на основе eval. Я был удивлен, что время выполнения JavaScript достаточно быстрое, чтобы позволить мне обойтись без этого, но это так. Я бы не стал пытаться реализовать майнер биткойнов на Hyperscript, но он достаточно быстр для легкого DOM-скриптинга. Парсер и среда выполнения Hyperscript находятся на границе сложности, которую я готов взять на себя при работе с JavaScript.

Тайсон: HTMX - это еще одна впечатляющая часть кодирования. Мое введение в HTMX было одной из самых читаемых статей на InfoWorld в прошлом году, что говорит о большом интересе к нему. Этот проект также кажется более серьезным, поскольку он, похоже, восстанавливает хотя бы возможность настоящей REST-архитектуры.

Гросс: Да, это был дикий год для HTMX. Для читателей, которые еще не слышали о нем, HTMX - это написанная мной библиотека JavaScript, которая позволяет добавлять атрибуты, очень похожие по духу на атрибуты href и action ссылок и форм в стандартном HTML. Используя эти атрибуты, вы можете вызывать AJAX-запросы, а затем заменять части DOM на HTML, которым отвечает сервер.

Тайсон: Я бы сказал, что HTMX расширяет словарный запас старого доброго HTML, чтобы охватить некоторые современные случаи использования, в частности AJAX. Это справедливое описание?

Гросс: Да, это хороший способ объяснить это. Я иногда говорю, что HTMX "завершает HTML как гипермедиа", поскольку позволяет любому элементу на странице отправить HTTP-запрос в ответ на событие, а затем поместить этот ответ в любое место DOM.

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

Тайсон: Должен сказать, что я думал, что знаю, что такое REST, но долгое время ошибался. Вы рассказываете о том, как это произошло, в своей статье "Как REST стал означать противоположное REST?

Не могли бы вы разъяснить читателям разницу между REST-как-намерение и REST-как-обычно-реализуется?

Гросс: *смеется* Ну, мы не меняем того, как индустрия использует термин REST. Сегодня этот термин означает "JSON APIs over HTTP" и, скорее всего, будет означать его до конца нашей карьеры.

Однако изначально REST означал не это. Напротив, REST - это описание того, как работала Всемирная паутина (ее сетевая архитектура) до появления JSON API; просто ссылки и формы, управляющие взаимодействием через браузер. Термин REST появился в знаменитой диссертации Роя Филдинга, в которой он определил ряд ограничений, которым должна соответствовать система RESTful.

Сегодня большинство JSON API, которые называют "RESTful", не удовлетворяют этим ограничениям. Еще более забавно, что простой статический веб-сайт с парой HTML-страниц, которые ссылаются друг на друга, удовлетворяет всем этим ограничениям. Таким образом, тот, кто создает простой статический веб-сайт, на каком-то уровне является лучшим "REST"-инженером, чем люди с причудливыми названиями "RESTful" JSON API-инженеров в своих резюме.

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

Тайсон: Я не был на занятиях по программированию с начала тысячелетия. Вы все еще пользуетесь книгами? Шучу. (Я думаю.)

Каково это - быть преподавателем программирования? Могу ли я взять у вас CSCI 468?

Гросс: Ха! Ну, если вы хотите взять 468, который является классом по компиляторам, который я преподаю, вы можете просто прочитать Crafting Interpreters Боба Нойстрома и получить около 50% от этого. Мы ориентируемся на JVM с байткодом на задней стороне, и, честно говоря, это не так уж интересно, если только вы не большой любитель Java.

Мне нравится преподавать. Есть, конечно, и минусы: зарплата отстойная, приходится иметь дело с бюрократией. Но есть и много плюсов, и мне нравится доводить студентов до того, что они чувствуют, что могут программировать самостоятельно.

Тайсон: Да, я определенно парень с Java.

Итак, мы немного возвращаемся к теме REST, но уже с другой стороны. Вы являетесь соавтором книги "Гипермедийные системы", в которой доказываете, что то, как устроен веб, обеспечивает архитектуру приложений, на которую мы можем опираться, если посмотрим на нее правильно.

Гросс: Определенно, и HTMX пытается опираться на эту сетевую архитектуру, улучшая HTML как гипермедиа, а не заменяя эту оригинальную архитектуру новой, а именно API данных JSON фиксированного формата. В книге я пытаюсь обрисовать системную природу правильно функционирующей гипермедиа. Например, долгое время я не понимал, насколько важен клиент гипермедиа (например, браузеры) для правильной работы единого интерфейса. На самом деле вам нужна целая система - гипермедиа, например HTML, сетевой протокол, например HTTP, гипермедиа-серверы и гипермедиа-клиенты, - чтобы все это работало так, как задумано.

Тайсон: В заключение я хотел бы подвести итог всему важному в нескольких коротких, забавных замечаниях, но вы уже сделали это. Я пытаюсь найти в философии Груга то, с чем я не согласен, но на самом деле не могу. Сложность выражений, закрытия, отказ... У Груга есть хорошие советы на все эти темы.

Но мне интересно, как Груг относится к шаблону visitor. Я использовал его и думал, что все прошло хорошо. В конце концов, проект не был отправлен, но код был надежным. Расскажите мне, что не так с шаблоном посетителя.

Гросс: Да, я не на 100% против паттерна посетителя, несмотря на то, что говорится в эссе grugbrain. (Вообще, в разработке программного обеспечения я ни за, ни против чего-либо на 100%.) Однако я часто думаю, что лучше кодировать операции непосредственно в дереве, чем иметь еще одну побочную штуку, выполняющую операции над деревом. Иногда это немного смешивает проблемы, но в данном случае я не возражаю против этого.

Например, в Hyperscript элементы дерева разбора имеют определенные для них методы eval и определяются непосредственно в том месте, где они разбираются. Это смешивает понятия, но я думаю, что это добавляет ясности программе, потому что, когда вы хотите понять, как, например, работает команда "wait", вы можете зайти в одно место и посмотреть, как она разбирается и оценивается. Я нахожу это очень полезным.

Тайсон: Почему мы знаем, что сложность вредна для нас, но все равно тянемся к ней?

Гросс: Ну, опять же, я думаю, что здесь играет роль давление индустрии. Программное обеспечение - это жестокая индустрия, и если показаться неинтеллектуальным, это может сильно навредить вашей карьере. Это означает, что все мы испытываем давление, стремясь продемонстрировать, что мы умны, а также не признавать, что чужой код запутан или кажется нам слишком сложным. Во многих кругах "сложный" - это похвала, а "тупой" - критика.

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