[5z7k9]

Zauważyliście, że Twitter korzysta z AJAXa by pobierać HTML w JSONie? "Renderują"(raczej nie w taki sposób jak React.renderToString) HTML po stronie serwera i podmieniają tylko odpowiednie elementy na stronie. Czy nie robi tak przypadkiem nawet(!) Wykop? I co powiedzą Ci od #react lub #angularjs? Progressive enhancement?
( ͡° ͜ʖ ͡°)

#programowanie #javascript #webdev

[moon_bluebird]

@5z7k9: no i w czym problem?

[5z7k9]

@moon_bluebird: nie ma problemu, chciałem tylko zwrócić uwagę na odmienne od (głównie) Reacta podejście do sprawy + prawdopodobnie najlepsze dla dużych aplikacji tego typu.

[Marmite]

@5z7k9: Wadą takiego podejścia jest tylko konieczność utrzymywania osobnej porcji kodu per docelowy klient API (przy założeniu, że klientami są nie tylko aplikacje webowe)

[Marmite]

@Marmite: Edit: A nawet bez tego założenia, bo przecież klienty webowe też mogą chcieć różnego szablonu

[5z7k9]

@Marmite: rozumiem, choć zakładając, że tworzymy aplikację typu Twitter, to jest jeden klient + osobne API JSONowe dla innych aplikacji.
Jeszcze jakieś wady/zalety? Chętnie usłyszę. :)

[Colos]

@5z7k9: plusem reacta jest dobra implementacja virtual dom. Przy większości zastosowaniach nie widać takiej różnicy, ale prawdziwego kopa widać na przykład w sytuacji gdy masz dużo danych aktualizowanych websocketami

[newblob]

w XHR2 można ustawić responseType na 'document' i pobierać Document object prosto z serwera, i nie trzeba wtedy ręcznie parsować HTML.

[regis3]

@Colos: aktualizacja drzewa DOM jest co najmniej tak szybka jak ta z reacta a często nawet szybsza. To co mówisz to mit.

[5z7k9]

@newblob: ale po co? Raczej w niewielu sytuacjach się to przyda. No i takie coś można zaimplementować samemu.

[newblob]

po to żeby zamiast tego kawałku kodu w JSON, który zawiera pseudo html, od razu pobrać HTML?

[5z7k9]

@newblob:

{"html":"<...>..."}

vs
prawdziwy DOM

Taka różnica? I jak wygenerujesz nie-pseudo-HTML np. w PHP?

[ves666]

@Colos: też tak myślałem, ale to jest faktycznie mit. Dowód https://jsperf.com/angular-vs-knockout-vs-ember/658

[y.....s]

@Marmite: nie dostrzegam tu wady, może to spaczenie korporacyjne ale mam z tym do czynienia na codzień. Webaplikacje muszą serwować zupełnie inne szablony w zależności od urządzenia, na tle różne w wyglądzie i zachowaniu, że przez frameworki mobile first jest to nie do ogarnięcia.

[i.....k]

@5z7k9: Wcale nie jest jakieś egzotyczne podejście. Nie ma w tym nic nowego.
Przy okazji react-a ... można oczywiście użyć kodu renderującego html-a po stronie klienta i serwera również w tym scenariuszu.

[5z7k9]

@informatyk15000k: ale ja nie napisałem że jest egzotyczne.

[i.....k]

@5z7k9: Ciekawostka .. jest jeszcze technika nazywana "pjax", która wykorzystuje podobny mechanizm do "miękkiego" przeładowywania całej strony. http://thisbythem.com/blog/super-fast-page-loads-with-pjax/

[y.....s]

@informatyk15000k: @5z7k9: @ves666: @Marmite: generalnie należy się tylko cieszyć, zmiany technologiczne są bardzo szybkie, ciśnienie na rynku pracy duże, zajęcia mam nie zabraknie, stagnacja nie grozi ;)

[ves666]

odpowiedz

@informatyk15000k: Właśnie tej nazwy szukałem, dzięki!

[newblob]

@5z7k9: No normalnie... Skrypt w PHP ci zwraca HTML, a przeglądarka mieli to automatycznie bez żadnego ręcznego parsowania w document object. Wydaje mi się to szybsze tak samo, jak za pomocą responseType można pobierać JSON bez parsowania.

[5z7k9]

@newblob: przecież przeglądarka i tak musi parsować JSONa...
responseType umożliwia pominięcie procesu ręcznego parsowania, więc w jakim znaczeniu jest to "szybsze"? Może chodzi Ci o wygodę programisty? :)

[newblob]

@5z7k9: Nie sprawdzałem szybkości tego, ale skoro przeglądarka robi to natywnie, to wydaje mi się, że ten proces jest maksymalnie zoptymalizowany.