Sam jestem fanem rozwiązań no code. Otwierają zupełnie nowe możliwości, ich dostępność zapewnia możliwość łatwej (taniej) realizacji rozwiązań, które wcześniej nie były możliwe bez dużych inwestycji. Ale muszę przyznać, że istnieją pewne aspekty no code, o których nikt głośno nie dyskutuje. Od czasu do czasu ktoś może o nich wspomina, ale w zasadzie ich podnoszenie nie jest na rękę firmom opowiadającym o „citizenship development” i innych tego typu historiach. Tymczasem technologie no code mają w moim przekonaniu pewne wady, o których warto wiedzieć.
1. Wejście nie takie proste, a wiedza potrzebna
No code to obietnica niskiego progu wejścia. W Internecie można znaleźć setki nagrań, gdzie ktoś kilkoma kliknięciami, już po jednym dniu nauki tworzy niesamowite rzeczy. Wielu osobom wydaje się, że „no code” to nie tylko „bez kodowania”, ale także „bez nauki” i „bez wysiłku”. To mit. To znaczy faktycznie, platformy typu Framer umożliwiają po godzinie zabawy wyczarowanie prostego landing page, zwłaszcza, jeśli opieramy go na gotowych komponentach graficznych. Ale tworzenie zaawansowanych aplikacji wymaga, niestety trochę nauki i wysiłku.
Weźmy Bubble. To moim zdaniem najlepsza, najbardziej uniwersalna platforma no code. Ale mówienie, że można z jej użyciem stworzyć skomplikowane rozwiązania po godzinie czy dwóch nauki jest lekką przesadą. Ok, prosta strona czy np. landing z zapisem danych do bazy da się zrobić po krótkim przygotowaniu. Niestety, szybko okazuje się, że nagle trzeba ogarnąć co to custom states (odpowiednik zmiennych lokalnych w językach programowania), czym różnią się frontend workflows (ciągi zadań wykonywanych w przeglądarce) od backend worflows (zadania po stronie serwera), jak używać option sets itp. Później nagle świeżo upieczony no-code’owiec zauważa, że przecież jest coś takiego jak bezpieczeństwo danych i musi nauczyć się zadbać o podstawowe ustawienia w tym zakresie. Chwilę potem odkrywa, że jednak do niektórych bardziej zaawansowanych rozwiązań potrzebuje czasem JavaScript, a w ogóle, to ekostystem Bubble jest wypełniony rozwiązaniami towarzyszącymi, uzupełniającymi pewne luki. Tak zaczyna poznawać świat API, połączeń z bazami danych itp. itd.
Niezależnie od zgłębiania jakichś technicznych rozwiązań charakterystycznych dla danej platformy, no code wymaga także często poznania ogólnych uwarunkowań technologicznych. Tzw. „nietechniczna” osoba szybko natknie się wchodząc w świat no-code na pewne bariery, których nie pokona nie przyswajając podstawowej wiedzy. Co to jest JSON, DOM, jak działa webhook – nie jest to jakaś wiedza tajemna, ale wmawianie komuś, że stworzy np. swój klon „Airbnb” zupełnie bez wysiłku intelektualnego i zrozumienia jak działają aplikacje internetowe jest w moim przekonaniu nie do końca uczciwe.
2. No code nie jest takie tanie
Jedna z podstawowych różnic pomiędzy programowaniem, a tworzeniem aplikacji narzędziami no code polega na tym, że w drugim przypadku praktycznie zawsze tworzymy coś w oparciu o rozwiązania komercyjne, stworzone, żeby generować zysk dla swoich twórców. W dużym skrócie no code to wyklikiwanie czegoś w gotowych systemach. Za wygodę, którą dają te systemy trzeba płacić. Na ogół mowa tu o opłatach abonamentowych. Strona postawiona na Framer czy Bubble to obowiązek opłacania rocznego lub miesięcznego abonamentu. Niewielkiego, pokrywającego hosting, certyfikat SSL, ale jednak.
O ile w przypadku prostej aplikacji web abonament dla platformy no code jest w zasadzie porównywalny z kosztem osobnego zakupu hostingu i innych usług, o tyle jeśli zaczniemy łączyć jedną platformę z innymi, abonamenty zaczną się szybko sumować. Np. we Framerze, żeby zbierać kontakty przez formularz, trzeba zarejestrować się na innym serwisie i tam wykupić osobny abonament. Tu trochę, tam trochę i w zasadzie łatwo się zorientować, że to duża droższa zabawa, niż początkowo sądziliśmy. Jeśli zaczynamy z kolei np. korzystać z możliwości automatyzacji łącząc z pomocą Make czy Zapier różne usługi, szybko może się okazać, że koszt „automatyki” to nie tylko abonament Zapier (tak, nie jest za darmo!), ale np. dodatkowo 2-3 dodatkowych produktów.
No code nie jest bezpłatne. Ma swoje koszty. Uzasadnione, dużo niższe niż wartość korzyści, które odnosimy tworząc aplikacje no code. Ale na ogół, w dłuższym okresie zauważalnie wyższe niż w przypadku rozwiązań stworzonych w tradycyjny sposób, a więc hostowanych niezależnie i zaprogramowanych w oparciu o bezpłatne technologie na darmowym frameworku.
3. Aplikacje no code i „cudza ziemia”
To dla mnie największa wada rozwiązań no code. Chodzi o to, że ponieważ budujemy w nich coś w oparciu o stworzoną przez kogoś platformę, bez niej nasze rozwiązanie przestanie działać. Jesteśmy w tym sensie uzależnieni od polityki biznesowej, cenowej i w ogóle losów konkretnej platformy, którą wybraliśmy.
Z przytłaczającej większości platform no code nie da się „wyeksportować” kodu. Nie istnieje taka możliwość. Można zapisać sobie jakieś dane, wyeksportować bazę danych. Ale same połączenia logiczne pomiędzy elementami, ich cyfrowe definicje istnieją wyłącznie jako zapisy w bazie platformy, z której korzystamy. Bez całego systemu, którym są otoczone, będą bezużyteczne. Dlatego aplikacja stworzona np. w Webflow, poza Webflow nie istnieje. Budowanie „na cudzej ziemi” w no-code ma też swoje proste, przyziemne wady. Przykładem jest zmiana cennika. Nie masz na nią wpływu, musisz ją zaakceptować albo zbuduj sobie wszystko od nowa, gdzieś indziej.
Tworzenie aplikacji no code i oparcie o gotowe platformy ma oczywiście także swoje plusy. Jednym z nich jest stabilność i bezpieczeństwo. Duże platformy takie jak Bubble wiedzą, że ciągłość pracy to kluczowy parametr, którego zakłócenie może zniszczyć cały ich biznes. Dlatego na pewno robią w celu zapewnienia stabilności aplikacji więcej niż Ty sam kiedykolwiek byłbyś w stanie zrobić samodzielnie. Stworzyłem w Bubble przez ostatnie lata wiele aplikacji i w zasadzie pamiętam tylko jeden poważniejszy problem, który był rozwiązany w ciągu kilkunastu godzin. Poza tym wszystko działa zawsze bez zarzutu i przerw. Tymczasem w przypadku serwisów tworzonych przez kodowanie, na ogół jest nieco więcej czynników ma wpływ na ich działanie. Awarie po stronie hostingu, aktualizacje serwera, wygasające certyfikaty, błędy wynikające np. z aktualizacji frameworków lub jakichś komponentów użytych przez programistę.
Jestem głęboko przekonany, że no code to prawdziwa rewolucja. Otwarcie nowych możliwości przed tysiącami ludzi. Wymienione wyżej, podobnie jak inne „wady” to niewielka cena za swobodę tworzenia, którą dają. Ale warto widzieć o rzeczach, które nie zawsze wynikają wprost ze stron producentów rozwiązań no code.
