인라인 스크립팅을 피해야하는 이유는 무엇입니까?

지식이 풍부한 친구가 최근에 내가 시작하는 데 도움이되는 웹 사이트를보고 "매우 멋진 사이트, 소스 코드의 인라인 스크립팅에 대한 수치심"과 같은 내용을 언급했습니다.

인라인 스크립팅이 발생하는 위치를 제거 할 수있는 위치에 있습니다. 나는 그것이 "나쁜 일"이라는 것을 모호하게 알고 있습니다. 내 질문은 : 인라인 스크립팅의 실제 문제는 무엇입니까? 중요한 성능 문제가 있습니까, 아니면 주로 좋은 스타일의 문제입니까? 사이트에보다 명백한 영향을 줄 수있는 다른 작업이있을 때 상사에게 인라인 스크립팅 전선에 대한 즉각적인 조치를 정당화 할 수 있습니까? 웹 사이트를 방문하여 소스 코드를 들여다 본다면 어떤 요인이 "여기서 전문적인 작업"이라고 말하게되며, 그로 인해 명백한 아마추어 직업에서 벗어나는 이유는 무엇입니까?

글쎄, 그 질문은 글에서 여러 가지 질문으로 바뀌 었습니다. 그러나 기본적으로 인라인 스크립팅-거래는 무엇입니까?

인라인 스크립팅의 실제 문제점은 무엇입니까? 중요한 성능 문제가 있습니까, 아니면 주로 좋은 스타일의 문제입니까?

장점은 성능에 기초한 것이 아니며 Michael이 의견과 컨트롤러 분리와 더 관련이 있습니다. HTML / CSS 파일은 이상적으로 프리젠 테이션 만 포함해야하며 스크립트에는 별도의 파일을 사용해야합니다. 따라서 시각적 측면과 기능적 측면을 더 쉽게 읽고 유지할 수 있습니다.

사이트에보다 명백한 영향을 줄 수있는 다른 작업이있을 때 상사에게 인라인 스크립팅 전선에 대한 즉각적인 조치를 정당화 할 수 있습니까?

아마 아닐 것입니다. 장기적으로 비용을 절감 할 수 있다고 생각하더라도 순수한 유지 보수 작업의 힘을 확신하기는 매우 어려울 수 있습니다. 그러나이 경우 모든 것을 중지하고 인라인 스크립팅을 제거 해야하는 것이 중요하다고 생각하지 않습니다. 대신 다른 이유로 작업 할 때 영역을 수정하기 위해 의식적인 노력을 기울여야합니다. 리팩토링 코드는 정기적으로 수행해야하지만 한 번에 조금만 수행해야합니다.

웹 사이트를 방문하여 소스 코드를 들여다 본다면 어떤 요인이 "여기서 전문적인 작업"이라고 말하게되며, 그로 인해 명백한 아마추어 직업에서 벗어나는 이유는 무엇입니까?

그것이 전문가가 아니라고 말할 수있는 가장 중요한 요소는 테이블이나 div를 과도하게 사용한다는 것입니다. 다음은 왜 과도하게 사용되지 않아야 하는지를 설명 하는 기사 입니다.

나는 악마의 옹호자가되지는 않지만 아마추어 직업과 인라인 JavaScript 사이에는 엄격한 관계가 없습니다. 가장 잘 알려진 여러 웹 사이트의 소스 코드를 보자 :

• 구글,
• 위키 백과,
• 마이크로 소프트,
• 어도비 벽돌,
• 작은 골짜기,
• IBM.

모든 홈 페이지는 인라인 JavaScript를 사용합니다. 모든 회사가 아마추어 사람들을 고용하여 홈페이지를 만들었습니까?

JavaScript 코드를 HTML에 넣을 수없는 개발자 중 한 사람입니다. 나는 내가 작업하는 프로젝트 내에서 결코 그것을 <a href="javascript:...">하지 않습니다 (처음부터 JavaScript가 필요하지 않은 프로젝트에 대한 호출을 제외하고 다른 사람의 코드를 리팩터링 할 때 항상 인라인 JavaScript를 제거하지만 노력의 가치가 있습니다) 확실하지 않습니다.

성능 측면에서 JavaScript를 별도의 파일에 넣을 때 항상 성능이 향상되는 것은 아닙니다. 일반적으로, 우리는 그것을 캐시 할 수 없기 때문에, 그 인라인 자바 스크립트 폐기물 대역폭을 고려하는 유혹 (정적 캐시 HTML을 처리 할 때를 제외하고). 반대로 extern .js 파일은 한 번만로드됩니다.

실제로 이것은 또 다른 조기 최적화입니다 . JavaScript를 외부화하면 웹 사이트가 빨라질 것이라고 생각할 수도 있지만 완전히 틀릴 수도 있습니다.

• 대부분의 사용자에게 빈 캐시가 있으면 어떻게합니까?
• extern .js 파일을 사용하면 웹 사이트가 올바르게 구성되어 있지 않은 경우 (그리고 일반적으로 그렇지 않은 경우) 모든 페이지 요청 마다이 파일에 대한 요청이 있다고 생각하십니까?
• .js 파일이 실제로 캐시됩니까 (IIS를 사용하면 쉽지 않을 수 있음)?

따라서 조기에 최적화하기 전에 방문자에 대한 통계를 수집하고 인라인 JavaScript가 있거나없는 성능을 평가하십시오.

그리고 마지막 논점은 소스에 JavaScript와 HTML을 혼합 한 것입니다. 하지만 누가 둘 다 섞 었다고 했어요? 브라우저가 사용하는 소스 코드가 항상 작성한 소스 코드는 아닙니다. 예를 들어, 소스 코드, 압축 축소 된, 또는 여러 CSS 나 JS 파일을 하나 개의 파일로 결합 할 수있다, 그러나 이것은 당신이 정말로이라는 것을 의미하지 않는다 할 수있다 당신의 변수 a, b, c... a1, 등 또는 당신이 쓴 공백이나 줄 바꿈이없는 거대한 CSS 파일. 같은 방법으로 외부 JavaScript 소스 코드를 컴파일 타임 또는 나중에 템플릿을 통해 HTML에 쉽게 삽입 할 수 있습니다.

결론적으로, 작성한 소스 코드에서 JavaScript와 HTML을 혼합하는 경우 향후 프로젝트에서 JavaScript와 HTML을 사용하지 않는 것이 좋습니다. 그러나 브라우저에 전송 된 소스 코드에 인라인 JavaScript가 포함되어 있다고해서 항상 나쁜 것은 아닙니다.

• 나쁠 수 있습니다.
• 그 반대는 웹 사이트가 성능에 관심이 있고 특정 테스트를 수행하고 클라이언트가 JavaScript의 일부를 인라인하는 것이 더 빠르다고 판단한 전문가가 웹 사이트를 작성했다는 표시 일 수 있습니다.
• 또는 전혀 의미가 없습니다.

"매우 멋진 사이트, 소스 코드의 인라인 스크립팅에 대해 부끄러운 일"이라고 말하는 사람에게는 웹 사이트가 어떻게 수행되었는지 전혀 몰라도 브라우저에 전송 된 소스 만보고 부끄러운 일이 있습니다.

일반적으로 HTML과 JS를 일반적으로 분리 된 상태로 유지하는 것이 좋습니다. HTML은보기 용이고 JS는 응용 프로그램 논리 용입니다. 그러나 내 경험상 html과 자바 스크립트의 극단적 인 분리 (순도를 위해)는 더 유지하기가 쉽지 않습니다. 실제로 유지 관리가 덜 쉬울 수 있습니다.

예를 들어 이벤트 핸들러를 설정할 때이 패턴 (ASP.net에서 차용)을 사용하는 경우가 있습니다.

<input type="button" id="yourId" onclick="clickYourId()" />

또는

<input type="button" id="yourId" onclick="clickYourId(this)" />

이벤트가 발생하는 원인은 미스터리가 없습니다. 그 이유는 6 개월 후에 요소 (예 : Chrome)를 검사하고 어떤 자바 스크립트 이벤트가 트리거되는지 즉시 확인할 수 있기 때문입니다.

반면에, 다른 사람의 코드 (십만 줄)를 읽고 있다고 가정하면 자바 스크립트 이벤트를 발생시키는 마법의 요소를 발견하게됩니다.

<input id="yourId"  />

이것이 어떤 자바 스크립트 메소드를 호출하는지 쉽게 알 수 있습니까? Chrome에서이를 쉽게 만들었지 만 이벤트가 ID에 연결되었거나 컨테이너의 첫 번째 하위에 연결되었을 수 있습니다. 이벤트가 상위 오브젝트에 첨부되었을 수 있습니다. 누가 알아? 행운을 빕니다. :)

또한 디자이너로부터 자바 스크립트를 완전히 숨기면 실제로 업데이트 할 때 가능성을 높일 수 있다고 주장합니다. 누군가가 마술처럼 활동적인 요소에 대한 코드를 편집하는 경우, 코드에서 어떤 요소가 표시되어 있으며 이것이 페이지에서 활동중인 요소임을 알 수 있습니까?

간단히 말해, 모범 사례는 HTML과 Javascript를 분리하는 것입니다. 그러나 경험의 법칙이 극단적으로 실행될 때 때로는 비생산적이라는 것을 이해하십시오. 나는 중간 도로 접근을 주장한다. 대량의 인라인 j를 피하십시오. 인라인을 사용하는 경우 함수 서명은 다음과 같이 매우 간단해야합니다.

1. emptyFunction()
2. doCallWithThis(this)
3. atTheExtremOnlyPassOneNumber(2)

여기서 누락 된 한 가지 주장은 크로스 사이트 스크립팅 공격 에 대한 보호 기능이 강화 될 수 있다는 것입니다 .

Content Security Policy 를 통해 최신 브라우저에서 인라인 JavaScript 실행을 비활성화 할 수 있습니다 . 이로 인해 사이트가 XSS에 피해를 입을 위험이 줄었습니다. 이것은 인라인 스크립트를 제거하는 데 투자하도록 경영진에게 더 설득력있는 주장 일 수 있습니다.

몇 가지 이유가 있습니다.

1. 인라인 스크립트를 축소 할 수 없습니다 (기호 축소를 통해 더 짧은 버전으로 변환). 광대역에 대한 우려는 아니지만 저 대역폭 영역의 모바일 장치 또는 글로벌 데이터 로밍을 사용하는 사용자를 고려하면 모든 바이트가 계산 될 수 있습니다.

2. 페이지 자체가 캐시 가능하지 않으면 브라우저에서 인라인 스크립트를 캐시 할 수 없습니다 (매우 둔한 페이지를 만들 수 있음). 페이지 내용이 매번 바뀌더라도 외부 Javascript 파일은 한 번만 검색하면됩니다. 저 대역폭 연결의 성능에 심각한 영향을 줄 수 있습니다.

3. 인라인 스크립트는 오류와 관련된 줄 번호가 의미가 없으므로 디버그하기가 더 어렵습니다.

4. 인라인 스크립트는 접근성 (508 / WAI) 고려 사항을 방해하는 것으로 유명하지만 모든 인라인 스크립트가 문제를 일으키는 것은 아닙니다. 스크립트 내용을 알리는 스크린 리더가 있으면 문제가있는 것입니다! (이런 일은 결코 보지 못했습니다).

5. 인라인 스크립트는 해당 페이지와 독립적으로 테스트 할 수 없습니다. 외부 Javascript 파일은 자동화 된 테스트를 포함하여 독립적 인 테스트를 통해 실행될 수 있습니다.

6. 인라인 스크립트는 (여기의 다른 답변들에 의해 설명 된 바와 같이) 우려의 분리가 나빠질 수 있습니다.

스크립트 인라인을 포함하지 않는 것이 정당화되는 여러 가지 이유가 있습니다.

• 우선, 분명한 대답은 더 깨끗하고 간결하며 이해하기 쉽고 읽기 쉬운 코드입니다.

• 보다 실용적인 관점에서 종종 스크립트 / CSS 등을 재사용하려고합니다. 웹 사이트 전체에서 이러한 부분을 인라인하면 작은 변경을 할 때마다 모든 단일 페이지를 편집해야합니다.

• 프로젝트에 SCM을 사용하는 경우 서로 다른 구성 요소를 잘 분리하면 변경 내용을 추적하고 관련된 모든 사람이 쉽게 커밋 할 수 있습니다.

내가 아는 한 성능은 문제가되지 않습니다. 웹 사이트의 성격, 서버의 사양 등과 관련된 많은 것들에 의존 할 것입니다. 예를 들어, 웹 페이지가 많은 자바 스크립트를 사용하는 경우 브라우저는 스크립트를 캐시 할 수 있습니다. 코드는 여러 파일로 구분됩니다. 반면에, 일부 서버는 여러 개의 작은 파일보다 하나의 큰 파일을 더 빨리 제공 할 수 있다고 말하고 싶습니다.이 경우 코드를 분리하지 않으면 성능이 더 현명하다고 주장 할 수 있습니다.

누군가이 시험을했을 가능성이 높지만이 분야의 공식 시험에 대해서는 알지 못합니다.

결국, 그것은 다른 어떤 것보다 좋은 관행의 문제이며 가독성과 구성 (특히 wrt point 2) 측면의 이점으로 인해 코드를 별개의 파일로 분리하는 것이 훨씬 더 나은 옵션이라고 말합니다.

대답은 실제로 인라인 코드 (자바 스크립트를 가정)가 어떻게 사용되는지에 달려 있습니다.

인라인 코드, SSI (서버 측 포함), js 파일 및 css 파일의 조합을 사용하여 원하는 효과를 만들고 onClick 이벤트에 대한 서버 리턴 트립을 줄였습니다.

따라서 누군가가 "인라인 코드"를 사용하는 방법이 잘못 이해 될 수 있다는 사실을 완전히 이해하지 못하면 나쁜 진술을 할 수 있습니다.

말하지만, 각 페이지에 js 파일을 사용하는 대신 동일한 사본과 붙여 넣은 자바 스크립트 코드가 있으면 좋지 않다고 말합니다.

각 페이지에 CSS 파일을 사용하는 대신 자체 사본과 붙여 넣은 CCS 섹션이 있으면 좋지 않습니다.

또한 모든 페이지에 전체 js 라이브러리를 포함시키는 데 많은 오버 헤드가 있습니다. 특히 해당 페이지에서 사용되는 함수가없는 경우 특히 그렇습니다.

여기서는 인라인 자바 스크립트를 가정합니다.

코드를 보지 않으면 확실하지 않습니다. 나는 그가 두 가지 중 하나를 언급하고 있다고 생각합니다.

1. 당신은 한 <script>페이지에 흩어져 s의
2. JS는 외부 파일이 아닌 페이지 헤더에 있습니다.

첫 번째는 잘못된 디자인 결정입니다. 소스 파일 전체에 스크립트를 확산 시키면 주어진 스크립트를 검색해야하기 때문에 페이지 를 유지하기가 훨씬 어려워집니다. 모든 코드를 한 곳에 보관하는 것이 훨씬 좋습니다 (소스 파일의 맨 위에 선호).

두 번째는 반드시 나쁜 것은 아닙니다. 페이지 특정 코드 가 해당 페이지에 있어야합니다. 페이지간에 중복 코드가있는 경우을 사용하여 코드를 외부화해야합니다 <script src>. 그런 다음 새 페이지를 만들 때 간단히 해당 파일을 포함시킬 수 있으며 수정 한 버그를 다시 방문하지 않아도됩니다.

웹 애플리케이션을 Chrome 앱으로 만들려는 경우 인라인 자바 스크립트를 사용하지 않는 한 가지 이유 (버튼의 onclick = "DoThis (this)")도 마찬가지입니다. 따라서 웹 앱을 기본 Chrome 앱으로 이식하려는 경우 인라인 자바 스크립트를 포함하지 않아야합니다. "Chrome-etize"하려는 경우 웹 앱에서 변경 (필수)해야 할 사항의 시작 부분에 바로 설명되어 있습니다.

인라인 스크립팅의 실제 문제점은 무엇입니까?

인라인 스크립팅은 좋지 않으며 코드를 읽기가 어렵 기 때문에 피해야합니다.

읽기 어려운 코드는 유지하기가 어렵습니다. 쉽게 읽을 수없고 진행 상황을 이해하지 못하면 버그를 쉽게 발견 할 수 없습니다. 유지 관리가 어려운 경우 나중에 문제가있을 때 더 많은 시간을 낭비하게됩니다.

어려움은 일반적으로 중첩 인코딩에서 비롯됩니다. 다음 코드 줄에 문제가 있습니다. 알아볼 수 있습니까?

<a onclick='alert("What\'s going wrong here?")'>Alert!</a>

이상적으로 코드는 실수가있을 때 쉽게 알아볼 수있는 방식으로 작성됩니다. Joel Spolsky는 2005 년에이 점을 강조한 훌륭한 기사를 썼습니다 . 코드 예제는 나이가 9 세가됨에 따라 크게 개선 될 수 있지만 기본 개념은 여전히 ​​강력합니다. 버그를 쉽게 선택할 수있는 방식으로 코드를 작성하십시오.

중요한 성능 문제가 있습니까, 아니면 주로 좋은 스타일의 문제입니까?

인라인 스크립팅은 반복으로 이어집니다. 100 페이지에 영향을주기 위해 한 줄의 코드를 변경하는 대신 100 페이지를 개별적으로 변경해야합니다. 이것은 가독성이 좋지 않아서 관리자의 성능 에 심각한 영향을줍니다 . 프로그래밍 시간에는 대부분의 코드 최적화에서 몇 밀리 초보다 빠르게 비즈니스의 수익성에 영향을 미치는 실제 비용이 있습니다. 병목 현상을 확실히 최적화하는 것이 중요하지만이 경우 코드의 성능 차이는 무시할 수 있습니다.

사이트에보다 명백한 영향을 줄 수있는 다른 작업이있을 때 상사에게 인라인 스크립팅 전선에 대한 즉각적인 조치를 정당화 할 수 있습니까?

아뇨. 어리 석고 효과가 있다면 어리석지 않습니다.

이것에 대한 프로그래밍 결과는 바보 같은 코드이고 작동하면 바보 같은 코드가 아닙니다. 깨지지 않은 것을 고치기 전에 실제 문제에 집중하십시오. 6 시간, 6 개월 또는 6 년이든 인라인 코드가 결국 업데이트를 필요로하는 경우 향후 유지 관리가 더 쉬운 방식으로 코드를 수정하십시오.

"여기서 전문적인 작업"이라고 말하는 요인은 무엇이며, 명백한 아마추어 직업에서 벗어나는 이유는 무엇입니까?

나는 "직업적"을 단순히 업무 수행에 대한 대가를받는 사람으로 정의하는 경향이 있습니다. 많은 전문가들이 확실히 훌륭한 업무를 수행 할 수는 있지만, 다른 전문가들이 해낸 끔찍한 일에서 아마추어가 생각해 낸 일보다 공포에 질리게되는 경우가 종종 있습니다. 지금까지 저의 많은 작업은 초기 개발자가 저지른 열차 사고 프로젝트를 복구하는 것과 관련이 있으므로 마일리지가 다를 수 있습니다.

말한 바와 같이, 일반적으로 엔터프라이즈 품질 프로그래밍을 쉽게 선택할 수 있습니다.