Trudne aspekty front-endu

Hej hej - razem z moim zespołem przymierzamy się do zbudowania agendy następcy kursu Opanuj JavaScript (Przeprogramowani). Nasz pierwszy kurs był materiałem wprost dla początkujących, natomiast teraz idziemy krok dalej mówiąc o tym, o czym zwykle się nie mówi w kontekście social-mediowej bańki programistycznej (wiadomo, wszyscy na najnowszej wersji Nexta, wszyscy na Vercelu, wszyscy na GraphQL #not)

Debatując o samej agendzie kursu wybraliśmy kilka modułów, które w takim materiale mogą być istotne. Tooling, wydajność, czysty kod, współpraca z backendem, jakość, architektura, wzorce i dobre praktyki, praca zespołowa, etc.

Po długich debatach postawiliśmy na pięć modułów:

• Architektura - jakiego młotka użyć na gwóźdź, który akurat musisz wbić
• Jakość - zarówno na poziomie kodu jak i procesów wzdrażania aplikacji
• Wzorce i dobre praktyki - PubSub i przyjaciele
• Frontend zespołowo - reużywanie kodu, komponentów, prywatne repozytoria artefaktów, utrzymywanie inner source, etc.
• Wdrożenia i utrzymanie front-endu - cloud, monitoring, alerting, incident management, czyli jak szybko dojechać do pożaru

Na dzisiaj nasza agenda wciąż jest otwarta więc chciałem was poprosić o feedback. Co sądzicie o takiej tematyce? Jakich materiałów na temat frontendu brakuje w internecie, a pracujecie z nimi na co dzień i warto, żeby znali je inni? Ogromne dzięki za sugestie.

Wydaje mi się, że nie potrzebnie próbujecie zrobić z frontendu osobny "byt".

Jak ja tworzę front, to podchodzę do tego jak do każdej innej aplikacji: która ma input (akcje usera), wewnętrzny stan, przeprowadza operacje, i ma output (czyli widok, np html), i nawet persystencję (np localStorage). Też ma integracje z innymi systemami (np z backendem), i też ma logikę biznesową. Jak dla mnie, to panują tam takie same zasady co na backendzie i nawet poza webówką.

Koncepcyjnie, czym się różni webówka w Reacie od aplikacji desktopowej w Windows Forms albo JavaFx? Argumentowałbym że niczym.

Nadal input, output i model powinny być oddzielnie, nadal należy to przetestować automatycznie, nadal należy używać wzorców, etc. Moim zdaniem, to że frontend i backend to są oddzielne byty, to jest iluzja.

Myślę że wszystkie filmy oraz artykuły które już powstały na temat tego jak dobrze tworzyć software, dobrze wpisują się również we front.

psmyrdek napisał(a):

Na dzisiaj nasza agenda wciąż jest otwarta więc chciałem was poprosić o feedback. Co sądzicie o takiej tematyce? Jakich materiałów na temat frontendu brakuje w internecie, a pracujecie z nimi na co dzień i warto, żeby znali je inni? Ogromne dzięki za sugestie.

Brakuje na 100% dobrych tutoriali jak pisać testy automatyczne na front. I nie mam na myśli jakichś biednych sztuczek typu snapshoty albo wizualna regresja, tylko prawdziwe, dobre testy.

Riddle napisał(a):

Wydaje mi się, że nie potrzebnie próbujecie zrobić z frontendu osobny "byt".

Jak ja tworzę front, to podchodzę do tego jak do każdej innej aplikacji: która ma input (akcje usera), wewnętrzny stan, przeprowadza operacje, i ma output (czyli widok, np html), i nawet persystencję (np localStorage). Też ma integracje z innymi systemami (np z backendem), i też ma logikę biznesową. Jak dla mnie, to panują tam takie same zasady co na backendzie i nawet poza webówką.

Koncepcyjnie, czym się różni webówka w Reacie od aplikacji desktopowej w Windows Forms albo JavaFx? Argumentowałbym że niczym.

Nadal input, output i model powinny być oddzielnie, nadal należy to przetestować automatycznie, nadal należy używać wzorców, etc. Moim zdaniem, to że frontend i backend to są oddzielne byty, to jest

Zgadza się. Problem w tym, że cykl życia danej technologii na front-endzie to 3-5 lat, a dzisiejszy "regular" nigdy na oczy nie widział Windows Formsa albo JavaFX.

Tezą tego kursu nie jest to, że przedstawiamy nigdy dotychczas nie widziane aspekty programowania (bo zgadzam się, to ciągłe wynajdywanie koła na nowo), ale przedstawienie, powiedzmy "state of the art" wg rynku pracy 2023/2024. A tutaj jednak tę specjalizację w kierunku front-endu widać, i widać dedykowane role na takie zadania.

psmyrdek napisał(a):

Zgadza się. Problem w tym, że cykl życia danej technologii na front-endzie to 3-5 lat, a dzisiejszy "regular" nigdy na oczy nie widział Windows Formsa albo JavaFX.

Tezą tego kursu nie jest to, że przedstawiamy nigdy dotychczas nie widziane aspekty programowania (bo zgadzam się, to ciągłe wynajdywanie koła na nowo), ale przedstawienie, powiedzmy "state of the art" wg rynku pracy 2023/2024. A tutaj jednak tę specjalizację w kierunku front-endu widać, i widać dedykowane role na takie zadania.

Nie ma znaczenia. Niezależnie od dobranej technologii, te zasady są nadal aktualne.

Prawa o których piszę są takie same dla aplikacji w vanilla js, jquery, react, backbone czy jakakolwiek inna technologia webowa. Wszystkie aspekty specyficzne do jakiejś danej technologii (np jakiś feature jakiejś biblioteki, albo rest vs graphql) to szczegół implementacyjny; i tak na prawdę nie ma aż takiego znaczenia.

To co chciałbym zobaczyć na froncie to dobre testy automatyczne, SOLID i Clean Code.

To czy regular nie widział Windows Forms czy JavaFX, też nie ma znaczenia. Mogę napisać aplikację w Reacie, i nie ma znaczenia czy odpalę ją jako aplikację webową czy jako desktopową w electronie. Zasady wytwarzania takiego oprogramowania powinny być takie same.

Jakich materiałów na temat frontendu brakuje w internecie, a pracujecie z nimi na co dzień i warto, żeby znali je inni?

Takich aby kod nich zawarty był jakości która pozwoli mu przejść jakieś sensowne code review. Poza tym wolałbym mniejsze projekty ale bardziej wymagajace w kontekscie logiki biznesowej. A nie ze ktos robi CRUDa i dorzuca kontrolki z materiala. Poza tym masowo olewana jest dostępność, testy e2e i wykorzystanie cssa do budowania bardziej zaawansowanych layoutow. Wbrew pozorom css się bardzo rozwija i można zostać sporo w tyle.

Zgadza się. Problem w tym, że cykl życia danej technologii na front-endzie to 3-5 lat, a dzisiejszy "regular" nigdy na oczy nie widział Windows Formsa albo JavaFX.

Wypraszam sobie :P haha

Brakuje podejścia holistycznego i takiego biorącego pod uwagę fundamenty.

To by się przydało, ponieważ ludzie często myślą zbyt redukcjonistycznie. Nie w ten sposób, że wszystko stanowi część jednej całości, ale bardziej, że aplikacje to ileś niezwiązanych ze sobą rzeczy, których trzeba się "nauczyć" (czytaj: wykuć).

Np. często traktują architekturę jak coś, co się "nakleja" na projekt. Czasem nawet mylą samą strukturę folderów / nazewnictwo plików z architekturą. Albo stosują wzorce "na pałę". Poziom cargo cultu jest ogromny.

Tylko to jest problem - jak sprawić, żeby ludzie zaczęli myśleć całościowo, w kategoriach "dlaczego", a nie tylko "jak". Opiszesz jakieś wzorce, to często oleją "rationale", a wezmą tylko sposób implementacji czy modną nazwę.

Riddle napisał(a):

Nadal input, output i model powinny być oddzielnie, nadal należy to przetestować automatycznie, nadal należy używać wzorców, etc. Moim zdaniem, to że frontend i backend to są oddzielne byty, to jest iluzja.

Ja widzę np. zastosowanie tego, co proponuje się w DDD, do frontendu (mimo że DDD jest popularne raczej na backendzie). Np. zasadę aggregate root można stosować do komponentów React przy tworzeniu większych widżetów(agregatów) złożonych z mniejszych komponentów, które powinny być odizolowane od reszty aplikacji i sterowane tylko przez roota (komponent na szczycie danego drzewka).

A o takich rzeczach mało kto wspomina. Że wzorce stosowane zwykle w jednym kontekście można zastosować również w innym kontekście (jeśli ma to sens. Bo czasem ludzie na siłę próbują przenieść jeden sposób pisania z jednego kontekstu do drugiego. Np. próbują pisać w JS tak, jakby pisali w Javie. Trzeba wiedzieć, kiedy nie próbować na siłę przenosić pewnego mentalu).

Oczekiwania podczas pracy

psmyrdek napisał(a):

• Architektura - jakiego młotka użyć na gwóźdź, który akurat musisz wbić
• Jakość - zarówno na poziomie kodu jak i procesów wzdrażania aplikacji
• Wzorce i dobre praktyki - PubSub i przyjaciele
• Frontend zespołowo - reużywanie kodu, komponentów, prywatne repozytoria artefaktów, utrzymywanie inner source, etc.
• Wdrożenia i utrzymanie front-endu - cloud, monitoring, alerting, incident management, czyli jak szybko dojechać do pożaru

VS rzeczywistość :D

Też proponowałbym zagadnienia związane z accessibility, może nawet coś z zakresu seo, bo oba zagadnienia opierają się w dużej mierze na htmlu i mogłyby być ciekawe, gdyby je omówiono z programistycznego punktu widzenia.

W sumie w tej agendzie nie za dużo widzę o samy frontendzie :p.

Z ciekawości co kryje się pod tematem "Architektura" i "Wzorce i dobre praktyki".
Planujecie np dyskutować o architekturze w stylu semantic html, jak pisać strony pod systemy asystujące, architektura styli (i np różne podejścia w tym temacie) ?

Mówimy o architekturze aplikacji całościowo, np. jaki framework do danego typu aplikacji, skalowalna struktura projektu, separacja odpowiedzialności, praca w środowisku przeglądarki internetowej, mikrofrontendy, współpraca kilku frameworków w ramach jednego projektu, etc.