Temat: Zmiana podejścia do programowania w javascript -...

Cześć,
chciałbym poznać Wasze zdanie na temat obecnego trendu w programowaniu aplikacji js. Wszystko idzie jakby w kierunku odrzucenia typowego widoku html z serwera, a zamiast tego parsowane są dane json przez widoki javascript.

Przy aplikacji działającej całkowicie bez żadnego przeładowania to podejście się broni, ale większość systemów posiada jednak normalne przejścia między adresami i wtedy według mnie nie zawsze wysyłanie json i generowanie w js jest wygodne. Dlaczego, więc nie wykorzystać widoku html z serwera i połączyć go z js. Moją ideę wprowadziłem w życie w https://github.com/bossbyte/datamodel.js. Biblioteka parsuje html, ładuje odpowiednie pliki js, automatycznie binduje znaczniki, wypełnia obiekty atrybutami z js i zapamiętuje strukturę html w celu późniejszego wykorzystania np. do dodania nowego rekordu lub elementu. Takie podejście jest według mnie bardzo wygodne, bo mamy połączenie bloku html z obiektem js co powoduje, że dany blok może być używany w wielu miejscach oraz nie ma konfliktu nazw w js.

Zapytałem Paula Irisha poprzez twitter co myśli o takim podejściu, okazało się, że nie jestem pierwszą osobą ( spodziewałem się :)), która zastanawia się nad tym problemem. Otrzymałem link - http://code.google.com/p/mdv/ i informację, że też uważa to podejście za słuszne. Model-driven Views (MDV). Jakie jest wasze zdanie?Maciej Sikora edytował(a) ten post dnia 09.08.12 o godzinie 11:28

Temat: Zmiana podejścia do programowania w javascript -...

Witaj!

Nie wiem czy nazywanie tego typu rozwiązań można określić mianem trendu. Bardziej sytuacja wymusza tego typu scenariusze aplikacji.

Przesłanie zawartości całej strony HTML, jej przeparsowanie, załadowanie plików JS (po raz kolejny tych samych zazwyczaj), odtworzenie atrybutów... przecież to cała masa operacji, które muszą wykonać się tylko po to by zmienić często mały element bądź obiekt na naszej stronie. Niech to nawet będzie i jej wygląd.

Trendem, według mnie, można śmiało nazwać dążenie do wykonywania działań po stronie klienta. Interfejs METRO w Windows 8, Windows Phone, masa nowych frameworków do tworzenia bogatych i interfejsowo ale i logicznie aplikacji działających w pełni po stronie klienta to coś co dotychczas nie było wykorzystywane na ten sposób. Programiści, zleceniodawcy jednak boją się tego typu rozwiązań, stąd też ta duża liczba serwisów oparta o przekierowania i zmiany adresów. Wydaje mi się, że raczej będzie się od tego uciekało z racji, iż rośnie liczba danych generowanych przez urządzenia przenośne. Wprawdzie rośnie też i transfer, który każdy z nas otrzymuje od swojego operatora telefonii komórkowej ALE nie rośnie nam liczba czasu potrzebna na przeglądanie zawartości sieci Internet.

W jakimś wątku na forum Androida widziałem porównanie wielkości plików: CSV, JSON, XML, HTML. CSV wypadło najlepiej z racji na najmniejszą ilość znaków. Zaraz dalej był właśnie JSON. Zazwyczaj wszelkiego rodzaju biblioteki do realizacji aplikacji client-side posiadają funkcjonalność odwołania do serwera w celu zaciągnięcia dowolnego z powyższych plików.

Również rozwój przeglądarek, pamięci offline, wszelkiego rodzaju magazynów danych, w których możemy je przechowywać napawa mnie optymizmem i daje mi szereg możliwości, na których mogę oprzeć te rozwiązania.

Temat: Zmiana podejścia do programowania w javascript -...

Mam ponad 20letnie doświadczenie w pisaniu różnych aplikacji w tym internetowych.

Marcin Zajkowski:
Witaj!

Nie wiem czy nazywanie tego typu rozwiązań można określić mianem trendu. Bardziej sytuacja wymusza tego typu scenariusze aplikacji.

Z tym się zgadzam absolutnie. Należę do tych co dobierają scenariusze/technologie do potrzeby projektu a nie do swoich upodobań i aktualnej wiedzy.
Akurat ten model/scenariusz aplikacji zacząłem używać jakieś kilkanaście lat temu. O modelu MDV to wtedy nikt nie słyszał ale mi pasowało by oddzielić wizualizacje od zarządzania danymi i samymi danymi. Więc budowałem dostawców danych w formacie XML i strony co budowały obraz danych na ich podstawie. Nie zawsze było to OK. na przykład problem wydajności przeglądarki. Ale te problemy to odeszły w niepamięć bo byle telefon ma procesor taktowany kilka razy więcej niż komputer gdy ja zaczynałem nie wspominając o ilości pamięci.
Obecnie właśnie uskuteczniam coś w ten scenariusz.
Mam aplikację główną na winCE6.0 co dziedziczy część kodu w C po aplikacji na AMR z RTOS. Da się pożenić. Aplikacja główna na kopę danych do ustawiania. W systemie z AMR jest aplikacja na napisana w C# taka zwykła okienkowa. A na WinCE ma być na WWW. Tak więc ma do dyspozycji natywne sposoby komunikacji w WinCE, serwer WWW i ISAPI do tego serwera czyli pisaną w C/C++ (naprawdę łamane) dll. Kontroler jest rozszerzeniem serwera WWW i decyduje czy wysłać dane z pliku czy połączyć się z aplikacją główną i przesłać dane. I oczywiście sprawdza uprawnienia i zawiaduje logowaniem. Serwer daje pliki typowe a dane i fragmenty html do edycji danych przesyłane są przez kontroler. Fragmenty te co się nie zmieniają zapisywane są w przeglądarce i jeśli już były pobrane to wywoływane są z pamięci.
Dlaczego tak. Komputerek ma dużo do roboty. Serwer WWW to raczej drugorzędny proces. Jego działanie nie może zakłócić żaden sposób pracy programu głównego. Musi być zachowana zasada minimalizmu oddziaływań. Tak więc program główny jedynie przetwarza niezbędne dane. Przeglądarka je przekształca do formy prezentowanej użytkownikowi.
To model minimalizujący aktywność serwera a przerzucający obciążenie na klienta. To jest model oszczędzający serwer i sieć, zarazem jasno definiujący warstwy aplikacji i przypasowujący do realnych zasobów.