Я написал своё первое одностраничное веб-приложение на Javascript в 2005 году, сразу после того, как узнал о XMLHttpRequest и до появления серьёзных фреймворков. Я оставил профессиональную веб-разработку примерно в 2009 году (а начал её в 1997 году с WebObjects), а последний десяток лет своей карьеры занимался мобильными.
Сегодня я смотрю на мир веб-разработки, и меня поражает его безумие. Существует так много фреймворков для веба, и каждый день появляются новые. Для создания веб-приложения (в отличие от веб-сайта, например, моего сайта про искусство, который сгенерирован статически и содержит лишь немного Javascript), часто требуются кучи инструментов и технологий, часто меняющихся с большой частотой и содержащих бесконечные объёмы других технологий, о существовании которых мы и не подозреваем (о, смотрите-ка, в папке пакета две тысячи файлов).
Javascript — ужасный язык, никогда не задумывавшийся для чего-то подобного, но, как ни странно, ставший популярным, потому что он всегда был под рукой. Потрясающе, какой объём инноваций затрачен на построение современной вселенной веб-разработки, несмотря на достаточно шаткий фундамент, на котором она основана.
На моей первой работе мобильного разработчика в туристической онлайн-компании (к сожалению, теперь это лишь бренд) команда веб-разработчиков выбирала веб-фреймворки для нового мобильного веб-приложения (для съёма номеров в отелях/покупки авиабилетов/аренды автомобилей). В конце концов она выбрала то, что, по её мнению, подойдёт лучше всего. Однако год спустя этот опенсорсный фреймворк был практически заброшен; к счастью, это было уже не важно, потому что наш бренд продали, а все технологии и сама компания исчезли.
Сегодня я даже не могу представить, из какого количества вариантов нужно выбирать, а ведь постоянно появляются новые. Некоторые из них представляют целые экосистемы, а часто после выбора смена технологии становится невозможной — компания вложила в неё слишком много средств. Вы как программист оказываетесь привязанным к одной, а переход на другую может стать сложным, потому что работодателям часто нужен человек с опытом в выбранной экосистеме. Однако специализация на одной технологии может усложнить карьеру, потому что технология может устареть или даже оказаться заброшенной.
Я помню первые два разработанных мной одностраничных приложения; это было интересно, а для их создания не требовалось почти ничего, кроме текстового редактора и браузера (для получения данных потребовался небольшой фреймворк маршалинга и немного кода на Java). Комиссия по архитектуре, в которой я состоял, пожаловалась на то, что я задействовал какую-то неодобренную ею технологию, поэтому мне пришлось показать ей, что это просто браузер и Javascript. Моим клиентам (приложение было только для внутреннего пользования) понравилось, что можно было быстро искать информацию, как будто это десктопное приложение, а не постоянно перезагружать страницу. Разумеется, это было не такое огромное приложение, как Gmail.
Сегодня если вы не крошечная команда, разрабатывающая мелкие приложения, то вы вкладываетесь в выбор экосистемы наподобие React, Angular и Vue, или комбинируете мелкие фреймворки с другими инструментами для развёртывания собственного окружения. Вам нужно заботиться о фреймворках CSS, упаковщиках/сборщиках ассетов и о множестве других опенсорсных фреймворков и утилит, изготовленных на основе нескольких слоёв ещё большего множества опенсорсных технологий. А после этого вам нужно постоянно всё обновлять, избегая несовместимостей и дыр в безопасности.
Какой же морокой должно быть всё это. Зато есть гарантии работы!
Когда я начинал в 80-х, программирование было гораздо более прямолинейным — тебе нужно было знать язык программирования, операционную систему и то, что тебе сказали создать, а всё остальное нужно было изобретать самостоятельно! Помню, как важно было для Trapeze (приложение для работы с электронными таблицами, которое мы выпустили в январе 1987 года), что мы получили от друга с доступом к Unix копию Lex и Yacc, позволившую нам создать парсер формул.
Сегодня почти всё необходимое нам выложено где-нибудь в опенсорсном виде. Однако эти технологии могут терять поддержку, страдать от неизвестных багов и оказываться несовместимыми с другими нужными тебе опенсорсными технологиями.
В последнем крупном проекте, выпущенном на моей предыдущей работе, не было опенсорсных элементов; его писали на чистом Swift. Нашему юридическому отделу было сложно угодить, и оказалось проще самостоятельно создать всё с нуля, чем иметь дело с ним.
Я не хочу сказать, что в современных экосистемах веб-фреймворков нельзя создавать и поддерживать сложные системы. Однако это может быть не особо увлекательно, и сейчас я задумываюсь, как будут эволюционировать приложения, учитывая постоянное изменение их экосистем. Кто-то до сих пор использует и поддерживает программы на Cobol, которые едва ли не старше меня, так что возможно всё. Любопытно, сможет ли когда-то ИИ взять на себя работу с постоянной каруселью бесконечных слоёв веб-окружений, или он не справится и этим придётся заниматься людям?
Программирование всегда менялось, а к изменениям сложно адаптироваться. Я всегда специализировался в создании нового, а не в поддержке старого, часто в компаниях или отраслях, где новые рынки или технологии требуют новых приложений. Я не помню, чтобы когда-либо имел дело с таким количеством новых технологий, которые постоянно развиваются, и постоянно приходится представлять, в какой ситуации они окажутся в следующем году, не говоря уже о следующем десятилетии.
Важной проблемой сегодня стала безопасность, которая в первой половине моей карьеры была неактуальной. Кому-то приходится заниматься всем этим и принимать решения, которые не должны вызвать проблем, возможно, несколько лет спустя. Как долго написанное вами сегодня приложение проживёт с тем же исходным кодом и в том же фреймворке, который вы выбрали изначально?
Приложение Deltagraph, которое я начал разрабатывать в 1988 году, жило с одним и тем же кодом тридцать лет (моя команда работала над ним только пять лет), прежде чем пандемия не убила последнюю компанию, которая его продавала. В конечном итоге, оно больше не может запускаться в MacOS, поскольку исходный код на C, которому уже четверть века, невозможно апгрейднуть до 64 битов. Я и представления не имел в 1988 году, что принятые тогда мной решения повлияют на кого-то тремя десятками лет позже. Основное веб-приложение моего последнего работодателя было сплавом такого количества технологий, что когда я впервые увидел его, разобраться в нём оказалось очень трудно.
Интересно, какая часть современных веб-приложений постепенно превратится в кучи доисторических отложений? Разработчики ненавидят переписывать крупные системы, но затраты на поддержку неподдерживаемого постепенно становятся слишком высокими (об этом я скоро напишу ещё один пост). Я задаюсь вопросом, разрушится ли рано или поздно эта огромная гора постоянно меняющихся технологий, на основе которой построены веб-приложения.
Возможно, рано или поздно ИИ возьмёт на себя эту ношу, позволив программистам заниматься только важными задачами. Но я настроен скептически; когда-нибудь это может произойти, но не думаю, что в ближайшем времени ИИ сможет самостоятельно писать сложные приложения.
Программирование для создания искусства похоже для меня на возврат в 1980-е. Я практически не пользуюсь опенсорсными пакетами, за исключением математических библиотек Swift, а основную часть кода, который я пишу, вы не найдёте больше нигде. За исключением релизов версий XCode и Swift, я по большей мере изолирован от серьёзных изменений.
Больше всего меня раздражает добавление новых возможностей к генератору сайта и самому сайту, только там я вижу признаки сложности в поддержании актуальности, но это не является моей повседневной работой. Я не завидую современным веб-разработчикам, им приходится быть в курсе постоянных изменений и эволюции, проблем безопасности и ситуаций наподобие бомбы left-pad. Даже работа с Github становится раздражающим процессом.
Сколько веб-фреймворков существует на данный момент? Вы не сможете ответить, ведь их количество только что снова увеличилось!
Автор:
nmgtech
