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?

Obecnie trwa bum na AngularJS, chociaż ostatnio szala przesuwa się na React. Po stronie serwera pisze się usługi, a po stronie klienta całą logikę prezentacji danych. Jako front-end developer musisz znać technologie wykorzystywane po stronie przeglądarki, czyli języki HTML, CSS, SASS, LESS, JavaScript, TypeScript, ES6, biblioteki AngularJS, jQuery, React, Embed.js, Bootstrap, Foundation, narzędzia npm, webpack, grunt, babel, bower, gulp i znacznie więcej. Minęły czasy, kiedy pisało się w czystym JavaScripcie, CSS i wystarczyło odświeżyć okno przeglądarki. Dziś większość firm używa jakiejś nakładki na JavaScript + LESS/SASS do generowania CSS-ów.

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.

I w sumie niewiele się zmieniło poza tym że doszły do tego nowe narzędzia i wymagania, 10-15 lat temu ludzie jarali się display:table w css i jquery, dzisiaj bootstrapem, angularem za kilka lat pewnie dojdą nowe twory, rzekomo to postęp, ale kto ich tam wie... A prawda pewnie jest taka, że daliśmy frontendowcom możliwość "programowania" aby nie czuli się gorsi i w końcu zaczęli coś robić, a nie tylko wycinać PSD przez 8h w firmie



Taka sama jaka była zawsze, i to nie ma znaczenia jakich narzędzi użyjesz do back/front-endu. Nauka nowych rzeczy o ile nie są wymyślone od czapy, zawsze się przyda, szczególnie jeśli to nadbudówka już istniejących, angulara, boostrapa, less bez js,html,css nie ruszysz, więc start jest ułatwiony

No ale jeżeli użyty jest Angular w froncie to nie ma żadnej zmiany po stronie backendu?
Rola warstwy biznesowej zostaje w backendzie, ale np. routing, jakieś walidacje, widoki bo nie wiem czy zwraca tam się np. json a widok sam już sobie te dane wyświetla?

Jak Angular to najczęściej REST API jednak. Angular załatwia na froncie widoki, routing, walidację - ogółem całą logikę aplikacji, a treścią wymienia się z webserwisem

Nie. Zmieniły się przeglądarki. Od gównianego IE, które miało problemy z wszystkim, do aktualnych przeglądarek, które robią nawet więcej niż powinny. Teraz? Progresywne aplikacje, działające offline, aktualizujące się kiedy będzie już połączenie. Takie rzeczy nie były nawet do pomyślenia kiedyś. Trendy się zmieniły. Osobiście nigdy nie uważałem kogoś takiego jak frontendowca który sobie wycinał obrazki z PSD. Dla mnie to było dość mocno naciągane. Zresztą dlatego też powstały te wszystkie szablony dla PHP, których nigdy nie trawiłem.. A moja awersja do nich, okazała się przyszłościowa, bo trendy się odwracają, i teraz potrzebna jest tylko komunikacja z frontendem.

Każda z technologii ma swoje zastosowanie i jej powodzenie zależy tylko od rynku i tego czy ktoś uzna że akurat w tej danej chwili jest ona najlepsza dla danego przypadku

Większość aplikacji szczególnie pracujących z urządzeniami peryferyjnymi jeszcze nie może być przeniesiona lecz moim zdaniem to się zmieni

jednak chyba masz na myśli urządzenia peryferyjne z automatyki... gdzie teraz urządzenia zarządzające takie jak Raspberry Pi są nie drogie i możesz odpalać na nich linux'a - więc gdzie problem uruchamiać języki skryptowe?? pewnie wyskoczysz o ogólnych kosztach gdzie wspomniałem, że małe... i o mikrokontrolerach które tańsze (a i tak wielu przepłaca za Arduino)... i dalej każdy chce zarobić... więc jedynie rodzinie zrobisz po totalnych kosztach...

@by_ikar - właśnie trendy, a one nie zawsze idą w parze z logiką. Np. angular jest schematem budowy aplikacji głównie opartych o js, tym czym było jquery dla ajaxa, wprowadza jeden, wspólny mechanizm. To czy dobrze zostanie on wykorzystany i czy prócz niego powinien działać stary, dobry backend to zależy od wyobraźni twórców aplikacji. A powiedz mi, bo chyba siedzisz w tym więcej niż ja, jak aplikacje tworzone w angularze mają się do indeksowania przez wyszukiwark (kilka lat temu google eksperymentowało z js, ale koniec końców nie wiem jak to się skończyło)

Nijak – stąd powstało http://prerender.io. A później ludzie przypomnieli sobie, że istnieje coś takiego jak "server-side rendering". Wielkie odkrycie 2015: stronę można generować na serwerze, wow-wow. Problem polega na tym, że z powodu tego, że taki React.js czy Angular.js są de facto w pełni oparte na DOM-ie, więc… generowanie po stronie serwera sprowadza się do odpalenia phantom.js/innego headless webkita i zescrape'owaniu DOM-u. Szaleństwo? Może, ale działa To samo się obecnie kombinuje dla Web Components. Czyli mamy takie Progressive Enhancement 3.0.

Równocześnie gdzieś się zatracił pierwotny nurt isomorphic webapps – chyba jedynym sensownym frameworkiem, który został z niego, jest Taunus. Z drugiej strony: boom na mikroserwisy przyciągnął ludzi ponownie do pomysłu z middleend (które dzisiaj się zwie "backends for frontends"). Czyli w skrócie: twardy backend to po prostu REST API (nieważne w jakiej technologii). Z tym backendem komunikuje się middleend, który generuje stronę (inną w zależności od tego, jaki klient się komunikuje) – i zajmuje się praktycznie wyłącznie tym – i przesyła do usera. Tam frontend przejmuje władzę i upgrade'uje całą komunikację z middlend przy pomocy Ajaksa. I jakbym miał zrobić całą skomplikowaną webappkę z backiem, to właśnie bym zrobił backend → middleend → frontend (w sumie będę wkrótce robił ).

No i nie można zapomnieć o nurcie Progressive Web Apps.

Wszystkie dostępne roboty internetowe wyszukiwarek działają synchronicznie, więc wszelkiej maści rzeczy które wymagają czas na załadowanie się, po prostu są pomijane. Działać JS działa, ale nie czeka taki crawler aż coś tam się z jakiegoś zasobu pobierze.


Osobiście mam do tego podejście że nie powinno się wszystkiego robić w angularze/reakcie/emberze/(czy co kto tam jeszcze wymyśli). Można napisać blog'a w jednym z powyższych, tyle tylko czy to powinno być tak zrobione. Jestem zwolennikiem "właściwa technologia do właściwego zastosowania" a nie jakieś fanatyczne "ja to umiem to będę w tym robić". Coś ala stawianie serwerów websocketowych w przykładowo php. Móc można, ale czy to powinno być w tym zrobione? Dlatego powstają jakieś alternatywy o których wspomniał @Comandeer, taki ratunek dla tych którzy muszą mieć bloga w angularze z jakiegoś powodu, ale potrzebują żeby to było dobrze indeksowane przez boty.

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).



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

Przy okazji tematu tak mi się przypomniało:

O, to słynne zdjęcie, które nijak się ma do dzisiejszej rzeczywistości… Tak, śmieszne

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



Ale z klimatyzacją i skrzynką whisky 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ś.

jeszcze nikt tego nie wrzucił

https://hackernoon.com/how-it-feels-to-lear...577f#.qk7s70yvq

Już się zaczęło przecież. Ember zaczął i nagle w obozach Reacta i Angulara zauważyli, że coś w tym może być

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.



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.



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ą. ; )

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" ) 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ść.

nie powiedziałbym że umie, odpala jedynie starając się uzyskać faktyczny wygląd strony i to robi nieźle

na onload można mu coś jeszcze wcisnąć ale i tak to raz działa raz nie działa

trzeba jeszcze chyba poczekać by przy pomocy js można było coś zrobić dla seo

Załóżmy że tworzysz aplikację która ma bardzo dużo efektów, jest po prostu prześliczna wizualnie, bo kto bogatemu zabroni. 90% efektów to JavaScript, reszta to CSS3 i SVG. Jako że cały budżet poszedł na te animacje, nie ma pieniędzy na stworzenie natywnych aplikacji mobilnych i trzeba posiłkować się RWD. I wszystko działa elegancko, każdemu opada szczęka jak to pięknie wygląda, całość została napisana w JS, prawie jak to Temat: zrobietaniejpl i wszyscy są zadowoleni, prócz osób które mają biedafony np Lumie 520 która jest bardzo popularna. Na tych i podobnych urządzeniach zamiaast ładnego i bogatego w efekty serwisu widać pokaz slajdów... w najlepszym wypadku, w najgorszym czystą, białą stronę, bo moc urządzenia nie pozwoliła na wyrenderowanie tego wszystkiego.
To właśnie jest ta inwazyjność JS, o której dużo osób zapomniało, a temat jest wałkowany co najmniej od lat 90. Dlatego odkąd siedzę w tej branży uważam że backend zawsze musi coś zwracać i być niezależny od działań frontu, jak już wspomniano dobrym przykładem jest tu samo google i gmail. Nikt z developerów nie musi się zastanawiać czy serwis zadziała komuś na urządzeniu X, bo i tak urzadzenie X dostanie choćby najbardziej okrojoną porcję danych

Panowie @Comandeer oraz @!*! - dzięki wam bardzo za rozjaśnienie sprawy! ; )

@kayman eksperymenty ze scraperem w PageSpeed i funkcją "Pobierz jako Googlebot" w Google Webmasters sugerują, że Googlebot to jakaś wykastrowana wersja Chromium (sugeruje to sposób, w jaki swego czasu interpretowały nagłówki CSP). Stąd można założyć, że w JS umie. Problem polega na tym, że np. zdarzenie load nie zawiera choćby inicjalnych żądań Ajaksowych, co sprawia, że już pojawia się problem – nie wiadomo bowiem jak taką stronę pobrać. Scraper w końcu nie może czekać w nieskończoność i sprawdzać, czy zawartość strony się zmienia po czasie.