![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 2 707 Pomógł: 290 Dołączył: 16.12.2008 Skąd: Śląsk Ostrzeżenie: (0%) ![]() ![]() |
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 |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 1 268 Pomógł: 254 Dołączył: 11.06.2009 Skąd: Świętochłowice Ostrzeżenie: (0%) ![]() ![]() |
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 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 15.10.2025 - 18:15 |