[anonim1133]

#webdev #frontend #php #nieprogramowanie więc :P

µProgramiści!

Wciąż nie do końca pojąć mogę, czemu mają służyć takie wynalazki jak #angularjs #angular #ember #react. Jest sens tak dużo rzeczy pchać do użytkownika, tak dużo robić po jego stronie? Jakąś walidację formularza, wyłączenie przycisku, czy coś - rozumiem. Ale budowanie całej aplikacji(?) po stronie użytkownika?
Osobiście podoba mi się tworzenie aplikacji na jakimś klasycznym frameworku jak #symfony ( #symfony2 ) - podoba mi się składanie widoków w TWIG i w ogóle. Po co wszystko przerzucać na przeglądarkę, jak w zasadzie jedyne co trzeba zwykle zrobić, to przesłać jakiś formularz, czy podświetlić jakieś pole jak ktoś coś kliknie - nie wystarczy wtedy #jquery(czy jakaś inna lżejsza biblioteka)?
Jak tak patrzę na te samouczki i porównania w sieci na temat tych frameworków w #js to jakoś skomplikowane mi się wydają na miarę tego, co potrzeba. Do tego odsłaniają jednak sporą część logiki - co w aplikacjach biznesowych chyba lepiej aby pozostało na backendzie? Czy przy takich aplikacjach po prostu poświęcacie więcej czasu, aby budować dla każdego użytkownika(ze względu na jego uprawnienia) jakby osobną instancję takiego frameworku?

Wiem, że taka teraz moda, tworzyć mikroserwisy i pchać całą resztę w przeglądarkę. Ale czy za tą konwencją idzie coś po za samą modą i baranim pędem jak to zwykle bywa?

No dobra, jednak #programowanie ( ͡º ͜ʖ͡º)

[epi]

@anonim1133: chociażby po to, by nie pieprzyć się z tworzeniem widoków po stronie serwera, to nie jest fajne


do tego są projekty, które mają jeden backend ale wiele frontów: desktop, mobile, apki natywne itp
wtedy backend jest prosty, wystawia tylko api, a każdy z możliwych frontów z tego api korzysta
dzięki temu masz ładnie rozdzielone projekty, osobny na backend, osobny na apke na androida, osobny na frontend itp, czysto, schludnie, porządeczek

[michalfranc]

@anonim1133: To nie jest tak ze jest przymus. Masz projekt ktory wymaga wiekszej logiki po stronie klienta badz aplikacji SPA to dobierasz narzedzia ktore sa odpowiednie. Angular 1 byl strasznym burdelem ale byl to pierwszy krok w ewolucji. Tak samo zacznal C / C++ / Java / .NET. Zanim pojawily sie porzadne frameworki badz biblioteki potrzeba bylo czasu i eksperymentow. Czasem rewolucja przychodzila z innych community ( np community ROR kompletnie

[anonim1133]

chociażby po to, by nie pieprzyć się z tworzeniem widoków po stronie serwera, to nie jest fajne

@epi: Kiedy właśnie jest :P

do tego są projekty, które mają jeden backend ale wiele frontów: desktop, mobile, apki natywne itp

No ok, takie zastosowanie faktycznie by się sprawdziło wtedy co najmniej dobrze. Ale tak po za tym, kiedy aplikacja jest typowo webowa? Bezsens chyba trochę się robi? Szczególnie kiedy nie ma wyspecjalizowanego zespołu

[michalfranc]

@anonim1133: Ad microserwisy - unikaj mody. Hype i moda to droga do piekla. Developerzy ktorzy dobieraja narzedzia ze wzgledu na to jak sa hip and trendy to bardzo duzy problem. Cargo Cult programming to powazna sprawa. Wystarczy ze Netflix pokaze swoje podejscie szyte na ich miare i wszycy chca to powielic. Nie wazne ze w 99% przypadkach podejscie Netflixa sie nie sprawdzi.

Moja firma zrobila transformacje z monolithu do wielu mikroserwisow

[anonim1133]

unikaj mody

@michalfranc: Zawsze i wszędzie. Ale w pracy trochę chcą iść w tym kierunku - o ile nowości lubię, to takie ślepe podążanie za nowościami mnie nie jara. Staram się szukać, czytać, aby móc wyrazić swoją opinię jakoś obiektywniej i merytoryczniej niż "No wiecie, mnie to się nie podoba".

Cargo Cult programming

O jakie ładne <3

Moja firma zrobila transformacje z monolithu do wielu mikroserwisow ( trwalo to 2 lata,

[Greenek]

@anonim1133: olbrzymim plusem jest na pewno to, że możesz przerzucić część obciążenia z serwera na klienta. W przypadku skomplikowanych backendów, które i tak zjadają olbrzymie zasoby na swoje zadania (np. indeksowanie setek tysięcy eventów w czasie rzeczywistym), przeglądarka przejmuje całe renderowanie strony, co przekłada się też na prędkość działania aplikacji.

[michalfranc]

@epi: Wlasnie przechodzimy transformajce z .NET shopu ze wszytkim w .NET-cie na podzial API .NET frontend NG, React. Daje to nam duze mozliwosci na rynku pracy poniewaz nie musimy straszyc frontendowcow C# i Microsoftem bo nigdy tego nie zobacza. Moga sobie programowac na maczkach w JS-ie i nigdy nie dotkna swiata MS ( swoja droga jako developer C# tez przenosze sie na maczka bo i tak duza czesc czasu spedzam w

[michalfranc]

@anonim1133: Znaczy to nie byl atak na ciebie czy twoja firme. Tylko taka sugestia zeby przemyslec zanim sie zacznie. Nie twierdze ze twoja firma i ty podazacie bezmyslnie za moda :) Nie znam ciebie i twojego projektu. Skoro siedzisz na mirko i zadajesz pytania to raczej wieksza szansa jest ze jestes tym rzadkim przypadkiem odpowiedzialnego deva.

Nowosci trzeba poznawac bo rzeczywiscie tak jak mowisz bez tego nie ma nawet jak podjac

[epi]

Ale tak po za tym, kiedy aplikacja jest typowo webowa? Bezsens chyba trochę się robi? Szczególnie kiedy nie ma wyspecjalizowanego zespołu który by tworzył frontend i drugiego dla backendu?

@anonim1133: Generalnie dobrze jest dobierać narzędzia do zadania i pracować z technologiami, które się zna. W przypadku, który podajesz, to jest proszenie się o problemy ;)

Swoją drogą dziwne, gdy nie ma kogoś od frontu i kogoś od backendu.

W zeszłym roku

[anonim1133]

Nie twierdze ze twoja firma i ty podazacie bezmyslnie za moda :)

@michalfranc: Póki co nic takiego się nie dzieje. Szukamy właśnie czegoś "nowego" - a przy tym często natyka się człowiek na te wszystkie modna hasła.

[q.....k]

@anonim1133: może najpierw odpowiedź sobie na pytanie po co w ogóle coś zmieniać?:

http://i.wp.pl/a/f/jpeg/36120/01-wp-1998.jpeg

Plusem powstałego front-endu jest też to że nikt nie zmusza backendowca do uczenia się/robienia np. animacji, patrzenia na szczegóły w designie, praca nad UX, dopracowywanie widoku w RWD itd. Oczywiście można też zadać sobie pytanie po co RWD? po co animacje? po co SPA? po co Ajax? i robić strony tak jak wyglądały 20 lat temu.

Osobiście

[Klopsztanga]

@anonim1133: Anonimku, chodzi o szybkość działania aplikacji. Strona szybko się ładuje na ajaxie, niż cała od podstaw. Taki serwis jest przyjemny, bo szybki.

Kolejna rzecz to serwery :) One służą tylko do generowania danych - generowanie widoku przeważnie najwięcej zajmowało czasu serwera.

[W.....l]

@anonim1133: Angular zwiększa szybkość ładowania strony, zmniejsza ilość danych przepływających z serwera do użytkownika. Czasem lepiej na bieżąco ładować pewne treści jeśli będą potrzebne, niż ładować wszystko na raz mimo że większość tego co załadujesz nie będzie potrzebna. Np. Facebook mógłby ładować 10, 20 postów od razu, ale czasem potrzebujesz po prostu wejść na czat i nie interesuje cię co się dzieje na osi czasu. Jaki jest więc sens ładować treści

[W.....l]

@anonim1133: z resztą spójrz na to w ten sposób: wyobrażasz sobie windowsową aplikację natywną, która za każdym kliknięciem pobiera z serwera cały widok i potem renderuje go u użytkownika? Brzmi jak katastrofa, a tak właśnie robiono aplikacje internetowe ;)

[anonim1133]

@Wunderwafel: Ciekawa analogia w sumie.

[DanioPL]

@anonim1133: poza tym co tutaj chłopaki powiedzieli. Popatrz na to ze strony współpracy w zespole. Zamiast ludzi fullstacków możesz wykorzystać ich umiejętności tam gdzie są najlepsi. Jest jakiś feature do zrobienia i wtedy backendowcy spotykają się z frontendowcami i omawiają co tym drugim jest potrzebne w tym, powstaje dokumentacja endpointów i jeśli użyjesz do tego odpowiedniego narzędzia to możesz od razu zmockować to api i frontendowcy mogą z uśmiechem na ustach

[eXtreme]

@anonim1133: po co? Zacznij tworzyć jakiś całkiem spory panel SaaSowy standardowo w szablonach po stronie backendu. Na pewno będziesz potrzebować troche JSa tu i tam by całość miała ręce i nogi. Z "trochę" w końcu zrobi ci się "CAŁA MASA", najczęściej jQuery, jakieś manipulacje domem, mnóstwo eventlistenerów, bazylion bibliotek - ani to testować, ani mieć pewność że się nie rozsypie po jakiejś modyfikacji.

Inna sprawa to komfort używania takiej aplikacji. Robienie

[Jurigag]

@anonim1133: po to aby aplikacja po prostu chodziła szybciej, mniej danych do pobierania, cache htmla wbudowany w przeglądarce, brak przeładowania strony itp itd, ale jak dla mnie łączenie angulara i symfony to głupota, lepiej angular + phalcon, jedyne sensowne rozwiązanie

[anonim1133]

phalcon

@Jurigag: Używasz go produkcyjnie?

[Jurigag]

@anonim1133: oczywiście

[anonim1133]

@Jurigag: Powiesz kilka słów od siebie o tym cudzie?

[Jurigag]

@anonim1133: framework napisany w c + zephir, kompilowany do c, działający jako rozszerzenie do php, dzięki czemu masz załadowany cały framework zanim zostanie wykonany cały request, dzięki czemu odchodzi ładowanie 30-100 plików w każdym requescie jak w innych frameworkach, głupi json z bazy danych(już za którymś razem gdzie działa cache) prostego zapytania ma zawsze przewagę nad symfony czy laravelu w czasie odpowiedzi, bo ładuje tam jedynie jakieś 3-5 twoich plików zamiast

[anonim1133]

@Jurigag: Wszystko działa, wszystko jest? Niczego Ci nie brakuje? Może... Może to jest jakaś opcja.

[Jurigag]

@anonim1133: no przy zwracaniu jsona wiele potrzebne nie jest, brakuje mi jedynie jakiegoś wbudowanego systemu repozytoriów, ale zrobić jakiś prosty z faktorią to akurat jest chwila roboty, no i wadą może być że trza rozszerzać phalconowe modele aby mieć własne aby korzystać z query builderów itp tylko że wymaga to możliwości instalowanai rozszerzeń do php, na jakimś najprostszym hostingu tego nie zrobisz, potrzebny vps/hosting z obsługą phalcona, lub taki który go

[stacktrace]

@anonim1133: Uważaj bo Jurigag ma 60gr za wpis chwalący Phalcona. Framework jak framework, jego kod wykonuje się szybciej od innych to fakt i tutaj przewagi się kończą.

[anonim1133]

@stacktrace: Z taką opinią też spotkałem się już wcześniej, od kogoś kto ma łeb na karku. Toteż podchodzę sceptycznie trochę do tego Phalcona.

Ale poczytam zawsze chętnie, wysłucham zdania innych, nawet jak są trochę fanbojami jakiegoś rozwiązania/marki :P

[eXtreme]

@anonim1133: zanim dojdziesz do momentu gdy bedziesz potrzebował analizowac czy twoj kod bedzie dzialac szybciej na phalconie i jeszcze napisany w zephirze (bo uzycie samego fwk przy pisaniu duzego kodu w php niewiele ci raczej da) to minie mnostwo czasu :p
użyj php 7.0, pamiętaj o włączeniu i skonfigurowaniu opcache i masz wydajność jakiej potrzeba

[anonim1133]

@eXtreme: też się ku temu skłaniam. A jak kiedyś będzie za wolno, to będę się martwił.

[eXtreme]

@anonim1133: to dołożysz troche ramu i proca i bedzie dzialac ;)

[anonim1133]

@eXtreme: Przekonałeś mnie :D

[michalfranc]

@bazingaxl: wydaje mi sie ze ng to angular :P ale nie jestem ekspertem i tez moge sie mylic

Sa roznego rodzaju programisci i eksperci w roznych dziedzinach. Natomisat MS stack odstarza wielu programistow z innych community tylko dlatego ze jest kojarzony z Microsoftem ( pozostalosc po czasach Gatesa i Ballmera i ich wojny z open sourcem )

.NET dev backendowy nigdy nie bedzie tak dobry jak dedykowany dev JS specjalista (

[eXtreme]

@anonim1133: ale wiesz, to taki wybujały problem tak naprawdę. packagist.org znasz zapewne? https://github.com/composer/packagist tu masz źródła, to normalna, bardzo "standardowa" apka w Symfony2 (nawet jakiś super best-practicies nie stosuje), oczywiście nie że sf jest jakąś ciężką kobyłą, bo nie jest, a serwis zapierdziela przecież jak szalony i obsługuje całego composera. I wcale to nie stoi na jakimś superklastrze chmurowym ujwieco tylko o ile jakoś rok temu czytałem to stoi to na

[michalfranc]

@bazingaxl: zarobki w firmie moga wynosic i 60k. Nie wiem skad twoje przekonanie ze 80k to taka normalna stawka w Londynie :) Ale tak firma jest dosc znana i dobrze kojarzona + duzo osob kojarzy ja z dobrym zapleczem technicznym.

@eXtreme: Zalezy w ktorych kregach, angular nadal bedzie popularny.