Czy natrętny JavaScript jest zawsze w porządku?

9

Pomyślałem, że jeśli wszyscy użytkownicy strony mają mieć włączoną obsługę JavaScript, czy można używać natrętnego JavaScript?

Jestem za progresywnym ulepszaniem, ale po co zaawansowana aplikacja internetowa odsyła użytkowników do drzwi, jeśli mają wyłączoną starą przeglądarkę lub JavaScript?

Mamy bardzo wąską grupę docelową i możemy powiedzieć naszej grupie docelowej, jaką przeglądarkę i wtyczki / funkcje muszą mieć. Więc moje pytanie brzmi: czy mieszanie JS i HTML jest w tym przypadku w porządku? Jak przy użyciu atrybutów onclick.

Petah
źródło
1
„Jeśli wszyscy użytkownicy witryny muszą mieć włączoną obsługę JavaScript ... jeśli mają ... JavaScript wyłączony?” <- To jest sprzeczność i nie jestem pewien, jak udzielić użytecznej odpowiedzi z nierozwiązanym.
HedgeMage
3
Pamiętaj, że w zależności od grupy docelowej i rynku mogą obowiązywać przepisy dotyczące dostępności, które wymagają, aby witryny były dostępne dla wszystkich użytkowników, w tym dla osób niepełnosprawnych. Co to oznacza w praktyce dla JS, nie wiem. AFAIK (IINAL) tam, gdzie ja jestem, mamy takie prawa, ale nie było jeszcze przypadków testowych w celu ustalenia szczegółów.
James
16
Co rozumiesz przez „natarczywy” javascript? Nie znam tego terminu.
Macke
2
Twoje pytanie w zasadzie brzmi: czy pisanie bzdurnego kodu jest w porządku? Tak, w przypadku prototypów i projektów, które są wystarczająco małe i nie wymagają konserwacji / aktualizacji po zakończeniu. W przeciwnym razie po pół roku sam się wyprostujesz, ponieważ zajmuje Ci godzinę, aby dowiedzieć się, co może być prawdopodobne, gdybyś zainwestował jeszcze kilka sekund, kiedy to umieścisz.
back2dos
3
Pomyślałem, że to pytanie powinno zadać pytanie, czy zmiana rozmiaru czyjegoś okna przeglądarki lub wyświetlenie mnóstwa wyskakujących oków było w porządku.
whatsisname

Odpowiedzi:

17

Jest to decyzja biznesowa, a nie decyzja projektowa.

Zapewnienie wersji strony internetowej działającej bez JavaScript (lub Flash lub Silverlight) kosztuje. Firma musi zdecydować, czy utrata przychodów / odwiedzających warto czy nie.

Więc jeśli napisanie tej wersji kosztuje 10 000 USD (liczba może być duża, ale jest tylko w tym przykładzie), to czy firma zrekompensuje ten wydatek przez cały okres istnienia witryny? Jeśli nie, nie udostępniaj tej wersji.

Jeśli jednak napisanie tej wersji kosztuje tylko 100 USD, warto zapewnić pełną wdzięku degradację.

Po podjęciu decyzji biznesowej, aby kierować reklamy tylko na przeglądarki obsługujące JavaScript i oczekiwać, że Twoi użytkownicy będą mieli włączoną obsługę JavaScript, to ma sens, aby Twoja aplikacja korzystała z funkcji, które już masz. Jedyne, co musisz zrobić, to (podobnie jak sam przepełnienie stosu) ostrzeżenie, że witryna nie będzie działać poprawnie, jeśli użytkownik nie włączy jej.

ChrisF
źródło
2
Myślę, że mnie źle zrozumiałeś.
Petah
5
Powinieneś uprzejmie powiedzieć nam, że WTF „natrętny JS” oznacza unikanie nieporozumień. Zostałeś już o to poproszony (pozytywnie oceniony 7 razy)!
maaartinus
1
W przeszłości budowałem z wdziękiem poniżające strony i stwierdziłem, że html i javascript są o wiele mniej przejrzyste, jeśli nadal chcesz oferować użytkownikom obsługującym JS najlepszą jakość obsługi. Strony były DUŻO trudniejsze do zbudowania i uważam, że facet prowadzący stronę będzie miał pewne trudności z przestrzeganiem twojego kodu. Tak więc z pewnością istnieje długotrwały koszt utrzymania, o którym należy pamiętać przy szacowaniu kosztu spowodowania, że ​​witryna będzie z wdziękiem poniżać. Uznałem, że to bardzo kuszące, aby pójść na kompromis w sprawie UX z włączoną JS.
Thomas Stock,
1
@maaartinus, natarczywy javascript jest przeciwieństwem dyskretnego javascript en.wikipedia.org/wiki/Unobtrusive_JavaScript
Petah
1
OK, więc mogę tylko powiedzieć ... html + js jest plagą (zepsute implementacje ignorujące dziwne standardy) i zminimalizuję wysiłek tak jak napisał Thomas Stock. Postaraj się, aby działał idealnie w wybranej przeglądarce (i nie wybieraj IE6: D) a oraz aby był możliwy do zniesienia w innych. Zamiast obejść wszystkie problemy, poświęć czas na funkcjonalność.
maaartinus
20

Coś, czego nikt jeszcze nie wychował…

99% witryn sieci Web wita określonego użytkownika, który nie ma JavaScript w ogóle lub wcale. Ten gość ma nazwę: Googlebot .

To ważny powód, dla którego wszyscy powinni dbać o niewidomych gości…

Jeśli jesteś jednym z nielicznych, który wcale nie dba o ruch w wyszukiwarkach, cóż, to twoja prerogatywa - ale z pewnością nie stanowi to ogólnej zasady.

Dori
źródło
4
W rzeczy samej. Ulepszyliśmy jedną z naszych witryn, aby była bardziej dostępna dla osób niewidomych i (niezamierzonym) skutkiem tego, że ruch z Google został pomnożony przez prawie 10 razy w ciągu jednego roku.
Kris,
1
Tak, ale strona nie jest dla publiczności. Rankingi wyszukiwania nie mają zastosowania.
Petah
3
@Petah: Czy za stwierdzając jasno i zwięźle co Państwa indywidualnych potrzeb, sytuacji i ograniczenia są w pytaniu zamiast przyprawiając małe fragmenty informacji tu i tam w komentarzach?
PO PROSTU MOJA poprawna OPINIA,
1
Nie masz już racji. Od dłuższego czasu Googlebot działa dobrze w javascript (nic dziwnego, biorąc pod uwagę, że Google działa zarówno na silniku V8, jak i angularjs).
maaartinus
8

Ludzie piszący rzeczy dla określonych środowisk wewnętrznych są dużym powodem, dla którego IE6 wciąż istnieje.

Pomyśl o tym

Oli
źródło
4

Jeśli tworzysz witrynę tylko dla JS (być może „aplikacja” w tym przypadku jest lepszym słowem), tak zwana „dyskretność” JS nie ma tak dużego znaczenia, jak w przypadku, gdy musisz z wdziękiem zdegradować się do nie- Wersja JS.

Jednak: JavaScript napisany w dyskretny sposób jest ogólnie łatwiejszy do napisania (a przynajmniej tak mi się wydaje) i utrzymania. Łatwiej jest wprowadzać zmiany w układzie HTML, które nie łamią JS, i zmiany w JS bez obawy o zerwanie HTML.

Mchl
źródło
4

Jeśli budujesz stronę internetową, JavaScript nie powinienem narzucać się. Jeśli jednak budujesz jakąś formę aplikacji (np. Dokumenty Google), JavaScript będzie dość natrętny.

JavaScript i HTML5 świetnie nadają się do budowania aplikacji, jeśli tego potrzebujesz, ale tak naprawdę jest to wybór biznesowy.

Zachary K.
źródło
Tak, bardziej przypomina dokumenty Google niż witrynę internetową. I intensywnie używamy HTML5.
Petah
Popraw mnie, jeśli się mylę, ale myślę, że nadal możesz korzystać z większości pojęć w dyskretnym JavaScript bez konieczności tworzenia bałaganu w kodzie? Jest to koncepcja, która wyróżnia się i sprawia mi najwięcej hałasu. Być może odwołujesz się do innych aspektów dyskretnego JavaScript, których należy unikać przy użyciu HTML5, takich jak wsteczna kompatybilność z użytkownikami innymi niż JavaScript? Musisz wybrać i wybrać to, co jest najlepsze dla ciebie i projektu, o ile możesz inteligentnie uzasadnić powody i przeanalizować ryzyko, wtedy myślę, że wszystko jest dobrze :) +1
jmort253
Mówię o tym, jak strona będzie działać, gdy JavaScript jest wyłączony. Są chwile, w których będzie w pełni funkcjonalny (jeśli nie być może tak przyjemny), a inne, w których całkowicie się nie powiedzie. Nie martwię się o stare przeglądarki, które nie obsługują JavaScript (Netscape 1). Oczywiście w żadnym wypadku nie ma powodu pisać ZŁEGO javascript
Zachary K,
2

Większość użytkowników (moi użytkownicy, nie wiem o twoich użytkownikach) ma włączoną obsługę JavaScript. Dajmy tym użytkownikom doskonałą obsługę. Nadal jednak musisz podać wersję swojej strony, która działa bez Javascript. Wiem, że zbudowanie 2 wersji jest kłopotliwe, ale tak właśnie wygląda tworzenie stron internetowych. (W rzeczywistości może być konieczne zbudowanie wielu wersji, trzecia może być wersją mobilną witryny).

To, czego nie chcesz robić, to projektowanie dla najmniej powszechnego mianownika: „Cóż, niektórzy użytkownicy mają wyłączoną obsługę Javascript, więc zaprojektujemy naszą stronę tak, aby działała dla nich dobrze - bez Javascript, uderz w serwer za wszystko . ” To po prostu karze większość użytkowników, którzy mają Javascript.

Marcie
źródło
Mówię, że żaden z użytkowników nie ma wyłączonej obsługi JavaScript. Jeśli tak, nie mogą uzyskać dostępu do witryny.
Petah
@Petah, cóż, to też nie jest świetne. Nie chcesz odrzucać użytkowników bez Javascript. Więc o co pytasz, skoro wyrzucam użytkowników bez Javascript, czy mogę umieścić JS w tym samym pliku z moim kodem HTML?
Marcie
Mamy bardzo wąską grupę docelową i możemy powiedzieć naszej grupie docelowej, jaką przeglądarkę i wtyczki / funkcje muszą mieć. Więc moje pytanie brzmi: czy mieszanie JS i HTML jest w porządku w tym przypadku? Jak przy użyciu atrybutów onclick.
Petah
4
@Petah, istnieją inne powody, aby unikać mieszania JS i HTML. To z tych samych powodów, dla których unikamy mieszania stylów i HTML - oddzielenie problemów. Jeśli twój styl miesza się ze strukturą, która jest mieszana z twoim zachowaniem, masz coś bardzo trudnego do utrzymania. Po zrobieniu tego w „dyskretny” sposób przez jakiś czas zobaczysz, jak eleganckie są twoje pliki i o ile łatwiej jest wprowadzać zmiany.
Marcie
2
@Petah, czy masz jeden ogromny plik JS dla całej witryny i wszystko tam jest? Mam mniej więcej jeden plik JS na stronę i to działa dobrze dla mnie. Naprawdę „wspólne” rzeczy to wszystko, co znajduje się we współdzielonym pliku JS.
Marcie
2

Wspomniałeś o użyciu atrybutów onlick. Czy planujesz używać obsługi zdarzeń JavaScript do nawigacji strony?

Odradzałbym to z jednego powodu: łamie środkowe kliknięcie .

W przypadku zwykłego klikania linków, przy założeniu, że JavaScript jest włączony, będą one funkcjonalnie równoważne:

<a href="#" onclick="window.location = 'myPage.htm';">Click here</a>
<a href="myPage.htm">Click here</a>

Jeśli spróbujesz kliknąć pierwszy przykład w środku, otrzymasz pustą stronę zamiast myPage.htm.

Pomijając ten przykład, myślę, że użycie natrętnego JavaScript jest w porządku, jeśli ma to dla Ciebie sens biznesowy. Pisanie (ale niekoniecznie utrzymanie) wbudowanego kodu JavaScript zajmuje mniej czasu, a utrata progresywnego ulepszania może nie być istotna w twojej sytuacji.

GavinH
źródło
W tym przypadku nie służy do nawigacji, ale do przycisków takich jak „Odśwież”, „Usuń”, „Utwórz” itp.
Petah,
W takim razie sugerowałbym swój osobisty styl. Uważam, że natrętna metoda jest szybsza / łatwiejsza do rozpoczęcia, ale „poprawny” sposób na bycie czystszym i łatwiejszym w utrzymaniu. Z pewnością właściwy sposób ma dobry rozmyt.
GavinH
+1 - Łatwiej jest utrzymać kod w czystości od samego początku, jeśli jest dyskretny. Uważam, że jeśli na początku zrobię się zbyt niechlujny, może być trudniej spróbować rozwiązać problemy później. Jestem przytłoczony. Wolę wykonywać tak dobrą robotę, jak tylko mogę, aby po powrocie do refaktoryzacji nie było tak źle.
jmort253
2

Uciążliwy JavaScript był w porządku 10 lat temu. Jest to również w porządku, jeśli jesteś amatorem lub budujesz prototyp, lub jeśli istnieją okoliczności, które tego wymagają, takie jak zależność od starszego kodu lub kodu opartego na danych i po prostu byłby to zwykły koszt za dużo, aby naprawić al

Jeśli budujesz coś od podstaw, postępuj zgodnie ze standardami, napisz dobry, czysty i łatwy do utrzymania kod. Napisz coś, z czego będziesz dumny, a to nie sprawi, że będziesz chory za rok, kiedy jakiś biedny schmuck poprosi cię o pomoc, ponieważ nie rozumie hackjobu, który zrobiłeś. Napisz coś, co zapewni, że twoi projektanci stron internetowych będą mogli łatwo zamienić CSS bez konieczności przekopywania się przez niechlujny HTML i JavaScript.

Zbuduj aplikację, aby mogła się rozwijać, aby każdy programista mógł ją obsługiwać. Czas zainwestowany teraz pozwoli zaoszczędzić czas w przyszłości, jeśli nie twój czas, cudzego.

Upewnij się, że JavaScript może być ponownie użyty w innym kontekście. Upewnij się, że całkowite przeprojektowanie strony internetowej może być właśnie tym, przeprojektowaniem, a nie całkowitą przebudową czegoś, co już istnieje, ale po prostu nie było trudne.

Wyobraź sobie, jak żenujące byłoby poświęcenie takiej samej ilości czasu na przeprojektowanie, jak w przypadku oryginalnej wersji.

Zaufaj mi z doświadczenia, dyskretny JavaScript zapobiegnie popełnianiu kosztownych błędów.

jmort253
źródło
2

W porządku, po prostu zadzwoń do mnie jako opiekuna krypty w przypadku wszystkich nekro, które robię, ale nigdy nie czułem, że prawdziwa wartość tego została właściwie zrozumiana. Historycznie twierdzono, że „dyskretny JavaScript” lub trzymanie JS z dala od HTML poprzez wbudowane atrybuty modułu obsługi zdarzeń HTML i znaczniki skryptów, które nie łączyły się z plikiem w jak największym stopniu, stanowią ogromny kluczowy element:

  • Obawy dotyczące dostępności
  • SEO
  • I progresywne ulepszenie

KŁAMSTWA! (cóż, teraz będą)

Prawda jest taka, że ​​możesz zrobić technicznie natrętny JavaScript i nadal odciągać powyższe trzy elementy. Chyba że budujesz zawartość HTML dynamicznie, co było wielkim nie-SEO dniem.

Ale przestań i pomyśl ... o Tobie!

Naprawdę, dużą korzyścią, największą i najbardziej niższą wygraną w utrzymywaniu separacji zawsze była bezpośrednia korzyść, jaką uzyskuje od niej deweloper. Możesz mieć tyle programów obsługi zdarzeń, ile chcesz w tym samym elemencie HTML dla tego samego zdarzenia, co jest wygodne. Oznacza to, że jeśli tag z class="some_class"zawsze zachowuje określone zachowanie, ale także zyskuje pewne dodatkowe zachowanie, gdy znajduje się w id="bonus_behavior"div, nie musimy zaczynać bałaganu z logiką wewnątrz naszej jednopozwolonej procedury obsługi zdarzeń, aby to rozgałęzić. Możemy po prostu dodawać lub nie dodawać procedury obsługi w zależności od kontekstu.

Zbyt łatwe do odczytania

Kolejną korzyścią jest czytelność. Było to bardziej krytyczne, gdy narzędzia przeglądarki składały się z wyjątkowego komunikatu o błędzie IE informującego, że coś jest nie tak z [object]IMO, ale to wciąż wielka sprawa. CSS tutaj, JS tam i HTML to miejsce, w którym spotykają się zarówno oni, jak i serwer. Ponieważ wszystkie te rzeczy łączą się w jednym miejscu, warto polegać na haczykach (identyfikatorach, klasach i hierarchii), aby stworzyć warstwę abstrakcji, której wszystko używa do łączenia się z HTML.

IMO, im więcej MOŻESZ trzymać HTML, CSS i JS oddzielone, tym łatwiej jest nie tylko czytać, ale także modyfikować i rozumieć, co się dzieje. Widzę pustą div z „dynamic_combo_box” jako klasę i mam dobry pomysł, że coś robi fantazyjny wybór, który ładuje dane dynamicznie. Mam wskazówki, jak znaleźć to w JS i CSS, a jeśli wpadnę na klasę w tych kwestiach, będę miał dobry pomysł, o co chodzi i jak to znaleźć w HTML.

Zbyt łatwy do zrobienia nawet niechlujny

Oczywiście czytelność idzie w parze z łatwością utrzymania. Kiedy po prostu robisz rzeczy bezpośrednio, zrzucając wszystko do tagów skryptu, w których znajduje się odpowiedni kod HTML, tak często, jak nie, łatwiej jest po prostu wyciąć i wkleić ten skrypt do kodu HTML innej strony, nad którą pracują, gdy chcą podobnej funkcjonalności, co oznacza, że ​​masz teraz jedną rzecz, która najprawdopodobniej ostatecznie stanie się dwie irytująco podobne, ale nie w 100% podobne rzeczy, których zachowanie może z czasem stać się problematyczne z powodu sprzeczności z oczekiwaniami i wymaga dodania bardziej bezsensownego rozgałęzienia w celu obsługi wyjątków, których potrzebujesz inny nie.

Tak więc zachowanie się względem tych haków HTML zachęca do ponownego użycia kodu w inteligentny sposób. Jeśli potrzebujesz rozgałęzić zachowanie dla alternatywnej implementacji, po prostu przejdź do tej samej funkcji i obsłuż ją tam za pomocą hierarchii HTML lub może danych, wyzwalając pewne zachowanie alternatywne. To jeden przystanek dla każdego, kto chce zrozumieć, jak działają elementy interfejsu określonego typu, a te ohydnie leniwe w niewłaściwy sposób wycinanie i wklejanie zrobią właściwą / łatwiejszą w utrzymaniu rzecz tylko dlatego, że najłatwiej jest to zrobić zrób to teraz, a to najlepszy sposób na utrzymanie łatwości konserwacji. Zrób to najłatwiejszą rzeczą do zrobienia nawet dla kogoś, kogo mniej obchodzi czy to z powodu paniki czy apatii.

Ale co z 2014 r.?

Może być uzasadnione, że we współczesnych jednostronicowych aplikacjach niektóre z tych lepkich rzeczy nie powinny być tak dogmatycznie, jak kiedyś, ale wierzcie mi, gdy mówię, że nie jestem jedyną osobą, która został na nim sprzedany, ponieważ ostatecznie ułatwia pracę. Jestem leniwy w (mam nadzieję) głównie dobry sposób. Podoba mi się, gdy muszę zmieniać rzeczy tylko w jednym miejscu, aby wprowadzać zmiany w całej aplikacji, kiedy muszę tylko patrzeć w jednym miejscu, aby dowiedzieć się, co to za błąd, i kiedy mam łatwy czas, aby zrozumieć, co to do cholery jest i jak najlepiej ponownie użyć tego kodu, aby zrobić coś bardzo podobnego.

To dobrze, jakby podział DB lub warstwy danych był dobry. To w końcu oszczędność czasu, dlaczego nie zrobiłem tylko pięciu minut, aby zrobić pranie poprzedniej nocy, zamiast spędzać 10 minut na zamrażaniu bokserów i przeprowadzaniu paranoicznego sprawdzania zapachu następnego dnia rano.

Dla mnie to właśnie te samolubne motywacje zawsze były głównym powodem, dla którego trzymam się nie tylko dyskretnego JS, ale oddzielenie stylu / zachowania / treści dotyczy tak bardzo, jak to możliwe, nawet jeśli to, do cholery, WG, robi rozwiewaj te obawy w zrozumiały i fajny sposób.

Teraz, gdy wszyscy robią SPA i prawie głupie jest próbowanie przekonania biznesu, że powinniśmy dbać o ludzi, którzy działają bez JS (dostępność może być teraz podobno obsługiwana z treściami generowanymi przez JS), wygląda na to, że następnej generacji twórców JS mniej zależy o tym, ale IMO wciąż tam jest wygrana i to głównie dla ciebie, programisty piszącego i utrzymującego te rzeczy. I tak naprawdę, ta wygrana powinna być zawsze najbardziej podkreślonym punktem, ale nigdy nie była z jakiegoś powodu, ponieważ ostatecznie przynosi korzyści tobie, a także produktowi przez szczęśliwy przypadek, dzięki łatwiejszemu dostosowaniu / modyfikacji / debugowaniu.

Czy to jest w porządku?

Chyba tak. W jednorazowej aplikacji do rzucania na konkurs lub coś takiego. Ale nadal bym to zrobił tylko dlatego, że mam taki zwyczaj i wcale nie jest to trudniejsze.

Erik Reppen
źródło
1

Jeśli znasz docelowe środowisko operacyjne, JavaScript i frameworki, takie jak jQuery, mogą być prawdziwym darem niebios. Na przykład w środowisku Enterprise, w którym SOE ma Javascript i IE8, niż jest bardziej niż bezpieczne pisanie intensywnych aplikacji przeglądarki po stronie klienta.

Jeremy
źródło
1

Ułatwienie pełnej wdzięku degradacji to tylko jeden z wielu czynników, które sprawiają, że dyskretny JavaScript jest atrakcyjnym wyborem i moim zdaniem nie jest najważniejszy.

Z własnego doświadczenia powiedziałbym, że jeśli mówisz o większym projekcie, który prawdopodobnie ewoluuje z czasem, to zastosowanie dyskretnego stylu sprawi, że aplikacja będzie dużo łatwiejsza w utrzymaniu, debugowaniu i refaktoryzacji. Jest to największy powód, dla którego zawsze stosujemy dyskretny styl, nawet w witrynach, które wymagają włączenia JavaScript dla wszystkich odwiedzających.

shang
źródło
+1 do Shanga za ten klejnot „Ułatwienie pełnej wdzięku degradacji to tylko jeden z wielu czynników, które sprawiają, że dyskretny JavaScript jest atrakcyjnym wyborem i moim zdaniem nie jest najważniejszy”. Implementacja Javascript może być czasem obosiecznym mieczem, znalazłem osobiście
MattyD
1

Ogólnie rzecz biorąc, jeśli tworzysz tradycyjną „stronę internetową”, która jest anonimowo dostępna, indeksowana przez wyszukiwarki i gdzie przychody są generowane przez reklamy, powinieneś zapewnić pełną wdzięku degradację. Idea polega na tym, że ten rodzaj witryny żyje i umiera dzięki dostępności, więc ograniczenie dostępności oznacza utratę wielu wyświetleń strony, a tym samym przychody z reklam.

„Witryna” (aplikacja internetowa) o ograniczonym dostępie, zasadniczo nieindeksowana i niepochodząca z reklam, może być znacznie bardziej elastyczna. Wszystko sprowadza się do wyboru między szerokością wsparcia, głębokością funkcji i kosztami rozwoju. Pomyśl o tym jak o stworzeniu tradycyjnej aplikacji: jaką platformę wspierasz i jakie są minimalne specyfikacje? Jeśli kierujesz reklamy tylko na jedną platformę i ograniczoną specyfikację, możesz skoncentrować się na zapewnieniu doskonałego produktu przy mniejszych kosztach rozwoju i wsparcia, kosztem utraconego potencjalnego udziału w rynku.

Przykład: wyszukiwarka Google to witryna internetowa. Dokumenty Google to aplikacja internetowa. Wyszukiwarka Google nie jest zbędna i może działać identycznie bez JavaScript, CSS i / lub obrazów itp. - działa w przeglądarkach tekstowych równie dobrze, jak w najnowszych przeglądarkach GUI. Dokumenty Google po prostu nie działają z wyłączoną obsługą JavaScript i nawet nie psują się z gracją - nawet ostrzeżenie o włączeniu JavaScript.

Curtis Batt
źródło
1

Wolę mieć większość układu i nawigacji obsługiwanych w CSS. Tak, Lynx może go nie obsługiwać, ale wszystkie w pełni wyposażone przeglądarki, o których wiem, nie mogą go wyłączyć. Następnie JavaScript może być użyty do bardziej krzykliwych, ale niewymaganych rzeczy. W tym celu lubię także Ruby on Rails. Może zrobić wiele z tego, co JavaScript byłby wymagany do wykonania po stronie serwera, o ile nie potrzebujesz dynamicznych aktualizacji strony.

Bardziej ukierunkowane na odpowiedź na pytanie: Nie lubię wymaganego JavaScript, ale jest przypadek biznesowy, w którym jest on wymagany, jak zauważył ChrisF.

RobotHumans
źródło
0

JavaScript jest standardem defecto, jeśli chodzi o wszelkiego rodzaju treści dynamiczne dostarczane po stronie klienta, jeśli nie mają JS, to prawdopodobnie nie będą miały srebrnego światła.

W takim razie musisz pomyśleć o swoim rynku / widowni, czy jesteś programistą. Stackexchcange czy bbc.co.uk/news? bardzo różni odbiorcy.

henry.oswald
źródło
0

Ponieważ możesz rozglądać się po Internecie i zobaczyć „natarczywy javascript” na wielu stronach, odpowiedź na twoje podstawowe pytanie, tak, jest w porządku, a wiele popularnych stron to robi, nawet Google.

Ważniejsza jest jednak pełna wdzięku degradacja funkcjonalności, nawet jeśli nalegasz, aby użytkownicy mieli włączoną obsługę Javascript, musisz zapewnić przyzwoity poziom doświadczenia użytkownikom niebędącym js, inaczej nigdy nie chętnie powrócą.

ocodo
źródło
W ogóle nigdy nie będą mogli przejść obok pierwszej strony.
Petah