flutter

Flutter скоро победит веб

Кросс-платформенный фреймворк предлагает самый привлекательный опыт веб-разработки.

Веб-сайты сегодня, включая тот, на котором вы сейчас, написаны на HTML, JavaScript и CSS. Вы, наверное, читаете это и думаете про себя: ну да, это совершенно очевидно. Если бы я сказал вам создать веб-сайт без использования какой-либо из этих трех технологий, у вас, вероятно, возникли бы некоторые вопросы.
И все же на протяжении всей истории у нас было много игроков в этой нише. У нас был Flash, у нас был Silverlight, все конкурирующие технологии, которые пытались захватить кусок рынка браузеров, чтобы позволить разработчику использовать другую технологию для создания веб-сайта. Но ни один из них так и не взлетел. Так как же это возможно, что я говорю вам, дорогой читатель, будто в этой нише появился конкурент? Особенно после того, как буквально никто из других игроков в этом пространстве никуда не ушел, несмотря на годы усилий?
Что ж, давайте уделим минуту тому, чтобы оценить то, что было общего у этих прошлых попыток, а именно:
1. Для запуска им нужен был плагин для браузера. Обычно для работы на целевой платформе им нужен специфичный для платформы браузерный плагин. Silverlight — хороший пример этого-в то время люди, использующие Linux, не могли смотреть Netflix, так как сайт зависел от Silverlight (который не был доступен для Linux). Конечно, были альтернативы с открытым исходным кодом, но ничего первоклассного.
2. Они ввели уязвимости в системе безопасности. Flash был печально известен этим (с более чем 1000 известными уязвимостями). Браузер должен был бы загрузить плагин для отображения содержимого, и в этот момент ни одна из мер безопасности браузера не имела значения, поскольку плагин имел полный доступ к главному компьютеру.
3. Производительность была не так хороша, как чистый HTML. С точки зрения того, было ли быстрее загрузить плагин и отобразить некоторый текст, всегда было быстрее просто сделать это в необработанном HTML и CSS, а не пытаться загрузить плагин для отображения некоторого контента для вас.
4. Появился HTML5, и CSS улучшился. Внезапно создание прекрасного, захватывающего опыта стало возможным. Более того, браузеры, которые ненавидели стандарты, использовали странные хаки или использовали конкретные реализации поставщиков вместо своих CSS-эквивалентов (например, Internet Explorer), были убиты.
Все это сделало выбор в пользу создания нового веб-приложения на родном HTML-языке простым. В конце концов, если технология, которую вы использовали для создания своего веб-опыта, устарела и перестала получать исправления безопасности, тогда не было бы другого выбора, кроме как переписать ваше приложение с нуля на новый, поддерживаемый язык. Но как мы вообще сюда попали? Как HTML стал такой оплотом в современном процветающем Интернете?

Фото Joshua Sortino на Unsplash

Рассвет новой эры

6 августа 1991 года интернет стал доступен всему миру. Затем, в конце концов, возник так называемый пузырь доткомов. Представьте себе на мгновение, что интернет появился для общественного пользования только в 1991 году, а затем девять лет спустя лопнул пузырь доткомов, стоивший ошеломляющие 1,7 триллиона долларов. Это означает, что пузырь доткомов стоил примерно 15% ВВП Соединенных Штатов в том же году.
Мы находимся в этой части истории, потому что это было время, когда интернет начинал становиться все более и более формальным, а способы написания веб-сайтов становились все более стандартизированными. Со временем мы получили стандарты, такие как HTML4, которые мы могли использовать, и эти стандарты гарантировали, что HTML, который вы пишете в своей части мира, будет работать для большинства, если не для всех, интерпретаторов HTML. Каскадные таблицы стилей (CSS) также вошли в обращение в 1996 году, а за год до этого на сцену вышел и JavaScript. Можете ли вы представить себе, что видите или используете веб-сайт без JavaScript или CSS? Это не будет приятным опытом, это точно.
Но на протяжении всей истории некоторые вещи в сети оставались неизменными. Честно говоря, многое из этого должно было быть: вы никогда не захотите вносить критические изменения в стандарт HTML без очень веской причины для этого, поэтому изменение больших частей того, как работает интернет, в будущих версиях, вероятно, никогда не произойдет. В результате мы получили интернет в том виде, в каком он есть сегодня, и что в него входит?
Документ
Когда интернет только появился, люди не пользовались приложениями, как сегодня. Некоторые из вас помнят про терминалы, которые действовали как клиенты, давая вам физическое соединение с мэйнфреймом на другом конце физического соединения. “Приложения” (если их можно так назвать), которые были у людей, были немногим больше, чем строки текста на экране. Люди привыкли иметь дело с вещами как с документами, как с физическими листами бумаги в руках, которые они могут просматривать. Поэтому неудивительно, что основой HTML-страниц является создание HTML-документа. Если вы когда-либо использовали JavaScript, вы будете знакомы с такими функциями, как document.getElementById(). Все, что вы делаете на веб-странице, заключается в создании, а затем преобразовании документа.
Традиционно большинство веб-страниц имеют высоту больше одного окна просмотра. Таким образом, пользователю придется пролистывать страницу пальцем или прокручивать ее с помощью мыши. Я не могу представить себе веб-сайт, который я использую сегодня, который аккуратно вписывается в окно просмотра пользователей (конечно, не в эту обличительную речь), поэтому разработчик всегда будет гарантировать, что какая-то часть страницы будет либо выше, либо ниже того места, где пользователь в данный момент смотрит на свою страницу.
Но все же вы хотели бы, чтобы определенные части вашей веб-страницы оставались в определенном положении или выравнивались определенным образом. Вы начинаете использовать такие вещи, как position в CSS, чтобы контролировать расположение ваших элементов. Существует тонна свойств CSS (520, если быть точным), и, как следует из названия, эти стили каскадируются в свои дочерние элементы. Когда вы пытаетесь заставить определенную часть вашего документа выглядеть определенным образом, он может стать довольно хаотичным. Если вы используете существующий фреймворк стиля, такой как Angular Material, то он также становится довольно пикантным, когда вы начинаете переопределять встроенный CSS для достижения определенного внешнего вида, который вам нужен. CSS позволяет вам переопределить это с помощью !override, но как только вы начнете это делать, битва в значительной степени проиграна. Если вы читаете это и думаете про себя: “Что? Похоже, этот парень безнадежен в CSS», — тогда все в порядке, и я бы не стал спорить с вами по этому поводу. Но когда ваши дизайнеры гоняются за определенным внешним видом, CSS может стать довольно сложным.

Фото Pankaj Patel на Unsplash


Изучение языков
Чтобы создать простой веб-сайт, вам необходимо использовать три разных языка, и это касается только самого веб-сайта. Это HTML, JavaScript и CSS. Ваш веб-сайт должен выглядеть и хорошо себя чувствовать, и он не сможет этого сделать, если вы не умеете писать эффективный JavaScript или если у вас плохой стиль CSS.
Если вы действительно хотите, чтобы ваш сайт что-то делал, то можете использовать фреймворк типа Angular или React. По мере того, как вы начинаете вводить пакеты через npm, размер вашего приложения начинает расти, поэтому вы также будете использовать сборщик, такой как webpack, чтобы связать все свои пакеты вместе и соответствующим образом минимизировать их. Webpack — это тема сама по себе (и при этом огромная), но ее стоит рассмотреть, и она составляет значительную часть при создании веб-приложений.
Бандлинг и транспиляции
После того, как у вас есть веб-сайт и пакеты, вам нужно использовать сборщик, чтобы объединить клиентское приложение и убедиться, что оно работает в их браузере. В зависимости от того, какой браузер они используют, вам также нужно будет настроить определенные функции, чтобы браузер пользователя действительно мог использовать ваш веб-сайт. Если вы используете такой язык, как TypeScript, webpack также преобразуется с этого языка в JavaScript. В этом нет ничего плохого по своей сути, но он очень сложен и имеет множество движущихся частей. Если ваш сайт ломается, вы испортили код, или минификация сломала его, или webpack не включил его должным образом, или процесс транспиляции привел к проблеме? Эти сложные конвейеры могут создавать трудности при отладке или обнаружении основной причины проблем в вашем приложении.

Чем Flutter лучше?

Если вы слышали о Flutter, то, скорее всего, слышали о нем в контексте разработки телефонных приложений. Так как же это относится к веб-сайтам? Ну, с обычной HTML-страницей вы имеете дело со страницей как с документом. Однако в Flutter “страница” (или то, с чем взаимодействует пользователь) фактически рисуется на HTML-холсте. Flutter фактически контролирует каждый пиксель, который рисуется на экране, и не использует HTML, JavaScript или CSS для определения его внешнего вида или логики. (Технически говоря, родной код Dart переносится на JavaScript через dart2js, но на самом деле никакая бизнес-логика не написана на JavaScript.)
Вы, вероятно, уловили две вещи, вызывающие тревогу в этом предложении. Во-первых, нет HTML. Во-вторых, мы все рисуем на холсте. Я понимаю — это звучит странно и, по крайней мере, в случае рисования непосредственно на холсте, не очень эффективно. Но давайте покопаемся в этом немного подробнее.

Photo by Keila Hötzel on Unsplash

Рисование на холсте вместо документа
Первый момент заключается в том, что мы не используем HTML для написания наших веб-страниц и не записываем что-то в документ. На первый взгляд это полная ересь. Но что именно вы делаете, когда разрабатываете веб-страницу в HTML? Ну, как мы уже говорили ранее в этой статье, вы создаете документ, который слишком велик для окна просмотра устройства пользователя, а затем они прокручивают его. То, что вы сейчас читаете на этой самой странице, высота документа больше, чем высота окна просмотра. И вы прокручиваете содержимое.
Когда вы думаете об этом, разве это не странный способ проектирования пользовательского интерфейса, ожидать, что контент будет слишком большим по вертикали и что пользователю придется прокручивать его? Что делать, если вы хотите, чтобы пользователь прокручивал страницу слева направо, а не сверху вниз? Это не особенно легко выразить на обычной веб-странице.
Во Flutter, если вы хотите сделать определенный фрагмент контента прокручиваемым по горизонтали, а не по вертикали, это так же просто, как обернуть виджеты в SingleChildScrollView. Вы также можете так же легко указать направление самой прокрутки, независимо от того, должна ли она прокручиваться по вертикальной или горизонтальной оси.
Поскольку Flutter основан на концепции размещения вашей страницы в отдельных виджетах, а не рисования документа на экране, разработчикам предоставляется больше контроля над тем, как именно они хотят расположить свои приложения.
Придерживаясь одного языка
Как уже упоминалось ранее, создание отличного веб-сайта означает, что вы должны знать HTML, JavaScript и CSS. Это также означает, что ваши знания не передаются между этими языками, и вы не можете повторно использовать какие-либо из ваших знаний JavaScript в HTML, например. HTML — это чисто ваш язык разметки, CSS — это чисто ваш синтаксис стиля, а JavaScript — это чисто ваш язык программирования. Ни один из этих вариантов не включает в себя такие вещи, как проверка типов, поэтому ваш CSS может быть полной чушью, и он просто потерпит неудачу, когда пользователь попытается использовать вашу веб-страницу.
Flutter использует Dart в качестве своего языка, и весь внешний вид приложения и бизнес-логика написаны на нем. Dart поставляется со статической проверкой типов, и скоро появится нулевая безопасность, поэтому каждая строка кода в вашем приложении, будь то визуальное описание вашего приложения, придание ему стиля или управление бизнес-логикой вашего приложения, полностью типобезопасна.
Проще выложить свое приложение
Вообще говоря, мы используем наши веб-сайты для отображения данных из другого источника: будь то база данных, API или что-то еще, мы получаем данные, которые хотели бы отобразить. Представьте, что у нас есть массив объектов, возвращаемых из нашего API, и вы используете что-то вроде Angular для их отображения. Обычно вы загружаете эти объекты в компонент поддержки, а затем используете *ngFor для итерации по ним. Вы, скорее всего, прикрепите это к div. Однако из коробки для не стилизованного div это выглядело бы довольно просто. Вероятно, вы хотите, чтобы элементы в этом списке отображались в столбце или строке, поэтому вам придется задействовать некоторые CSS или flexbox для этого.
И наоборот, с Flutter вы размещаете своих дочерних элементов, используя Column  или Row , у которых есть свойство children, которое принимает массив объектов. Когда вы думаете об этом, в большинстве случаев вы, вероятно, хотите, чтобы ваши массивы объектов располагались в строке (рядом) или в столбце (друг под другом). Поскольку у вас есть это, вы можете быстрее получить желаемый визуальный макет, прежде чем переходить к стилизации отдельных элементов в списке. По моему опыту, это приводит к более быстрому скаффолдингу и прототипированию сайта без ущерба для конечного результата.
Контроль над каждым пикселем в окне просмотра
Поскольку Flutter отображает каждый пиксель на экране, это дает дизайнерам и разработчикам полный контроль над тем, как именно они хотят, чтобы их приложение или опыт выглядели. Рендеринг каждого пикселя на экране звучит так, как будто это приведет к значительному снижению производительности, и не поймите меня неправильно, в наши дни это, конечно, не так быстро, как рендеринг необработанного HTML, но такие вещи, как canvas с ускорением на GPU, повышают производительность в этом. Традиционно дизайн вашей веб-страницы в формате HTML означал бы, что вам придется учитывать различные браузеры, на которые вы ориентируетесь. Однако в случае Flutters, поскольку вы размещаете виджет Text  с определенным шрифтом, он будет выглядеть одинаково независимо от того, где он отображается, потому что Flutter контролирует, как этот конкретный виджет будет выглядеть на основе каждого пикселя.
Прощай, вебпак!
Поскольку Flutter использует Dart, когда приложение Flutter компилируется для своей целевой платформы, оно также переносит все зависимые пакеты (также написанные на Dart) в JavaScript. Dart — это типобезопасный язык, который не поддерживает рефлексию, поэтому компилятор лучше понимает, что вызывает ваше приложение, а что нет. Это приводит к лучшему встряхиванию дерева (tree-shaking) и минификации вашего приложения. Создание приложения Flutter для веба не использует webpack, потому что оно ему не нужно, что само по себе является довольно сильным аргументом в пользу Flutter (по крайней мере, на мой взгляд). В webpack нет ничего плохого; это качественная программа. Но это сложный инструмент в уже сложном пайплайне.

Но мы еще не совсем там

В вебе есть нечто большее, чем шикарные веб-страницы, великолепная анимация и прекрасные впечатления. Нам действительно нужно нечто большее. Нам нужен рендеринг на стороне сервера (SSR), чтобы наши веб-страницы могли обрабатываться поисковыми системами для выполнения любого типа поисковой оптимизации (SEO). В настоящее время веб-сайты Flutter могут интерпретировать только люди, а не поисковые системы, так что это окажет огромное влияние на то, как люди ищут и находят информацию на вашем веб-сайте. (Люди обсуждают этот вопрос, и не похоже, что в ближайшем будущем будет принято решение).
Рисование всего на холсте также влияет на производительность, но не так плохо, как вы думаете. Я сделал тестовое приложение, которое интенсивно использует визуальные эффекты, и оно работает на моем MacBook со скоростью около 60 кадров в секунду. Даже когда вы перетаскиваете лист по экрану, он все равно работает нормально, постепенно увеличивая размытие на изображении позади. Я ни в коем случае не эксперт в Dart, поэтому, без сомнения, этот процесс можно оптимизировать еще больше.
Итак, есть несколько ключевых моментов, которые Flutter необходимо улучшить, прежде чем люди будут рассматривать его для веб-разработки. Но подумайте на мгновение: Flutter действительно вышел только за последние два года, а производительность и набор функций, которые у него уже есть, просто невероятны.
Что бы это могло быть, если бы вы могли сделать веб-сайт, который был бы эффективным, и вы могли бы использовать один язык для разработки, стиля и написания бизнес-логики для вашего веб-приложения? Если webpack стал лишним для вашего конвейера разработки? А если бы со временем у вас был серверный рендеринг и все те SEO-блага, которые есть сегодня на традиционных HTML-сайтах?
Если бы у вас было все это, то Flutter мог бы выиграть веб.

Перевод с английского. Источник.