Programista vs dzisiejeszy FRONTEND DEVELOPER, Przyszłość programistów PHP Opcje

[markonix]

Jak większość od zarania dziejów zacząłem od PHP i równolegle przy jednoosobowych projektach wymuszone zostało też na mnie nauka frontendowych technologii (css, jquery itp.).

Patrząc na oferty, bywając na jakichś konferencjach widać wyraźnie przesunięcie w stronę frontendu. Frontendowiec kiedyś dla mnie był kimś kto kroił szablon i zrobił mi formularze i na tym koniec. A jak jest teraz? Jak oglądam wynalazki takie jak Angular co to widzę? Bindowanie, layouty, routing - takie pojęcia od razu na myśl mi przynoszą jakieś komponenty z moich frameworków PHP, tu wygląda jakby co raz więcej logiki biznesowej zostało przenoszony bliżej przeglądarki.

Jaka jest dzisiaj rola backendowca? Pytanie zwłaszcza do osób pracujących w firmach.
Pisanie API dla frontu? Wydaje mi się, że i tak dużo musi zostać po stronie backendu - cała logika obliczeń, bazy danych, walidacja?
Jak wygląda kod PHP? Czy to w ogóle jest kod PHP czy inny język?

Tak troszkę abstrahując od powyższego - czy warto się uczyć mi takiego Angulara gdy cały projekt robię sam? Jaki jest próg wejścia bo na pewno nie można tego traktować jak kolejne jQuery? Czy w Anguarze stosuje się normalne templatki (boostrap, gotowe szablony) czy muszą one być jakoś dostosowane pod jego użycie?

Ten post edytował markonix 15.09.2016, 23:54:32

[by_ikar]

Minęły czasy, dlatego że i strony przestały być tylko stronami, a coraz bardziej są aplikacjami, których UI jest porównywalnie skomplikownay do tego w desktopowych aplikacjach. Mało tego, taką stronę-aplikacje możesz sobie opakować w elektrona/node-webkita/jakąś instancje chrome i możesz wówczas mieć aplikacje desktopową na różne systemy, w tym także mobilne. Strony przestały już czekać na kliknięcie użytkownika żeby przeładować treści, teraz bardzo modne jest tworzenie real-time aplikacji, w których mogą pracować całe zespoły. Ot dokumenty google, spróbuj takie coś ogarnąć w jquery, najlepiej w jednym pliku.

[Dejmien_85]

Minęły czasy, dlatego że i strony przestały być tylko stronami, a coraz bardziej są aplikacjami, których UI jest porównywalnie skomplikownay do tego w desktopowych aplikacjach. Mało tego, taką stronę-aplikacje możesz sobie opakować w elektrona/node-webkita/jakąś instancje chrome i możesz wówczas mieć aplikacje desktopową na różne systemy, w tym także mobilne. Strony przestały już czekać na kliknięcie użytkownika żeby przeładować treści, teraz bardzo modne jest tworzenie real-time aplikacji, w których mogą pracować całe zespoły. Ot dokumenty google, spróbuj takie coś ogarnąć w jquery, najlepiej w jednym pliku.

Ta opinia jest najbliższa moim obecnym odczuciom.

Gdy zaczynałem karierę programisty na zaszczytnym stanowisku "klepacza PHP", wtedy oprócz logiki sporo czasu spędzałem na HTML-ach i przygotowywaniu widoków (taka niestety rola PHP-owca była, chcąc nie chcąc zawsze trzeba gdzieś wypluć HTML-a i ruszyć go trochę choćby w mniejszym stopniu).
Przykładowo Wordpress wymagał (i dalej wymaga!), aby człowiek na backendzie obsłużył generowanie widoku. Lepiej było z frameworkami (np. CodeIgniter - ciągle mówię o starych czasach), tam warstwa logiki była już całkiem fajnie oddzielona od prezentacji, "klepacz PHP" powol przekształcił się w programistę (niestety, ale Wordpress wypaczył umysł wielu niczego nieświadomym ofiarom).

Dla mnie frontendowiec był za tamtych czasów osobą, która znała dobrze HTML, CSS, potrafiła obsłużyć Photoshopa, a także i sieknąć fajny slider w JavaScripcie (lub jQuery).

To co się stało później to już dość spora rewolucja. Zgadzam się, że aktualnie aplikacje napisane w JS przypominają złożonością aplikacje desktopowe. Przyznam, że byłem w dwóch projektach, w których złożoność apki SPA napisanej w Angularze i Backbonie była bardziej skomplikowana, niż przeciętna apka desktopowa z jaką człowiek na co dzień się boryka. Te apki to już poważne monstra, które trzymają swój stan i borykają się z tematami wycieków pamięci (i tutaj czas docenić prostotę PHP, tj. działanie tylko na czas żądania HTTP).

Co prawda sporo rzeczy dzieje się ciągle na backendzie, jednak front obsługuje znaczą część logiki biznesowej (zdałem sobie z tego sprawę gdy zauważyłem, że zespoły frontendowe pracowaly nad zadaniami, którey zawierały w sobie logikę biznesową). Oczywiście nie wszystko może dziać się na froncie, bo kod JS jest dostępny publicznie, jednak naprawdę wiele, wiele, bardzo wiele dzieje się na froncie. To już nie te stare czasy, kiedy wypluwało się templatkę strony i ewentualnoe dodawało kilka smaczków przez jQuery (poprawka: niektórzy tak jeszcze robią).

Ale, ale - to bardzo dobre dla backendu. Backend ma jasne i dobrze określone zadania, które opierają się głównie na przetwarzaniu danych i obsłudze bazy danych. Mnie osobiście aktualny stan rzeczy odpowiada. Jest jasny podział pomiędzy frontem i backendem. Lubię to. Jedyne co łączy frontend i backend to kanał I/O. Tak powinno być. Człowiek może zmienić cały backend, przepisać apkę z języka A na język B nie tykając nawet jednego bitu w aplikacji frontendowej. I to samo działa w drugą stronę.

BTW. Aktualnie jest straszny brak frontendowców na rynku, słyszałem to od managerów ze swojej firmy, a także kolegów pracujących w innych firmach (także na stanowiskach managerskich).

I w sumie niewiele się zmieniło poza tym że doszły do tego nowe narzędzia i wymagania,

Obywatelu, ostatnie 5 lat to chyba w jakiejś jaskini przesiedzieliście. ; )

[!*!]

Ale, ale - to bardzo dobre dla backendu. Backend ma jasne i dobrze określone zadania, które opierają się głównie na przetwarzaniu danych i obsłudze bazy danych. Mnie osobiście aktualny stan rzeczy odpowiada. Jest jasny podział pomiędzy frontem i backendem. Lubię to. Jedyne co łączy frontend i backend to kanał I/O. Tak powinno być. Człowiek może zmienić cały backend, przepisać apkę z języka A na język B nie tykając nawet jednego bitu w aplikacji frontendowej. I to samo działa w drugą stronę.

Tylko, że tak było od... zawsze?

Obywatelu, ostatnie 5 lat to chyba w jakiejś jaskini przesiedzieliście. ; )

Ale z klimatyzacją i skrzynką whisky (IMG:style_emoticons/default/wink.gif) Za kilka lat być może nie będziemy słyszeli o połowie z tych narzędzi, albo i nie biorąc pod uwagę jak co niektórzy zachłysnęli się tymi "nowinkami". I nie mam nic do tego co i w czym zostanie zrobiona określona funkcja serwisu/aplikacji byleby nikt nie wchodził sobie w paradę, tylko że czasami od tych bzdur wygłaszanych przez... chciałem napisać fanatyków, ale to było by za mocne, dostaje gorączki... Przykładowo menadżer projektu w jednej z trójmiejskich firm radośnie oznajmił "porzucamy jQuery, ponieważ jest angular" i fajnie, firma robi aplikacje głównie mobilne, gdzie faktycznie angular jest niekiedy plusem, ALE to było wypowiedziane w kontekście jakiejś małej funkcji która miała działać asynchronicznie...

Za kilka lat czeka Nas wszystkich rewolucja... Ktoś odkryje że logika biznesowa może być generowana po stronie serwera, a cały frontend nie musi być inwazyjny a na dodatek nie będzie katował urządzeń na których jest wyświetlany. Mówię Wam, to zatrzęsie całą sceną... web2.0 to pikuś.

[Dejmien_85]

Za kilka lat czeka Nas wszystkich rewolucja... Ktoś odkryje że logika biznesowa może być generowana po stronie serwera

Sądzę, że ta teoria ma swoje dobre strony, przykładowo fronty byłyby bezpieczne, bo backend mógłby sobie na serwerze po cichu obrabiać ważną logikę (nie pokazując kodu tej logiki) - wiemy jak to wygląda na froncie, kod jest dostępny i można się próbować wbijać do apki.

Zastanawiam się jednak jak to odnosi się do zasad SOLID (głównie do literki S), a także do znanego stwierdzenia "Low Coupling i High Cohesion". Mam tutaj na myśli mieszanie frontów w backendzie. Automatycznie tworzymy monolita, w którym backend i front są od siebie zależne i pogłębiają tą zależność z każdą linia kodu.

, a cały frontend nie musi być inwazyjny a na dodatek nie będzie katował urządzeń na których jest wyświetlany.

Możesz wyjaśnić co masz dokładnie na myśli?

Wydaje mi się, w tym wypadku inwazyjność fontendu się pogłębi - zacznie podbijać backendy.
Nie wiem też dokładnie co masz na myśli poprzez "katowanie" urządzeń.

Ostatecznie generowanie frontów na backendzie nie różni się niczym od podrzuceniem linku do zwykłego pliku JS. Na backu można wygenerować tylko statyczne strony i pliki, później i tak to wszystko
musi wczytać przeglądarka i przerabiać. Wydaje mi się, że z katowaniem nic się nie zmieni.

Już się zaczęło przecież. Ember zaczął i nagle w obozach Reacta i Angulara zauważyli, że coś w tym może być (IMG:style_emoticons/default/wink.gif)

O własnie, Ty tutaj jesteś Yodą od frontów, mam do Ciebie pytanie.

Zastanawiałem się jaki jest sens generowania frontów na backendzie. Gdy jakiś czas temu grzebałem się w jednej apce z Reactem i przeszukiwałem samouczki, to widziałem
w kilku miejscach przykładu kodu, w którym komponenty reacta były generowane z backnedu (Node je wypluwał).

Nie zastanawiałem się nad tym zbytnio, bo nie miałem czasu, ale urodziło się wtedy pytanie w mojej głowie.
Przejrzałem przelotnie tamten kod, to co było napisane w backendowym-react nie różniło się zbytnio niczym od frontendowego-reacta (były to po prostu najzwyczajniej w świecie napisane komponety, tak samo jak się je pisze dla "frontów").

Pytanie więc brzmi - jaki jest cel takiego działania? Podziel się proszę swoją mądrością. ; )

Ten post edytował Dejmien_85 21.10.2016, 13:02:01