웹 브라우저라는 범위 내에서는 실행의 한계가 있을 수도 있으나, 기술적인 한계는 아니다. 클라이언트 자바 스크립트는 외부의 침입(?)을 방지하기 위한 용도로도 사용된다. 예를 들어, 여러분의 시스템 파일을 바꿀 수도 있는 자바스크립트가 다운 가능하다고 한다면 문제가 발생할 것이다. 이와 비슷한 제한사항이 자바 애플릿에도 존재한다.

즉, 자바스크립트는 여러분의 시스템 자원을 제어하는 용도로도 사용될 수 있으며, 이와 같은 경우는 적절한 보안 대책이 필요하게 된다.

서버의 경우는 특정한 사용자에게만 허용하는 디렉토리 같은 것을 만들 필요가 있을 것이다. 서버 자바스크립트 인터프리터는 이러한 보안 모델의 기반하에 작동한다.

여러분의 애플리케이션 내에 스크립트 실행 기능을 넣는다면 매우 유용할 것이다. 이는 네트워크나 웹 서버 등의 환경과는 관계없이 유용하게 사용될 수 있다.

스크립팅은 여러 가지 작업의 자동화에 유용하게 사용될 수 있으며, 기본적인 프레임워크 내에 꼭 들어맞는 애플리케이션을 만드는 데에도이용할 수 있다. 여러분은 유용한 구성요소의 툴킷을 만들어 스크립트 제어하에 이를 호출할 수 있으며, 이러한 과정 속에서 적절한 애플리케이션이 만들어진다.

서버측 스크립트는 개발자에게 많은 이점을 제공한다. 사용자로부터 스크립트를 감추고, 추가 플러그인 또는 COM 컨트롤을 다운로드할 필요없이 HTML 페이지를 유용하게 만들 수 있다.

이에 반해, 클라이언트는 특정한 스크립트를 실행하는 데 최고의 장소로 여겨지고 있다. 만약, 서버의 폼에서 데이터를 확인하려고 하면 어떤일이 일어날까? 일부 값에서 에러가 발생하게 되면, 서버는 에러 메시지를 전달하므로 클라이언트는 다시 폼으로 채워지고 데이터 확인을 필요로하게 된다. 이는 서버의 추가 작업, 네트워크의 정보 전달의 폭주와 같은 사용자의 중요한 시간 지연을 암시하는 것이다. 별로 대수롭게 생각하지 않더라도 이 영향은 매우 크다.

하지만 해결 방법은 간단히 클라이언트측 코드를 ASP 페이지로 통합하면 된다. 모든 서버측 스크립트는 <%...%> 태그 또는 <SCRIPT RUNAT=SERVER> ...<SCRIPT> 태그로 제한되어 있다는 것을 기억할 것이다. 서버는 이러한 태그에 있지 않은 스크립트는 처리하지 않으며, 브라우저를 떠나서 이러한 스크립트는 평범한 HTML로 해석되고 실행된다.

클라이언트 측 코드를 ASP 페이지로 통합하게 되면, 서버측 코드의 서버 오브젝트 모델과 클라이언트 코드의 사용자 인터페이스 모두를 사용할 수 있는 페이지가 만들어진다. 서버측 코드는 브라우저의 요소를 사용할 수 없으며, 클라이언트측 코드에서는 서버측 오브젝트를 사용할 수 없다. 이 특징을 이해하는 것은 알맞은 요소를 지정하고 문제가 발생하는 원인을 찾는 데 매우 중요하다.