웹 사이트를 구축 할 때 JavaScript 사용을 최소화하는 것이 일반적인 관행입니까? [닫은]


32

나는 거의 10 년 동안 웹 개발자였으며 ​​가능할 때마다 JavaScript를 사용하지 않는 습관을 들었습니다. 여기서 웹 응용 프로그램을 작성하는 것이 아니라 데이터베이스 기반 웹 사이트를 말하는 것입니다.

이것이 좋은 접근 방법입니까?


6
나는 표준 자바 스크립트를 비활성화하고 noscript는 javscript 가로 드 된 소스를 알려줍니다. 웹 사이트가 10 개가 넘는 2 차 소스에서 자바 스크립트를로드하는 것은 드문 일이 아니며, 3 차 소스에서 자바 스크립트도로드합니다. 그리고 페이지가 20 개가 넘는 외부 소스에서 자바 스크립트를로드하는 것은 드문 일이 아닙니다. 그래서 나는 말할 것입니다 : 자바 스크립트 사용을 최소화하는 것은 창 밖입니다.
피터 B

9
자바 스크립트가 많을수록 내비게이션 및 SEO에 덜 친숙한 사이트라는 것을 알았습니다. "자바 스크립트 링크"등으로 인해 얼마나 많은 웹 사이트를 떠 났는지 셀 수 없습니다.
BiAiB

1
internetz에 많은 자바 스크립트가 있다는 것을 알았습니다. 문제는 1) 간단한 인덱서가 js를 이해하지 못하고, 2) 많은 양의 js가 CPU를 태운다는 것입니다. 3) 일부 플랫폼에는 여전히 js (전화기, 링크 브라우저)가 없습니다. 따라서 필요하지 않을 때 js를 피하는 것이 좋습니다.
permeakra

이 질문이 왜 이번 주입니까? 나는 이것을 명확하지 않고 건설적이지 않은 것으로 투표 할 것입니다. 일반적으로 "X를 사용해야합니까?" 이 사이트에는 질문이 없습니다. 누군가가 나를 깨달을 수 있습니다.
Mark E. Haase

Microsoft 웹 스택은 (지금까지 MVC에서) ASP.NET 및 SharePoint의 모든 단일 버튼 클릭을 위해 JS에 의존했습니다. 따라서 사용을 최소화하는 것은 일반적이지 않습니다.
Graham

답변:


51

모든 종류의 코드 를 줄이는 것은 대부분의 프로그래머의 본능입니다 . 상기 코드에서 더 적은 코드, 더 적은 복잡성 및 더 적은 가능한 오류 포인트. 이 규칙은 다른 언어뿐만 아니라 Javascript에도 적용됩니다. 당신은 단지 전통을지지하고 있습니다.

HTML 페이지 내에서 필요에 따라 Javascript를 사용하십시오 ... 그러나 실제로 필요하지 않을 때 사용할 필요는 없습니다.


9
JavaScript를 피하는 것은 더 많은 코드를 피한다는 일반적인 본능과 다릅니다. JS를 사용하면 개발 복잡성을 줄이는 것이 아닙니다. 사용자와의 호환성 문제가 실제로 있습니다.
jhocking

34

10 년 전에는 좋은 생각이었을 것입니다. 오늘날 인터넷에서 대부분의 부분 (적어도 매우 인기있는 부분)은 브라우저에서 Javascript를 비활성화 할 때 거의 사용할 수 없거나 매우 제한된 기능 만 제공합니다. 따라서 IMHO는 오늘 사용자가 Javascript를 사용하도록 설정할 수 있습니다.

그리고 브라우저 비 호환성 문제를 해결하기 위해 JQuery와 같은 많은 프레임 워크가 있습니다. IMHO 오늘 귀하의 웹 사이트에 자바 스크립트를 사용하지 말고 스스로를 제한해야 할 이유가 없습니다. 그 이유는 귀하가 그 웹 사이트를 전혀 사용하지 않기 때문일 것입니다.

편집 : 다른 질문은 : 방문자가 JS를 사용하도록 설정하지 않은 상태에서 웹 사이트의 최소한의 기능을 제공 해야하는 경우 -일부 의견 작성자가 지적한 이유로 대부분 좋은 생각입니다.

EDIT2 : 모든 웹 사이트에서 사용자 친화적, 검색 엔진 친화적 및 개발 노력 사이의 균형을 찾아야합니다. 오늘날 IMHO는 현명하게 사용될 경우 균형을 개선하는 데 도움을 줄 수 있습니다. 그 균형을 유지하기 위해 오늘날 더 이상 일반적으로 Javascript 사용을 최소화 할 필요가 없다고 생각합니다. 조심해서 사용하고 그것을 악마 화하지 마십시오.


17
SEO, 웹 애그리 게이터, 스크린 리더, NoScript, curl, 모바일 브라우저가 있습니다. 기본적으로 스크립트를 사용 중지하고 인터넷의 대부분은 여전히 ​​잘 작동합니다.
tdammers

7
자바 스크립트없이 사이트를 사용할 수없는 경우 Google에서 효과적으로 크롤링 할 수 없으며 RESTful 컨텍스트에서 사용하거나 사용하지 못할 수 있습니다. Facebook조차도 자바 스크립트 없이도 최소한으로 사용할 수 있습니다
GordonM

9
여기에 언급 된 대부분의 내용에 동의하지만 사이트가 "최소한 JavaScript 없이는 사용 가능해야"한다는 아이디어에 강력히 반대합니다. 그것은 틀 렸습니다 : JavaScript 없이는 최대한 사용할 수 있어야합니다 .
Jörg W Mittag

4
웹 기술을 사용하지 않으려면 @ JörgWMittag 웹 사이트의 전체 이점을 기대하지 않아야합니다. 시나리오는 다르지만 웹 응용 프로그램을 작성하는 경우 21 세기로의 이동을 거부하는 소수의 사용자를 위해 완전히 호환되도록 시간을 낭비하지 않을 것입니다. 대부분의 프로젝트에서 IE 6을 지원하지 않는 방법과 비슷합니다.
Tom Marthenal

2
모든 사용 사례를 지원하는 것은 단지 전문가입니다. 당신이 그것을 놓쳤다면, 그것은 옳습니다. 모든 사람들은 가끔 잘못을 저 지르지 만 그것들을 무시하는 것은 다른 문제입니다. JS없이 100 % 웹 사이트를 개발할 준비가되어 있으며, 작동시킨 후 JS를 추가하여 작업을 간소화하고 UX를 개선하십시오.
Spidey

13

JavaScript없이 사용할 수있는 사이트가 있다는 것은 가능한 많은 사람들이 이용할 수 있다는 것을 의미합니다. 대부분의 브라우저가 JavaScript를 지원하고 대부분의 사용자가 기본적으로 JavaScript를 그대로 둔다는 것은 사실이지만 확실하게 신뢰할 수는 없습니다. 귀하의 사이트에 액세스하는 모든 것이 결국 브라우저는 아닙니다. Google과 같은 검색 엔진에서 사이트를 올바르게 색인 생성하려면 GoogleBot에서 JavaScript없이 사이트를 탐색 할 수 있어야합니다.

JavaScript를 사용할 수 없거나 예상대로 작동하지 않는 웹 브라우징 소프트웨어도 있습니다. 예를 들어 시각 장애인이 사용하는 화면 읽기 또는 점자 소프트웨어. 또한 메모리가 제한되어 있고 많은 양의 자바 스크립트가 있으면 스마트 폰 브라우저와 같이 브라우징 환경이 불쾌하거나 비현실적 일 수 있습니다.

자바 스크립트없이 작업 할 수있는 사이트를 구축 한 다음 사용자 환경을 개선하기 위해 자바 스크립트 레이어를 추가하는 "진보적 인 향상"개념을 살펴 봐야합니다. 그렇게하면 적어도 자바 스크립트가없는 사람들이 사용할 수있는 사이트를 갖게됩니다.

JavaScript가 아닌 브라우저에 JavaScript로 구현하려는 모든 가능한 기능을 제공하기 위해 노력할 필요는 없지만 최소한 JavaScript없이 기본 사용 사례를 남겨 두는 것이 여전히 중요합니다. 사이트를 탐색 할 수있는 것은 분명히 목록의 최상위에 있지만 전자 상거래 사이트를 구축하는 경우 JavaScript에 의존하는 결제 프로세스를 만드는 것은 판매 비용이 들기 때문에 어리석은 일입니다.


4
전혀. 자바 스크립트는 메인 코스가 아닌 향신료로 사용해야합니다.
hlovdal

9

다른 답변은 "JavaScript를 사용해서는 안됩니다"에 초점을 맞추고있는 것 같습니다. 필요하지 않은 경우 JavaScript를 사용하지 않아야합니다. 어떤 사람들은 모든 것에 JavaScript를 사용합니다 .

  • 호버 효과 (CSS 여야 함)
  • AJAX ( href합리적 이어야 함 )
  • 포지셔닝 (CSS 여야 함)

이점은 다음과 같습니다.

  • 사이트가 더 빨리 표시됩니다
  • CSS는 대부분 JavaScript보다 훨씬 덜 복잡합니다
  • 백업 href링크가 있으면 검색 엔진, 다른 탭에서 링크를 열려고하는 사용자 및 JavaScript를 싫어하는 사용자에게 도움이됩니다.

물론 AJAX는 매우 시원하고 동적 페이지도 있으므로 일부 사람들은 필요하지 않기 때문에 이러한 것을 버리지 마십시오.

내 요점은 JavaScript없이 일을하는 법을 배우는 것이 좋으며 JavaScript를 최소화하는 것이 좋으며 JavaScript가 작동하지 않을 때 백업하는 것이 좋지만 JavaScript가 필요하기 때문에 기능을 피할 이유가 없습니다.


1
수년 전에 Man Machine Interfaces에 대한 몇 가지 조언을 받았던 기억이납니다. 소리 등이 탑승해야합니다.
앤드류

8

불필요한 기능, 기간을 피하는 것이 좋습니다. jQuery와 같은 프레임 워크를 사용하면 추가하는 것이 합리적이지만 때로는 그렇지 않은 프릴을 추가하기가 매우 쉽습니다. 예를 들어 :

실제로 애니메이션을 적용해야합니까?

... 또는 ...

그런 간단한 선택기에 전체 DOM 통과가 실제로 필요합니까? 문맥을 사용하여 제한 할 수 있습니까? 처음에 필요합니까?

JS 사용을 피 하지는 않지만 느린 컴퓨터를 찾는 동안 눈에 띄지 않도록주의를 기울입니다. 그림자와 같은 CSS3에서 얻을 수있는 새롭고 멋진 것들도 마찬가지입니다. 과도하게 사용하면 저전력 시스템의 누군가가 실제로 나쁜 경험을 할 수 있습니다.

이에 대한 예외는 다양한 종류의 어플라이언스에 대한 프론트 엔드 제어를 작성하는 것인데, 여기서 JS를 사용하지 않도록 설정해야합니다 (아마도 데이터 센터 관리 네트워크의 엄격한 보안 정책은 JS를 지시하지 않음). 따라서 위의 요구 사항에 관계없이 위의 내용을 취해야합니다.


6

나는 비교적 새롭고 젊은 웹 개발자 (약 4 년)이기 때문에 자바 스크립트가 어디에나 있기 때문에 이것에 대해 많은 연구를해야한다고 생각합니다.

내 프로젝트에서 수행하려는 작업은 자바 스크립트없이 사이트 기능을 확인한 다음 의미가있는 곳에 자바 스크립트를 추가하는 것입니다 (클라이언트 측 유효성 검사, UI 개선 등). 그것은 진보적 인 개선 의 일종이며 SEO, 비활성화 된 자바 스크립트 및 이전 브라우저 비 호환성을 처리합니다.

똑같은 질문이 너무 많이 제기되었지만, 내 사랑을 기억할 수는 없습니다.


5

JavaScript 사용은 여러 경우에 제한 될 수 있습니다.

  • 확인. 서버 측에서 수행해야합니다. 때로는 웹 응용 프로그램에서 빠른 클라이언트 측 유효성 검사가 있지만 그 자체로는 충분하지 않습니다.
  • 매우 중요한 작업. 사용자는 브라우저의 스크립트를 비활성화하여 JS 코드가 전혀 작동하지 않도록 선택할 수 있습니다. 어떤 경우에도 어떤 브라우저에서든 작동하는지 확인하려면 JS를 신뢰하지 마십시오.
  • 속도. JS 코드는 클라이언트로 보내 져야하며, 더 많은 코드를 작성할수록 시간이 더 걸립니다. 적은 양의 코드는 실질적인 영향을 미치지 않습니다.

JS에는 서버 측 코드로 대체 할 수없는 많은 기능이 있습니다. 위의 것 외에는 JS 사용을 제한하는 합리적인 주장이 있다고 생각하지 않습니다.


5

" 데이터베이스 기반 웹 사이트 "가 그 핵심입니다. 웹 사이트를 만드는 방법에는 두 가지가 있으며, 허용되는 자바 스크립트의 양은 실제로 사용하는 웹 사이트에 따라 다릅니다. 당신은 만들 수 있습니다 :

  1. 컨텐츠 중심 웹 사이트 . 첫 번째 경우, 마법의 단어는 "진보적 인 향상"입니다. 일반 HTTP를 통해 컨텐츠에 대한 클래식 액세스를 제공 할 수있는 중복 기능으로 Javascript를 제한합니다.

  2. 웹 응용 프로그램 . 응용 프로그램의 경우 웹을 소프트웨어 플랫폼으로 사용하고 있습니다. 앱은 최신 브라우저, 최신 버전의 인기있는 자바 스크립트 라이브러리, 마우스로 데스크탑 액세스 및 / 또는 멀티 터치로 태블릿에 액세스 할 수있는 소프트웨어에 대한 일부 가정에 의존합니다.

소프트웨어 플랫폼으로서의 웹

실제로 응용 프로그램을 구축하는 경우 최소 액세스 요구 사항은 정상입니다. 특정 플랫폼을 대상으로 다른 방식으로는 구축 할 수없는 고급 기능을 얻을 수 있습니다. 그것은 파이썬이나 자바 또는 .Net을 위해 개발하는 것과 같습니다. HTML5와 같은 유행어와 "어디서나 실행"을 약속하지 마십시오. 전체 플랫폼이 지원되는 경우에만 장치간에 이식 가능한 코드를 사용할 수 있습니다. 개발 스택이 변경되면 소프트웨어가 중단됩니다.

따라서 지불해야 할 가격은 새로운 버전의 플랫폼이 출시됨에 따라 움직이는 목표를 따르는 것입니다. 플랫폼이 진화함에 따라 앱이 계속 작동하도록 따라 잡아야합니다. 패키지 나 응용 프로그램 저장소에 의존하지 않는 앱의 반 유니버설 전달 메커니즘 만 얻을 수 있습니다. 그러나 이전 네트워크 컴퓨터 시스템과 웹을 차별화하는 주요 기능이 손실됩니다.

컨텐츠 전달로서의 웹

컨텐츠 중심 웹 사이트는 다른 짐승입니다. 그들은 고전적인 월드 와이드 웹의 전통에 있습니다. 클라이언트가 컨텐츠를 느슨하게 해석하여 프리젠 테이션 전에 원하는 변환을 수행 할 수 있습니다. 이 사이트는 현재 표준을 지원하거나 지원하지 않을 수있는 다른 플랫폼의 생태계에서 액세스 할 것으로 예상됩니다.

  • 가장 비싼 최신 종과 휘파람을 지원하는 모바일 장치
  • 업데이트 방법을 모르거나 (집에서) 모르는 (집에서) 오래된 브라우저 사용자
  • 이전 API를 사용하지 않는 인기있는 엔진의 향후 버전

항상 진화하는 현재의 자바 스크립트 유형이 필요한 경우 모든 것을 잃게됩니다. 이와 관련하여 콘텐츠에 액세스하지 못하게하는 깨진 자바 스크립트는 죄입니다.

"자바 스크립트 사용을 최소화해야한다"고 말하는 사람들은이 스타일을 옹호합니다. 그것은의 확인을 포함하는 일부 , JS 당신을 마음,하지만 모든 기능은 서버 측을 얻을 수있는 콘텐츠에 대한 기본 accesss와 중복해야한다 :

  • 데이터 입력 검증
  • 가장 빠른 탐색을위한 AJAX 컨텐츠 업데이트 (JS 없이도 작동)

이 방법의 이점은 테스트 및 업그레이드가 덜 필요하고 유통 기한이 길다는 것입니다. 20 년 전의 첫 번째 정적 웹 페이지는 여전히 모든 웹 클라이언트에서 찾아 볼 수 있지만 첫 번째 웹 응용 프로그램은 영원히 중단됩니다. 사이트에 아카이빙 가치가 있다면 장기적으로 웹을 애플리케이션 플랫폼이 아닌 컨텐츠 전달 시스템으로 사용하는 것이 유리합니다.


3

저는 주 정부에서 일하고 있으며 결과적으로 대부분의 개발에는 데이터 중심의 대화 형 웹 사이트가 포함됩니다. 과거 데이터, 양식 제출 등을 쿼리합니다. 다음과 같은 이유로 Javascript를 절대 최소로 유지합니다.

1) 양식 입력의 유효성 검사는 항상 클라이언트 측이 아닌 서버 측에서 이루어져야합니다. 클라이언트 측에서 입력의 유효성을 검사하려는 경우 해커가해야 할 일은 웹 페이지의 로컬 복사본을 만들고 Javascript를 다시 작성하여 보내려는 내용 (SQL 삽입 등)을 허용하는 것입니다. 귀하의 검증은 독점적 통제, 즉 서버에서 수행되어야합니다.

2) 많은 사용자가 Javascript를 끄거나 제대로 구현하지 않을 수있는 브라우저를 사용합니다. 정부이기 때문에 정말 오래된 장비를 사용하더라도 모두를 지원해야합니다. HTML은 모든 곳에서 작동합니다. Javascript는 그리 많지 않습니다. 웹 페이지에서 Javascript를 사용하지 않으면 리소스를 거의 사용하지 않고 클라이언트 시스템에서 실제로 작은 공간을 차지하게됩니다. 이를 통해 컨텐츠에 액세스 할 수있는 사람의 수를 최대화합니다. 같은 이유로 CSS를 너무 많이 사용해서는 안됩니다. 1999 년에 컴퓨터를 구입 한 경우에도 간단하게 유지하고 깨끗하게 유지하고 작은 여성들이 귀하의 사이트를 볼 수 있도록하십시오 (실수로 이와 같은 사람들로부터 기술 지원 전화를받습니다).

3) 서버 측 프로그래머보다는 "웹 개발자"가 선호하는 툴인 자바 스크립트는 꽤 추악한 경향이있다. 그리고 디자이너 (정말로 웹 개발자가 정직한 경우)는 웹의 임의 위치에서 "스크립트"를 다운로드 할 때 문제가 발생하지 않는 경향이 있습니다. 그들은 "왜 바퀴를 재발 명합니까?" 그리고 "여기서 발명되지 않았습니다". 그래서 그들은 자신의 코드를 작성하는 대신 종종 다른 사이트에서 무언가를 가져 와서 인터넷에 있으면 공정한 게임이라고 생각합니다. 이 문제에는 두 가지 문제가 있습니다. A) 실수로 사용자를 잡는 데 시간이 걸리는 악의적 인 Javascript를 게시 할 수 있으며 B) 누군가의 저작권을 위반하여 소송을 제기 할 수 있습니다. 두 상황 모두 피해야합니다.

일반적으로 Javascript는 나쁜 생각입니다. 모든 종류의 클라이언트 측 코드는 나쁜 생각입니다. 클라이언트 측에는 마크 업 언어와 CSS 만 포함되어야합니다. 서버 쪽이 무거운 물건을 다룰 수 있도록하십시오.


2

따라 다릅니다.

데스크탑 사용자 에이전트가 의미있는 방식으로 Javascript를 지원하고 실행할 것으로 예상 할 수 있지만 모든 사용자 에이전트가 그래픽 데스크탑 브라우저 인 것은 아니며이를 수용 할 것인지 결정해야합니다.

예를 들면 다음과 같습니다.

  • 검색 엔진 (Google은 일부 자바 스크립트를 실행 하지만 일부 는 아닙니다), 자바 스크립트를 사용하여 탐색하는 경우 검색 봇이 모든 콘텐츠를 찾지 못할 수 있습니다.
  • 애그리 게이터 및 스크레이퍼
  • 텍스트 기반 브라우저 (많은 사람들이 사용하지는 않음)
  • 스크린 리더 및 기타 읽기 도구
  • (일부) 모바일 브라우저

제 경험에 따르면 일반 사용자 (사내, 커뮤니티, 그런 종류의 사용자)를위한 웹 응용 프로그램 인 경우 Javascript를 사용하는 것이 좋습니다.하지만 공개적으로 액세스하고 찾을 수 있으려면 적어도 중요한 것은 기능은 자바 스크립트없이 완벽하게 작동해야하며 '정의되지 않은'동작을 나타내는 것이 아니라 필요할 때 정상적으로 실패해야합니다.


2

구식 접근 방식은 완전히 구식입니다. 예를 들어 사이트 중 하나에서 중재자를 위해 아약스 삭제를 만들었으며 속도가 급격히 향상되어 행복합니다.

물론 개발자는 JS 사용자와 비 JS 사용자 모두에 대해 두 가지 버전을 수행 할 수 있지만 대부분의 경우 비용이 매우 비싸며 웹 사이트 사용자의 1-2 %에 해당하지 않습니다 (물론 Google이 아닌 경우).

제 대답은 '아니오'입니다. JavaScript는 많은 사용자 경험 질문에 대한 답입니다. 왜 사용하지 않아야합니까?


1

내 경험으로는 회사가 정책으로 JavaScript를 비활성화하는 시간이있었습니다. 그러나 지금은갔습니다. 현재 저는 큰 글로벌 회사를 위해 몇 가지 큰 인트라넷 응용 프로그램과 웹 응용 프로그램을 구축했습니다. 모든 애플리케이션에서 JavaScript 및 JQuery 사용은 고객이 기대하는 것의 일부였습니다.

고객을위한 애플리케이션 구축은 더 이상 속도와 보안뿐만 아니라 고객은 AJAX 기술의 유용성과 사용법에 초점을 맞추기를 원합니다. JavaScript를 사용하지 않으면 그렇게 잘 작동하지 않습니다. PostBacks는 계산과 같은 매우 작은 작업이나 그와 비슷한 일부 작업에 대해 항상 옵션이 아닌 대부분의 회사에 적용됩니다.

대기업의 현재 상황에 대해 생각할 때 JavaScript가 현재 필요한 또 다른 지표가 있습니다. 현재 비즈니스에서 실행중인 CMS 시스템을보십시오. 대부분은 Microsoft SharePoint 또는 Adobe CQ를 사용하고 일부는 Drupal 또는 기타를 사용합니다. 이 모든 시스템은 JavaScript를 사용합니다. 자바 스크립트가 없으면 사용자가 예상 한대로 대부분의 응용 프로그램이 작동하지 않습니다.


0

시간이 지남에 따라 JavaScript가 사용되어 악용되었으며 스크립트는 취약점과 멀웨어 소스로 가득 찼습니다.

많은 기업 네트워크는 오늘날 많은 조직에 여전히 옳고 그른 정책 인 JS를 비활성화함으로써 대응했습니다.

아주 간단하게, 나는 어떤 사이트가해야한다고 제안 의존하지 작동 JS에


3
나는이 의견이 완전히 구식이라고 생각한다. 대부분의 회사는 인트라넷 솔루션에 SharePoint 또는 CQ를 사용하고 있습니다. 두 시스템은 모두 JS에 의존합니다.
Smokefoot

나는 "대부분의 회사"가 Sharepoint ...를 사용하는 것을 절대적으로 반박한다. 그리고 내부적으로 JS를 허용하는 회사의 경우에도 인트라넷 설정은 외부와 다를 수있다.
앤드류

0

여기에 나오는 대부분의 답변에서 설명 하듯이 사용 javascript은 해가되지 않습니다. 코딩과 지저분한 소스 코드 coffee-script를 저장하려면 많은 노력을 기울이지 않아도됩니다 javascript.

http://coffeescript.org/

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.