Лучшая платформа для разработки приложений в 2019 году — это не один из основных фреймворков, а платформа. «Платформа» — это набор нативных технологий, доступных в браузерах. И они, наконец, подошли к тому, чтобы разрушить устоявшиеся рамки.
Это не значит, что в 2019 году вы увидите значительный рост числа приложений, разрабатываемых без Angular/React/Vue (или какой-то еще малоизвестной среды). Это займет еще некоторое время. Технология платформы есть, но для того, чтобы она набрала обороты, требуется больше.
Сначала сообществу веб-разработчиков необходимо выяснить, как наилучшим образом использовать эту технологию. Я думаю, что нынешние подходы ошибочны из-за очень вводящей в заблуждение истории. Давайте посмотрим на это, хорошо?
Немного истории — вы можете пропустить этот раздел, если вам все равно
1989 Тим Бернерс Ли (тогда Тим, а теперь сэр Тим) придумал, как связывать тексты. Его работа была технически выдающейся по своему видению и гибкости. Но запутанная история веб-разработки началась с него. Например, он придумал несколько специальных стандартных тегов, которые позже были частично отозваны. Затем последовали войны браузеров, когда каждый поставщик браузера создавал стандарты так, как они считали нужным, чтобы навредить конкурентам. После того, как Microsoft использовала свою монополию на настольные компьютеры, чтобы уничтожить конкурентов, наступила темная эра веб-разработки. Microsoft просчиталась с потенциалом Интернета, высмеивая его перед бумом доткомов, и поэтому отправила своего темного лорда IE, чтобы терроризировать веб-разработчиков, чтобы они не выполняли обещания Интернета.
К тому времени веб-разработка была ужасным бизнесом. IE был безусловно номером один, но были и другие, которые должны были работать. А IE был заведомо несовместимым куском дерьма. Появился jQuery. Эта библиотека представляет собой хороший набор синтаксического сахара для ускорения работы. Но самое главное, это был уровень совместимости, который позволял разработчикам действительно делать что-то для изменения, вместо того, чтобы обходить множество ошибок и несовместимостей IE.
И мир (веб-разработки) никогда не был прежним. В то же время появилось несколько других фреймворков, но ни один из них не получил сравнимой популярности. Таким образом, jQuery стал де-факто языком общения в веб-разработке. До того как.
Google, наконец, было достаточно. Как компании, живущей в Интернете, они окончательно устали от недоброжелательности или некомпетентности Microsoft, а также от неспособности проекта Mozilla обеспечить высокую производительность. И поэтому Google разработал свой собственный браузер Chrome, который завоевал мир, почти потопив Firefox, который только что украл корону у IE.
После того, как Microsoft тоже проиграла — по правде говоря, бесконечную — войну браузеров, они, наконец, увидели свет и сделали IE несколько совместимым. Примерно в то же время HTML5 тоже стал стандартом, а jQuery все еще была крутой утилитой, но ее убийца совместимости потерял свою привлекательность. Это также был набор инструментов, разработанный для того, чтобы вдохнуть жизнь в веб-страницы, с анимацией здесь и некоторыми крутыми изменениями цвета там. Он никогда не предназначался для создания сложных веб-приложений, которые начали появляться примерно в то время.
Таким образом, jQuery стал устаревшим в отношении общей картины. Сегодня многие крупные сайты используют jQuery, но если вы хотите создать приложение, вы ищете что-то другое. jQuery, тем не менее, добился одного: он воспитал целое поколение веб-разработчиков в полном осознании неоспоримого факта, что вам нужен слой абстракции между вами и браузером, если вы хотите разрабатывать для Интернета.
Появился Angular, следующий верховный правитель веб-разработки. Angular сделал две вещи: он установил структуру для веб-проектов, которой раньше не было. Если вы разрабатываете сложное приложение с несколькими разработчиками, структура — это ключевой вопрос, который вам необходимо решить правильно. Веб-разработчики, будучи в среднем веб-дизайнерами, которые в какой-то момент изучили кодирование, как правило, испытывают недостаток в таких вещах. Это вполне может быть главным фактором успеха Angular.
Но Angular также сделал кое-что еще: он установил идиому смешивания JavaScript и разметки, вариант которой сегодня используется всеми актуальными фреймворками, а также большинством нерелевантных. Таким образом, он смешал два совершенно разных мира в один: разметка — это HTML, он говорит: «Это заголовок: Foo; а это текст после заголовка: Bar». Это декларативный язык, он объявляет, что есть вещи. JavaScript — императивный язык, императивный, потому что он управляет браузером с каждым высказыванием: «Возьмите этот заголовок! Сделай его зеленым!». Каждое предложение императив.
Теперь Angular позволяет вам сказать: «Хорошо, это заголовок, я скажу вам позже, что там происходит, но если он зеленый, я хочу, чтобы его не было». Веб-разработчики любят такие вещи. Это дает нам много сил. И что делают веб-дизайнеры, изучившие программирование с большой силой? Используй это. Но прости им, ибо не ведают, что творят.
Это не высокомерие, а смирение. Я программирую (начиная с rough boy C) уже около 20 лет, и я, конечно, не знаю, что делаю, когда пишу: «Хорошо, это заголовок, я расскажу вам позже, что там происходит, но если он зеленый, я хочу, чтобы его не было». Дело в том, что каждый из этих фреймворков размером с небольшую (Vue) или большую (Angular) книгу. Когда я пишу это предложение, они создают неполный виртуальный HTML-документ, а затем проезжают через него на «Феррари». Когда вглядываешься в происходящее, сразу начинает кружиться голова — отчасти это уже было с jQuery, и дальше точно не полегчало.
Конец истории
Итак, платформа спешит на помощь! облом. Сегодня существует несколько фреймворков, которые пытаются облегчить использование платформы. И что делает каждый из них? Справа: «Хорошо, это заголовок, я расскажу вам позже, что там происходит, но если он зеленый, я хочу, чтобы его не было» (если вы пропустили раздел истории: это смешивание HTML и JavaScript / декларативный и императивный язык ). Из-за того, что подавляющее большинство практически каждого фреймворка говорит нам об этом, возможно, так оно и будет.
Если это так, вам придется подождать еще пару лет, прежде чем вы избавитесь от привязки к поставщику и преуспеете на платформе. Потому что каждая такая структура имеет свою специфическую идиому приклеивания императивного мира к декларативному. И получение канонического, поддерживаемого браузером способа произнесения таких вещей заняло бы очень много времени. Если это вообще произойдет, т. В конце концов, Конец Истории может быть не близок.
Интермеццо
Так что эта рандомная статья сузилась до взаимодействия императивного и декларативного. Это всего лишь один из аспектов разработки приложений, хотя именно на него веб-разработчики тратят больше всего времени. Я упомянул главное преимущество Angular: структуру проекта. Вам это нужно. Но для этого вам не нужен веб-фреймворк.
Это одна из вещей, которую необходимо выяснить сообществу веб-разработчиков: какова каноническая структура проекта? На это будет более одного ответа, но все становится очевидным: когда у вас большой проект, вам, вероятно, лучше управлять состоянием приложения отдельно от рендеринга. Redux, возможно, не является окончательным словом в этом вопросе, но общая архитектура, которую он навязывает, скорее всего, останется. Если у вас небольшой проект, вам может сойти с рук двусторонняя привязка.
Нужна ли нам цепочка сборки? Если нет, нам все еще нужен канонический способ сообщить серверу, что отправлять со страницей через http/2. Инструменты сборки уже являются независимыми объектами, хотя каждый фреймворк включает в себя один из них. То же самое касается управления пакетами.
Таких вопросов еще много. И, надеюсь, в будущем у каждого проекта будет своя комбинация ответов, вместо того, чтобы быть запертым в одном из нескольких фреймворков с одним набором ответов для каждого мира.
Тем не менее, есть еще одна вещь, которая становится совершенно очевидной, более чем любая другая: вы организуете свои представления в композицию компонентов. Крошечный компонент может быть меткой, простой кнопкой, вводом. И компонент следующего уровня, например. форма, может быть композицией первых трех. Это одна вещь, с которой соглашаются все соответствующие фреймворки, даже самые нерелевантные, и платформа. Что возвращает нас к вопросу о том, как императивное и декларативное взаимодействие взаимодействуют в компонентах.
Продолжение
Если вы совершенно уверены, что бросите их в котел и хорошенько перемешаете, вы можете выбрать крошечный рендер-помощник, такой как lit-html, трафарет… нужно посмотреть, что получится через несколько лет. Ну, может быть, вы пока придерживаетесь Angular/React/Vue. Тем не менее, я здесь, чтобы сказать вам, что, хотя смешивание объектно-ориентированного, функционального и процедурного совершенно нормально, смешивание декларативного и императивного может быть не так.
Декларативные и императивные языки — это инструменты, величие которых трудно переоценить. Императив дал нам весь ИТ-мир, который у нас есть сегодня, а декларативный подход строит сеть поверх него, помимо прочего. Но смешивать их — это то, к чему я начинаю относиться скептически. Я делал это в течение нескольких лет, и у меня растут сомнения по этому поводу.
Для начинающих
Во-первых, в старые времена мы помещали наши обработчики событий прямо в HTML: «Это заголовок, и если пользователь щелкнет по нему, вызовите этот JavaScript». Эта практика оказалась плохой, и сегодня ее повсеместно осуждают. Вместо этого вы говорите: «Это название». И в своем JavaScript вы говорите: «Дайте мне этот заголовок! Спасибо, если кто-то кликнет, позвоните мне!».
Причина такого изменения отношения в том, что заголовок может быть интересен разным частям кода. И если вы смешиваете объявление и привязку с императивным кодом, части последнего начинают наступать друг другу на пятки. Смешение миров нарушает главный принцип информатики: разделение задач.
Почему в наши дни всем сходит с рук это нарушение? Потому что компоненты. Компоненты разделяют весь код по определенной оси. Каждый компонент владеет своим шаблоном и может быть уверен, что никто другой не будет с ним связываться.
Так все хорошо? Я думаю, если вы готовы ограничить себя очень ограниченным способом ведения дел, то да. Это хорошо. Действительно, это ограничение, вероятно, является еще одним преимуществом Angular и того, что последовало за ним. Я упомянул веб-дизайнера, который в какой-то момент изучил программирование.
В наши дни веб-разработчики, вероятно, являются самой большой подгруппой разработчиков на планете. И качество веб-разработчиков имеет очень широкий диапазон: много людей колеблются, и довольно мало высококвалифицированных дизайнеров программного обеспечения.
В такой среде ограничение вариантов является большим плюсом. Вы даете своему разработчику карту, рисуете красную линию и говорите ему: «Следуй по этому маршруту, в конце ты найдешь мое приложение». Это оставляет меньше шансов на провал, чем сказать ему: найди мое приложение, твой предел — небо. И это оставляет позади раздутые, дрянно работающие веб-приложения с небольшим количеством повторно используемого кода — изобилие повторно используемого материала обычно делается опытными людьми (часто вне проектов) и едва ли понятно среднему разработчику. Он не оставляет места для великих свершений.
А основные фреймворки превратились в очень сложных устрашающих зверей. Все отчаянно ищут достаточно приличных разработчиков Angular/React/Vue. Мы наложили массу сложностей на разочаровывающе сложную веб-платформу, мы создали множество диалектов для работы в Интернете, разделив и без того недостаточную базу разработчиков на несколько сегментов.
В конечном счете, было бы неплохо иметь хороших разработчиков вместо того, чтобы баловать плохих разработчиков, чтобы они едва выполняли свою работу. Мы не упрощаем задачу стать хорошим специалистом в веб-разработке, сегментируя предметную область.
Искусство программирования
Искусство программирования заключается в нескольких областях: разделить сложную проблему на несколько простых решений. Сделайте эти решения многоразовыми. Сделайте их элегантными и эффективными. Смешивание шаблона и кода (я устал от (decl. & imp. :-)) не соответствует нескольким из этих пунктов.
Очень сложно написать эффективный код, если вы не знаете, что именно вы говорите браузеру делать. Как я указал выше, это почти невозможно понять, если вы используете какую-то виртуальную среду DOM, которая использует динамический шаблон для визуализации вашего представления. Когда вы, таким образом, попадаете в ловушку производительности, это очень трудно обнаружить, потому что вся производительность теряется во фреймворке, а не в вашем коде, где это было бы тривиально найти с помощью профилировщика. Повторное использование шаблонов также вряд ли возможно, когда вы смешиваете их со своим кодом, и повторное использование кода наоборот так же сложно по тем же причинам.
Из списка, который я привел в качестве своего специального определения искусства программирования, вам остается разбить вашу проблему на несколько избыточный набор простых и элегантных решений, которые можно повторно использовать только на уровне компонентов — если вообще можно. Страдают повторное использование и эффективность. Элегантность ограничивается очень ограниченным подмножеством возможной красоты. То, что выглядит просто и элегантно в небольших демонстрациях, в больших проектах выглядит бесполезно и неэффективно, потому что оптимизация сложна, когда вы не знаете, что происходит, и каждому компоненту трудно поделиться с другими.
Но больше всего меня отталкивает то, что я не совсем понимаю, что делаю, когда использую такие системы. Это кажется простым и интуитивно понятным, когда вы смотрите на него, и сопоставление динамического шаблона с результатом действительно довольно простое и интуитивно понятное. Но знать, что происходит между ними, почти невозможно.
Я сталкивался с несколькими случаями, когда мне нужно было что-то оптимизировать, и каждый раз это был момент, когда мне приходилось оставлять фреймворк позади и прибегать к «старому способу» ведения дел. Итак, если мне все равно нужно знать стандартный способ, чтобы выполнять свою работу, зачем вообще использовать другой способ? Потому что я могу сделать больше с меньшими усилиями? Я думал, что. Но, к своему удивлению, я обнаружил, что ошибался.
Платформа спешит на помощь!
Я реализовал небольшой (1,5 тыс. строк кода) частный проект и хотел посмотреть, как далеко я продвинусь, просто используя платформенные технологии. Я не зашел так далеко и попробовал наименее инвазивную вещь, которую только мог придумать, небольшую библиотеку шаблонов (lit-html). Когда я закончил, я был счастлив, но не полностью. Производительность была меньше, чем я надеялся, и мне не нравился lit-html, навязывающий свой собственный синтаксис смешивания кода и шаблона. Так что я начал свой собственный материал, и, поскольку у меня были мучительные сомнения относительно динамических шаблонов, и я был слишком ленив, чтобы решать такие проблемы, я разделил миры.
Всего через 200 строк императивов у меня было все, что мне нужно, чтобы двигаться дальше. Производительность значительно возросла, а занимаемая площадь снизилась до беспрецедентного уровня. Все мое приложение имело около 50 тыс. или около того, включая графику (SVG). И мне даже нужно было немного меньше кода в моем приложении, а не больше, как я ожидал. Затем я провел рефакторинг кода библиотеки, чтобы сделать его по-настоящему унифицированным и пригодным для повторного использования. Для этого я написал демонстрацию производительности (dbmonster), которая входит в число лучших среди всех подобных демонстраций (их много, включая все основные фреймворки… которые все на 30% отстают от вершины). И это при размере менее 10 000, 100 строк кода плюс шаблоны. Если интересно, загляните на проект: https://github.com/schrotie/shadow-query
Однако дело здесь не в этой крошечной библиотеке. Дело в том, что для того, чтобы сейчас писать приложения только для платформы, которые имеют отличную структуру, хорошо читаемый код и выдающуюся производительность, вам не нужны фреймворки. Вам просто нужен крошечный набор помощников — для этого пока не существует хорошего стандарта. Однако вы можете освободить себя от идеи динамических шаблонов. И лучше знать, что делаешь :-)
