FRONTEND jak to wygląda w pracy ?

Witam,

Od czasu powstania moich postów, ukierunkowałem się na frontend. Zrobiłem kilka statycznych stronek, i jakieś proste projekty w js. Zastanawiam się jakie skille prócz dalszego rozwoju js, i frameworków doszlifować.

Czy typowy frontendowiec który korzysta np z reacta, bawi się w jakieś bardziej skomplikowane animacje css? Wiadomo że można być frontendowcem który ma jakieś ukierunkowane lepiej wykształcone technologie i czuje się w nich dobrze. Czy w pracy takie osoby są rozdzielone na warstwy które odpowiadają typowo za wygląd WOW, i skupia się na css, a ktoś inny np buduje warstwę OOP aplikacji ?

Czy powinien dobrze robić każdą z tych rzeczy podaną w ogłoszeniu ?

Pytanie może wydawać się bez sensu, ale narodziło mi się gdy zacząłem rozwijać swój projekt w czystym Jsie z użyciem zew bibliotek. O ile funkcje, i manipulacje doomem fajnie mi wychodzą i nie mam problemu z dodaniem nowych funkcjonalności do aplikacji, a jeśli mam to jakoś szukam rozwiązania. To wygląd samej aplikacji nie robi super wow.
Tworząc większy nie mam za dużo do roboty w css i animacji bo opiera się bardziej na funkcjonalności. (Większy mam na myśli, większy dla mnie, dalej bez użycia np node ) . Czy warto też czasem np zaprojektować coś w figmie z animacjami i spróbować taką stronę główną z wodotryskami zaprojektować ? Typu animacje, slidery itp.

W korpo aplikacjach UI zazwyczaj ma wtórne znaczenie a liczy się UX + kwestie często accesibility. Jeżeli ktoś tworzy na rynek konsumencki zazwyczaj wazny tez jest sam UI. Jedyny podział jak ja spotkałem to ew UI Designer który przygotowuje mockupy, palete barw a cała reszt nalezy do frontend lub fullstacka developera.

@Schadoow: Tylko że pracuje się zazwyczaj w zespołach. Czyli jest np zespół przeznaczony za implementacje i stworzenie z makiety ui, całą warstwę wizualną ? Czy np bierze ktoś taska że pracuje nad ui a ktoś inny już implementuje coś innego ?
Czy np jest w zespole ktoś kto za lepsze skille css i ta osoba klepie właśnie to zawsze bo czuje się w tym lepiej, a później bierze inne taski.
Cały proces tworzenia apli wiem ze zaczyna się od ux, pomysłu itp, później mockupy, prototypy, i już docelowy prototyp.

Cały proces tworzenia apli wiem ze zaczyna się od ux, pomysłu itp, później mockupy, prototypy, i już docelowy prototyp.

Chciałbym żeby tak wyglądało :v. Pracuje już pare lat i mockup dostałem w całym jednym projekcie. Zazwyczaj dostaję dokumentacje z paleta firmy, loga i na tym koniec.

Nie spotkałem się ze specjalnymi zespołami. Zazwyczaj zadania bierze się wedle priorytetów. Wiadomo w zespole trafiają się różni ludzie z różnymi preferencjami i potem często podczas dzielenia tasków można się tym kierować. Ale myślenie, że zawsze tak będzie jest mocno życzeniowe.

To wszystko zależy od miejsca pracy. Ja np. pracuję jako full stack, przez kilka lat pracowałem w React- od UX mieliśmy dedykowany zespół który dawał nam gotowe mockupy, my mieliśmy tylko to przenieść na markup. Od zaawansowanego CSS mieliśmy do pomocy doświadczonego w tym developera. Teraz pracuję w innym stacku i wszystko obecnie trzeba robić samemu (chociaż to ma ulec zmianie bo są otwarte pozycje dla UX).

Mimo wszystko uważam że jeśli chcesz rozwijać się w pełni jako frontend developer to wypadało by opanować CSS w stopniu zaawansowanym. Jakby nie patrzyć to jest to integralna część wyglądu stron.

To frontendowiec nie zmienia tylko labelek i koloru guzika?

A tak na serio ;) to nie ma podziału na ludzi od Reacta i ludzi od CSSa - z tego co kojarzę, to jest sporo już gotowych komponentów jak chociażby Material Design czy inne gotowe rzeczy. Czasami okej, trzeba zrobić coś customowo i wtedy można coś podziałać na cssach bezpośrednio. Ale raczej nie ma tak, że w pracy chcą od Ciebie, żebyś zaprojektował im sam szatę graficzną i sam wymyślał bajery - wymyślają UX Designerzy czy inni.

O ile funkcje, i manipulacje doomem fajnie mi wychodzą i nie mam problemu z dodaniem nowych funkcjonalności do aplikacji, a jeśli mam to jakoś szukam rozwiązania. To wygląd samej aplikacji nie robi super wow.

No to znaczy jedynie, że efekty Twojej pracy są słabe skoro ich za dobrze nie widać. Jeśli to Cię boli wtedy lepiej jest ukryć się za backendem.

Czy typowy frontendowiec który korzysta np z reacta, bawi się w jakieś bardziej skomplikowane animacje css?

Zależy od potrzeb, im bardziej dynamiczna treść tym częściej zmierza się w tym kierunku.

Czy powinien dobrze robić każdą z tych rzeczy podaną w ogłoszeniu ?

Sam sobie odpowiedź czy taka opcja Ci leży. Jeśli czujesz, że to co robisz ma jednak wartość to olej ogłoszenia, a skup się na wymyślaniu rozwiązań na problemy, które bardziej Cię ciekawią. Jestem pewien, że jak zrobisz coś ponad szablonowego to zainteresujesz sobą więcej firm, niż robiąc to co obecnie jest wymagane w ogłoszenia. Jak ktoś potrafi robić złożone projekty w Angular to czemu np. miałby się nie odnaleźć w React, i vice versa.

@Pinek: @Aventus: @Schadoow: Z perspektywy czasu jeśli jeszcze w ogóle pamiętacie swoje początki jaki tryb nauki byłby dla was lepszy.
Chcę stworzyć projekt który za zadanie ma przechowywać trasy kierowców oraz punkty na mapie. Taki menadżer dla logistyka. Pomijając które biblioteki i technologie będę musiał uzyć oraz kwestie funkcjonalności, to tylko przykład żeby zobrazować mój problem. Dla osoby która zna podstawy jsa, bez reacta i noda. Lepiej.

A. Rzucić się na taki projekt i starać się pracować i uczyć na żywym projekcie, szukać informacji, i implementować - wiadomo po znajomości podstawowej teorii danej technologii
B. Ćwiczyć daną technologie na małych projekcikach typu pseudokod zanim weźmie się za większe. By później po zdobyciu jakies podstawowej praktycznej wiedzy dopiero zabrać się za taki projekt.

Wiem że doświadczenie to podstawa i tego nie uniknę, a także to że trzeba zmierzyć się z problemem.

Obierając to w inne słowa czy jest sens katować daną mniejszą cześć technologii aż poczuje się w niej w miarę ok, zanim wezmę się za jakiś projekt ?

Mogę się wydawać takie pytania idiotyczne i trywialne, ale zastanawiam się czy nie tracę za dużo czasu na naukę wszystkiego po trochu. Z drugiej strony mam wrażenie że jak pracuję nad jakimś żywym problemem to mimo że pisanie idzie wolniej, to samo szukanie rozwiązania i własna implementacja sprawa, że uczę się dużo więcej i dużo więcej zapamiętuję oraz że znam logikę danego rozwiązania. Kod nawet jeśli zapomnę, to pamiętam logikę jego rozwiązania.

Wiem że sama technologia i język to tylko narzędzie i jak wiemy jak ugryźć dany problem logicznie to implementacja rozwiązania opiera się o doświadczenie w kodzeniu.

Nie zrozumcie mnie źle, pytam was bo może błędnie się uczę. Kwestie robienia tutorialów już miałem za sobą i średnio idzie wyciągnąć z nich jakąś wiedzę bez implementacji i zmierzenia się z problemem samemu.

A)
Przy czym odzworowywanie trasy i zanzaczanie punktów na mapie to dość prosty temat np z uzyciem leafleta i routing pluginu.

https://leafletjs.com/
https://leafletjs.com/plugins.html#routing

80% to łączenie jsonowego api z backendu pod front.

To zależy na ile znasz te podstawy. Dam Ci przykład z autopsji- jak wiadomo najlepiej uczyć się na błędach innych ;)

Naukę pisania aplikacji webowych ogólnie zacząłem od przerobienia tutoriala ASP.Net MVC i następnie zabrałem się za pisanie własnej aplikacji w tej technologii. Problem w tym że prawie w ogóle nie znałem ekosystemu JS, chociaż w swoim mniemaniu znałem "podstawy"- wtedy nie zdawałem sobie sprawy że ogarnianie składni to jeszcze nie znajomość podstaw. Co za tym idzie kiedy przyszło do dodania bardziej dynamicznej funkcji- o ile dobrze pamiętam usunięcie czegoś bez przeładowania całej strony- to zaczęły się problemy. Coś nie zadziałało, a ja używając jakiś gotowy i tylko lekko zmodyfikowany fragment kodu oraz nie wiedząc jak w ogóle to debugować spędziłem pół dnia na dojściu do tego gdzie tkwi problem. Normalnie było to coś co powinno zając max 5 minut dla kogoś kto porządnie ogarnia podstawy.

Także jeśli możesz z pewnością stwierdzić że faktycznie dobrze ogarniasz podstawy które są Ci potrzebne, to wybierz opcję A. W przeciwnym razie opcja B jest lepsza, bo zaoszczędzisz sobie frustracji, lepiej spożytkujesz czas na naukę (pół-dniowe dochodzenie problemu to marnowanie czasu, nawet jeśli uda się coś drobnego w tym procesie nauczyć) oraz uzbroisz się w solidną podstawową wiedzę- będziesz miał gotowe klocki z których będziesz mógł znacznie łatwiej zbudować coś większego.

@Aventus: Trafiłeś w sedno z tym przykładem. Właśnie w takim miejscu stoję. Przy implementacji funkcji np edycji trasy / punkty też zaciąłem się na banalnym jak się później okazało problemie. Spędziłem przy tym 3h a powinienem max 15 minut. Plus to do siebie ma to taki, że już to zapamiętam na wieki, i że sam znalazłem rozwiązanie.

Pytanie do ciebie jak tych gotowych klocków się uczyć. Wiadomo mniejsze fragmenty kodów, jakieś modyfikacje, manipulacje na jakiś drobnych przykładach. Kwestia zapamiętywania rzeczy z takich tutoriali ma się różnie skoro ma się gotowe rozwiązanie w tutorialu czy filmiku.

Nie mam osoby która mi powie jak dany problem rozwiązać, a takie coś by było super i pewnie przyśpieszyło by naukę.

Aktualnie wydaje mi się że coś tam umiem, jeśli nie to wracam do jakiś poprzednich zadań by podpatrzeć kod i jakoś sobie radzę - ale nie są to skomplikowane rzeczy jak na razie. I nie wiem czy jest sens za branie się za dalsza naukę innych technologii.

@AventusL : jakbyś to ugryzł w tym punkcie w którym jestes?

Ciężko powiedzieć bo nikt nie wie tak naprawdę na ile już ogarniasz ten cały frontend. Jedno jednak jest pewne- rzucanie się na różne frameworki bez dobrej znajomości podstaw to nigdy nie jest dobry pomysł.

Natomiast zmaganie się z różnymi problemami jest czymś normalny, tak samo jak wracanie do zadań które się przerabiało- albo fragmentów kodu z aplikacji które się robiło wcześniej. Sam musisz ocenić na ile Twój problem był "naturalny" a na ile wynikał z nie wystarczającej znajomości podstaw.