Nie podobają mi się strony całkowicie nie działające bez włączonego JS. Jednak zastanawiam się czy słusznie? Czy jest sens robić tak, aby to co może, działało również bez włączonego JavaScript? Jeśli jest sens to co za tym przemawia?

Zawsze robiłem, że strona działała również przy wyłączonym JS w przeglądarce. Jednak ostatnio stworzyłem formularz kontaktowy, wysyłał on wiadomość za pośrednictwem AJAXa. Z lenistwa nie zrobiłem standardowej obsługi formularza - bez JS nie można wysłać wiadomości. Zostało uznane to za wadę. Raczej słusznie, chociaż po przemyśleniu mam wątpliwości.

• Przeglądarki niepotrafiące obsługiwać JavaScript to obecnie pewnie 0,1‰ wszystkich odsłon albo jeszcze mniej. Więc jest to ilość którą można zignorować.
• Ci którzy mają wyłączony w przeglądarce JS wiedzą jak go włączyć i będą w stanie włączyć jeśli zajdzie taka potrzeba. Zresztą nieogarnięty użytkownik sobie nie wyłączy JS bo nie będzie wiedział jak. Opcje dotyczące JS są od jakiegoś czasu mocno poukrywane w przeglądarkach.

Czyli jak każdy nabierasz się na mit wyłączonego JS… a sprawa jest dużo bardziej skomplikowana http://kryogenix.org/code/browser/everyonehasjs.html

Web appy mogą sobie pozwolić na js only. Natomiast strony, gdzie pewne rzeczy można z palcem w uchu zrobić bez JS można… zrobić bez JS i nałożyć na to warstwę zachowania. Tak działa od zawsze progressive enhancement i jak na razie nie wymyślono IMO nic lepszego. Prosty przykład: formularz dodawania avatara. Podstawową wersję, dostępną dla każdego, zrobimy w czystym HTML. Nawet userzy z IE5 wyślą avek do tego dorabiamy bombastyczny styl dla pola [type=file], który obsłużą przeglądarki z css3. Natomiast jak komuś mało, nałożymy na to wgrywanie pliku websocketem z możliwością jego przerwania i wznowienia. Trzy poziomy funkcjonalności, niezależne od siebie, dostarczające takich doznań userowi, jakie wytrzyma jego browser

Bo strona to nie druk i nie musi wszędzie wyglądać tak samo. Po prostu ma działać najlepiej jak tylko się da na sprzęcie usera: http://www.slideshare.net/mobile/nzakas/pr...erence-agnostic

Pomijam fakt, że takie są równocześnie założenia projektowe standardów sieciowych: rozwijać od najprostszych do najtrudniejszych rzeczy, warstwowo http://www.w3.org/TR/html-design-principles/

Eee nie bede sie jakos udzielał bo raczej jestem "weak" z front endu.
Ale za to moge przedstawic jak to widze jako nie programista a uzytkownik.

Wedlug mnie wszystko co sie da powinno dzialac bez js,
Oczywiscie.. Gdy cos dziala na js to jest to fajne czesto, efektywne itd.

Ale... Nagle smutek gdy sobie wejde z gorszej przegladarki z uwagi że w np. Danej chwili mam wolniejszy internet a tu nic... Czasem nawet tresci strony nie zoabcze bo wymaga js ;-;

Poza tym niektorzy nie uzywaja js dla bezpieczenstwa (np. TOR). (Wszelkie ataki xss ktore mogly by IP usera ukrasc itd, więc wiadomo).

Tyle z dziennika amatora ^^
--
Także jak dla mnie liczy się dostępność, jeśli wyłączenie JS pozbawi mnie dostępu do danej treści,
To zazwyczaj się z taką stroną raczej nie przywiąże.

A tak gdyby ktoś jednak robił z supportem bez js, a z js by jeszcze płynniej chodziło(np. Bez przeładowań) to już duża szansa że przyciągła by mnie taka strona.

To co mnie bawi w webdevie obecnie są właśnie pytania tego typu - z jednej strony ludzie stracili mentalność wstecznej kompatybilności dla starszych przeglądarek - i budowanie rozwiązań opartych o ciut starsze technologie, byleby działało na 2-3 letnim FireFoxie jest patrzone obecnie jako dziwactwo, bo "autoupdate!", a z drugiej strony ludzie zastanawiają się czy robić osobne wersje działające dla przglądarek z wł. / wył. JS. Zalatuje mi to hipokryzją.

Co do samego pytania, to autor podaje dobre argumenty przemawiające za brakiem potrzeby implementowania fallbacków dla funkcjonalności czysto wirtualnych. Osobiście uważam, że decyzja o tworzeniu ich czy też nie zależy głównie od projektu. Jeśli tworzysz typową stronę WWW, forum, portfolio etc. to możesz się zastanowić nad taką opcją, jeśli jednak idziesz bardziej w stronę webaplikacji czy gier online, innymi słowy high-endowych technologicznie projektów, wtedy zdecydowanie nie warto. Comandeer napisał bardzo fajnego posta o tym, że można tworzyć aplikację warstwowo, tak by działała dla każdego, ale dla ludzi z lepszym sprzętem działała po prostu lepiej. Należy jednak pamiętać tutaj, że każda taka warstwa kosztuje. Z tego powodu użyłem wcześniej słowa "zastanowić" zamiast "zaimplementować". Nawet jeśli masz opcję zrobienia czegoś takiego musisz zadać sobie pytanie 1. Czy projekt tego wyamga? 2. Ile osób z tego skorzysta? 3. Ile będzie nas/mnie to kosztowało pieniędzy/czasu/zasobów ludzkich? 4. Ile na tym zyskamy? etc. Znając odpowiedzi na te pytania - wtedy podejmujesz decyzje.
No i na sam koniec należy również wspomnieć, że niektóre rozwiązania uniemozliwiaja działanie z wył. JS - chociażby Extjs - wtedy zupełnie nie ma dylematu

Pozwolę sobie dopowiedzieć kilka rzeczy.



To nie jest tak A przynajmniej nie w wypadku Progressive Enhancement, gdzie z założenia takie przeglądarki powinny być obsługiwane. One po prostu nie dostałyby tych najnowszych ficzerów, a jedynie podstawową funkcjonalność.
Zresztą jak sam później zauważasz, wszystko zależy od projektu, a na chwilę obecną 2-3-letnich fx na rynku jest mniej niż przeglądarek z wyłączonym JS: http://ranking.pl/pl/rankings/web-browsers.html → najstarsza notowana wersja Fx to 32, który ma porywające 0.07%.
Poza tym z tym JS nie jest tak, że on nie działa tylko na przeglądarkach, gdzie jest wyłączony JS. JS może nie zadziałać na każdej przeglądarce - wszystko zależy od okoliczności (polecam zobaczyć pierwszy link z mojego poprzedniego posta).


True. Osobiście jednak wychodzę z założenia, że PE pozwala napisać aplikację szybciej, nawet w przypadku zaawansowanych webappów. Bo PE wbrew pozorom nie polega na dbaniu o tych z wyłączonym JS (to jest prawdę mówiąc skutek uboczny), ale na logicznym podziale funkcjonalności aplikacji i tym samym zapewnieniu maksymalnej dostępności: http://www.kryogenix.org/days/2015/06/28/availability/


Tylko, że ja wychodzę z założenia, że trzy podstawowe warstwy powinny istnieć zawsze Te warstwy to: HTML → treść, CSS → prezentacja, JS → zachowanie. Wiadomo: separation of concerns. Tak, jak w MVC nie pchamy wszystkiego do kontrolera, tak głupio byłoby we froncie wsadzisz wszystko np do HTML lub - co ostatnio popularne - do JS. Łatwo sprawdzić czy nie wepchaliśmy zachowania i prezentacji do treści - aktywując Content Security Policy Taki podział wspiera także metodologia BEM, która pozwala stworzyć abstrakcję na drzewku DOM: https://bem.info
Myślę, że na takim podziale zyskać może każdy webapp. No i sam developing toczy się szybciej (nie musimy szukać stylów po JS). A końcowy produkt potrafi być szybszy od JS-only: https://jakearchibald.com/2013/progressive-...ment-is-faster/ http://ponyfoo.com/articles/stop-breaking-the-web → de facto prerender na serwerze pierwszej strony, którą dostaje user będzie zawsze szybszy niż parsowanie tego u klienta (i nawet push z HTTP/2 tu nic nie pomoże, bo swoje robi sam proces parsowania, a nie downloadu!). Stąd powstają takie rozwiązania, jak np. Taunus (https://github.com/Taunus/Taunus), doskonale wpisujące się w tzw. new frontend (http://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/ - osobiście nazywam to "middleend"). Tym sposobem webappy mogą stać się jedynie cienkim GUI zbudowanym na potężnych REST APIs. Ale to już raczej wyjechałem grubo poza sam temat PE


Owszem, ale… Obecnie Sieć zmierza raczej w kierunku małych, "zwinnych" komponentów. Popularność zdobywa React ze swoimi komponentami oraz eksperymenty z Web Components (osobiście również się tym bawię). Dzięki temu można tworzyć autonomiczne komponenty, które są małe i można ich reużywać bez najmniejszych kłopotów w innych projektach. A jeśli muszą coś przekazać reszcie, puszczają event. Dzięki temu można wprowadzić bardzo luźną (przez co potężną) architekturę eventową, gdzie trzon systemu po prostu nasłuchuje na zdarzenia poszczególnych komponentów, które nawet nie muszą wiedzieć o swoim istnieniu. Jednocześnie istnieje trend tworzenia microlibów, niezależnych od takich monolitów, jak jQuery czy Ext.js (np. https://github.com/bevacqua/dragula).
Moim zdaniem nadchodzi zmierzch takich monolitycznych rozwiązań na rzecz małych części, które będzie się układać jak klocki Lego. Chyba nie trzeba mówić, że jest to łatwiejsze w rozwoju… no i od lat sprawdza się w praktyce (przecież to de facto przeniesienie filozofii Uniksa do Sieci!).

Tak, jestem fanatykiem

Jasne że warto, ja tak właśnie buduję strony.