웹사이트는 Javascript로 동작됩니다.
그렇다면 왜 초기에 Javascript로 채택을 하였을까. Java와 비교를 해보겠습니다.
- 클라이언트측 스크립팅 및 상호 작용:
- JavaScript의 장점: JavaScript는 클라이언트측 스크립팅을 지원하도록 설계되었으며 이를 통해 개발자는 웹 브라우저 내에서 동적이고 대화형 사용자 인터페이스를 만들 수 있습니다. 이 기능은 전체 페이지를 다시 로드할 필요 없이 사용자 상호 작용이 즉각적인 시각적 피드백을 트리거하는 반응적이고 매력적인 웹 애플리케이션을 구축하는 데 중요합니다.
- Java 비교: 반면에 Java는 전통적으로 강력하고 확장 가능한 백엔드 시스템을 구축하기 위해 서버 측에서 더 많이 사용되었습니다. Java는 클라이언트 측 애플릿에 사용될 수 있지만 특히 웹 초기에는 동적 대화형 웹 페이지에 적합하지 않았습니다.
- 더보기
JAVA가 웹 초기에 동적 대화형 웹 페이지에 적합하지 않은 이유
- 브라우저 호환성: 웹 초기에는 브라우저에서 Java 애플릿을 지원하는 수준이 다양했습니다. 애플릿은 웹 페이지에 내장되어 대화형 콘텐츠를 제공할 수 있는 작은 Java 프로그램이었습니다. 그러나 다양한 브라우저에서 일관된 동작을 달성하는 것은 어려웠으며 사용자는 특정 플러그인을 설치하거나 브라우저에서 Java 지원을 활성화해야 하는 경우가 많았습니다.
- 성능 문제: Java 애플릿의 로드 및 실행 속도가 느려져 사용자 경험이 저하될 수 있습니다. Java 애플릿의 성능은 JavaScript와 같이 나중에 등장한 기술만큼 웹 기반 상호 작용에 최적화되지 않았습니다.
(- 다운로드 크기: Java 애플릿을 사용하려면 JVM(Java Virtual Machine)을 다운로드하여 사용자 컴퓨터에 설치해야 합니다. JVM은 대규모 소프트웨어 패키지이므로 다운로드 크기가 상당할 수 있습니다. 다운로드 크기가 크면 로딩 시간이 느려지는데, 특히 인터넷 연결 속도가 느린 사용자의 경우 더욱 그렇습니다.
- 초기화 시간: 초기 다운로드 이후에도 JVM이 애플릿에 대한 런타임 환경을 설정하므로 초기화 시간이 상당히 걸렸습니다. 이 초기화 프로세스는 Java 애플릿의 인지된 속도 저하를 추가했습니다.
- 실행 오버헤드: Java 애플릿 실행은 JavaScript와 같은 기본 브라우저 기술에 비해 추가 오버헤드를 발생시켰습니다. Java 바이트코드는 런타임 시 해석되거나 컴파일되어야 했으며 이로 인해 처리 시간이 추가되고 성능이 저하되었습니다.
- 가비지 수집: Java 애플릿은 가비지 수집을 통한 자동 메모리 관리에 의존합니다. 가비지 수집은 메모리 관리에 유용하지만 JVM이 메모리를 회수함에 따라 애플릿 실행이 일시 중지되어 성능 문제가 발생할 수 있습니다.
- 하드웨어 및 브라우저 차이점: Java 애플릿은 하드웨어 및 브라우저 구현의 차이점과 싸워야 했습니다. 다양한 운영 체제와 브라우저 버전에서 일관된 성능을 달성하는 것은 어려웠으며 한 플랫폼에 대한 최적화가 다른 플랫폼에 제대로 적용되지 않을 수 있습니다.
- 보안 문제: Java 애플릿에는 보안 취약성이 있었고 악성 애플릿이 사용자 시스템의 보안을 손상시킬 가능성에 대한 우려가 있었습니다. 시간이 지나면서 이러한 보안 문제로 인해 웹에서 Java 애플릿이 쇠퇴하게 되었습니다.(
- 샌드박스에서의 실행: Java 애플릿은 "샌드박스"라고 알려진 제한된 환경 내에서 실행되도록 설계되었습니다. 샌드박스는 애플릿이 사용자 컴퓨터의 민감한 리소스에 액세스하는 것을 방지하고 브라우저 범위 내에서만 안전한 작업을 수행하도록 보장하기 위해 만들어졌습니다.
- 권한 모델: Java 보안 모델은 애플릿이 수행할 수 있는 작업을 제어하기 위해 권한 시스템을 사용했습니다. 애플릿에는 애플릿 소스와 사용자 기본 설정에 따라 특정 권한이 부여되었습니다. 그러나 이 권한 모델 구현의 취약점으로 인해 악성 애플릿이 보안 제한을 우회할 가능성이 있습니다.
- 코드 서명: 보안을 강화하기 위해 개발자는 디지털 서명을 사용하여 Java 애플릿에 서명할 수 있습니다. 서명된 애플릿은 개발자가 디지털 인증서를 사용하여 코드에 서명한 애플릿입니다. 이는 애플릿의 출처에 대한 일정 수준의 보증을 제공했지만, 애플릿의 코드에 보안 취약점이 없다는 것을 보장하지는 않았습니다.
- 보안 악용: 시간이 지남에 따라 보안 연구원과 악의적인 행위자는 악의적인 애플릿이 악용할 수 있는 Java 런타임 환경의 취약점을 발견했습니다. 이러한 취약점은 Java 보안 모델의 결함부터 JVM 자체 구현의 버그까지 다양합니다.
- 악성 애플릿의 확산: Java 애플릿이 웹에서 인기를 얻으면서 취약점을 악용하려는 공격자의 표적이 되었습니다. 악성 애플릿은 손상된 웹사이트, 이메일 첨부 파일 또는 기타 수단을 통해 배포될 수 있습니다. 일단 실행되면 이러한 애플릿은 잠재적으로 사용자 시스템의 보안을 손상시킬 수 있습니다.
- 브라우저 공급업체의 응답: Java 애플릿과 관련된 보안 문제가 증가함에 따라 브라우저 공급업체는 해당 실행을 제한하거나 비활성화하는 조치를 취하기 시작했습니다. 일부 브라우저는 Java 애플릿을 실행하기 전에 사용자를 차단하거나 메시지를 표시하는 기능을 구현했으며 시간이 지남에 따라 Java 애플릿에 대한 지원이 감소했습니다.
- Oracle의 조치: Java를 담당하는 회사인 Oracle은 알려진 취약점을 해결하기 위한 패치와 업데이트를 발행하여 보안 문제에 대응했습니다. 그러나 새로운 취약점이 자주 발견되고 사용자가 Java 설치를 업데이트하는 데 걸리는 시간으로 인해 지속적인 보안 위험이 발생했습니다.
) - 학습 곡선: 언어로서 Java는 HTML 및 JavaScript와 같은 기술에 비해 학습 곡선이 더 가파르습니다. 초기 웹은 단순성과 사용 용이성에 중점을 두었고 Java의 복잡성은 당시의 웹 개발 요구 사항에 잘 맞지 않았습니다.(
- 객체 지향 패러다임: Java는 엄격한 객체 지향 프로그래밍 언어입니다. 캡슐화, 상속, 다형성과 같은 객체 지향 원리를 이해하고 적용하는 것은 프로그래밍을 처음 접하는 초보자에게는 어려울 수 있습니다. 반면 HTML과 JavaScript는 각각 마크업 언어와 스크립팅 언어이므로 객체 지향 개념에 대한 동일한 수준의 이해가 필요하지 않습니다.
- 컴파일 프로세스: Java는 컴파일된 언어입니다. 즉, 코드를 작성하고 바이트코드로 컴파일한 다음 JVM(Java Virtual Machine)에서 실행해야 합니다. 이 추가 컴파일 단계는 코드가 브라우저에서 직접 실행될 수 있는 JavaScript와 같은 해석 언어에 더 익숙한 초보자에게 복잡성을 가져옵니다.
- 개발 환경 설정: Java 개발 환경 설정은 HTML 및 JavaScript용 환경 설정보다 더 복잡할 수 있습니다. Java 개발에는 일반적으로 JDK(Java Development Kit), IDE(통합 개발 환경) 설치 및 빌드 도구 구성이 포함됩니다. 이 과정은 초보자, 특히 프로그래밍을 이제 막 배우기 시작한 사람들에게는 부담스러울 수 있습니다.
- 강력한 유형 지정: Java는 정적으로 유형이 지정되는 언어입니다. 즉, 변수 유형은 명시적으로 선언되어야 하며 유형 확인은 컴파일 타임에 수행됩니다. 이는 런타임에 변수 유형을 추론할 수 있는 JavaScript와 같은 동적 유형 언어에 비해 더 엄격할 수 있습니다. 초보자는 코딩을 배울 때 동적 타이핑의 유연성이 더 관대하다는 것을 알 수 있습니다.
- 추상화 및 복잡성: Java는 장점이자 과제가 될 수 있는 높은 수준의 추상화를 제공합니다. 추상화를 사용하면 복잡하고 확장 가능한 시스템을 구축할 수 있지만 인터페이스, 추상 클래스, 디자인 패턴과 같은 개념에 대한 더 깊은 이해도 필요합니다. 반면 HTML과 JavaScript는 추상화 측면에서 상대적으로 간단합니다.
- 메모리 관리: Java는 가비지 수집을 통한 자동 메모리 관리에 의존합니다. 이는 개발자의 메모리 관리를 단순화하지만 가비지 수집 작동 방식을 이해하고 메모리 사용을 최적화하는 것은 특히 초보자에게는 어려울 수 있습니다. 자동 메모리 관리 기능을 갖춘 해석 언어인 JavaScript는 이러한 측면에서 더 간단해 보일 수 있습니다.
- 느린 개발 주기: Java를 배우고 개발 환경을 설정하는 데 필요한 시간으로 인해 HTML 및 JavaScript와 같은 웹 기술에 비해 개발 주기가 느려질 수 있습니다. 이는 웹사이트의 신속하고 반복적인 개발에 중요한 요소가 될 수 있습니다.
- 리소스 집약도: Java 기반 웹 애플리케이션은 서버 리소스 및 메모리 사용량 측면에서 리소스 집약적일 수 있습니다. 이는 리소스가 제한된 소규모 웹사이트나 프로젝트의 경우 문제가 될 수 있습니다.
- 호환성 문제: Java 기반 웹 애플리케이션이 다양한 브라우저와 플랫폼에서 원활하게 작동하는지 확인하는 것이 어려울 수 있습니다. 웹 브라우저의 표준 기술인 HTML과 JavaScript는 일반적으로 브라우저 간 호환성이 더 좋습니다.
- 유지 관리 복잡성: Java 웹 애플리케이션에는 복잡한 아키텍처와 프레임워크가 포함되는 경우가 많습니다. 이러한 애플리케이션을 유지 관리하고 업데이트하려면 더 높은 수준의 전문 지식이 필요할 수 있으므로 소규모 개발 팀이나 개인에게는 잠재적으로 어려울 수 있습니다.
- 팀을 위한 가파른 학습 곡선: Java로 웹 사이트를 구축할 때 개인뿐만 아니라 개발 팀의 학습 곡선도 더 가파를 수 있습니다. Java 기술로 작업하도록 팀을 조정하고 교육하는 데는 단순한 웹 기술로 작업하는 팀에 비해 시간이 더 걸릴 수 있습니다.
) - 대체 기술: 웹이 발전함에 따라 JavaScript, HTML, CSS와 같은 대체 기술은 동적 및 대화형 웹 페이지를 만드는 데 인기를 얻었습니다. 이러한 기술은 더 가볍고 구현하기 쉬웠으며 모든 주요 브라우저에서 지원되었습니다.
- 클라이언트측 vs. 서버측: Java는 일반적으로 서버측 개발과 관련이 있습니다. 웹 초기에는 클라이언트 측 기술과 서버 측 기술이 명확하게 구분되었습니다. Java는 애플리케이션 구축을 위해 서버 측에서 자주 사용되었지만 클라이언트 측 상호 작용에는 덜 선호되었습니다.(
Java가 일반적으로 서버 측 개발과 관련되어 있고 클라이언트 측 상호 작용에 덜 선호된다는 주장은 웹 개발의 역사적 맥락과 프로그래밍 언어로서의 Java의 특성에 뿌리를 두고 있습니다.- 서버측 개발:
- 서버 측 Java의 강점: Java의 강점은 견고성, 확장성 및 복잡한 서버 측 작업을 처리하는 능력에 있습니다. JVM(Java Virtual Machine)을 통해 플랫폼 독립적인 환경을 제공하므로 개발자가 한 번 코드를 작성하고 다른 플랫폼에서 실행할 수 있습니다.
- 엔터프라이즈 수준 애플리케이션: Java는 웹 서버, 애플리케이션 서버, 백엔드 시스템을 비롯한 엔터프라이즈 수준 애플리케이션 개발에 널리 채택되었습니다. Java의 광범위한 표준 라이브러리, 프레임워크(예: Spring 및 Java EE) 및 멀티스레딩 지원을 통해 Java는 비즈니스 로직, 데이터베이스 상호 작용 및 기타 서버 중심 기능을 처리하는 서버 측 구성 요소를 구축하는 데 매우 적합합니다.
- 초기 클라이언트 측 상호 작용:
- JavaScript 우위: 웹 초기에는 클라이언트 측 상호 작용이 주로 HTML, CSS 및 JavaScript를 통해 이루어졌습니다. JavaScript는 클라이언트 측의 상호작용성과 응답성을 향상시키는 핵심 기술로 등장했습니다. 가볍고 HTML과 통합하기 쉬웠으며 웹 브라우저에서 직접 실행되었습니다.
- Java 애플릿: Java 애플릿과 같은 기술을 통해 클라이언트 측에서 Java를 사용할 수 있었지만 느린 로딩 시간, 보안 문제, 추가 플러그인 필요성 등의 문제에 직면했습니다. JavaScript는 클라이언트 측 스크립팅을 위한 더 간단하고 접근하기 쉬운 대안으로 점차 주목을 받았습니다.
- Java의 클라이언트측 과제:
- 복잡성 및 리소스 집약도: 언어로서의 Java는 JavaScript보다 더 복잡하므로 클라이언트측 개발에 장벽이 될 수 있습니다. 또한 Java를 클라이언트 측으로 가져오는 한 가지 방법이었던 Java 애플릿은 종종 리소스 집약적이어서 최적이 아닌 사용자 경험으로 이어졌습니다.
- 학습 곡선: 앞에서 설명한 것처럼 Java의 가파른 학습 곡선으로 인해 단순성과 사용 용이성이 우선시되는 빠르고 가벼운 클라이언트측 개발에는 매력이 떨어졌습니다.
- 웹 기술의 진화:
- 경량 기술로의 전환: 웹이 발전함에 따라 클라이언트측 개발을 위한 경량 기술로의 전환이 있었습니다. JavaScript는 HTML5 및 CSS3의 지원을 받아 동적 및 대화형 사용자 인터페이스를 만드는 데 주요 언어가 되었습니다. 이러한 추세는 배우기 쉽고, 구현이 빠르며, 웹 브라우저와 잘 통합되는 기술을 선호했습니다.
- 우려사항의 명확한 분리:
- 클라이언트 측과 서버 측 분리: 클라이언트 측과 서버 측 책임을 분리하는 아키텍처가 표준 관행이 되었습니다. 이러한 분리를 통해 사용자 인터페이스와 사용자 상호 작용을 처리하는 클라이언트 측 기술과 비즈니스 논리, 데이터 저장 및 데이터베이스와의 통신을 관리하는 서버 측 기술을 통해 보다 유지 관리 및 확장 가능한 웹 애플리케이션이 가능해졌습니다.
) - 서버측 개발:
- 비동기 작업:
- AJAX 및 비동기 프로그래밍: JavaScript는 웹 애플리케이션이 서버에 비동기 요청을 할 수 있도록 하는 AJAX(Asynchronous JavaScript and XML) 개념을 도입했습니다. 이 비동기 프로그래밍 기능은 사용자 인터페이스를 차단하지 않고 데이터를 가져오고 업데이트할 수 있는 효율적인 웹 애플리케이션을 구축하는 데 기본입니다.
- 더보기
AJAX(Asynchronous JavaScript and XML)는 전체 페이지를 다시 로드할 필요 없이 웹 페이지가 서버와 비동기적으로 통신할 수 있도록 하는 일련의 웹 개발 기술입니다. 이를 통해 더욱 동적이고 대화형 사용자 인터페이스를 생성할 수 있습니다.
- 비동기 요청:
- 정의: AJAX는 기본적으로 서버에 비동기 요청을 하는 것입니다. 비동기란 클라이언트(브라우저)가 서버의 응답을 기다리는 동안 다른 작업을 계속 수행할 수 있음을 의미합니다. 이는 응답이 수신될 때까지 사용자 인터페이스를 차단하는 동기식 요청과 대조됩니다.
- XMLHttpRequest 개체:
- 핵심 구성 요소: XMLHttpRequest 개체는 AJAX의 핵심 구성 요소입니다. HTTP 요청을 생성하여 서버에 보내고 서버의 응답을 비동기적으로 처리하는 데 사용됩니다. 이름에도 불구하고 교환되는 데이터 형식은 XML에만 국한되지 않습니다. JSON과 같은 다른 형식과 함께 사용할 수도 있습니다.
- 서버측 기술:
- 데이터 교환: 서버 측 기술은 들어오는 AJAX 요청을 처리하고 적절한 응답을 다시 보냅니다. 여기에는 서버 측 스크립팅 언어(예: PHP, Python, Ruby) 또는 요청에 따라 동적 콘텐츠를 생성하는 프레임워크가 포함될 수 있습니다.
- 데이터 형식(XML 또는 JSON):
- 데이터 표현: XML은 AJAX라는 용어의 일부이지만 다른 데이터 형식, 특히 JSON(JavaScript Object Notation)을 사용하는 것이 일반적입니다. JSON은 가볍고 JavaScript를 사용하여 구문 분석하기 쉽기 때문에 클라이언트와 서버 간의 데이터 교환에 널리 사용됩니다.
- 콜백 함수:
- 응답 처리: AJAX 요청은 일반적으로 비동기식입니다. 즉, 나머지 프로그램 실행을 차단하지 않습니다. 응답을 처리하기 위해 개발자는 콜백 함수를 사용합니다. 이러한 기능은 서버의 응답이 수신되면 실행되어 웹페이지를 동적으로 업데이트할 수 있습니다.
- DOM 조작:
- UI 업데이트: AJAX의 주요 목적 중 하나는 서버의 응답에 따라 사용자 인터페이스를 동적으로 업데이트하는 것입니다. JavaScript는 DOM(문서 개체 모델)을 조작하고 페이지의 요소를 추가, 수정 또는 삭제하여 변경 사항을 반영하는 데 사용됩니다.
- 혜택:
- 지연 시간 단축: 비동기식 요청을 통해 클라이언트와 서버 간에 필요한 데이터만 교환되므로 전송되는 데이터 양이 줄어들고 응답 시간이 향상됩니다.
- 향상된 사용자 환경: AJAX를 사용하면 전체를 다시 로드하지 않고도 페이지의 일부를 업데이트하여 웹 애플리케이션에 데스크탑과 같은 느낌을 더함으로써 더욱 부드럽고 대화형인 사용자 환경을 구현할 수 있습니다.
- CORS(교차 원본 리소스 공유):
- 보안 고려 사항: AJAX 요청에는 동일한 도메인에서 요청이 발생하도록 제한하는 동일 출처 정책이 적용됩니다. CORS는 서버가 리소스에 액세스할 수 있는 원본을 지정하고 필요할 때 동일 원본 정책을 완화할 수 있는 메커니즘입니다.
- Promise 및 Fetch API:
- 최신 접근 방식: XMLHttpRequest가 AJAX 요청을 처리하는 전통적인 방법인 반면, 현대 웹 개발에서는 Promise를 반환하고 비동기 요청을 위한 더 깔끔한 구문을 제공하는 Fetch API를 활용하는 경우가 많습니다.
- 비동기 요청:
- Java 비교: 웹에서 초기에 사용된 Java는 종종 동기 작업을 포함했으며 비동기 작업 처리는 덜 간단했습니다. 이로 인해 JavaScript는 웹 상호 작용의 비동기 특성을 처리하는 데 더 자연스럽게 적합해졌습니다.
- 빠른 개발 반복:
- 신속한 프로토타이핑: JavaScript의 동적 특성과 브라우저와의 통합을 통해 개발자는 개발 중에 빠르게 반복할 수 있습니다. 변경 사항을 실시간으로 확인할 수 있어 신속한 프로토타이핑이 가능하고 개발 주기가 단축됩니다.
- 더보기
프로토타입 제작은 본격적인 개발에 착수하기 전에 개념을 검증하고, 피드백을 수집하고, 위험을 줄이기 위해 시스템의 예비 버전을 만드는 것과 관련된 소프트웨어 개발의 귀중한 관행입니다. 이는 소프트웨어 제품 구축에 대한 반복적이고 사용자 중심 접근 방식의 필수적인 부분입니다.
- Java 비교: Java의 컴파일 주기와 컴파일 단계를 포함하여 보다 구조화된 환경에 대한 요구로 인해 JavaScript의 가볍고 해석된 특성에 비해 개발 반복이 느려질 수 있습니다.
- 브라우저 간 호환성:
- 통합 개발 환경: JavaScript는 모든 주요 웹 브라우저에서 지원되며 웹 개발을 위한 통합 환경을 제공합니다. 이러한 브라우저 간 호환성은 다양한 플랫폼에서 일관된 동작을 보장하는 데 필수적입니다.
- Java 비교: Java 애플릿은 브라우저에서 실행될 수 있지만 Java 애플릿에 대한 브라우저 간 호환성 보장은 사실상 웹 스크립팅의 표준이 된 JavaScript만큼 원활하지 않았습니다.
- HTML 및 CSS와의 통합 용이성:
- 기본 통합: JavaScript는 웹의 핵심 기술인 HTML 및 CSS와 원활하게 통합됩니다. 이 통합을 통해 개발자는 DOM을 조작하고, 이벤트에 응답하고, 웹 페이지의 모양을 수정할 수 있습니다.
- Java 비교: Java 애플릿은 풍부한 기능을 제공하지만 HTML 및 CSS와 통합하는 데 더 많은 노력이 필요한 경우가 많았으며 동적 페이지 조작에 대해 동일한 수준의 유연성을 제공하지 않았습니다.
- 서버측 개발(Node.js):
- 풀스택 JavaScript: Node.js의 도입으로 JavaScript는 서버 측 개발로 범위를 확장했습니다. 이 전체 스택 기능을 통해 개발자는 클라이언트와 서버 측 모두에서 동일한 언어(JavaScript)를 사용하여 코드 재사용을 촉진하고 개발 프로세스를 간소화할 수 있습니다.
- Java 비교: Java는 서버 측에서 지배적인 힘이었지만 전체 스택에서 일관된 언어를 갖는 것은 JavaScript가 Node.js를 통해 제공하는 고유한 이점입니다.
- 최신 JavaScript(ECMAScript) 채택:
- JavaScript의 진화: 시간이 지남에 따라 JavaScript는 ECMAScript 표준의 도입과 함께 발전하여 최신 기능과 향상된 언어 기능을 제공합니다. 이러한 업데이트는 코드 가독성, 유지 관리성 및 성능을 향상시킵니다.
- Java 비교: Java에는 자체적인 발전이 있지만 JavaScript의 적응성과 발전은 웹 개발 환경에서 특히 두드러졌습니다.
'javascript Deep Dive' 카테고리의 다른 글
| [Javascript] var, let, const 차이점과 각각의 사용 이유 (1) | 2023.12.29 |
|---|---|
| [Javascript] map vs for(각 특징과 map의 장점) (0) | 2023.12.28 |
| [Javascript] V8 엔진 (0) | 2023.12.27 |
| [Javascript] 클래스(class) (1) | 2023.12.26 |
| [JavaScript] prototype (0) | 2023.12.23 |
