Кроссплатформенный фреймворк дает самый привлекательный опыт для веб-разработки.
Современные Web-сайты пишутся на HTML, JavaScript и CSS (и этот сайт в том числе). Наверно, вы сейчас прочитали это и подумали «да это же очевидно». А если я вам скажу, что можно написать сайт без использования этих трех технологий, у вас наверняка возникнут вопросы…
На протяжении истории на этом поле побывали разные игроки. Был Flash, был Silverlight - конкурирующие технологии, которые пытались отобрать кусок рынка у браузеров и не дать разработчику использовать другие технологии для создания сайта. Правда ни одна из них по-настоящему так и не взлетела. А что, если я вам скажу, что в этой сфере снова может появиться конкурент? И это несмотря на то, что буквально никто из других игроков так и не смог сдвинуться с места, невзирая на годы усилий.
Но давайте сначала отвлечемся чтобы понять, что общего было у всех этих попыток:
Для запуска нужен был плагин браузера. Обычно нужен был плагин браузера для запуска на соответствующей платформе. Хороший пример – Silverlight. В то время те, кто использовал Linux, не могли смотреть Netflix, так как сайту нужен был плагин Silverlight (который не был доступен для Linux). Конечно, были альтернативные, open source варианты, но среди них не было ничего стоящего.
Они представляли угрозу для системы безопасности. Flash был печально известен этим (более 1000 известных уязвимостей). Браузер обязательно должен был загрузить плагин для отображения содержимого, и в этот самый момент ни одна из гарантий безопасности браузера уже не имела значения, так как плагин имел полный доступ к хосту.
Производительность была не так хороша, как у чистового HTML. Зачем грузить плагин, чтобы отобразить в нем некоторый текст, если можно использовать чистый HTML и CSS, которые гораздо быстрее?
Появился HTML5, и CSS стал лучше. Внезапно создание чего-то прекрасного и захватывающего перестало быть невозможным. И, что еще лучше, браузеры, которые ненавидели стандарты, использовали странные хаки или специфичные для конкретного браузера реализации, вместо их CSS-эквивалентов (как например, Internet Explorer) были попросту уничтожены.
Все это сделало выбор в пользу создания новых веб-приложений на привычном HTML. В конце концов, если бы технология, которую вы использовали для создания вашего веб-приложения в итоге устарела и перестала получать обновления безопасности, то не было бы другого выхода, кроме как переписать ваше приложение с нуля на новом, поддерживаемом языке.
Но как мы пришли к этому? Как HTML стал основой веб-разработки в сегодняшнем процветающем веб-пространстве?
Рассвет новой эры
6 августа 1991 года Интернет стал доступен всему миру. Затем, пришел и ушел так называемый пузырь доткомов, Представьте себе, что Интернет для общего пользования появился только в 1991 году, а девять лет спустя лопнул пузырь доткомов, стоивший 1,7 триллиона долларов (это примерно 15% ВВП США на тот момент)!
Это было время, когда веб начинал становиться все более и более организованным, и способ, которым мы писали веб-сайты, становился все более стандартизированным. Со временем мы выработали стандарты, такие как HTML4, и эти стандарты гарантировали, что HTML, который вы пишете в одной части мира, будет работать для большинства, если не для всех, интерпретаторов HTML. Каскадные таблицы стилей (CSS) вошли в обращение в 1996 году, а годом ранее появился JavaScript. Можете ли вы представить себе, что видите или используете веб-сайт без JavaScript или CSS? Боюсь это произвело бы на вас не лучшее впечатление.
Но на протяжении всей истории определенные вещи в вебе оставались неизменными. Хотя, по правде говоря, многое должно было быть изменено. Но никто не захочет вносить существенные изменения в стандарт HTML без весомой на то причины. Поэтому изменения большей части того, как работает веб, не происходили и вероятнее всего не произойдут и в будущих версиях. В результате мы получаем веб в том виде, в каком он есть сегодня. Что же именно он в себя включает?
Документ
Когда Интернет только появился на свет, люди не использовали приложения, как это делают сегодня. Кто-то из вас, возможно, помнит программы-терминалы, которые, обеспечивали вам физическое соединение с сервером на другом конце. Эти «приложения» (если их можно так назвать) были лишь немного больше, чем просто строчками текста на экране (прим. переводчика: автор тут видимо имеет ввиду BBS доски и их аналоги). А так как люди привыкли иметь дело с документами, с реальными кусками бумаги в руках, которые они могут листать - неудивительно, что основой HTML-страниц является работа с HTML-документом. Если вы когда-либо использовали JavaScript, вы конечно знакомы с такими функциями, как document.getElementById(). Все, что вы делаете на веб-странице, заключается в создании, а затем преобразовании документа.
Традиционно большинство веб-страниц слишком длинные, чтобы поместиться в одну область просмотра. Таким образом, пользователю приходится пролистывать страницу пальцем или прокручивать ее с помощью мыши. Я не представляю себе современный веб-сайт, из тех, что я использую, который мог бы аккуратно вписываться в область просмотра пользователя. Поэтому разработчику можно гарантировать, что какая-то часть страницы будет либо выше, либо ниже текущего места просмотра.
Если же вы хотите, чтобы определенные части вашей веб-страницы оставались в нужном положении или выравнивались определенным образом, вы используете вещи типа position в CSS, чтобы контролировать расположение элементов. Существует множество свойств CSS (520, если точнее), и, как следует из названия, эти стили каскадируются в свои дочерние элементы. Когда вы попытаетесь заставить определенную часть вашего документа выглядеть так как вам нужно, высока вероятность того, что они станут довольно хаотичными. Если вы используете готовый CSS фреймворк, например, Angular Material, и начинаете переопределять встроенный CSS для достижения нужного вам внешнего вида, это тоже становится довольно «пикантным» занятием. CSS позволяет вам выполнить переопределение при помощи !override, однако, как только вы начнете это делать, вы уже практически проиграли битву. Если вы читаете это и думаете про себя: “Что? Да этот парень совершенно безнадежен в CSS:” ОК, я не буду с вами спорить. Но как только ваши дизайнеры начиняют гнаться за определенным внешним видом, ваш CSS может стать довольно сложным в понимании.
Изучение языков
Чтобы создать простой веб-сайт, вам необходимы три разных языка, и это только для самого сайта. Это HTML, JavaScript и CSS. А так как ваш сайт должен быть удобным и отлично выглядеть, этого не произойдет, если вы не знаете, как писать эффективный JavaScript или если ваши навыки в CSS оставляют желать лучшего.
Если вы действительно хотите, чтобы ваш сайт мог делать что угодно, вы можете использовать фреймворк типа Angular или React. Когда вы начнете добавлять пакеты через npm, размер вашего приложения начнет расти. Поэтому вы будете использовать сборщик, такой как webpack, чтобы связать все ваши пакеты вместе и соответствующим образом их минимизировать. Webpack сам по себе отдельная тема (при том огромная), но ее тоже стоит рассматривать, т.к. она играет свою не маловажную роль в создании веб-приложений.
Бандлинг и транспиляция
У вас есть веб-сайт и ваши пакеты, теперь вам нужно использовать bundler для объединения вашего приложения, а затем еще убедиться, что оно работает в нужных браузерах. В зависимости от того, какой браузер использует пользователь, вам потребуется “прокладка” для определенных функций, чтобы браузер пользователя мог отображать ваш сайт. Если вы используете такой язык, как TypeScript, webpack также преобразует его в JavaScript. В этом нет ничего плохого, но это все еще больше усложняет. Если ваш сайт ломается, возможно это вы накосячили в коде, минификация сломала его, webpack не собрал все должным образом или процесс транспиляции привел к проблеме? Все эти сложные конвейеры могут создать трудности при отладке или поиске основной причины проблем в вашем приложении.
Чем лучше Flutter?
Если вы слышали о Flutter, то, скорее всего, слышали о нем в контексте разработки мобильных приложений. Так какое отношение он имеет к веб-сайтам? С обычной HTML-страницей вы работаете как с документом. Во Flutter «страница» (или то, с чем взаимодействует пользователь) фактически рисуется на канве (canvas) HTML. Flutter фактически контролирует каждый пиксель, который рисуется на экране, и не использует HTML, JavaScript или CSS для определения его внешнего вида или логики. (Технически говоря, родной код Dart переносится на JavaScript через dart2js, но на самом деле никакая бизнес-логика не пишется на JavaScript.)
У вас наверно уже вызвали беспокойство две вещи. Во-первых, нет HTML. Во-вторых, мы все рисуем на канве. Я понимаю — это звучит странно и, по крайней мере, рисование непосредственно на канве, не очень производительно. Но давайте углубимся в этот вопрос.
Рисование на канве вместо работы с документом
Собственно, мы не используем HTML для написания наших веб-страниц и не пишем ничего в документ. На первый взгляд - полная чушь. Но что именно вы делаете, когда разрабатываете веб-страницу в HTML? Как мы уже говорили ранее в этой статье, вы создаете документ, который слишком велик для области просмотра устройства пользователя, его приходится скроллить. Это то, что вы сейчас видите на этой самой странице, высота документа больше, чем высота окна просмотра и вы прокручиваете содержимое.
Если задуматься об этом, разве это не странный способ проектирования пользовательского интерфейса, ожидать, что контент будет слишком большим по вертикали, и что пользователю придется прокручивать его? Что делать, если вы хотите, чтобы пользователь прокручивал страницу слева направо, а не сверху вниз? Это уже не так просто сделать на обычной веб-странице.
Во Flutter, если вы хотите сделать определенную часть контента горизонтально прокручиваемым, а не вертикально прокручиваемым, это так же просто, как сделать виджеты в SingleChildScrollView. Вы точно так же можете легко указать направление прокрутки, независимо от того, должна ли она прокручиваться по вертикальной или горизонтали оси.
Поскольку Flutter основан на концепции размещения отдельных виджетов, а не рисования документа на экране, разработчикам предоставляется больше контроля над тем, как именно они хотят компоновать свое приложение.
Использование одного языка
Как уже упоминалось ранее, для создания хорошего веб-сайта, требуются знания HTML, JavaScript и CSS. Это также означает, что ваши знания не переиспользуются между этими языками, и вы не можете повторно использовать какие-либо из ваших знаний, например в JavaScript для HTML. HTML — это язык разметки, CSS — синтаксис описания стилей, а JavaScript — язык программирования. Ни один из них не поддерживает, проверку типов, поэтому, например, ваш CSS может быть неработоспособным, когда пользователь попытается открыть вашу веб-страницу.
Flutter использует Dart в качестве языка. Весь внешний вид приложения и бизнес-логика написаны на нем. Dart поставляется со статической проверкой типов данных, и скоро появится null safety (прим. переводчика: уже появился), поэтому каждая строка кода в вашем приложении, будь то визуальное описание вашего приложения, придание ему стиля или управление бизнес-логикой вашего приложения, полностью типобезопасна.
Простая компоновка вашего приложения
Обычно мы используем наши веб-сайты для отображения данных из какого-то источника: база данных, API или что-то еще, от куда мы получаем данные, которые хотели бы отобразить. Представьте, что у нас есть массив объектов, которые возвращаются из нашего API, и вы используете, например, Angular для их отображения. Вы загружаете эти объекты во вспомогательный компонент, затем используете *ngFor для их итерации и вы скорее всего положите его в div. Но из коробки, для нестилизованного div, это будет выглядеть совсем просто. Вероятно, вы хотите, чтобы ваши элементы в этом списке отображались в столбце или строке, поэтому вам еще придется задействовать некоторые CSS или flexbox для этого.
С Flutter наоборот, вы размещаете дочерние элементы с помощью Column или Row, которые имеют свойство children, которое принимает массив объектов. При использовании этого свойства, вы можете записать ваши массивы в строку (элементы друг за другом) или в столбец (элементы друг под другом). С Flutter, вы можете быстрее получить визуальный макет, который вы хотите, прежде чем перейти к стилизации отдельных элементов в списке. По моему опыту это приводит к более быстрому скаффолдингу и прототипированию сайта без ущерба для конечного результата.
Контроль над каждым пикселем в области просмотра
Поскольку Flutter визуализирует каждый пиксель на экране, это дает дизайнерам и разработчикам большой контроль над тем, что именно они хотят видеть в приложении. Но рендеринг каждого пикселя на экране звучит как нечто, что будет сопровождаться большим ударом по производительности, и да, в наши дни — это, конечно, не так быстро, как рендеринг чистого HTML, но такие вещи, как канва с аппаратным (за счет GPU) ускорением, значительно повышают производительность в этой области. Традиционно проектируя веб-страницу в HTML, нужно учитывать различные браузеры, на которые вы ориентируетесь. Однако в случае с Flutter, если вы размещаете виджет Text с определенным шрифтом, он будет выглядеть одинаково, независимо от того, где он отображается, потому что Flutter контролирует, как этот конкретный виджет будет выглядеть на основе каждого пикселя.
Прощай, webpack!
Flutter использует Dart, поэтому приложение компилируется для своей целевой платформы, оно также переносит все зависимые пакеты (также написанные на Dart) в JavaScript. Dart — типобезопасный язык, который не поддерживает рефлексию, поэтому компилятор лучше понимает, что ваше приложение вызывает, а что нет. Это способствует лучшему tree-shaking (избавление от неиспользованного кода) и минификации вашего приложения. Flutter не нужен webpack для сборки приложения, что само по себе является довольно сильным аргументом в пользу Flutter (по крайней мере, на мой взгляд). В webpack нет ничего плохого; это высококачественный софт. Но это сложный инструмент и без того в сложном конвейере.
. . .
Но пока это все лишь теория
В вебе есть нечто большее чем отличные веб-страницы, великолепная анимация и прекрасный опыт взаимодействия с ними. Нам нужен серверный рендеринг (SSR), чтобы наши веб-страницы могли быть проиндексированы поисковыми системами для разных вариантов поисковой оптимизации (SEO). И на данный момент сайты Flutter интерпретируются только людьми, а не поисковыми системами, так что это оказывает огромное влияние на то, как люди ищут и находят информацию на вашем сайте (сообщество все еще работает над этим вопросом, но не похоже, что в ближайшем будущем будет найдено решение).
Рисование всего на канве также имеет свои последствия для производительности, но они не так плохи, как вы предполагаете. Я сделал тестовое приложение, которое интенсивно использует визуальные эффекты, и оно работает на моем MacBook со скоростью около 60 кадров в секунду. Даже когда вы тащите лист по экрану, оно все равно работает нормально, постепенно увеличивая размытие на изображении позади. Я ни в коем случае не специалист в Dart, так что, без сомнения, этот процесс можно было бы оптимизировать еще больше.
Таким образом, есть несколько ключевых областей, в которых Flutter необходимо улучшить, прежде чем люди станут рассматривать его в качестве основы для веб-разработки. Но задумайтесь: Flutter появился лишь 2 года назад, а производительность и набор функций, которые у него уже есть, просто невероятны.
Представьте, если бы вы могли сделать веб-сайт, который работает быстро, и вы бы могли использовать один язык для разработки, стилей и написания бизнес-логики для вашего веб-приложения? Если бы webpack стал не нужен для вашего конвейера разработки? А если бы со временем у вас был серверный рендеринг и все те SEO-блага, которые есть сегодня у традиционных HTML-сайтов?
Если бы Flutter уже обладал всем этим, он мог бы стать непобедимым в вебе.
От переводчика:
Совсем недавно (03.03.2021) Flutter web перешёл в stable ветку! В своем первом релизе Google в первую очередь сосредоточился на вопросах производительности и улучшении точности рендеринга. Более подробно о нововведениях и изменениях можно почитать тут
P.S. Догадываюсь, что эта статья может вызвать много споров и критики, особенно у web разработчиков. Действительно есть много подходов и готовых библиотек для решения описанных выше сложностей. Но я не могу не разделить с автором всех плюсов, которые потенциально дает Flutter, да и впечатляющая скорость, с которой он развивается и завоевывает рынок мобильной разработки тоже вселяет определенную уверенность в успехе его Web составляющей.
