Makabryczny bloat stron WWW...

3

Problem jest dlatego, że wprost przenosi się rozwiązania technologiczne SPA, które idealnie sie sprawdzą w intranetowej aplikacji, do zwykłej strony internetowej, która głównie wyświetla tekst i zdjęcia. Przecież gdyby było to pomyślane z głową, to strony www powinny być bezproblemowo wczytywane przez komputery z przed 20 lat. W końcu nawet w latach 70, na Xeroxach wyświetlano jednocześnie obraz i tekst;-)

3

Większość narzekających nie zauważa jednej rzeczy - w 99% to klient chce by strona była taka. Poza tym chociażby animacje to jest często wymóg, pamiętaj jak znajomy coś mówił, że miał zrobić stronę i klient chciał by po całej stronie skakały zające. Po dłużej rozmowie udało mu się ograniczyć te żądania ale nadal miały skakać gdzieś w tle.

0
axde napisał(a):

Praktycznie każda strona stojąca na jakimś frameworku przy każdej wizycie zasysa kilkanaście mb danych. Co ma do tego cache? Nic niej jest ciężkie do zrwalizowania. Zwykle to tylko niewiedza lub lenistwo. Siedziałem w projekcie w którym zdecydowano, że nie będziemy zaprzęgać jakiegokolwiek frameworka tylko czysty JS.

No ale przecież nie ma sensu za każdym wejściem na stronę zasysać tych samych plików css, javascript czy obrazków. Co do frameworków czy bibliotek, to daje przede wszystkim wygodę. Np. tak jak realizowałem dość zaawansowane formularze, ukrywanie i pojawianie się pewnych części formularza, przechodzenie bez przeładowania strony pomiędzy zakładkami, procedury AJAX czy inne rzeczy to takie połączenie Knockout.js + jQuery i bindowanie, no i MVVM vs. Vanilla JS znakomicie ułatwiało realizację tych zadań. Coraz większe wymagania klientów z którymi trzeba się uporać, dlatego są frameworki i biblioteki. Oczywiście nie ma problemu, wszystko mógłbym w projekcie który nie tak dawno robiłem obsłużyć wszystko w czystym JS, pytanie ile by to wszystko zajęło i jak to przełożyłoby się na akceptowalną cenę przez klienta końcowego.

1
drorat1 napisał(a):
axde napisał(a):

Praktycznie każda strona stojąca na jakimś frameworku przy każdej wizycie zasysa kilkanaście mb danych. Co ma do tego cache? Nic niej jest ciężkie do zrwalizowania. Zwykle to tylko niewiedza lub lenistwo. Siedziałem w projekcie w którym zdecydowano, że nie będziemy zaprzęgać jakiegokolwiek frameworka tylko czysty JS.

No ale przecież nie ma sensu za każdym wejściem na stronę zasysać tych samych plików css, javascript czy obrazków.

Oczywiście, że nie ma sensu. Ale dlaczego jest to bardzo częste zjawisko? Wychodzę ze strony, wchodzę za jakiś czas tego samego dnia, i pobieram cały pakiet od nowa. Niewiedza czy lenistwo?

drorat1 napisał(a):

Co do frameworków czy bibliotek, to daje przede wszystkim wygodę. Np. tak jak realizowałem dość zaawansowane formularze, ukrywanie i pojawianie się pewnych części formularza, przechodzenie bez przeładowania strony pomiędzy zakładkami, procedury AJAX czy inne rzeczy to takie połączenie Knockout.js + jQuery i bindowanie, no i MVVM vs. Vanilla JS znakomicie ułatwiało realizację tych zadań.

Takie ich założenie. Często słyszę, że można za ich pomocą zbudować raz element, i powielić bez pisania kodu ponownie. Szkoda, że jest dużo projektów, które rzadko kiedy powiela jakiś element, a mimo to pcha się tam dużą kobyłę. Inna sprawa, że ten sam efekt można osiągnąć bez wspomagaczy, i nie musi to być dużo większy koszt nakładu pracy.

drorat1 napisał(a):

Coraz większe wymagania klientów z którymi trzeba się uporać, dlatego są frameworki i biblioteki. Oczywiście nie ma problemu, wszystko mógłbym w projekcie który nie tak dawno robiłem obsłużyć wszystko w czystym JS, pytanie ile by to wszystko zajęło i jak to przełożyłoby się na akceptowalną cenę przez klienta końcowego.

Pytanie jak to się przełoży kiedy projekt się rozrośnie. Jak to się będzie skalować. Co gdy okaże się, że zaciąganie setek zależności powoduje zamulenie projektu przy większym ruchu? Winę zgonimy na backend jak to zawsze ma miejsce.
Byłem raz w takim projekcie. Chłopaki przejęli rzeźbiony Angular z Reactem, i przepisywali na nowo bez frameworków. Zaciąganie 10kb biblioteki do animacji jednego elementu to nie jest najlepszy pomysł, a gdy takich kwiatków jest kilkanaście to bardzo kiepsko.

2

Weźcie pod uwagę, że nawet jak strona dociąga 2 MB po każdym przejściu do następnej strony to i tak na łączu 5 MB/s trwa to pół sekundy. Kiedyś stronki ważyły < 100 KB, ale na łączu np 33 kbps czyli 4 KB/s stronka taka ładowała się np pół minuty. I tak jest postęp :] Mamy dzisiaj 1000x szybszy dostęp do Internetu (biorąc pod uwagę przepustowość) niż w czasach dostępu wdzwanianego. Stronki nie ważą 1000x więcej tylko np 100x więcej niż wtedy, więc i tak jest 10x szybciej.

2
Wibowit napisał(a):

Weźcie pod uwagę, że nawet jak strona dociąga 2 MB po każdym przejściu do następnej strony to i tak na łączu 5 MB/s trwa to pół sekundy.

Nie koniecznie, zależne od opóźnienia serwera, rodzaju plików, sprzętu klienta (cpu, przeglądarka, plan energii w lapku, ustawień karty sieciowej), lokalizacji, itp. 2MB to bardzo dużo jest, a transfery nadal kosztują sporo.

5

Dobra, nikt nie chce wzbudzić nostalgii to ja ją wzbudzę...

Ten dźwięk z jednej strony mnie przerażał, z drugiej wiedziałem, że zaraz będzie internet.

0

Narzekacie na spory js a zaraz będzie jeszcze gorzej :D Co prawda link do portalu gdzie nie ma za wiele dobrych technicznie tekstów ale no przynajmniej złapiecie o co chodzi :) https://www.dobreprogramy.pl/Blazor-WebAssembly-na-uslugach-Microsoftu-czyli-C-trafi-pod-strzechy-w-aplikacjach-SPA,News,102659.html

1 użytkowników online, w tym zalogowanych: 0, gości: 1