[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,

[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

[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

[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

[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

[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

[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

[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

[K.....a]

@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: 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

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

[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