Сложность плохая: интервью с создателем 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 автоматически разрешает встреченные обещания, поэтому авторам сценариев не нужно с ними иметь дело. Он имеет естественный, похожий на английский синтаксис, который некоторые любят, а многие ненавидят. Это определенно мой страстный проект, но я надеюсь довести его до версии 1.0 в этом году, после выхода HTMX 2.

Что касается его реализации, да, он реализован в JavaScript как среда выполнения, основанная на лексере, синтаксическом анализаторе и оценке. Я был удивлен, что среда выполнения 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 API через HTTP», и, вероятно, именно это он будет означать до конца нашей карьеры.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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