W ciągu ostatnich miesięcy coraz bardziej wzbraniam się przed wykonywaniem zadań frontendowych. Nie wzbraniam się oczywiście w pracy, bo tam nie mam luksusu wybierania sobie tasków, ale jeśli chodzi o projekty po godzinach, to wybieram takie, gdzie jest możliwie mało frontendu. Star Trek API jest przykładem takiego projektu, do którego dopiero w ostatnich dniach dopisuję jakikolwiek frontend, a wcześniej był do tylko kod produkcyjny w Javie i testy w Groovim.
W tym poście opiszę, jakie są powody mojego odchodzenia od frontendu.
Ciekawsze problemy
Problemy rozwiązywane na backendzie są ciekawsze. Złożone operacje biznesowe, wielkie zbiory danych, współbieżność, modelowanie domeny – to wszystko odbywa się na backendzie. Frontend, w idealnym świecie, dba tylko o odbieranie i zapisywanie danych za pośrednictwem wystawionego przez backend API o uproszczonym modelu. Można się spotkać z praktyką realizowania logiki biznesowej na frontendzie, ale abstrahując od wszystkich innych powodów, by tak nie robić, jeden wydaje mi się przesądzający. Nie należy rozbijać realizacji logiki biznesowej na frontend i backend, ponieważ nie sposób wyznaczyć, co powinność być realizowane na frontendzie, i dlaczego.
Mniejsza powtarzalność
Wolę nie robić w kółko tego samego. Wolę nowe rzeczy, i nie tylko jeśli chodzi o implementację nowych funkcjonalności, którą preferuję ponad realizację utrzymania istniejącego kodu. Wolę nowe rzeczy także jeśli chodzi o rozwiązywanie nowych problemów. A problemy na frontendzie mogą być powtarzalne, przynajmniej jeśli realizuje się typowy frontend dla aplikacji B2B albo B2C. Trzeba pociąć layout z PSD. Trzeba napisać kontroler w Angularze lub w innym frameworku. Kontroler pobiera jakieś dane, i może jakieś zapisuje. Trzeba poprawić CSS-y, bo znów inaczej wyglądają na Chromie i na IE. I tak dalej.
Upraszczam tutaj problem, ale wyzwania frontendowe to pewna dość wąska specjalizacja, w której łatwo popaść w rutynę. Są naturalnie ciekawe wyzwania frontendowe, ale jest ich relatywnie mało, przynajmniej takich, które bym nie pociągały. A pociągałaby mnie np. praca przy frameworkach do wizualizacji danych. Na pewno byłaby trudna, ale dająca satysfakcję.
Technologia
Na frontendzie nie ma alternatywy dla JavaScriptu. Jest długa lista języków i dialektów, które transpilują się do JavaScriptu, ale ostatecznie, w przypadku debuggowania kodu, i gdy zawodzą sourcemapy, zmuszeni jesteśmy do przedzierania się przez sieczkę, jaką jest kod wygenerowany przez transpiler.
JavaScript ciągle jest dość okropnym językiem, nawet jeśli piszemy w ES6. Ilość problemów nierozwiązanych do tej pory w JavaScripcie, a rozwiązanych lub nigdy nie istniejących w innych językach skłania mnie do myśli, że JS nigdy nie zostanie naprawiony, bo ciągnie za sobą ogon zbyt wielu złych decyzji podjętych na początku jego istnienia.
Ekosystem
Ekosystem javascriptowy jest pełen ciągle nowych frameworków, pluginów do tych frameworków, integracji między tymi frameworkami i tak dalej. Duże frameworki są finansowane przez biznes, któremu zależy na ich jakości, ale wokół nich wypączkowują różne mniejsze inicjatywy, często ciągnięte do przodu tylko przez jedną osobą. Często ta jedna osoba traci w końcu zainteresowanie swoim projektem, więc mamy bardzo dużo średnio działającego, niezbyt aktualnego, marnie napisanego oprogramowania. Kto nie wierzy, niech zobaczy na GitHubie, jak są napisane javascriptowe projekty, które mają tysiące gwiazdek. Wiele z nich nie przeszło by nigdzie wewnątrzfirmowego code review, gdyby podobny kod powstał w Javie albo C Sharpie.
I to kolejny problem JavaScriptu. Brak jest w tym ekosystemie znajomości i chęci stosowania dobrych praktyk, jeśli chodzi o wytwarzanie oprogramowania. Ciągle powstaje dużo kodu bez testów, stosowanie wzorców projektowych jest sporadyczne, a kod spaghetti ciągnie się kilometrami.
Podsumowanie
Nie jest tak, że narzekam na frontend, bo go nie znam. Przeciwnie, w obecnej firmie zostałem zatrudniony w dużej mierze ze względu na kwalifikacje frontendowe, bo na Javę dopiero chciałem się przekwalifikować. Po prostu, po tych paru latach, frontend mało mnie już ekscytuje, a na backend ciągle mam ochotę, zarówno jeśli chodzi o poszukiwanie nowych wyzwań zawodowych, jak i o poszukiwanie nowych tematów na projekty realizowany po godzinach.