On 2015-08-15 10:05, Marek wrote:
> Nie zawsze jest tak, że można rysować partiami, nikt nie chce oglądać
> efektów komputerowych z filmów z lat 80 u.w.

W interfejscie uzytkownika to czy lista pojawi się od razu czy po 5ms
nie ma żadnego znaczenia. Dla responsywności i płynności przewijania
scrollbara - ma znaczenie *zasadnicze*.

> Przwciesz windows przyzwyczaiło wszystkich do takiego modelu

Microsoft nigdy nie był i już nie będzie wzorcem dla gui. To oni
przyzwyczaili ludzi do dziadostwa, głwnie dlatego że ich API pochodzi z
Win3.x a tam nie bylo wątkow tylko cooperative multitasking. Efektem
czego współczesne bibloioteki, nawet te nowoczesniejsze jak Qt wymagają
paintowania z wątku GUI a nie z innych. I nikt tak naprawdę nie wie
dlaczego, bo dla karty graficznej nie ma znaczenia jaki wątek ją o coś
prosi, a synchronizacja i tak jest bo kazdy proces ma po jednym watku
głownym. Unix to samo, X-y wymagają paintowania z jednego wątku. Diabli
wiedzą dlaczego.

, albo co
> chwila okno modalne albo inna blokada gui, nie można sobie np. otworzyć
> w aplikacji okna ustawień i mieć je otwarte nie blokując reszty.

Modalność nie ma nic wspolnego z responsywnością. Responsywność - z
grubsza - polega na tym że jak masz załadować milion elementów do
drzewa, to tępak załaduje je od razu blokując GUI a mądrzejszy załaduje
je w 2 sekundy ale pozwoli na działanie gui w międzyczasie dając
*złudzenie* responsywności. Jego ładowanie potrwa dłużej, ale będzie
nieblokujące dla gui. Inna sprawa że tępaki zazwyczaj testują apliakcje
na kilku elementach, nie zastanawiają się nad O(N^2).

> Aaa Ty do przeglądarki pijesz.

Nie. Przeglądarki to typowy przykład że masz 20 zespołów programistow i
*WSZYSCY* popelniają te same błedy robiąc logikę w onklikach. Bo tak
jest taniej. Myślałem że może Edge coś zmieni, ale wygląda na to że
podstawą zmianą w Edge jest branch repozytorium IE.

> Trzabyło tak od razu. Tylko myślę, że
> argument o deklaracji rozmiaru obrazka w html pasuje do lat 90

Dalej działa i roku na rok jest coraz rzadziej stosowany. Głównie
dlatego że proces layoutu strony przerzuca się na gówno wydziargane w
javascript. Nie zmienia to jednak faktu że np. głowne logo allegro po
załadowaniu powoduje przesuniecie strony za co student dostał by czapę
na zaliczenie.

> i mosaica
> (nie wiem czy się orientujesz co to było)

Używałem.

> a nie do współczesnego html,
> w którym jest coraz mniej html.

Zgoda. To powoduje że mimo to że strony migają, zmieniają layout w
trakcie ładowania, zmieniają style itd dalej sa używalne. Bo nie jest
istotne żeby strone załadować *szybko* i od razu gotową. Istotne jest
aby w trakcie procesu ładowania pozwolić na interakcję. A to wymaga
zmiany myslenia i czasem zakopania kilku liderow zespołu programistów.
Obecnie to działa bardzo przeciętnie, ładowanie w tle to tylko jakaś
cześć procesu, dalej przetwarzamy dane w onklikach.

> W kwesti przeglądarek to raczej rzucasz
> się z motyką na Słońce.. Nawet najlepszą przeglądarkę "ubije"
> webdeveloper, a najoptymalniejszą stronę www ubije kiepska przeglądarką.

Nie. To wina przeglądarki, że gui staje się nieresponsywne. Nawet jeśli
trafie na debila z portalu robiącego O(N^3) to dalej - gui przeglądarki
nie ma prawa zatrzymać sie na dłużej niż 50ms a i tak to jest grube
przegięcie. Scrollbary mają działać, linki mają się klikać. To jest
wyłacznie wina przeglądarek że tak nie jest.

> To czego oczekujesz wymaga kooperacji obu stron (obu progamistów) co w
> praktyce jest niemożliwe.

Nie wymaga. Wymaga zakopania liderów zespołów programistów przeglądarek,
spalenia kilkudziesięciu durnych książek (głównie o delphi, przepraszam
za złośliwość) i zmiany kilu OSów. Czyli pikuś.

> Dlatego powstaje coś takiego jak aplikacje mobilne do serwisów www,
> jakiś absurd.

Powstawały zawsze ponieważ głos decydujący o kierunku tego rynku nie
należy do ludzi inteligentnych z wizją tylko do prawników, ekonomistów,
cieciów i innej swołoczy.