Обзор 2023 года: могло бы быть, но не произошло

Мы давно пишем на TypeScript, но браузеру по-прежнему отдаём JavaScript. Почему бы не убрать этот промежуточный шаг? В конце 2023 года на YaTalks я спросил Глеба Михеева, хотел бы он получить нативную поддержку TypeScript. Он ответил: «Нет».

TypeScript нужен разработчику, а браузеру?

Для Глеба TypeScript прежде всего помогает анализировать код до его выполнения. Типы позволяют раньше находить ошибки, увереннее вносить изменения и меньше держать в голове. Польза появляется во время разработки. Из этого ещё не следует, что браузер должен научиться исполнять дополнительный язык.

Мария Просвирнина напомнила, что не так давно у TypeScript был заметный конкурент, Flow. Сейчас преимущество TypeScript кажется устойчивым, но браузеры принимают решения на гораздо больший срок. Осторожность их разработчиков может раздражать, зато защищает платформу от постоянной смены направлений. Лично ей поддержка TypeScript была бы удобна; вопрос в том, достаточно ли этого удобства для всей индустрии.

Я возражал: TypeScript уже занимает большую часть нашей повседневной работы, а его распространение продолжает расти. Возможно, JavaScript постепенно превращается для нас в промежуточный язык, который нужен инструментам, но который мы сами всё реже пишем.

Виталий Харисов не увидел здесь проблемы. Есть понятная среда выполнения, в которую можно преобразовать код из TypeScript, а завтра из другого языка. Зачем менять саму среду, если этот способ уже работает?

Алексей Охрименко вспомнил попытку продвинуть Dart в браузер. Добавлением поддержки синтаксиса такая работа не заканчивается: нужно приспособить инструменты разработчика, расширения и всё, что помогает человеку писать и отлаживать программы. Виталий добавил, что JavaScript при этом никуда не исчезнет. Новую поддержку придётся нести рядом со старой на самых разных устройствах, включая телефоны и телевизоры.

У TypeScript, по мнению Охрименко, есть аргументы в пользу долгой жизни. Microsoft старается следовать стандартам JavaScript, даже когда ради этого приходится менять собственные решения. Пример с декораторами как раз об этом. Есть и Deno, где запуск TypeScript стал частью обычного взаимодействия со средой. Правда, Виталий сразу разделил серверную среду и браузер: ограничения и цена поддержки у них разные.

Глеб всё время возвращал нас к вопросу: «Чтобы что?» Я предлагал упростить сборку и отладку, избавиться от необходимости разбираться с картами исходного кода. Он спрашивал, сколько мы выиграем и сколько потратим на реализацию.

Карты исходного кода уже позволяют видеть в инструментах разработчика тот TypeScript, который написал человек, хотя исполняется преобразованный JavaScript. Глеб считает это достаточным решением. Если позже появится другой удобный язык, можно будет поменять инструменты разработки, сохранив среду выполнения.

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

Нейросеть вместо разработчика или рядом с ним

Следующий вопрос мне регулярно задают начинающие: не поздно ли идти во фронтенд, если нейросети скоро будут писать весь код? Маша напомнила, что разговор о замене верстальщиков начался задолго до ChatGPT. Прошло несколько лет, а профессия осталась.

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

Сам Охрименко сразу оговорил условия: кто-то должен понимать желаемый результат и уметь достаточно точно поставить задачу. Пока запрос звучит как «хочу красиво», работы для человека остаётся много.

Маша допускает, что со временем нейросети научатся создавать и сложные приложения, но не ждёт мгновенного исчезновения профессии. Ей ближе постепенное изменение задач: разработчики будут меньше набирать код и больше объяснять инструментам, что требуется получить. Исследовательская работа и поиск нового решения тоже остаются отдельной частью профессии.

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

Помощник, которому можно отдать пять старых проектов

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

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

Вот здесь ему пригодился бы виртуальный опытный разработчик, сидящий рядом. Можно было бы передать ему код и объяснить, какие изменения нужны. Но Виталий не ожидает, что инструмент без участия человека придумает новый код для его текущих проектов: задачи слишком слабо формализованы, сначала их приходится исследовать и проверять предположения.

Я спросил, что в таком мире остаётся джунам. Если помощник хорошо решает рутинные задачи опытного разработчика, он, вероятно, справится и с частью работы новичка. Маша ответила, что учиться всё равно нужно. Переход, которого она ожидает, будет постепенным, и люди смогут осваивать новые задачи по мере его развития.

Что именно мы будем поручать компьютеру

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

Его особенно впечатлил собственный эксперимент. Он показал ChatGPT функцию, написанную девять лет назад, и попросил объяснить её. Ожидал пересказа отдельных действий, а получил определение: реализация мемоизации. Для Глеба это стало признаком того, что с инструментом уже можно обсуждать код на более высоком уровне.

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

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

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

Глеб напомнил, что мы уже постоянно отказываемся от ручной работы. Используем редакторы, фреймворки, компиляторы, автоматическую обработку стилей. Когда-то скруглённое окно собирали из таблиц и картинок. Сейчас можно вспоминать это с теплотой, но возвращать такую работу в каждый проект желающих немного.

Его ожидание состоит в том, что с ростом производительности усложняется продукт, а вместе с ним и работа людей. Когда-то один веб-мастер делал почти всё. Теперь вокруг разработки гораздо больше специализаций.

Опыт, которого нет в документации

В практической работе у Охрименко есть ограничение, которое не связано с качеством модели: закрытый код нельзя без разрешения отправлять во внешний сервис. Иногда можно попросить нейросеть написать универсальный скрипт, а затем применить его к своим данным локально. Так задача получает помощь инструмента без передачи самой кодовой базы.

Для новичков он видит ценность в опыте, который трудно получить из общих материалов. В качестве примера приводит разработку для телевизоров. На отдельной модели может не отвечать fetch, хотя по документации такого поведения никто не ожидает. Чтобы разобраться, придётся исследовать реальное устройство и накопить знание, которого пока нет в готовом ответе.

Маша заметила обратную сторону: с очень узкой специализацией может быть сложно найти следующую работу именно по этому профилю. Охрименко согласился. Уникальный опыт ценен, но его узость не перестаёт быть ограничением.

Из чата пришёл вопрос о другой границе. Виталий знает, что хочет изменить в проекте. А если человек ещё не разобрался в коде и не умеет даже сформулировать вопрос?

Охрименко напомнил о галлюцинациях. Модель может уверенно отвечать на бессмысленный запрос и придумывать детали, вместо того чтобы остановиться. В разговоре он привёл пример выдуманного медицинского метода, для которого ChatGPT сочинил подробную процедуру. Смысл примера в том, что уверенный тон ответа ничего не доказывает. Опыт нужен и для постановки задачи, и для проверки того, что вернул инструмент.

Можно ли прийти на собеседование с ChatGPT

Я предложил участникам представить себя нанимающими руководителями. Приходит джун и сразу говорит, что будет отвечать на вопросы вместе с ChatGPT. Готовы ли они взять такого человека?

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

Виталий сравнил ситуацию с использованием Stack Overflow. Разработчики и раньше искали готовые решения. Однако он считает, что на собеседовании всё равно нужны способы проверить навыки самого человека, а для разных сторон работы можно сделать отдельные секции.

Глеб возразил против проверки навыков, которые не нужны на будущей работе. Человек может отлично решать алгоритмические упражнения, но не уметь собрать базовый проект или организовать компоненты. Если в работе нужно что-то делать без помощи модели, это можно отдельно проверить. Для другой части задач инструмент можно разрешить.

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

Я довёл этот аргумент до следующего вопроса. Если компания делает типовые посадочные страницы и сотрудник собирает их с помощью модели, когда бизнес попробует исключить из процесса и самого сотрудника? Глеб отвечает: когда это станет возможно. Сохранять медленную ручную работу только ради её ручного характера он не видит смысла. Исключением может быть продукт, в котором именно ручная работа и составляет ценность для покупателя.

Чужой сервис получает наш код

Чем больше задач мы отдаём помощнику, тем больше контекста ему хочется показать. Отдельная функция мало что объясняет; целый проект даёт гораздо больше возможностей. Но вместе с удобством возникает вопрос, что именно компания передаёт наружу.

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

Охрименко снова вернулся к риску передачи закрытого кода. Даже если большой прогноз о замене компаний не сбудется, сведения о конкретном проекте уже могут оказаться там, куда их не собирались отдавать.

Глеб при этом не предлагает отвергать технологию целиком. Ему важнее научиться применять её так, чтобы разработчик и компания получали пользу.

Другие движки на iOS: больше выбора или ещё больше Chrome

Виталий ждёт настоящий Firefox на iOS, со своим движком. Для Охрименко личный интерес связан с WebGPU: ему нужны возможности, которые уже появляются в Chrome и которых он не получает в Safari. Он надеется, что допуск других движков увеличит вероятность появления этих возможностей на устройствах Apple.

При этом сам Охрименко видит ограничение. Платформа может разрешить дополнительный движок, но не дать ему доступ к нужным системным API. Формальная возможность установить браузер ещё не гарантирует равные условия.

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

Я спорю с предположением, что Apple совсем не заинтересована в развитии веба. Safari участвует в Interop и вместе с остальными браузерами улучшает совместимость выбранных возможностей. Виталий уточняет: интерес к развитию есть, но компания может выбирать прежде всего удобное для себя направление. Конкуренция должна заставлять её учитывать и другие потребности.

Мы расходимся ещё и в том, где проводить границу рынка. Если смотреть только на iOS, у пользователя нет выбора движка. Если смотреть на мобильный веб целиком, Chrome уже значительно крупнее Safari. Я опасаюсь, что расширение доступа Google усилит крупнейшего игрока, а не добавит разнообразия.

Маша поддерживает этот вопрос. Исключительное положение внутри собственной платформы и доминирование во всей индустрии для неё разные вещи. Глеб отвечает, что условия входа всё равно нужно создавать: без них потенциальный конкурент вообще не сможет попробовать. Для него свобода такого входа важнее текущего распределения долей.

Как разработчику влиять на платформу

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

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

Охрименко согласен с пользой Interop, но считает, что конкуренция отдельных реализаций тоже имеет значение. Он приводит position: sticky как пример возможности, в развитии которой один браузер, по его мнению, подтолкнул остальные.

Маша спрашивает, как именно техническое преимущество превратилось в рыночное давление. Пользователь не обязательно меняет браузер ради отдельного CSS-свойства. Если бы набор возможностей сам по себе определял популярность, у Firefox, возможно, была бы большая доля.

Охрименко всё равно верит, что будут появляться функции, ради которых люди выберут другой браузер. На этом мы остаёмся с разными ожиданиями. Он хочет WebGPU во всех браузерах, чтобы запускать больше нейросетей. Виталий по-прежнему ждёт Firefox на iOS. Маша надеется на более широкое применение веб-компонентов, а Глеб хочет развития архитектурных практик: приложения усложняются, и нам нужно уметь с ними работать.