Залязва ли слънцето пред кросплатформените технологии?

Нека се върнем на 20 юни 2018 г. Всички сме с две години по-млади и все още никой не говори за глобална пандемия (тази част е особено хубава, въпреки че предполагам, че не сме оценили колко хубаво тогава беше).

Airbnb обяви, че спира използването на React Native за своите приложения и вместо това отива ол-ин на собствения си опит. До този момент те бяха една от многото компании, които се възползваха добре от рамката за мобилно развитие на Facebook. Един месец по-късно Udacity прекрати своя експеримент с React Native и реши да не продължава с него.

В по-ново време местното развитие изобщо не е в застой. „Apple пусна SwiftUI“ наскоро, за да получи широко признание, а Android също отбеляза подобрения в своя собствен набор от инструменти. Така че случаят с естественото разработване никога не е бил по-добър, възпрепятстван само от един проблем, актът на писане на приложението nпъти, където n е броят на платформите, на които искате приложението ви да работи.

Не е трудно да се разбере защо има толкова много междуплатформени рамки. Писането на едно и също приложение няколко пъти за множество платформи изглежда нарушава Не повтаряйте себе си (DRY), един от основните принципи на разработката на софтуер. Но писането на приложение на един език и внедряването му в множество цели като iOS или Android винаги е идвало с компромиси. Нека да разгледаме някои от тези технологии, преди да се върнем към „Flutter“.

В началото имаше Кордова

Знам, че Cordova беше първоначално PhoneGap и също така знам, че концепциите за разработка на различни платформи датират от Java и след това, но не искате да прочетете несъкратено есе от 20 000 думи за разработката на междуплатформен софтуер (и Не искам да пиша), така че Кордова изглежда като добро място за начало.

Когато Cordova беше пуснат за първи път през 2009 г., мрежата беше в разцвета си. Само няколко години по-късно беше пуснат HTML5 и мисълта беше, че ако познавате HTML и JavaScript, можете да създадете доста завладяващо приложение за телефон. И това би било вярно, ако бяхте изключително талантлив разработчик, който разбираше нюансите на платформите, към които се насочвате. Ако вашият бизнес беше основно насочен към мрежата и имате нужда от приложение за телефон, не бихте ли предпочели да използвате съществуващите знания на вашия уеб разработчик, за да създадете приложение, вместо да наемете другразработчик за iOS и Android?

За съжаление бяха пуснати много приложения, които или изглеждаха ужасно, или се държаха ужасно. Създаването на микроуебсайтове чрез Cordova, които имат естествена функционалност, беше лош заместител на действителното създаване на добросъвестно местно изживяване. Някои приложения дори бяха толкова лоши, че потребителят можеше да избира текст в приложението (както са на нормална уеб страница) или да щипне, за да увеличи мащаба на части от приложението, които не са предназначени за него, и т.н.

С течение на времето имахме други прогресивни технологии като Ionic, които също използваха Cordova и предлагаха по-силна рамка, върху която да изградите вашето приложение, но основните проблеми, свързани с хостването на микроуебсайт на вашия телефон с достъп до собствени компоненти, надделяха. Най-големият проблем, освен използваемостта, бешепроизводителността. Използването на HTML и JavaScript на устройството като приложение обикновено води до лоша производителност.

Ако вашият бизнес беше основно насочен към мрежата и имате нужда от приложение за телефон, не бихте ли предпочели да използвате съществуващите знания на вашия уеб разработчик, за да създадете приложение, вместо да наемете другразработчик за iOS и Android?

Тогава имаше Xamarin

През 2013 г. излезе Xamarin Native, а малко след това излезе Xamarin Forms. Това беше особено дразнещо за хора, които вече имаха познания и опит в C# и .NET, тъй като те вече можеха да създават и телефонни приложения. На теория беше забиване. Имахте достъп до C# — зрял, усъвършенстван език — и можехте да проектирате потребителския си интерфейс в XAML. За известно време високите разходи за навлизане в реално създаване на приложение Xamarin Forms бяха бариера, но след това Microsoft купи Xamarin и направи така, че всеки да може да разработи пълноценно корпоративно приложение, без да плаща разходите за лицензиране.

На хартия това е невероятно предложение. Звучи сякаш току-що сте натиснали превключвател и изведнъж всеки, който познава C# и малко Windows Presentation Framework (WPF) или UWP (Universal Windows Program), може да създаде приложение за телефон. Още по-добре, те биха могли да създадат родноприложение за телефон – без да използват HTML или JavaScript. Производителността също би била страхотна, тъй като самото приложение ще работи с почти естествени скорости.

Сигурен съм, че много хора са имали невероятен успех с Xamarin и дори все още много хора все още го използват днес. Но според моя опит Xamarin дойде със собствените си главоболия. Изпълнението беше наред, но проектирането на UI в XAML не беше интуитивно или приятно изживяване. Всички контроли по подразбиране бяха скучни, граничещи с грозни и ако искахте да подобрите начина, по който изглеждаха, трябваше да напишете персонализиран рендър.

Тези платформени реализации, както подсказва името, са за всяка платформа, така че ако искате красива градиентна кутия или нещо подобно, ще трябва да напишете персонализирания рендер на iOS, Android и дори Universal Windows. Още по-лошо, всяка отделна платформа имаше различен език, който беше картографиран към C# чрез обвързваща библиотека. Това означаваше, че дори да намерите начин да постигнете ефекта, който искате, ще трябва ръчно да го пренапишете на C#. Това е достатъчно лошо, но ако не знаете Swift или Kotlin, се опитвате да превеждате от език, който не знаете, на този, който знаете, което вероятно ще има лош резултат.

Изпълнението (Xamarin Forms) беше наред, но проектирането на потребителски интерфейси в XAML не беше интуитивно или приятно изживяване. Всички контроли по подразбиране бяха скучни, граничещи с грозни и ако искахте да подобрите начина, по който изглеждаха, трябваше да напишете персонализиран рендър.

Имахме и React Native

React Native се превърна, смея да го кажа, в едно от най-популярните междуплатформени нативни имплементации наоколо. Той позволява на разработчика да представя естествени изгледи и тези изгледи да общуват с междуплатформения JavaScript бекенд чрез мост. Всъщност не използвах React Native твърде много. Не ми хареса как се декларират изгледи и по времето, когато го използвах, JavaScript беше единственият поддържан език, така че безопасността на типа не беше включена в полето. По-късно поддръжката на TypeScript дойде в React Native, но аз лично не се наслаждавах на шаблоните за изглед JSX или TSX за оформление на моето приложение. React Native безспорно има огромно количество последователи от разработчици, така че е ясно, че много хора предпочитат React Native за създаване на приложенията си.

И тогава дойде Флутър

През декември 2018 г. Flutter видя първото си стабилно издание. Сега нека бъдем честни със себе си. Вероятно има, не знам, стотици хиляди разработчици, които или вече познават междуплатформена рамка, или които са напълно доволни от използването на родни реализации. Така че, всъщност, в съда на общественото мнение, Flutter всъщност дойде в много лош момент. Защо казвам това?

Хората вече имат мнения относно крос-платформените решения

При наличието на толкова много хора, които са използвали междуплатформени решения, неизбежно е да има много мнения относно това, което вече е на пазара. И през много време тези мнения ще бъдат отрицателни: че са бавни, че не работят правилно, че трябва да жертвате твърде много, за да получите надежден опит. Тези критики са правилни и са актуални от дълго време в междуплатформеното пространство. С Xamarin дори съм преживял приложението ми да работи перфектно при отстраняване на грешки и след това просто да се срине на работния плот, когато се опитам да изградя версия. Също така настоявах за разработка на различни платформи на работното си място, за да ми кажат, че вместо това ще разработим собствено приложение.

Хората вече са избрали рамка

Ако някой е отворен към идеята, че разработката на различни платформи можеда работи, тогава има доста голям шанс, че вече е избрал предпочитаната от тях рамка и в момента я използва, за да създава своите приложения. За да се променят, случаят трябва да е убедителен. Защо бихте се отказали от вашия език или от вашата рамка, с която вече се чувствате удобно? Това, къмтрябва да е много по-добро.

При наличието на толкова много хора, които са използвали междуплатформени решения, неизбежно е да има много мнения относно това, което вече е налице. И през много време тези мнения ще бъдат отрицателни.

Не можете да носите нищо със себе си

За да научите Flutter, трябва да научите Dart. Не можете да носите своя JavaScript, C#, Kotlin или друг език със себе си. Dart има много общо с тези езици и прескачането не е твърдетрудно,но случаят разработчикът да научи Dart трябва да е убедителен. Разработчиците не са от хората, които учат нови езотерични езици по прищявка – те осъзнават, че всеки език отнема време за научаване и още повече време за овладяване.

Ще остане ли за дълго?

Преди Flutter да кацне, Dart всъщност беше мъртъв език. Знам, че хората в Google го използваха в някои от своите приложения, но факт е, че TypeScript беше далеч по-популярният и широко използван език. „През 2018 г. беше оценен като най-лошият език за работа“. Очевидно това се промени наскоро с популярността на Flutter, но Google също има навика да убива продукти, които потребителите и разработчиците харесват еднакво. Така че притесненията относно това дали Flutter ще съществува след две години – като се знае историята на Google – са основателни.

И така, видяхме проблемите, които е имало кросплатформеното развитие през годините, а също така разгледахме някои от потенциалните проблеми със самия Flutter. Заслужава ли си все пак да го обмислим?

Как се подрежда Flutter?

Така че, за да може Flutter дори да има кон в това състезание, следното трябва да е вярно:

  1. Трябва да е толкова добър, че да сте щастливи да научите изцяло нов език (Dart).
  2. Той трябва да предложи повече от настоящите играчи в това пространство.
  3. Тъй като вие се лишавате от години ресурси и техническа документация, за да го използвате (тъй като той съществува от много по-малко време от аналозите си), тази жертва трябва да си заслужава.
  4. Трябва да сте уверени, че има бъдеще.

Всичко, което мога да направя, е да разсъждавам върху собствения си личен опит, който основно е, че направих приложения в Cordova, Ionic и Xamarin Forms, преди да дойда във Flutter. Така че нека преминем през тези точки.

Заслужава си да научите Дартс

Знам, знам. Трудно е да се научи нов език. Още по-трудно е за нас, разработчиците, които вече имаме толкова много езици, които вече се въртят из главите ни, и още по-трудноза хората с пълен стек, които също трябва да се занимават с различни шел скриптови езици на всичкото отгоре. Но мисля, че си струва да научите Dart. Използвал съм C#, TypeScript, JavaScript и много други и чувствам, че Dart е красив, изразителен език за използване.

Dart е някак по-лесен за използване от много други играчи в това пространство, като същевременно по някакъв начин е също толкова мощен — ако не и по-мощен — от тях. Това не е правилната статия за операторите на Dart, но дори начинът, по който Dart ми позволява да манипулирам списъци, е с години по-напред от всичко, което е налично в C# днес.

Той също така търгува ниво на многословие за конвенция. Например, можете да направите полетата частни, като просто поставите пред тях долна черта. Полетата без префикс са публични. Има и по-малки промени, които наистина ми харесват, като премахването на оператора new. За да създадете нов обект, просто извиквате конструктора с необходимите параметри и това е всичко. Може да звучи като проста промяна, но ви кара да осъзнаете, че операторът new е излишен и всъщност не добавя нищо към кода, който пишете. Смятам, че Dart е пълен с тези синтактични изненади, които правят писането на код по-приятно и по-бързо изживяване.

Трудно е да се научи нов език. Но мисля, че си струва да научите Dart.

Има какво да предложи

Може би не е най-добрата идея да влезете в интернет и да обявите, че един език или рамка е „по-добър“ от друг. Това е просто чудесен начин да започнете битка. По мое лично мнение намирам, че Flutter може да предложи повече от всяко друго междуплатформено решение, което съществува в момента. Казвам го по следните причини:

Отличен контрол върху визуалните елементи в приложението. Тъй като Flutter изобразява директно на екрана и контролира всеки пиксел от екрана (подобно на двигател на играта), вие имате пълен контрол върху това, което се изобразява на екрана. В същото време има и клас CustomPaint, който ви позволява да рисувате каквото искате на екрана. Когато мислите за това в контекста на факта, че Flutter поддържа Android и iOS — и след това, в бета версия — Web, Windows, macOS и други по пътя, става доста феноменално.

Фактът, че мога да създам градиент, който изглежда „по определен начин“, който се изобразява по същия начин, без значение на каква платформа се изпълнява, е много впечатляващ. Той се поддава на много завладяващи, красиви изживявания на широк набор от платформи. Възможността да се рендира нещо на екрана, без да се пише специфичен за платформата код, за да се постигне това, е нещо, което намерих достъпно само във Flutter. Разбира се, има невероятен набор от готови джаджи, които идват с рамката, и можете да ги използвате, както желаете, но също така да навлезете в детайлите и сами да изобразите някои персонализирани контроли, когато търсите много конкретен поглед или усещане.

Естествено изпълнение. Flutter създава собствено приложение за устройството с iOS или Android, на което работи. В комбинация с усилията на Google всяко приложение да работи с 60 FPS, това означава, че приложенията са копринено гладки за използване. Дори по начините, по които Flutter изобразява ListView означава, че елементите в списъка се изобразяват само когато са превъртени в изгледа, което поддържа високо ниво на производителност и по-малко използване на паметта на устройството. Не е нужно да правите сложни математически изчисления, за да разберете дали елементът от списъка е видим на устройството или не, Flutter го прави вместо вас.

Страхотен избор за управление на държавата. Когато работите върху приложение с по-голям размер, неизменно вероятно ще трябва да изберете рамка, върху която да надграждате, вместо просто да разчитате на това, което естествената рамка ви дава. В Xamarin това обикновено е някакъв вариант на Model View ViewModel (MVVM). При Flutter това обикновено е моделът BLOC. След като проектирах приложение в Xamarin Forms и след това пренаписах същото приложение във Flutter, чувствам, че BLOC е по-разширяем, по-лесен за използване и по-лесен за тестване от всичко друго, което съм използвал във всяка друга рамка.

Постига правилния междуплатформен баланс. В Xamarin Forms абсолютно всичко е C#, дори специфичните за платформата имплементации на програми за изобразяване. Не ме разбирайте погрешно, знам, че голяма част от смисъла на Xamarin е да напишете кода на вашата платформа на C# и писането на споделената част от вашето приложение на C# има смисъл. Писането на специфичните за платформата битове на C# обаче няма смисъл и според мен само усложнява процеса.

Причината, поради която се чувствам така, е, че бързо става объркващо кое е „правилното“ нещо, което да използвате във вашия специфичен за платформата код. На Android, например, използвате ли List или JavaList? Те не са взаимозаменяеми и ако използвате грешния, в най-добрия случай ще получите грешка за безопасност на типа или, в най-лошия, ще въведете проблеми в приложението си.

Flutter използва платформени канали, за да изпълнява естествен код, когато имате нужда от специфични за платформата реализации. Така че вашият споделен код е написан на Dart, но специфичните за платформата неща са написани на езика, роден за тази платформа. В същото време смятам, че си струва да спомена, че когато пренаписах приложението си от Xamarin Forms на Flutter, преминах от изискване на специфичен за платформата код за определени програми за изобразяване и т.н. до липса на нужда от тях изобщо. Същите задачи бяха изпълнени от това, което вече беше налично във Flutter. Може би мисълта за изучаване на родните езици на платформата, когато имате нужда от специфичен за платформа код, изглежда малко непосилна, но е много по-добреотколкото да се опитвате да използвате същата функционалност чрез всякакъв вид обвързваща библиотека.

Какво не е наред с обвързващите библиотеки?

Xamarin излага собствената функционалност на устройството чрез това, което е известно като библиотека за обвързване – библиотека, която картографира естествената API повърхност към нейния еквивалент на C#. Това означава, че когато търсите начин да изпълните конкретната си задача, обикновено ще намерите резултати само на родния език на тази платформа и много рядко ще намерите резултати, които вече са написани на C# за вас.

Така че това означава, че трябва да пренапишете всяка функционалност от родния й език (като Kotlin, Objective-C или Swift) на C#. Като крос-платформен разработчик с ограничена осведоменост за тези езици вече бихте могли, в най-добрия случай, да се занимавате с излизащи корекции на StackOverflow, но пълното им пренаписване на различен език просто изисква проблеми.

Във Flutter можете да оставите специфичния за платформата код на родния му език, да го настроите по ваш вкус и след това да го извикате чрез „Канал на платформата“. Това са по същество мостовете от вашия роден код на Dart към вашия роден код на платформа. Според моя опит това е много по-добър подход за специфични за устройството реализации.

Когато пренаписах приложението си от Xamarin Forms на Flutter, преминах от изискване на специфичен за платформата код за определени програми за изобразяване и т.н. до липса на нужда от тях изобщо.

Има изненадващо количество налична техническа информация

Всяка седмица (или около това време) в канала на Flutter в YouTube има нов видеоклип „Widget of the Week“, демонстриращ как да използвате определен widget във Flutter. Това вероятно звучи толкова завладяващо, колкото да гледате как боята изсъхва, но някои от джаджите позволяват наистина красиви анимации и взаимодействия по начини, които лесно можете да приложите в приложенията си.

Други компании като Codemagic (доставчик на CI/CD) правят тази крачка напред, като също „предлагат технически ръководства“ за други области на Flutter. Според моя опит има достатъчно техническа информация, за да можете да създавате повечето приложения днес и вероятно няма да срещнете проблеми, които са уникални само за вас.

Ще остане*

(*вероятно)

„Flutter формира UI компонента на следващата операционна система на Google, наречена Fuchsia“. Ако Google убие Flutter, те ще убият потребителския си интерфейс за Fuchsia. Не можете да използвате операционна система без потребителски интерфейс, така че освен ако Google не излезе с напълно нова рамка и не накара всички да мигрират към нея или пуснат операционна система само с обвивка, те няма да имат какво да използват в действителност. Така че, искам да кажа, разбира се, Google може да убие Flutter, но бих го оценил като малко по-малко вероятно, отколкото да решат да се измъкнат от бизнеса с търсачките. Те буквално биха изхвърлили около десетилетия работа, ако го направят.

И така, струва ли си да използвате Flutter? Струва ли си да научите изцяло нов език, да се откажете от другите налични ресурси, с които разполагат другите рамки, защото съществуват от по-дълго време, и да търгувате с всичко това, само за да можете да използвате Flutter като рамка за вашето телефонно приложение? Според мен да. Със сигурност е така.

Това е проблем с времето

Няма спор, че отново Flutter може би дойде в най-лошия възможен момент, с хората, които вече имат отрицателни мнения относно инструментариума за разработка на различни платформи, и с толкова много компании, които мигрират обратно към естественото развитие. Но Flutter наистина предлага някои наистина уникални възможности, които са изключителни за него, и лично аз съм много развълнуван от продължаващото разширяване и развитие на Flutter.

Не вярвам, че слънцето залязва за междуплатформени рамки като Flutter и мисля, че те ще се радват на богато развитие в бъдеще. Може да греша напълно, но съм готов да остана, за да видя докъде ще стигне Flutter през следващите години.

Ако мислите да го пробвате, честно казано, никога не е имало по-добър момент. По мое мнение, Flutter също има една от най-добрите общности в момента, така че хората като цяло са доста полезни и информативни, независимо от вашия опит в кодирането.

Забавлявайте се и се наслаждавайте на изживяването по пътя 😊.