Предисловие


Все совпадения с реальностью случайны. Автор не претендует на истинность в последней инстанции.


Пролог


Технологии сменяют друг друга — на рынке чуть ли не со скоростью звука последние N лет, и у этих бурных перемен всегда есть некая идеологическая причина. Лежащая в области удобства, и комфорта разработки ПО. Современный цирк во Front End разработке является лишь отражением того, что на волне хайпа некоторые компании/разработчики тоже решили влезть на этот рынок. Хотя критический нового они ничего не преподнесли. Если бы мы жили в лучшем из миров, где каждый разработчик судил о своих инструментах, с точки зрения методологической базы, которая более приближена к ценностям науки разработки ПО ничего бы из этого не было. Мы бы не получили столько качественно новых пустышек, но увы, мы не живем в таком мире.


Эпилог


Фундаментальные проблемы Front End разработки — это CSS, DOM, динамическая типизация, разные виды браузеров, бизнес, процесс сборки.


Итак, разберем как мы пытались бороться с каждой из этих проблем.


Разные виды браузеров


Мы боролись с этим во времена WEB 1.0, путем стандартизации работы с DOM деревом через библиотеку jQuery. Это работало отлично, но на фоне все более, и более больших проектов появилась другая проблема.


DOM


Поиск по DOM дереву содержит в себе 2 проблемы. Первая — он слишком гибок, то есть можно искать через id и css selector. Вторая-все подвязано на каких-то мнимых переменных. То есть id и селекторы, как их называют. Зачастую сводится к слишком контекстно-зависимым словам и фактам. То есть, чтобы узнать к чему принадлежит тот или иной id зачастую нужно знать/искать контекст. А это прямо не очень. И благодаря этой проблеме у нас появились React/Vue/Angular/Svetle/Blazor список можно продолжать до бесконечности. А точнее SPA предоставления о Front End приложениях. И это работает до сих пор.


CSS


Чем меньше надо писать, тем лучшее, абстракции нам нужны для скорости разработки. Когда CSS на уровне WEB 1.0 представлял из себя такую идеальную абстракцию, со временем, все стало хуже. Ввели !important что бы решить вопрос с легаси CSS. Но это решение было на уровне вытаскивания себя из воды за волосы. Возможно, с !important мы отсрочили фундаментальные проблемы, но они все равно встают. И еще одна проблема, наш код в дальнейшем разделяется на две кодовые базы, или три. В данный момент в SPA это 2 кодовые базы. Баги которых зависят от друг друга. Что не есть хорошо и удобно. Да, мы там еще пытались изобрести различные методологии написания CSS кода. Но это все опять же, слишком зависит от того с какой ноги встал разработчик, и это не решило проблем CSS подхода. Как например тот же SOLID решил проблемы ООП.


Динамическая типизация


Ну в чем проблема динамической типизации, и почему это зло я думаю объяснять не надо. Другой момент в том что на рынке хайпанул TS. А он добавляет псевдо типизацию. Не вмешиваясь в реал тайм, и обещает нам что все будет работать на уровне компилятора, но компилятор как оказалось слишком легко обмануть.


Процесс сборки


Мы решили эту проблему, путем написания сборщиков проектов по типу Webpack. И это хорошо, сборщики проектов есть у почти любого уважающего себя языка, сообщества разработчиков. Но с изобретением Webpack'а крупные фреймворки, решили автоматизировать этот процесс и предоставили для нас удобные CLI приложения. Через которые мы создает свои проекты. И надобность учить Webpack, отпала. Абсолютное большинство моих знакомых Front End разработчиков его не знают. Потому что им нету надобности его учить, а раз нету надобности. То всю его мощь и вариативность настройки они естественно не знают.


Бизнес


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


Экспозиция


Статья про Flutter, и про то как он справляется со всеми этими проблемами.


  1. Кроссплатформенность — Web/Android/Ios/Windows/MacOs. Недавно я запилил 2 проекта под Web на работе, весь тот функционал который есть во всех решениях выше. Он делает на ура.


  2. DOM — он там отсутствует как и в любом другом нормальном фреймворке.


  3. Разные виды браузеров — эта проблема уже почти отпала.


  4. CSS — Во Flutter всем управляют классы, и все достаточно задокументировано. Нету разделения кода, все компоненты Flutter специфично разделены. И можно делать абсолютно такой же функционал, который есть у CSS. Но только на уровне классов. Что повышает скорость разработки.


  5. Процесс сборки — здесь конечно Flutter'у можно поставить минус. По скольку он не предоставляет таких удобство кои есть у Webpack'а. И это все работает из коробки.


  6. Динамическая типизация — во Flutter, используется Dart. Dart предоставляет реал тайм проверку типов, и его не так легко обмануть. Нету Option?, и нельзя просто так из типа any взять другой тип. Хочешь из любого типа получить нужный тебе тип, конвертируй, свой any в строку.


  7. Бизнес — ну думаю глядя на все что описано выше, Flutter/Dart отлично помогает бизнесу, в далекой и не очень перспективе.



Проблемы


Серебряной пули не существует, мы не знаем законов совершенства. Но тем не менее совершенство достижимо. Конечно разработка на Flutter'е принесет какие то новые проблемы и вызовы. Автор отдает в себе в этом отчет.


От автора: Я не являюсь, проповедником Flutter'а. Автор оставляет за собой право на ошибки. И он их так же будет исправлять по мере получения обратной связи.