눈에 잘 띄지 않는 JavaScript는 괜찮습니까?

웹 사이트의 모든 사용자가 JavaScript를 사용하도록 설정 해야하는 경우 눈에 잘 띄지 않는 JavaScript를 사용하는 것이 좋습니까?

나는 진보적 인 향상을 위해 노력하고 있지만, 고급 웹 애플리케이션이 구식 브라우저 또는 JavaScript를 사용할 수없는 경우 사용자를 튕겨 낼 때 중요한 점은 무엇입니까?

타겟층이 매우 적으며 타겟층에게 필요한 브라우저 및 플러그인 / 기능을 알려줄 수 있습니다. 그래서 내 질문은 JS와 HTML을 혼합하는 것입니다. onclick 속성을 사용하는 것과 같습니다.

이것은 디자인 결정이 아닌 비즈니스 결정입니다.

JavaScript (또는 Flash 또는 Silverlight)없이 작동하는 웹 사이트 버전을 제공하는 데 비용이 발생합니다. 사업은 수익 / 방문자의 손실이 가치가 아닌지 여부를 결정한다.

따라서이 버전을 작성하는 데 $ 10,000의 비용이 든다면 (숫자가 많을 수도 있지만이 예제에만있을 것입니다.) 비즈니스 수명이 사이트 수명 기간 동안 늘어날 것입니까? 그렇지 않은 경우 해당 버전을 제공하지 마십시오.

그러나이 버전을 작성하는 데 100 달러 밖에 들지 않으면 우아한 성능 저하를 제공하는 것이 좋습니다.

JavaScript 지원 브라우저 만 대상으로 비즈니스 결정을 내리고 사용자가 JavaScript를 사용 가능하게하려면 응용 프로그램에서 현재 사용 가능한 기능을 활용하는 것이 좋습니다. 스택 오버플로 자체와 마찬가지로 사용자가 사이트를 활성화하지 않으면 사이트가 제대로 작동하지 않는다는 경고가 표시됩니다.

다른 사람이 아직 제기하지 않은 것…

웹 사이트의 99 %는 JavaScript가 거의 없거나 전혀없는 특정 방문자를 환영합니다. 해당 방문자의 이름은 Googlebot 입니다.

_{모두가 맹인 방문객들에게 관심을 가져야하는 큰 이유는 ...}

검색 엔진 트래픽을 전혀 신경 쓰지 않는 극소수의 사람이라면 이것이 귀하의 특권입니다. 그러나 확실히 일반적인 규칙은 아닙니다.

특정 내부 환경을 위해 글을 쓰는 사람들은 IE6이 여전히 존재하는 큰 이유입니다.

생각 해봐

JS 전용 사이트 (이 경우 '응용 프로그램'이 더 나은 단어 일 것입니다)를 수행하는 경우 JS의 소위 '방해 성'은 경우와 같이 정상적으로 저하시키지 않아야 할 때와 같이 크게 중요하지 않습니다. JS 버전.

그러나 눈에 거슬리지 않게 작성된 JavaScript는 일반적으로 작성하고 유지하는 것이 더 쉽습니다. JS를 깨뜨리지 않는 HTML 레이아웃과 HTML을 깨는 것에 대한 걱정없이 JS를 바꾸는 것이 더 쉽습니다.

웹 사이트를 구축하는 경우 JavaScript를 방해하지 않습니다. 그러나 Google 문서와 같은 일부 형식의 응용 프로그램을 작성하는 경우 JavaScript가 눈에 거슬리게됩니다.

JavaScript 및 HTML5는 필요한 경우 응용 프로그램을 작성하는 데 유용하지만 실제로 비즈니스 선택입니다.

대부분의 사용자 (내 사용자, 사용자에 대해 잘 모르겠습니다)에는 JavaScript를 사용할 수 있고 활성화되어 있습니다. 그 사용자들에게 훌륭한 사용자 경험을 제공합시다 . 그러나 여전히 Javascript없이 작동하는 사이트 버전을 제공해야합니다. 2 버전을 빌드하는 것이 번거 롭다는 것을 알고 있지만 웹 개발에 사용되는 방식입니다. (실제로 여러 버전을 빌드해야 할 수도 있고, 세 번째는 사이트의 모바일 버전 일 수도 있습니다).

원하지 않는 것은 가장 일반적인 분모를위한 디자인입니다. "자바 스크립트를 사용하지 않도록 설정 한 일부 사용자가 있으므로 사이트를 잘 작동하도록 사이트를 디자인 할 것입니다. " 이것은 Javascript를 가지고있는 대부분의 사용자에게 불이익을줍니다.

onlick 속성 사용을 언급했습니다. 페이지 탐색에 JavaScript 이벤트 핸들러를 사용할 계획입니까?

한 가지 이유 때문에 이것을 반대하는 것이 좋습니다 . 중간 클릭을 중단 합니다.

일반 링크 클릭의 경우 JavaScript가 활성화되었다고 가정하면 기능적으로 동일합니다.

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

첫 번째 예제를 가운데 클릭하면 myPage.htm이 아닌 빈 페이지가 나타납니다.

이 예제와는 별개로 비즈니스에 적합한 JavaScript를 사용하는 것이 좋습니다. 인라인 JavaScript를 작성하는 데 시간이 덜 걸리지 만 (유지 관리 할 필요는 없음) 상황에 따라 점진적 향상의 손실이 중요하지 않을 수 있습니다.

10 년 전에는 눈에 잘 띄지 않는 JavaScript 가 괜찮 았습니다 . 아마추어이거나, 프로토 타입을 제작하거나, 레거시 코드 나 데이터 중심 코드에 대한 의존성과 같은 상황에 따라 비용이 많이 드는 것도 괜찮습니다. 알을 고치기에는 너무 많이

처음부터 무언가를 구축하는 경우 표준을 따르고 깨끗하고 유지 관리하기 쉬운 코드를 작성하십시오. 당신이 자랑스러워 할만한 어떤 것을 쓰십시오. 불쌍한 schmuck이 당신이 해킹 한 일을 이해하지 못해서 도움을 요청할 때부터 지금부터 아프지 않을 것입니다. 웹 디자이너가 복잡한 HTML 및 JavaScript를 통해 길을 찾지 않고도 CSS를 쉽게 바꿀 수 있도록 무언가를 작성하십시오.

모든 개발자가 들어 와서 유지할 수 있도록 확장 할 공간이 있도록 응용 프로그램을 빌드하십시오. 지금 투자 한 시간은 미래가 아닌 다른 사람의 시간을 절약 해줍니다.

다른 컨텍스트에서 JavaScript를 재사용 할 수 있는지 확인하십시오. 완전한 웹 사이트 재 설계는 단지 재 설계가 될 수 있고 이미 존재하지만 터프하게 구축되지 않은 것의 완전한 재 구축이 될 수 없는지 확인하십시오.

원래의 디자인을 재 설계 할 때와 같은 시간을 재 설계 하는 데 얼마나 당황 스러울 지 상상해보십시오 .

경험으로부터 나를 믿으십시오. 눈에 잘 띄지 않는 JavaScript 는 비용이 많이 드는 실수를 막을 수 있습니다.

알았어, 내가하는 모든 네크로의 크립 키퍼라고 불러.하지만 이것의 진정한 가치가 제대로 이해되지 않았다 역사적으로, "명확하지 않은 JavaScript"또는 파일에 최대한 링크되지 않은 인라인 HTML 이벤트 핸들러 속성 및 스크립트 태그를 통해 JS를 HTML 외부로 유지하는 것이 다음과 같은 중요한 요소입니다.

• 접근성 문제
• SEO
• 그리고 점진적인 향상

거짓말! (그러면 지금은 그럴 것입니다)

문제의 진실은 기술적으로 눈에 띄는 JavaScript를 수행하고 위의 세 가지 항목을 계속 끌어낼 수 있다는 것입니다. 당신이 HTML 컨텐츠를 동적으로 구축하지 않는 한, 그것은 하루 중 큰 SEO 아니오였습니다.

그러나 멈추고 생각하십시오.

실제로, 분리를 유지하는 데있어 가장 큰 이익이자 가장 많이 팔린 큰 이익은 항상 개발자가 얻는 직접적인 이익이었습니다. 편리한 동일한 이벤트에 대해 동일한 html 요소에 원하는만큼의 이벤트 핸들러를 가질 수 있습니다. 즉, 태그가 class="some_class"항상 특정 동작을 얻지 만 id="bonus_behavior"div 안에있을 때 보너스 동작이 발생하면 허용되는 이벤트 처리기 내부의 논리를 망칠 필요가 없습니다. 컨텍스트에 따라 핸들러를 추가하거나 추가하지 않을 수 있습니다.

너무 읽기 쉽다

또 다른 이점은 가독성입니다. 브라우저 도구가 IE의 독점적 인 오류 메시지로 구성되어 [object]있지만 IMO에 문제가 있음을 알려주는 더 중요한 문제였습니다 . 여전히 큰 문제입니다. 여기 CSS, JS가 있고 HTML은 서버와 서버가 만나는 곳입니다. 이러한 모든 것들이 한곳에 모이면 후크 (ID, 클래스 및 계층)에 의존하여 모든 것이 HTML에 연결하는 데 사용되는 추상화 계층을 만드는 것이 좋습니다.

IMO를 사용하면 HTML, CSS 및 JS를 더 많이 분리 할 수있을뿐만 아니라 진행 상황을 읽고 수정하는 것이 더 쉬워집니다. "dynamic_combo_box"를 클래스로 사용하는 빈 div가 있으며 데이터를 동적으로로드하는 멋진 선택을하는 것이 좋습니다. 나는 JS와 CSS에서 그것을 찾는 방법에 대한 리드를 가지고 있으며 그러한 문제에 대해 수업에 뛰어 들면 그것이 무엇이고 HTML에서 그것을 찾는 방법을 알게 될 것입니다.

훨씬 더 가파르게 만들기

물론 가독성은 유지 관리 성과 함께 진행되는 경향이 있습니다. 관련 HTML이 자주 발생하는 스크립트 태그에 직접 덤프하여 직접 작업을 수행하면 사람들이 작업중인 다른 페이지의 HTML에서 해당 스크립트를 잘라 붙여 넣기가 더 쉬워집니다. 그들은 비슷한 기능을 원합니다. 이제 당신이 결국 두 가지 성가신 유사하게 될 것입니다.하지만 기대를 무시하고 시간이 지남에 따라 행동이 문제가 될 수있는 100 %는 아닌 두 가지가 될 것입니다. 다른 사람은하지 않았다.

따라서 이러한 HTML 후크에 대한 동작을 리깅하면 코드를 스마트하게 재사용 할 수 있습니다. 대체 구현을 위해 동작을 분기 해야하는 경우 동일한 기능으로 이동하여 HTML 계층 구조 또는 일부 대체 동작을 트리거하는 데이터 첨부로 처리하십시오. 특정 유형의 UI 요소가 작동하는 방식과 나쁜 게으른 잘라 내기 및 붙여 넣기 유형이 UI를 사용하는 것이 가장 쉬운 방법이기 때문에 옳고 유지 보수가 쉬운 것을 이해하려는 사람에게는 쇼핑 중 하나입니다. 지금해야하며 유지 관리가 가능하도록하는 가장 좋은 방법입니다. 공황이나 무관심으로 인해 덜 신경 쓰지 않는 사람에게도 가장 쉬운 "두"일을하십시오.

그러나 2014 년은 어떻습니까?

현대의 단일 페이지 응용 프로그램에서 이러한 까다로운 것들 중 일부는 독단적으로 붙어 있지 않아야하지만 내가 유일한 사람이라고 생각하지 않을 때 나를 믿어야한다는 것이 합법적 인 점 일 수 있습니다 궁극적으로 작업이 쉬워지기 때문에 판매되었습니다. 나는 대부분의 좋은 방법으로 게으르다. 앱 전체에서 변경 사항을 얻기 위해 한 곳에서만 변경해야 할 때, 버그가 무엇인지 파악하기 위해 한 곳에서만 살펴보고, 도대체가 무엇인지 쉽게 이해할 수있을 때 좋아합니다. 계속해서 그 코드를 가장 잘 재사용하여 매우 유사한 것을 수행하는 방법.

DB 또는 데이터 계층을 분리하는 것이 좋습니다. 결국 권투 선수들에게 바람을 불어 넣고 다음날 아침 편집증 냄새 검사를하는 데 10 분을 소비하는 것보다 밤에 세탁을하기 위해 5 분을 모두 걸리는 것과 같이 시간을 절약하는 것은 궁극적 인 이유입니다.

나를 위해, 내가 왜 방해받지 않는 JS뿐만 아니라 스타일 / 행동 / 콘텐츠 문제의 분리를 가능한 한 중요하게 생각하는 것은 이기적인 동기입니다 .WHAT-freaking-WG는 이러한 우려를 당연히 훌륭하고 시원하고 편리한 방법으로 해결하십시오.

이제 모든 사람들이 SPA를 수행하고 있으며 JS없이 실행하는 사람들에 대해 관심을 가져야한다는 것을 거의 바보짓하려고 노력하고 있습니다 (이제 JS로 생성 된 콘텐츠로 접근 할 수있는 접근성). 이것에 관해서는 IMO와 관련하여 여전히 승리가 있으며 개발자 가이 물건을 작성하고 유지 관리하는 것은 대부분 당신에게 있습니다. 그리고 실제로, 그 승리는 항상 가장 밑줄이 났어 야했지만 어떤 이유로 든 결코 손쉬운 수정 / 수정 / 디버그 덕분에 행복한 사고로 당신과 제품에 이익을주기 때문에 어떤 이유로도 그런 적이 없었습니다.

괜찮아?

그래, 내 생각 엔 콘테스트 또는 무언가에 대한 일회용 던져 버림 앱에서. 그러나 나는 습관을 가지고 있기 때문에 여전히 그렇게 할 것입니다. 실제로하기가 더 어렵지 않습니다.

대상 운영 환경을 알고 있다면 jQuery와 같은 Javascript 및 프레임 워크가 진정한 신의 선물이 될 수 있습니다. 예를 들어 SOE가 Javascript 및 IE8을 사용하는 엔터프라이즈 환경에서 집약적 인 클라이언트 측 브라우저 응용 프로그램을 작성하기에 안전합니다.

우아한 성능 저하를보다 쉽게 ​​만드는 것은 눈에 잘 띄지 않는 JavaScript를 매력적인 선택으로 만드는 많은 요인 중 하나 일 뿐이며, 제 생각에는 가장 중요한 것은 아닙니다.

개인적인 경험을 통해 더 큰 프로젝트에 대해 이야기하고 있다면 시간이 지남에 따라 많은 발전을 거둘 수 있지만 눈에 거슬리지 않는 스타일을 사용하면 응용 프로그램을 유지 관리, 디버그 및 리팩터링하기가 훨씬 쉬워집니다. 이것이 모든 방문자가 JavaScript를 활성화해야하는 사이트에서도 항상 눈에 거슬리지 않는 스타일을 사용하는 가장 큰 이유입니다.

일반적으로 익명으로 제공되고 검색 엔진에 의해 색인이 생성되고 광고에 의해 수익이 생성되는 전통적인 "웹 사이트"를 개발하는 경우, 정상적인 성능 저하를 제공해야합니다. 이러한 유형의 사이트는 접근성에 따라 존재하고 죽으므로 접근성을 제한한다는 것은 많은 페이지 뷰와 광고 수익을 잃는다는 의미입니다.

일반적으로 색인을 생성 할 수없고 수익 기반이 아닌 "사이트"(웹 응용 프로그램)라는 제한된 액세스가 훨씬 더 유연 할 수 있습니다. 광범위한 지원, 기능 심도 및 개발 비용 사이의 결정으로 이어집니다. 기존 응용 프로그램을 개발하는 것과 같이 생각하십시오. 어떤 플랫폼을 지원하고 최소 사양은 무엇입니까? 하나의 플랫폼과 제한된 사양 만 목표로 삼 으면 잠재적 인 시장 점유율을 잃는 비용으로 적은 개발 및 지원 비용으로 우수한 제품을 제공하는 데 집중할 수 있습니다.

예 : Google 검색은 웹 사이트입니다. Google 문서는 웹 애플리케이션입니다. Google 검색은 설득력이 없으며 JavaScript, CSS 및 / 또는 이미지 등 없이도 동일하게 작동 할 수 있습니다. 최신 GUI 브라우저에서와 마찬가지로 텍스트 모드 브라우저에서도 작동합니다. Google 문서 도구는 자바 스크립트를 사용 중지 한 상태에서 작동하지 않으며, 자바 스크립트를 사용하도록 설정하라는 경고조차도 정상적으로 저하되지 않습니다.

CSS에서 대부분의 레이아웃과 탐색을 처리하는 것을 선호합니다. 예, Lynx 는 지원하지 않을 수 있지만 알고있는 모든 기능을 갖춘 브라우저는 끌 수 없습니다. 그런 다음 JavaScript는 더 화려하지만 필요한 것은 아닙니다. 이 목적을 위해 Ruby on Rails도 좋아합니다. 동적 페이지 업데이트가 필요하지 않은 한 서버 측에서 수행해야 할 JavaScript를 많이 수행 할 수 있습니다.

질문에 대한 답변을 더 많이 목표로 : 나는 JavaScript가 필요하지 않지만 ChrisF가 지적한 것처럼 비즈니스 사례가 필요합니다.

자바 스크립트는 클라이언트 측에서 제공하는 모든 종류의 동적 컨텐츠에있어 결함 표준입니다. JS가 없다면 실버 라이트가 없을 것입니다.

그렇다면 당신은 당신의 시장 / 청중에 대해 생각해야합니다. 당신은 programmers.stackexchcange 또는 bbc.co.uk/news입니까? 매우 다른 청중.

웹 사이트를 둘러보고 많은 사이트에서 "자랑스러운 자바 스크립트"를 볼 수 있기 때문에 기본 질문에 대한 대답이 있습니다. 예, 괜찮으며 많은 인기있는 사이트, 심지어 Google도 마찬가지입니다.

그러나 사용자가 Javascript를 활성화해야한다고 주장하더라도 JS가 아닌 사용자에게 적절한 수준의 경험을 제공해야합니다. 그렇지 않으면 기꺼이 돌아 오지 않을 것입니다.