Факап вебпроєкту, або Як втратити $45 000 через розробку сайту на Flutter

Усі статті, обговорення, новини про Mobile — в одному місці. Підписуйтеся на телеграм-канал!

Вітаю, я — Борис Барський, Co-founder сервісної компанії Lampa Software. Уже понад вісім років ми займаємося розробкою IT-рішень для бізнесів. Зокрема, зосереджені на створенні мобільних продуктів, а також застосунків для SmartTV (Android, Apple, Samsung та LG).

Одним з важливих каналів лідогенерації для нас є корпоративний вебсайт. Останній раз ми робили його редизайн ще понад п’ять років тому, і в середині 2022-го постало нагальне питання про модернізацію — як візуальної, так і технічної частини.

Ми вирішили відійти від традиційних JS-фреймворків і спробували зробити корпоративний вебсайт на Flutter.

Нижче розповім історію про те, як ми намагалися побудувати середнього розміру вебсайт на Flutter. А також як потенційно витратили на нього не менше $45 000, на які труднощі натрапили та до якого висновку дійшли.

Сподіваюсь, цей досвід збереже час, нерви та гроші як розробникам, так і компаніям загалом.

Чому саме Flutter

Наше знайомство з фреймворком від Google почалося ще у далекому 2018 році. Тоді фреймворк ще навіть не доріс до stable-версії, а перебував у beta.

Відразу зазначу, що перші спроби були досить вдалими. Розробка на платформі мала низку суттєвих переваг (і мовиться не лише про економію бюджету).

Водночас неприємних компромісів (про них — далі), традиційних для кросплатформових рішень, виявилось не так багато.

А порівнювати нам є з чим: свого часу ми перепробували більшість мейнстримних «вбивць» нативної розробки: Phonegapp, Cordova, Xamarin, React Native.

Слід сказати, що тоді Google позиціював Flutter насамперед як платформу для мобільної розробки. Але згодом було заявлено і про підтримку web- та desktop-застосунків.

Саме цей факт, помножений на наш вдалий попередній досвід та традиційну схильність до експериментів і новаторства, переконав нас у доцільності такого підходу.

Крім того, ми планували використати наш сайт як свого роду «вітрину» Flutter для потенційних замовників, які все ще з острахом ставились до нової технології.

Отже, за результатами брейнштормів була сформована команда, і все закрутилося.

Коротко про фреймворк Flutter. Переваги та недоліки

Перед тим, як перейти безпосередньо до історії розробки сайту, кілька слів про сам Flutter і його технічні специфікації — для тих, хто не зовсім орієнтується, про що йдеться.

Фреймворк Flutter — це мультиплатформове технічне рішення від корпорації Google, основане на мові Dart.

Його особливість полягає в гарній оптимізації коду, архітектури та інтерфейсу для всіх типів систем, форматів і розмірів екрана. До того ж мова програмування Dart вважається досить зручною.

Застосунки, створені на базі Flutter, підтримують як ARM, так і x86-64 архітектуру та можуть працювати водночас на багатьох ключових операційних системах. Серед них: Android, iOS, macOS, Linux та навіть Windows.

Ці програмні рішення мають хороші показники продуктивності, співставні з нативними застосунками.

Серед інших переваг:

  • Потокове редагування коду. Під час емуляції ПЗ можна корегувати функції та стежити за змінами в режимі реального часу.
  • Дизайн. Штатного функціонала фреймворку достатньо для створення сучасного та елегантного стилю застосунка, віджетів.
  • Швидкість розгортання. Розробляється лише тіло програми, яке контейнеризується для встановлення на цільових платформах.
  • Універсальність. Весь дизайн, функціонал та екрани створюються для базової платформи, з подальшою адаптацією під інші.

На нашу думку, перелічені особливості Flutter й роблять його одним з найперспективніших рішень для кросплатформової розробки. Проте окрім переваг, фреймворк має й низку очевидних недоліків.

Типові проблеми фреймворку:

  • Мультиплатформова розробка. Так, це є і плюсом, і мінусом. Зокрема, під час застосування низки IT-рішень потрібно орієнтуватись на особливості всіх цільових операційних систем одночасно, що в деяких випадках створює незручності та нагромадження в коді.
  • Погані механіки для SEO. Неможливість підключення SSR (Server side rendering) для оптимізації швидкості роботи та налаштувань індексації контенту сайту.
  • Слабка маршрутизація. Навіть у випадку веброзробки сайт на Flutter залишається за своєю суттю мобільним застосунком. Тому під час переходу на нього весь статичний контент завантажується повністю, навіть якщо наразі не використовується.
  • Занадто довга перша компіляція новоствореного проєкту та наступний білдінг release-версій для iOS та Android. У великих проєктах на підготовку релізної версії може витрачатися 15-40 хвилин.
  • Інколи болючі переходи між major-версіями. Мова та фреймворк активно змінюються, тому постійно виникають особливості, що потребують від розробника додаткової роботи (наприклад, як у випадку з появою null safety).

Утім повертаємось до історії розробки.

Початок роботи над вебсайтом

У нашій компанії існує така практика, що перед стартом будь-якого проєкту ми завжди маємо сформулювати чітке розуміння, навіщо ми його робимо і яких цілей прагнемо досягти.

Тому й цього разу поставили собі низку конкретних вимог до результату:

  • проактуалізувати дизайн сайту;
  • повністю оновити застарілий технічний стек;
  • підготувати та наповнити вебсайт додатковими розділами та даними для більш потужного SEO;
  • реорганізувати навігацію та форму зворотного зв’язку;
  • покращити швидкість роботи та продуктивність сайту;
  • відключити російськомовну версію 🙂.

Для реалізації задуманого була сформована команда в такому складі:

  • два дизайнери (основний та арткерівник);
  • два Flutter-розробники;
  • backend-розробник;
  • QA-спеціаліст;
  • project-менеджер.

Сумарно розробка першої версії корпоративного сайту на Flutter, а також API та власної CMS зайняла орієнтовно 3-4 календарних місяці.

За цей час ми відмалювали приблизно 90% сторінок (десктоп, планшет та мобільну версію) й реалізували близько 75% всього майбутнього функціоналу сайту.

Закінчивши основну частину роботи, ми перейшли до етапу фіналізації проєкту. Він містив виправлення багів, додавання різноманітних «плюшок» у вигляді симпатичних анімацій, а також оптимізацію продуктивності та серйозну роботу з інструментами для SEO.

Зазначу, що в напрямі SEO та Digital marketing ми співпрацюємо з досвідченим агенством, яке одразу поставило нам жорсткі вимоги до структури сайту та підготовки до його просування.

Саме на цьому етапі ми зрозуміли, що історія розробки на Flutter пішла не зовсім у правильному напрямі.

Проблеми, проблеми й ще раз проблеми

Ще у розпал роботи над проєктом ми почали помічати проблеми зі швидкодією та завантаженням сайту, особливо в деяких сценаріях. Проте на початку вони проявлялися доволі м’яко.

Тому ми сприймали їх як тимчасові труднощі, які бувають у будь-яких експериментах і які з часом за умови докладання певних зусиль можна буде подолати.

Але що глибше ми в це занурювались, то більше нюансів з’являлось.

Проблема #1. SEO

По суті, у проєкті на базі цього фреймворку завжди існує статична сторінка, яка змінюється тільки тоді, коли повністю завантажиться рушій Flutter. І вже після цього починають прописуватися всі метатеги, розмітка та інші інструменти для індексації, а сайт стає видимим для пошукових ботів.

Проблема в тому, що зазвичай боти не дочікуються повного завантаження контенту, тому сайт не може нормально індексуватися у пошукових системах. Тобто фактично можливості SEO «з коробки» просто відсутні.

Для розв’язання аналогічної проблеми в типових JS-фреймворках був придуманий SSR, але у Flutter він не підтримується. Натомість все грунтується на CSR (client side rendering).

Цей нюанс впливає також і на відображення превʼю посилань на сайт, поширених у соцмережах, месенджерах тощо. Будь-яке посилання на певну сторінку сайта завжди відображатиме один і той самий статичний контент, який був прописаний для першої сторінки.

Порівняння відображення превʼю сторінок на Flutter та React.js відповідно

Проблема #2. Недостатня продуктивність сайту

Оскільки Flutter побудований навколо CSR, весь інтерфейс завжди промальовується на потужностях самого пристрою. Тому фреймворк надмірно навантажує пристрої, на яких запускається програма.

І якщо в браузері ПК це ще не так помітно, то під час завантаження на мобільних девайсах справи зовсім кепські.

Зокрема наш сайт «гальмував» настільки помітно, що нам не потрібні були навіть спеціальні інструменти для визначення рівня продуктивності.

Порівняння продуктивності сайту на Flutter та React.js відповідно

Фреймворк Flutter завжди завантажує весь вміст сайту замість необхідної сторінки.

Це викликає затримки та значний розхід трафіку на відкриття сайту. До того ж не найкращим чином впливає на оцінку продуктивності такими інструментами, як-от Google Performance Tools. У нашому випадку за 100-бальною шкалою сайт отримав гордий знак питання.

Цікавий нюанс: швидкість завантаження була різною для різних роздільних здатностей екрана. Найкращий результат зафіксували на розширенні 1080×1920.

Пізніше ми встановили, що рушій щоразу також завантажує Failing Font, який збільшувався в розмірах пропорційно до кількості статичного тексту. У нашому випадку в діапазоні від 10 до 300 мегабайтів.

Проблема #3. Низька швидкість завантаження

Під час блекаутів в жовтні 2022-го ми тестували сайт за допомогою 3G-модему. Його завантаження займало 30-40 секунд для кожного циклу. І це за умови, що корпоративний сайт тоді складався з відносно простих та «легких» елементів.

Підсумки. Прагнули SEO, а отримали лише проблеми

Як ви вже зрозуміли, з SEO виникло найбільше питань. Усе через специфіку рушія фреймворку та його роботу з таблицями стилів, контентом, а також одночасним завантаженням всіх елементів.

Проте саме оптимізація була одним з найголовніших тригерів для редизайну. Тому так легко відступити ми не могли.

Стикнувшись з проблемами розробки вебсайту на Flutter, ми полізли до інтернету. Передивились десятки статей та навіть зв’язались з розробниками фреймворку.

Але і вони не надали нам відповіді на всі запитання, а просто фіксували проблеми й відправляли їх у беклог.

До того ж в один момент у своїх пошуках ми натрапили на твіт одного з топменеджерів Flutter (тепер уже колишніх). У ньому йшлося про те, що, попри офіційну підтримку, фреймворк не варто застосовувати для розробки вебсайтів.


Сказати, що ми були здивовані, це не сказати нічого. Проте і після цього ми не полишили спроб довести проєкт до розуму.

Зокрема, знайшли частковий компроміс щодо SEO. Ми додали ще один плагін, що генерував HTML-розмітку для пошукових ботів, щоб вони хоч якось могли індексувати JavaScript/Dart-контент. Однак однаково до ідеалу було далеко.

Крім цього, ще майже місяць експериментів з продуктивністю не дав бажаних результатів. Через особливості фреймворку ми так і не змогли оптимізувати швидкість завантаження та промальовки UI до рівня, за який було б не соромно.

Отже всіх наших практичних навичок та солідного досвіду роботи з Flutter не вистачило для успішного закінчення проєкту.

Тому, врахувавши за та проти, ми вирішили відмовитися від подальших експериментів з Flutter. Адже результат був негарантований, а сумарно проєкт уже затягнувся майже на пів року. І подальша втрата на нього часу просто не мала б економічної доцільності.

Було ухвалене дещо неприємне, але справді необхідне рішення про кардинальну зміну стека і розробку вебсайту з нуля.

Ми вирішили повернутись до JavaScript, класичного для веброзробки, а саме — до Next.js. І вже за 2,5 місяці (від першої стрічки коду) сайт було повністю завершено, і він став доступний онлайн. Без жодних нюансів та проблем.

Резюме

Оскільки це був наш власний проєкт, та ще й в напівтестовому режимі — формально можна вважати, що експеримент пройшов вдало.

Зокрема, ми отримали експертний досвід використання Flutter з метою веброзробки, перевірили його плюси та мінуси на практиці, дійшли певних логічних висновків.

Проте з комерційної точки зору таку розробку назвати вдалою аж ніяк не можна. Це, скоріше, провал. Ми втратили купу часу, зусиль, грошей, а фактично не отримали жодного результату.

Зокрема ми підрахували, що сумарно на розробку версії Flutter було витрачено понад 1,700 робочих годин інженерів та менеджерів:

  • Design — 370 годин.
  • Flutter — 500 годин
  • Back-end — 350 годин.
  • Project-менеджмент — 380 годин.
  • QA — 160 годин.

Якщо припустити, що ми б замовили розробку такого сайту в невеликій сервісній компанії, а команда складалася б навіть не з найбільш дорогих мідлів з середніми рейтами $25-30, сумарна вартість проєкту для нас як для замовника становила б не менше $45,000.

Звісно слід враховувати, що ту ж Back-end частину ми використали повторно і під час розробки сайту на Next.js.

То що ж у підсумку: обирати чи не обирати Flutter для реалізації вебпроєкту? Вважаємо, що це рішення дуже індивідуальне.

Ваша відповідь — так, якщо ви пишете, наприклад, адмінпанель для вже наявного застосунку на Flutter. Ви можете залучити тих самих розробників чи навіть перенести певну частину коду, і це є великим плюсом.

Але перед тим, як взятися за будь-який вебпроєкт на Flutter, радимо відразу сформулювати ваші кінцеві цілі та задачі у середньостроковій перспективі. А саме: його майбутній маштаб, аудиторію, необхідність пошукової оптимізації й т. д.

Наша рекомендація із цього приводу така: якщо ваш вебсайт — це щось більше, ніж MVP чи адмінпанель, якщо він містить велику кількість графіки, статичних зображень й тексту або потребує SEO — відмовтесь від розробки на Flutter.

Натомість виберіть щось з перевіреного часом стека JS — це буде найкращим рішенням. Принаймні станом на зараз.

👍ПодобаєтьсяСподобалось32
До обраногоВ обраному3
LinkedIn

Найкращі коментарі пропустити

Якщо чесно, то для того, щоб побачити ці всі мінуси флпттера для веба мені знадобилося декілька годин, які я потратив для написання прототипу сайту для свого петпроекту.

У вас прямо тотальний про**б, але дякуюю, що поділилися. Не всі так можуть після такого.

Дякую за Вашу історію. Напевно, найскладніше в написанні історії про провал — це очікування, а потім відповіді на коментарі на кшталт «ну хто так робить?!», «і їжу було ясно!» і т.п. Хоча всі чудово розуміють, як розгортається фейл — думаєш до останнього, що розрулиш, впораєшся і таки пройдеш цей тернистий шлях і потім напишеш про саксес сторі. Але часто виходить навпаки, а пишуть про таке взагалі дуже рідко. Так що знімаю капелюха перед Вашою мужністю визнати провал і тим більше поділитися результатом з ком’юніті.

Могли б втратити більше, якби платили ринкові зарплати. Мені пропонували щось смішне (в районі 5 баксів на годину), коли я був з 4-ма роками досвіду у айті. На моє зауваження що мене продаватимуть за 25-50 баксів на годину кофаундер розлютився, та як це я смію рахувати чужі гроші, і не погоджуюсь на цифру що була значно нижче ніж та що стояла на djinni, коли мені писала їх ейчар та бачила її. Радий що не потрапив до них у рабство. Здивований що про недостатки флаттеру ви дізнались постфактум. Наведені у статті тези знає кожний хто працює з ним. Намагаючись найняти флаттер розробника якомога дешевше вистрілили собі в ногу. Чотко!

За информацию спасибо, правда не очень понятно почему Вы не пошли по стандартному пути:

1) выявить ключевые требования
2) накидать прототип для 1
3) проверить
4) делать уже продукт ..

а вы бросились сразу в пункт 4, попахивает политическим решением вида «делаем на ... а кто не согласен — в сад »

В коментарях забагато критики. Але стаття не стільки про флюттер як про систему прийнятті рішень в цілому.

Імхо, неуспішні проєкти вчать нас більше ніж успішні, і такий досвід теж важливо популяризувати — наступне покоління розробників скаже дякую.

Потрібно більше таких статей

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую за сміливість поділитись досвідом,
Читав як цікавий триллер.
Після того як дочитав, виникло питання.
Де саме сталась помилка?
Експерементувати то не є помилка, то є шлях до успіху.
Добрався в роздумах до наступного:
А яким чином результат розробки ( навмистно залишу це в абстракній формі) повинен бути використованим на мобільних девайсах.
І ось тут як на мене випливає проблема.
Згадно із задумом автора фреймворку — у вигляді ДОДАТКУ.
А згідно із задумом команди автора топіку : у вигляді САЙТУ.
Що булоб, якби результат роботи був завантажегний як додаток на мобільний?
Повангую, що картинка перформансу була б без знаків питання.

Одразу згадав досвід з MeteorJS... Для прототипчику прикольно, а далі це біль.

FlutterFlow не пробували? /жарт_офф
Дякую за історію,таких треба побільше на цьому ресурсі, а то срачі вже дістали

Flutter як дитина Гугла і купа проблем з швидкістю завантаження та SEO.... No comments. Дякую за чесну історію. Корисно

Зайшла на проект, де management обрав Flutter для реалізації веб(!)платформи з пошуку персоналу з думкою, що колись там ми зробимо ще й мобільні додатки. Що сказати — це непередаваємий біль й struggle кожен день. Плюсом до цього — всі розробники з Індії, які звісно до того Flutter в житті не бачили....

Взагалі, по всім тестам флатер по продуктивності далеко позаду жаваскриптів, жаби та пітонів. Чому ви раптово вирішили що на ньому хоч щось буде працювати швидко? Бо в гуглі писали шо ця дрисня «заміна с++»?

Бро, ви взяли фреймворк для мобільних додатків і здивувалися, що він криво працює у вебі?

Окрім створення сайту, ціллю було дослідити чи підходить Flutter для вебу та з якими труднощами можна стикнутись. Ми розуміли, що йдемо на певні ризики, хоч ми їх і недооцінили

Думаю зараз й з React18 й серверними компонентами багато хто дуже недооцінює ситуацію з Next.js та Remix — там є більше й гнучкіше механізмів зарахунок виконання на Bun й СloudFlare / Akamai Workers... але CD з A/B тестами потребує значних заморочок.

... поліфілив якось UIKit’и на React/RN + TailwindCSS — також доволі цікаве заняття. Загалом платформно-залежна верстка крива усюди, й ситуація з react-native-web по SSR не сильно відрізняється від flutter.

У вас не було в кого спитати й проаналізувати відповідні ризики розробки й підтримки, перш ніж залазити в Flutter ? — там багато сирих й недороблених рішень без життєздатної спільноти.

В коментарях забагато критики. Але стаття не стільки про флюттер як про систему прийнятті рішень в цілому.

Імхо, неуспішні проєкти вчать нас більше ніж успішні, і такий досвід теж важливо популяризувати — наступне покоління розробників скаже дякую.

Потрібно більше таких статей

Правда на факапах вчимось. Та висновки тут мають бути в тому що експериментувати треба на маленьких проєктах і на маленькі гроші. На про рівні треба використовувати перевірені рішення і саме рішення має прийматись в балансі між менеджеметном і розробниками де останнє слово як і відповідальність за реалізацію на девелоперах.

Так, дійсно. Була віра у те, що ми зможемо подолати перешкоди у процесі розробки, проте фінал цієї історії вже відомий.

Суть сайту яка? Щоб через пошукові системи користувачі знайшли Вашу компанію та замовили послуги. Розробники Flutter конкретно сказали, що SEO не працює зараз для розробки сайту на фреймворку. А тому, хоч з бубном стрибайте чи бігайте результату не отримаєте. Так, Ви отримали досвід і переконались. Але тут є нюанс, у статті було сказано, що Вас консультувала фірма:"Зазначу, що в напрямі SEO та Digital marketing ми співпрацюємо з досвідченим агенством, яке одразу поставило нам жорсткі вимоги до структури сайту та підготовки до його просування." Дивно, що вони не знали про це.

Ми вирішили випробувати можливості флаттеру для веброзробки на «власній шкурі», адже була потреба оновити корпоративний вебсайт. Якби ми отримали позитивний результат — могли б пропонувати таке і для клієнтів. Проте не сталось як гадалось.

Ви просто використали Flutter не за призначенням. Це дійсно App framework, робити на ньому сайт це все одно що на Qt WebAssembly.

Нам подобається Flutter і ми хотіли дослідити чи здатний він на більше. Цілком ймовірно, що SPA на цьому фреймворці буде працювати коректно.

Мені теж подобається Flutter. І я вивчав його не в останню чергу, щоб мати можливість робити сайти (веб-додатки) без використання Javascript. І це дійсно можливо, і дуже швидко робиться. Але традиційні підходи не замінить, на жаль.

Ми вирішили відійти від традиційних JS-фреймворків і спробували зробити корпоративний вебсайт на Flutter.
Саме цей факт, помножений на наш вдалий попередній досвід та традиційну схильність до експериментів і новаторства, переконав нас у доцільності такого підходу.

ото вас вштирило!

того, хто прийняв таке рішення, варто переврити на компетентність

Не зрозуміла калькуляція втрат.
Чи на react потрібен інший дизайн ? Чи для іншого ui потрібен інший бекенд?
Невже flutter вимагає дуже специфічних речей ?

Ми продовжуємо використовувати ті самі бекенд та дизайн і на реакті

Тоді варто рахувати втратами тільки час на FE? 500 годин * 30 (наприклад) і ось 15к, не так і багато :)

Ми розрахували скільки часу витратили на реалізацію всієї цієї задумки. Ну і потрібно ж було клікбейтний заголовок до цієї статті придумати 😄

Так буває, коли береш інструмент не розуміючи як він працює)
А чого брали?
Бо всі беруть!

Якщо припустити, що ми б замовили розробку такого сайту в невеликій сервісній компанії, а команда складалася б навіть не з найбільш дорогих мідлів з середніми рейтами $25-30, сумарна вартість проєкту для нас як для замовника становила б не менше $45,000.

Коли я був мідлом ви мені пропонували 5 чи 6 баксів на годину, про що я ще тоді залишив відгук на сторінці вашої галєри. А ви ще сказали що я офігів рахувати чужі гроші (свою зп) xDDD

Якщо порахувати в тих грошах які ви хотіли платити мені тоді, при тому що я пройшов дві співбесіди у вашу контору і ніхто не ставив питання до цифри на djinni в меншу сторону, то ви витратили не більше десяти тисяч доларів на свою гіга адмінку галєрну.

Якщо мідлам по 20 баксів платити, то грошей на експеритменти не залишиться.

Цікаво, що основою стала необхідність Server Side Rendering. Тобто взагалі можна було би взяти скажімо Word press чи Joomla і витратити в 10 разів меньше грошей на розробку ніж навіть Next.JS А решту грошей витратити на розкрутку сайту та цілком інтернет канал продажів і стратегію присутності в інтернет.

Или взять index.html и сделать все как надо, без джумл)

Как насчёт семантической вёртски и производительности? На вордпрессе не особо такое построишь. Лучше заплатить больше (не особо больше) за правильный сайт, чем использовать бесплатные плагины платформ для создания сайтов.

На вордпрессе не особо такое построишь.

вообще-то вордпресс дает штатные возможности управлять генерацией html на самом низком уровне. какую тему надо — такую и пиши.

и производительности?

кешируется в нем тоже — как глобально, так и фрагментарно.

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

они разные, плагины платформы для создания сайтов. Есть что да, не дают доступа к низкому уровню.

Лучше заплатить больше (не особо больше) за правильный сайт

Поэтому лучше заплатить меньше писателям сайта, которые потратят деньги и время на решение стопицот раз решенных проблем, и выбрать платформу с необходимым для задачи возможностями. Выйдет и дешевле, и быстрее.

Флаттер чудовий інструмент. Але в даному випадку не була проведена попередня аналітика платформи. Робили на авось:

традиційну схильність до експериментів і новаторства

Це як і модний amp свого часу. Коштувало нервів доводити недоліки тої технології перед керівництвом. Бо воно почуло модне слово, і давай тулити в проект.

Design — 370 годин.
Flutter — 500 годин
Back-end — 350 годин.
Project-менеджмент — 380 годин.
QA — 160 годин.

Нормально менеджер і дизайнер собі годин дописали)

Менеджер витратив більше бекенд розробника на 20 годин. Цікаво що воно за дизайн такий веб сайту, що його дизайнери робили 46 повних робочих днів ??? Чим звичайний шаблонний дизайн корпоративного сайту, трохи підведений під загальний стиль не влаштував — напевно тим самим що і необхідність випендритись і вдати з себе Google або : Facebook, Amazon чи Apple. При цьому результат — за Овчинніком «сайт візитка». Там навть не зрозуміло як зв’язатись з представниками компанії, щоб замовити послугу. І це по ціні в 45 к баксів.

Та і більше ніж FE деви (бо їх було двоє, тому і годин майже Х2)

Власне є вже не нова книга, де усі ці проблеми розписані. Технології з часом міняються зі швидкістю Торнадо, помилки в бізнесі — ні kniga.biz.ua/...​saita-bolshego-00639.html По факту розробку сайту, який не мав би коштувати більше тех штук баксів, пішло 45. І це гроші які мали би підти на маркетинг, зокрема SEO.

Те, що викотили пост мортем — молодці, не кожен так зможе 👍

Чисто теоретична думка майнула — якщо вже використовували Flutter для вебу, можна було б спробувати використати Dart для бекенду?

Раз пустились у авантюру, то вже йти до кінця, а також можна було б спробувати реюзати деяку логіку, якщо це можливо.

Плюс був би хороший кейс «ми змогли в Dart на сервері» 🙃

Дякуємо! Доволі цікава думка, розглянемо її в більш сприятливих до експериментів умовах 🤝🏻

Використовую Flutter для web у пет-проекті (в першу чергу щоб не розводити зоопарк технологій, бо мобільні застосунки на Flutter, та для реюза компонентів), також бачив проблеми з перфоменсом, але потім переключив рендерер з canvaskit (дефолтний) на html і стало краще.

от би вони ще й impeller для веба зробили, але не тойво

For this added implementation complexity, Web support has not been a priority at this time for the small team working on Impeller.
We are aware that these priorities might change in the future.

на хтмл проблем вагон i на скiльки я читаю то вони його вже не пiдтримують а вкладають сили в ВАСМ

а вы в следующий раз не жалейте, заплатите денег архитектору, он вам все как нужно подизайнит и поплывете весело без просера бюджетов

Архитектур))) смеялся))) корпоративный сайт затащит в одно рыло талантливый джун с полгода опыта или средний миддл с до 3 лет опыта.

Дододо, доводилось перероблювати після таких "

талантливый джун с полгода опыта

Простіше було з нуля заново

Это смешно. Это корпоративный сайт. Страница отдаются, формы заполняются? Что там переделывать? Какая ещё архитектура? 95 процентов синиоров никогда не видели ничего кроме 3 лэйеров стандартных в бизнес приложениях. И по инерции продолжают городить 3 лэйера во всех приложениях и пробрасывать сущности и Дто через эти лэйеры.

Навряд чи тут є проблема саме з архітектурою проєкту. Як виявилось з вже власного досвіду, Flutter це поганий вибір для створення багатосторінкового сайту

у вас проблема была в выявлении ключевых требований (ASR, architecturally significant requirement), отсюда неверный выбор стека и бюджета

Всі описані проблеми були широко відомі на момент старту проекту. Треба поміняти заголовок статті на щось типу «Забули загуглити — зробили і заплакали» )))

Ваша правда, для таких ризикованих проєктів важливо більше часу витрачати на дослідження

А я выкинул все «фреймворки» и с ворпресса (т.к. тормозил и ломаемый) перешли на самодельный сайт — ну написали на php. Суммарно 2 месяца заняло, 1-2 человека работали на этим — и в результате всё работает.
Страница отдаётся за 30-40 миллисекунд. Рендерится тоже ессно мгновенно, потому что нативный js без всякой новомодной херни.

Интересно, что не так?..

Все так. Jquery c плагинами (даже без npm) + бэкенд на чем угодно. И все работает.
И это касается не только корпоративных сайтов, а и практически любых сайтов с любой сложностью.

И это касается не только корпоративных сайтов, а и практически любых сайтов с любой сложностью.

Ні, ну це вже переборщили. jQuery лапша дуже хріново масштабується, тестується, та підтримується. Я б подивився на сайт типу ютуба, чи google photo, з jquery під капотом. А ще краще — подивився б на те, як його тестують та фіксять)

Ютуб невероятно простой сайт с точки зрения юай. Писан он скорее всего не то что на жеквери, а скорее всего ваниллой. Если кто то думает что если он накидает кучу компонентов в реакте и это не превратится в лапшу похуже жеквери, то это самообман. Фреймворки не помогут из плохого программиста сделать хорошего.

jQuery лапша дуже хріново масштабується, тестується, та підтримується. Я б подивився на сайт типу ютуба, чи google photo, з jquery під капотом.

Ну ютуб легко зліпити(якщо тільки фронт взяти), гугл фото не певен треба дивитися.

А ще краще — подивився б на те, як його тестують та фіксять)

Порівняно з чим?

Насправді сайт доволі складний, залийте своє відео і побачите, що далеко не усе так вже і просто. Хоча так, по деякім інсайтам уся фішка в бекенді який написаний переважно на С++.

Phonegapp, Cordova, Xamarin, React Native.

Я прям відчуваю біль з яким це писалося. Особливо перші дві позиції в списку.

Phonegapp

Имел опыт с этим уродцем. Врагу не пожелаешь.

Та там усе уродці, крім реакт нейтіва можливо, але і там є своя специфіка.

Це якось трохи дивно — сайт як джерело лідів, але роблять його на фреймворку, який у цьому плані проблемний. Чим вам WordPress не вгодив, який в плані можливостей для SEO-оптимізації дасть фору якщо не всім, то абсолютній більшості?

Ну, крім того, що було багато вільних грошей, яких більше нема )

Заднім розумом усі розумні, тільки не кажіть що ніколи нічого не фейлили. Звикли просто люди до підрядної роботи, так і робили власний сайт. Хоча треба було починати з бізнес концепції присутності в інтернет. Могло так статись — що той сайт візитка і взагалі не треба, а краще там якось промоутитись десь на фріланс біржах, та мати розкручені сторінки в соціальних сітях, щоб розширити воронку продажів і приводити клієнтів в компанію.
Для того щоб конкурувати по видачі в пошуках скажімо з TATA чи Accenture в ключових словах пошуку — треба вкласти в SEO декілька мільйонів доларів.
Вам зараз дати те саме — напевно так само зробите купу власних помилок. Питання тільки в тому розповісте ви про них товариству, або ні ?

Бо для більшості тих крутих і високотехнологічних спеціалістів вордпрес це фу, некрасиво і немодно. Зачасту це базується на «я в 2011 році на ньому робив свій перший сайт і щось лайно вийшло». Тому забивають цвяхи мікроскопом за 45к баксів, і потім про це розповідають на доу з позиції «не засцяв розповісти про факап»)

На Word Press чи на Joomla чи Drupal можна так само зафакапитись, запросто. Наприклад коли вирішив мігрувати існуючий контент з PHP Nuke чи e107 бо фу-фу там верстка не модна на таблицях.
Якщо ви перечитайте уважно, то помилка не в технології як такий, технологія добре робить те для чого видумана. А те для чого вона видумана — це вирішення типових проблем які стоять наприклад перед Google або іншими компаніями які впроваджують SAS, тобто помилка в архітектурі рішення. І вона швидше бізнесова ніж чисто технічна, пов’язана з bottom up проектування не від бізнес проблеми — а від технології тобто з низу. Це власне трапляється бо бізнес стратегія індустрії давно полягає в тому, що ми повторюємо за Google та іншими FAANG часто бездумно. Це взагалі класична поведінка для радянського і пострадянського бізнесу взагалі. Брати успішну іноземну ідею бізнесу (будь якого від шоубізу до мілтечу) і адаптувати її тут. Треба відмітити, що тим не меньше це дає доволі високий процент успіху, звісно якщо проаналізувати ідею добре.

Зафакапити можна що завгодно, само собою. Але ми розглядаємо варіант розробки сайту з нуля. В данному випадку є вже ідеальні варіанти стеку для цієї задачі, і факап був на етапі «не обрати цей стек». Розмірковувати що «та і там могли б налажати» це вилами по воді.

Та я навіть більше скажу, можливо навіть той веб сайт та SEO оптимізація не надасть тих бізнес результатів які очікуються.
Якщо подивитись на лідерів індустрії аутсорсу TSC та Accenture — то в них якісь криві зовсім сайти (бо нема сенсу дивитись на Google якщо ти займаєшся іншим видом діяльності). Тим не меньше це багатомільярдні корпорації. Напевно в них є якісь інші дієві канали виходу на клієнтів ніж класична інтернет розкрутка, яка вже років 10 для малих компаній швидше базується на розкрутках через соціальні сіті та виходу на таргетовану аудиторію іншими шляхами. В одному зі своїх відео венчурний інвестор Гай Кавасакі називав першою з 10 проблем бізнесменів — брати великий ринок і вважати, що буде легко взяти з нього 1%. Насправді виходе — що один процент від великого ринку взяти неймовірно складно.

Сайтик галеры никогда и не был каналом продаж. Максимум на 20%.

Скорее на 0.2%. Обычный способ — приезжаєт условный индус в эмиграцию устраивается там на работу контактором в компании и подтаскивает своих на подряды и субподряды, уже через интернет. Потом открывается там офис и юр лицо, местные HR и далее масштабирование через релокейт и инсайты. По факту все на личных связях и интернет не особо задействован вообще, кроме рынка труда в странах где клиенты находятся.

У маленьких украинских шлюпок на 5-10 гребцов, бывает кто-то заблудиться и наппишет в контактную форму. Но возможно нашли эту шлюпку на линкедине или фейсбуке, а оттуда уже пошли на сайт.

Тесть сайт хоть на PHP хоть на Flutter хоть на Brainfuck++ или Visual Basic script, главное чтобы на него пришел потенциальный заказчик т.е. — лид, и при этом ему было бы удобно и быстро без лишних обратных связей, звонков и прочих попыток врулить ему dynamic pricing (когда цена зависит от того кто покупатель) и других трюков продавцов по повышению общего чека с покупки о которых все и давно все знают, потому что эра интернет, узнать приблизительную цену и сроки реализации и связаться с «прорабом» чтобы обсудить предварительные условия. Тогда вопрос ? Зачем тут SEO оптимизация — продажа ссылок, таг менеджмент и т.д. вообще ?

Месьє експерт, і вже розклав тут все по поличкам, а ви тут зі своїми спрощеннями. Не заважайте людині демонструвати експертизу, якої вона по відео Гая Кавасакі набралася )

Та і про провалам, також не експерт. Що правда не настільки сміливий щоб розповідати подробиці як наприклад зібрав команду — а клієнт счез і перестав відповідати (після чого настало прозріння для чого потрібні посередники безпосередньо за кордоном, юристи і т.д.). Чи як витратив півтора року на інтернет проект типу Stack Oveflow та не отримав жодної монетизації і т.д. зато експериментував з міграціями на Joomla чи переписуванням на Java EE і т.д.

Зробив на ньому свій перший сайт ще в 2008, а в 2011 там вже були реалізовані можливості, які значна частина фрейморків для лісапедів з нуля, не мають і досі. Тому так, варіант з цвяхами і мікроскопами найбільш ймовірний )

можливості, які значна частина фрейморків для лісапедів з нуля, не мають і досі

Яка різниця між фреймворками для лісапедів і фреймворками не для лісапедів (типу «серйозними»)?

Не треба вкладати декілька десятків тисяч доларів у розробку того, що вже доступно з коробки.

Так і на коробочник рішеннях від скажімо Oracle або IBM взагалі мільйони доларів втрачають на ліцензії, коли різні експерти втюхують їм рішення яке може бути все боко гірше ніж скажімо безкоштовна версія Magento Commerce або Drupal commerce і т.п.
І за ті гроші які пішли на ліцензії по факту безнадійного легасі (а там реально мільйони в деяких випадках мінімально два), можна було зробити повністю кастомне рішення яке відповідає структурі бізнесу — а не закривати усе костилями з величезною командою в 120 людей, та рвати волоси на заду коли стало ясно — що воно ще і виїдає шалені апаратні ресурси і при цьому все одно не витримує елементарне навантаження та навіть не підтримує дві сесії від одного користувача з двох різних пристроїв бо розроблено індусами на початку нульових коли про такі вимоги не йшлось. А потім з тими американцями та підрядниками судитись доводиться.
Помилки в невірно обраному фреймверку, зазвичай насправді мають інші глибинні першопричини.
А так to google Flutter CMS та отримується якесь рішення з коробки із Flutter як дуже треба www.ebizondigital.com/...​headless-cms-for-flutter

Дякую за Вашу історію. Напевно, найскладніше в написанні історії про провал — це очікування, а потім відповіді на коментарі на кшталт «ну хто так робить?!», «і їжу було ясно!» і т.п. Хоча всі чудово розуміють, як розгортається фейл — думаєш до останнього, що розрулиш, впораєшся і таки пройдеш цей тернистий шлях і потім напишеш про саксес сторі. Але часто виходить навпаки, а пишуть про таке взагалі дуже рідко. Так що знімаю капелюха перед Вашою мужністю визнати провал і тим більше поділитися результатом з ком’юніті.

Сергію, дякуємо! Цей весь негатив був очікуваним насправді, адже полити брудом в коментах — то нескладна робота)

Типова історія про ірраціональну ескалацію або як ще називають «незворотні затрати»

«ну хто так робить?!», «і їжу було ясно!»

Ну й про фундаментальну помилку атрибуції теж )

Коротше не вони перші, не вони останні. В інтернеті купа історій де застосовують якісь модні технології недоречно, ті ж мікросервіси, а поітм дивуються а чого це команада займається тільки інфраструктурними задачами, фіксить баги з пропущеними івентами або неконсистентністтю в бд замість того щоб писати нові фічі.

Дякуємо за такий теплий відгук, Сергію!

Это тот случай когда коммерция решила что она сильнее разума и практическая борьба показала кто главный

Могли б втратити більше, якби платили ринкові зарплати. Мені пропонували щось смішне (в районі 5 баксів на годину), коли я був з 4-ма роками досвіду у айті. На моє зауваження що мене продаватимуть за 25-50 баксів на годину кофаундер розлютився, та як це я смію рахувати чужі гроші, і не погоджуюсь на цифру що була значно нижче ніж та що стояла на djinni, коли мені писала їх ейчар та бачила її. Радий що не потрапив до них у рабство. Здивований що про недостатки флаттеру ви дізнались постфактум. Наведені у статті тези знає кожний хто працює з ним. Намагаючись найняти флаттер розробника якомога дешевше вистрілили собі в ногу. Чотко!

То есть отношения строятся на «я начальник — ты дурак». Тогда все понятно ...
почему бросились делать без прототипа, почему пишется «мы» при такого размера провале, который явно следствие приказа «делаем на ... и не жужжим» ...

flutter насамперед це не про високі зарплати, а для бажаючих зекономити на нативній розробці

Так, це про те що один програміст замість двох окремих зробить два додатки з одною code-base, це не про те, що цьому програмісту можна платити нижчеринкову зп і економити на тому.

Все одно якось дивно: один програміст мав би отримувати меньше ніж два, а у випадку із флаттером, то один програміст отримує меньше ніж один.

судячи з цієї теми, і те, що вони 1700 годин витратили на провальний і очевидно безперспективний проект — вони таки знайшли веб-девелопера і менеджера за 5 баксів на годину ))

вибачте але заголовок з розряду «Як програти 45к $ в казино»
Як сказали нижче — Флаттер насамперед інструмент для мобільної розробки, в меншій степені десктопної

Дякую за статтю. Не зовсім моя предметна область, але було цікаво ознайомитися. Всі люблять розповідати про історії успіху, але розповіді про кейси подібні до вашого — набагато корисніші. :)

Дякую що поділилися досвідом, саксес сторі ділитись звісно набагато легше, тому тут вам респект

Слід сказати, що тоді Google позиціював Flutter насамперед як платформу для мобільної розробки. Але згодом було заявлено і про підтримку web- та desktop-застосунків.

Саме цей факт, помножений на наш вдалий попередній досвід та традиційну схильність до експериментів і новаторства, переконав нас у доцільності такого підходу.

отут не зовсім ясно для чого все таки був вибраний Flutter, трохи нагадує про мем як хіпстери беруть фреймворк через 0.0001 секунди після його релізу, сорі :)

Дякую за відгук. Як вже було згадано вище, ми вирішили як ця платформа себе поведе саме для web та desktop, адже на той момент кейсів в інтернеті було небагато. Згодом ми зрозуміли чому саме)

Ми вирішили повернутись до JavaScript, класичного для веброзробки, а саме — до Next.js.

Цікаво, зараз на «ванільному» JavaScript ще дійсно пишуть, чи мова йде про Typescript?

«ванільний» js і реакт це дещо різні речі)

ванільний JS це JS без фреймворка, а не TS

Ок :)
Моє питання було більше про вибір мови — на зразок того, як Java люблять замінювати на Scala чи Kotlin

А Typescript тепер панацея для встого, і його треба пихати кругом і завжди?

А чому люди на фронті ставляться до всього, як до релігії? :))) це пояснює оці всі баталії за next best framework.

Я ж просто запитав на чому пишуть. Та й мені особисто на Typescript приємніше було писати, ніж на JS.

«Новий, покращений, тепер із банановим смаком»? Ось тобі й маєш... Висновок: тренуватися треба на кішках, а серйозну роботу робити на інструменті, в котрому впевнен.

Цікавий досвід, дякую.
Давно під SEO не роблю, так як немає таких вимог в моїх задачах, але цікаво яка зараз ситуація з SEO і JS. Чи є якісь надійні рішення окрім SSR?

Хлопці реально думають шо провалились в 2022-2023 зза поганих оптимізацій в пошукових системах?

думаю там більше проблема була в ux, а саме те що юзерам треба було чекати досить довго щоб хоч щось побачити. Це дуже суттєвий фактор, і до речі, ще одна причина чому heavy webassembly like .net blazor чи інші що викачують по 3мб initial наврядчи взлетять

Авжеж ніж. Проте часи важкі, тому важливо використовувати всі наявні інструменти, як онлайн, так і офлайн

с одной стороны как для человека, не занимающегося вебом и застрявшего на две декады в понимании актуальности эволюции решений в этой сфере, вышеописанное кажется дикостью on so many levels.
с другой же, странно видеть на данном ресурсе комменты, критикующие подход и предлагающие простые коробочные решения. камон, мы все знаем но не признаем насколько vaporware вот это вот всё.
тут же типичный пример самоиндоктринации, когда впарили дичь не кастомеру, а самим себе.

SEO це настільки неймовірно платинова проблема для SPA що дивуюсь коли в 2023 наступають на ці граблі. Я зіткнувся з цим ще в далекому 2015 коли СТО теж вирішив робити по суті контентний сайт на реакті. Що тоді тільки не придумували — і пререндерер, і ssr, і так далі. Особливо я сміявсь з тверждень типу «гугол бот достатньо розумний щоб відрендерити ваш джаваскріпт тому не партесь».

це проблема настільки бородата що страшне
ще у 2001 буле абсолютно все теж саме с Flash сайтами котрі тоді поважали для статусності

о, Флеш!
щойно спробував згадати, коли я його востаннє бачив на сайтах і не можу — давно мабуть

Да лааадно. Огромные предприятия за бугром до сих пор работают на сильвере.

Там навіть не те що в CSR проблема, а в тому що Flatter не використовує ніякі нативні компоненти ні на мобайлі, ні на вебі. Тобто якщо CSR в будь якому випадку можна чи закешувати публічні сторінки, чи якось прикрутити SSR, то флатер видає в HTML просто купу своїх влсних тегів, які браузер не може зрозуміти.
І тому це в рази гірше ніж, бо це по суті як робити вебсайт на Unity або просто відображати весь контент на canvas. У вас мінус не тільки SEO, а ще й Accessibility і всі стандартні речі для вебу віддані на переробку розробникам фреймворку. Будете потім розбиратись чому ховер не працює, чи навігація з клавіатури, чи скрол лагає, чи в accessibility tree не видно лейблу для іконки. А якщо базуєтесь в Європі чи Штатах, то ще й хорший шанс що вас засудять.
Дивно що це не озвучується в статті, хоча б пост портем пожна було б розібратись.

якщо не помиляюсь флаттер теж канвас використовує

той випадок коли не використовувати який небуть Wex це прямо велика помилка.
потратили б гроши на якісний дізайн і все

Бачу проблему у тому, як ви на старті робили порівняльний аналіз чи просто огляд технічних рішень. Мати вимогу щодо SEO і обрати інструмент без підтримки серверного рендерингу. Це як взагалі? :)

У свою чергу пробував Флатер для мобільного застосунку. Вступ був досить неочевидним для фронтендера, але з часом, з читанням документації і практикою ставало легше та цікавіше. До проду аппку тоді не довів, та виглядало цілком реалістично.

Дякую, що поділилися цінним досвідом!

Навіщо взагалі на корпоративний вебсайт витрачати стільки годин?
Це ж просто веб сайт, це не застосунок!

Флаттер гарний, коли вам треба розробити саме кросс-платформений застосунок. Наприклад для ведення бухгалтерської документації чи якусь адмінку для якогось сервісу і т.д.
Щось, де будуть форми, кнопки, CRUD і т.д.

А навіщо робити сайт з нуля, тим більш не флаттері...
Є ж гарні конструктори сайтів — той же Wix. Є інші конструктори.
Є різні CMS, є різні теми для них і т.д.
Тобто можно обрати для будь яких потреб і на будь-який гаманець. Умовно від 100$ до 10000$.
Але нащо це все робити з нуля?
Крім реалізації амбіцій когось в керівництві, хто хоче випробувати, що стильно, модно, молодьожно...

Корпоративний вебсайт це величезна робота зазвичай, бо робота по ньому ніколи не може бути спланована від початку до кінця. Це постійна гонка та експерименти. Тому такі, і навіть більші бюджети виправдані.

Как это все смешно, все эти флаттеры, реакты. Возьми jQuery с плагинами и готовой темой за 20 долларов и просто сделай несчастный сайт. Все гениально просто, быстро и эффективно и главное дешево.

Можливо задача була трошки іншою — спробувати флаттер на веб, наступити на всі можливі граблі, набратись експертизи.
Але стаття подає це під іншим кутом. Тому всі в ахуі як так сталось)

нам цікаво було спробувати якесь нетипове рішення, хоч і воно вилізло тріііішечки боком)

А замовник поділяв вашу зацікавленість?

це був наш власний сайт, а не сайт замовника)

Тоді пробачте. В цьому випадку ви молодці.

всі працювали безкоштовно, чи хтось таки оплатив витрачені години?

Всі робочі години було оплачено. Навіть здивувався, що хтось міг би подумати інакше

За информацию спасибо, правда не очень понятно почему Вы не пошли по стандартному пути:

1) выявить ключевые требования
2) накидать прототип для 1
3) проверить
4) делать уже продукт ..

а вы бросились сразу в пункт 4, попахивает политическим решением вида «делаем на ... а кто не согласен — в сад »

Дякую за статтю!

Та окреме дякую, що поділились саме провальним досвідом бо то рідкість

Google дуже активно просуває Flutter, але я очікую розвитку Rust-екосистеми, яка буде покривати SSR та CSR, beta.tauri.app або yew.rs

Заголовок клікбейт, дуже приємно)

Фреймворк не відповідав вимогам — для чого було починати?

Дякую за відгук! Коли Флаттер тільки вийшов для мобільної розробки, то він теж не покривав «з коробки» усі потрібні нам кейси.

Але така вже ціна за бажання бути early adopters. 🙂 І це стосується не тільки Flutter, а і будь яких новинок у розробці.

Все так.
Тим не менше в данному випадку не той кейс.
Одна справа коли фреймворк не покриває усі кейси(бо це фізично неможливо) інша коли фреймворк прямо каже «не для того мама квіточку ростила»

У документації вказуються на обмеженість флаттер вебу. Тому дуже дивно що ніхто з команди не зауважив на те що «гомеопатія це не ліки».
docs.flutter.dev/...​tform-integration/web/faq

Якщо чесно, то для того, щоб побачити ці всі мінуси флпттера для веба мені знадобилося декілька годин, які я потратив для написання прототипу сайту для свого петпроекту.

У вас прямо тотальний про**б, але дякуюю, що поділилися. Не всі так можуть після такого.

Дякую за відгук! Пет-проекти також робили, і повністю згоден, що можна було пошвидше «стопнути» розробку. Але якщо чесно, до останнього вірили, що щось придумаємо і за рахунок солідної експертизи вивезем. Так само як і у випадку розробки мобілок на ранній стадії розвитку Флаттера.

за рахунок солідної експертизи вивезем

Вибачте)
Але тут я не можу не розсміятися)))
Вся солідна експертиза закінчилась на тому що документацію не подивились ;-)

Жесть. Було таке що манагери хотіли флатер для вебу бо модно. Важко повірити що таке рішення могло виникнути в девів.

Може девів то й забули спитати

не треба недооцінювати 23-річних архітектів

— Дякую за відгук! Якщо чесно, то ми вірили, що як і у випадку з моб. розробкою на Flutter кілька років тому (а вона була максимально сирою), зможемо домучати його хронічні болячки і для web.

Підписатись на коментарі