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

[Comandeer]

Cel jest prosty: dostarczyć aplikację większej liczbie userów. W tym wypadku, jeśli oprócz app shella posyłamy także jakąkolwiek podstawową treść, user otrzyma przynajmniej krytyczną część naszej aplikacji. To się może przydać przy tak ważnych usługach jak e-mail (GMail to dobrze ogarnia, bo działa nawet na Lynksie!), gdzie tego typu server-rendering jest po prostu fallbackiem jakby JS-a jednak zabrakło (bo np. user właśnie wjechał do długiego tunelu kolejowego i internetu ani widu ani słychu, a nasze 800 KB Angulara się nie zdążyło ściągnąć).

Tyle z punktu widzenia PE (BTW w najbliższym czasie skubnę serię artków na temat pisania aplikacji w ten sposób ). Natomiast najbardziej trywialny powód (który zapewne twórcom Embera przyświeca bardziej niż moje pieprzenie o "większej dostępności" (IMG:style_emoticons/default/wink.gif) ) to po prostu większa wydajność. Server-side rendering zawsze jest szybszy przy pierwszym wczytaniu strony – nie trzeba bowiem czekać na zassanie całego silnika JS, żeby wygenerować cokolwiek na ekranie. Natomiast przy kolejnych wczytaniach strony oczywiście leci to już client side (albo wręcz offline/z cache'u jeśli mamy dostęp do Service Workera).

No i jest jeszcze jeden powód, dla którego takie rzeczy się robi: SEO. Google co prawda w JS umie, ale zaawansowanego Ajaksa i tak nie przetworzy, stąd server-side rendering pozwala łatwiej i skuteczniej pozycjonować treść.

Ten post edytował Comandeer 21.10.2016, 14:14:29