[paul8585]

Mam takie oto pytanie otwarte z gatunku tych egzystencjalnych, w razie jakby ktoś wystarczająco expa w #webdev aby mieć wyrobione zdanie. Ostatnio zacząłem się uczyć frameworków #javascript i #frontend i tak sobie myślę, że co prawda odciążają one serwery na #backend , które są w #php czy innym #python . Natomiast z kolei sporo obciążają one przeglądarkę u klienta. Tak źle i tak nie dobrze. Macie jakiś pomysł na złoty środek, gdzie postawić granicę obciążenia? Chodzi mi o coś w stylu np. generować widok warto na backendzie, ale np. walidację już lepiej zrobić na frontendzie czy odwrotnie. Albo np. asynchroniczne żądania na froncie, cała reszta na serwerze. Będę wdzięczny za wasze zdanie.

[asdfghjkl]

@paul8585: Walidację czego?

[paul8585]

@asdfghjkl: formularzy, ale to był tylko przykład

[asdfghjkl]

@paul8585: Nigdy nie waliduj formalarzy po stronie frontu. Tzn możesz częściowo ale i tak drugi raz musisz to zrobić po stronie backendu ze względu na bezpieczeństwo. Na froncie jedynie jakaś wstępna walidacja co najwyżej. Co do obciążania to zależy od aplikacji. Od jej skali. To co będzie akceptowalne w jednej w drugiej już niekoniecznie.

[asdfghjkl]

@paul8585: Także nie ma tak że jakieś rozwiązanie jest jedynym i słusznym

[techko]

dziwne pytanie, bo w przypadku walidacji robisz ja po obu stronach, a obecne urzadzenia - w tym mobilne bez problemu radza sobie z obsluga nawet tych bardziej 'zasobozernych' aplikacji (btw. o jakie obciazenie chodzi? pamieci?, sieci?).

Zeby uniknac powstawania problemow trzeba robic wszystko w zgodzie ze zdrowym rozsadkiem i co wazne zdawac sobie sprawe z tego jak dana technologia dziala - wlacznie z zarzadzaniem pamiecia (tak garbage collector w js tez istnieje

[zackson]

Nigdy nie waliduj formalarzy po stronie frontu.

@asdfghjkl: po #!$%@? wysyłać formularz i czekać na error serwera jak można go zwalidować na froncie?

[asdfghjkl]

@zackson: Bo w większości przypadków i tak musisz zrobić request. Jak masz zamiar bez requestu zwalidowac czy podany adres e-mail nie jest już w użyciu? Na froncie co najwyżej możesz powiedzmy zwalidowac czy podany ciąg znaków spełnia warunki żeby zaklasyfikować go jako poprawny adres e-mail. I o tym napisałem że jakaś wstępna walidacja owszem. O tym że należy walidować wszytko ponownie po stronie backendu napisałem bo widziałem już różne dziwne pomysły

[zackson]

, że co prawda odciążają one serwery na #backend , które są w #php czy innym #python .

@paul8585: Te wszystkie frameworki głównie powstały, żeby szybko i łatwo pisać fronty a nie odciążyć backend. Odciążyć backend to można dokładając mocniejsze maszynki, po froncie tego nie zrobisz

[zackson]

Bo w większości przypadków i tak musisz zrobić request.

@asdfghjkl: W większości przypadków to ludzie klikają "submit" bez wypełniania i bo chcą zobaczyć co jest wymagane Xd

[zackson]

Macie jakiś pomysł na złoty środek, gdzie postawić granicę obciążenia?

@paul8585: cel i budżet projektu. Chcesz szybko z pominięciem wydajności czy wolnej i ultra wydajną? Najczęściej i tak kończy się z wolną apką której development trwał zbyt długo

[asdfghjkl]

Te wszystkie frameworki głównie powstały, żeby szybko i łatwo pisać fronty a nie odciążyć backend.

@zackson: co ty gadasz xd

[zackson]

co ty gadasz xd

@asdfghjkl: a jaki był ich główny cel?

[asdfghjkl]

@zackson: Robić rzeczy niemożliwe wcześniej to raz. A druga sprawa że odciążenie też jest ogromną korzyścią. Chyba nie chcesz powiedzieć że danie refresh w przeglądarce jest mniej obciążające niż reakcja na event z websocketu i pobranie/dodanie zmiany w danych. Powiedzmy nowego wpisu na czacie czy aktualizacja wyniku meczu. Lepiej żeby użytkownik spamował refresh? ( ͡° ͜ʖ ͡°)

[zackson]

A druga sprawa że odciążenie też jest ogromną korzyścią. Chyba nie chcesz powiedzieć że danie refresh w przeglądarce jest mniej obciążające niż reakcja na event z websocketu i pobranie/dodanie zmiany w danych. Powiedzmy nowego wpisu na czacie czy aktualizacja wyniku meczu. Lepiej żeby użytkownik spamował refresh?

@asdfghjkl: ja pytam o frameworki a Ty wyskakujesz z technologia dostępna w przeglądarce bez frameworka. Podałeś jeden przykład i do tego błędny xD

[asdfghjkl]

@zackson: Framework ma za zadanie upraszczać użycie pewnych rzeczy. Żadnych frameworkow w żadnym języku nie trzeba używać. Można też koło na nowo wymyślać

[zackson]

Framework ma za zadanie upraszczać użycie pewnych rzeczy. Żadnych frameworkow w żadnym języku nie trzeba używać. Można też koło na nowo wymyślać

@asdfghjkl: Dopisz jeszcze, że 2+2=4 bo tego też nie wiedziałem XDD. Sam napisałem "Te wszystkie frameworki głównie powstały, żeby szybko i łatwo pisać fronty a nie odciążyć backend"

Można też koło na nowo wymyślać

jest różnica między wymyślaniem koła na nowo a braniem Angulara do zrobienia landing page'a

[paul8585]

Macie jakiś pomysł na złoty środek, gdzie postawić granicę obciążenia?

@paul8585: cel i budżet projektu. Chcesz szybko z pominięciem wydajności czy wolnej i ultra wydajną?

Załóżmy że chcę szybko. Jaki model sugerujesz?

[asdfghjkl]

@paul8585: Nikt normalny co nie odpowie na tak postawione pytanie bo trudno jest mówić o technikaliach bez informacji o tym o czym rozmawiamy. Rozsądek przedewszystkim bo z podejściem przenoszenia logiki na front można skończyć tak, że strona na starcie robi 20 requestow do API żeby dane skompletować konieczne do wyświetlenia widoku

[asdfghjkl]

@zackson: Ale o czy ty teraz że mną rozmawiasz? Jeśli sugerujesz że framework js często są nadużywane to absolutnie się z tobą zgadzam. Natomiast często to najlepsze rozwiązanie. Wolę to niż dzikie czasy jQuery i rozwiązań pisanych z palca gdzie nie spojrzałeś to w kodzie te same rzeczy pisane na milion różnych sposobów

[paul8585]

@asdfghjkl uczę się dopiero i napisałem, że to otwarte pytanie. Niemniej jednak wypowiedzi są ciekawe. Trudno mi wyczuć co powinien robić framework na froncie, żeby nie była to sztuka dla sztuki. Generalnie chodzi mi o małe i średnie aplikacje.