[mathix]

Aplikacje single page to wymysł JavaScriptowych hipsterów. Wszystko co potrzeba do tworzenia aplikacji internetowych to dobre MVC z templatingiem po stronie serwera (Play Framework, ASP .NET MVC, Rails...).

Można bić, ale sensownymi argumentami. Liczę na dyskusję.
#javascript

[M4ks]

@mathix: a czemu template? Mozna przecie stringi sklejac, tez da rade...
Poza tym jak slysze o MVC i zaawansowanych aplikacjach... to wiem, ze ten kto to mowi nie widzial nigdy zaawansowanej aplikacji ( ͡° ͜ʖ ͡°)

[m.....e]

Zaryzykuje, ze nie trolujesz i odpowiem.
A) od strony developers odseparowywujesz w 100% warststawy.
B) użytkownicy wola taka interakcje

[mathix]

@micze: Trochę trolluję, ale liczę na dyskusję. Potrzebuję argumentów z drugiej strony.

A) To samo można zrobić za pomocą micro service'ów - stawiasz serwisy z API i oddzielne frontendy, które z API korzystają. Użycie SPA żeby to uzyskać nie jest konieczne.
B) Taką to znaczy jaką?

[m.....e]

A) o czym innym mówimy. Takie mvvc w wykonaniu Angulara daje co możliwość zmiany np. C# na Jave. Mocno teoretyczna możliwość ale w praktyce wyglada to tak ze możesz zmienić wygląd aplikacji i jej zachowanie za pomocą samych frontendowcow. Ludzi którzy znają tylko HTML i js. Duzo łatwiej jest to testować
B) taka ze apka jest bardziej responsywna. Nie oglądasz przeładować tylko informacje o ładowaniu

[taximan]

@mathix: 1. nie trzeba tyle pobierac
2. bardziej natywne doświadczenie dla moblików
3. płynniejsze przejścia z stanu do stanu.
generalnie tej siły już nie powstrzymacie PHPowcy ( ͡° ͜ʖ ͡°)

[m.....e]

@mathix: no i suma sumarum szybciej to sie developuje.

[mathix]

@micze:
A) W sensie przepisania API na inny język? W tym podejściu co opisałem również jest to możliwe, bo integracja idzie po REST i HTTP.

B) To jest słuszny argument. Pytanie tylko czy dość silny, żeby decydować o robieniu SPA.

[mathix]

@taximan:

2. bardziej natywne doświadczenie dla moblików

Mógłbyś rozwinąć? Zakładam, że nie robię aplikacji

[taximan]

@mathix: mam na myśli zwykłe strony internetowe które po skurczeniu wyglądają i dają zbliżony UX do tych natywnych aplikacji. Tak na zachętę rzucę, http://engineering.flipboard.com/2015/02/mobile-web/ wątpie abyś tradycyjnym stackiem uzyskał taki efekt(wszystko się dzieje w przeglądarce).

[Marmite]

@mathix: Myślę, że tutaj przede wszystkim kluczową rolę gra fakt wykorzystania zasobów. Skoro można coś wyrenderować po stronie serwera albo szybciej i oszczędniej po stronie klienta, to czemu nie zrobić tego po stronie klienta?

[mathix]

@Marmite: Argument przeciwko renderingowi po stronie klienta jest taki:
- słabo działa na słabych urządzeniach (np. starych telefonach)
- pierwsze pojawienie się interfejsu zajmuje więcej czasu

@taximan: OK To jest solidny argument. Nie zrobisz takiego interfejsu bez JS-a.

[Marmite]

@mathix: Pierwsze ładowanie to w sumie żaden argument, dzieje się to raz i koniec. Jak ludzie poprawnie korzystają z CDN-ów oraz kilku zasad UX mających w użytkowniku sprawić wrażenie, że wszystko idzie płynnie; a potem do tego umieją skorzystać z application cache, to efekt pierwszego ładowania praktycznie nie ma znaczenia.

Slabe urządzenia to niestety jest problem, tu chyba nie ma innego sposobu niż serwowanie im treści odchudzonej ile tylko się