Czy jest sens robić strony używające JS, tak aby działały również w przeglądarce w wyłączonym JS? Opcje

[land]

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.

[Comandeer]

Pozwolę sobie dopowiedzieć kilka rzeczy.

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ą.

To nie jest tak (IMG:style_emoticons/default/wink.gif) 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).

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.

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/

Należy jednak pamiętać tutaj, że każda taka warstwa kosztuje.

Tylko, że ja wychodzę z założenia, że trzy podstawowe warstwy powinny istnieć zawsze (IMG:style_emoticons/default/wink.gif) 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 (IMG:style_emoticons/default/wink.gif) 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 (IMG:style_emoticons/default/wink.gif)

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

Owszem, ale… (IMG:style_emoticons/default/wink.gif) 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 (IMG:style_emoticons/default/wink.gif)

Ten post edytował Comandeer 16.08.2015, 17:48:24