날코딩 항목에서 서술되어 있듯, 웹 개발자들은 다양한 마크업 언어 및 프로그래밍 언어를 사용하기 때문에 통합 개발 환경보다는 텍스트 에디터를 사용하는 경우가 많다. 크롬이나 파이어폭스에서는 개발자 도구를 지원하여 브라우저에서 개발을 돕기도 한다.# 텍스트 에디터로는 그냥 메모장을 사용하는 사람들도 있지만 EditPlus, UltraEdit, Notepad++, vim이 주로 사용되었다. 통합 개발 환경이 필요하다면 JetBrains의 WebStorm이 권장되는데 이는 유료이다.[12]이클립스의 JavaScript Development Tools는 무료. 허나 이클립스의 무거움은 그대로 가지고 있다.
부모 자식의 구분도 없으며, 메인 메소드 같은 것도 없고, 클래스-인스턴스 관계도 없으며, 모든 함수가 클래스도 될 수 있으며 인스턴스도 될 수 있다. 그렇기 때문에 모든 함수가 따로 놀기에 따라서 객체 지향처럼 "서로 맞물리는" 것을 기대할 수도 없다.(그런 이유로 클로저 개념이 있다.) 이 특성을 잘 이해해야 한다. 오히려 순서대로 읽는 절차 지향/객체 지향 언어보다는 모든 요소가 각자 따로 움직이는 스타크래프트 맵 에디터 스크립트에 더 가까운 개념으로 이해해야 한다. 로드는 순서대로지만 실행은 동시 실행이다. 그러니까 main()같은건 없고 필요할때 실행되고 사라지는 스크립트들의 집합이라고 보면 된다. 오히려 웹 페이지 자체가 main()이라고 봐야 할 지경.
JavaScript는 C에서 영향을 받은 C-Family 언어로 기본적인 문법이 유사 중괄호로 구분하는 블럭, 세미콜론으로 줄이 끝남을 알리는 것[17], 변수 쓰는 법, 연산자 사용법 등 기초적인 문법이 C 문법과 크게 다르지 않다. 호이스팅 같은 것도 C언어의 잔재이다. 무엇보다 다른언어 쓰다온 사람들을 힘들게 하는건 클래스와 메소드가 외관으로 구분이 안된다라는 점이다.
JavaScript에서도 함수형[18] 언어의 불편함과 호이스팅 등 여러 문제를 무마하기 위해서 클래스 개념의 도입과 변수 선언을 let[19], const[20]로 하는 등 다른 언어 쓰는 사람들의 적응을 돕도록 흉내는 내 주는 척하는게 다행.
JavaScript는 멀티-패러다임 언어로 명령형, 함수형, 객체 지향형 언어다. 기본적으로는 함수가 일급 시민으로 취급되는 언어로써 함수형 프로그래밍 패러다임을 따른다. 자연스럽게 이는 클로저로 시작해 끝을 보는 것이 가능하다.[21] 멀티 패러다임 언어인만큼 원한다면 명령형 프로그래밍(imperative programming)으로 코드를 쓸 수도 있지만 보통은 함수형/선언형 프로그래밍으로 작성해야 JavaScript가 제공하는 장점을 백분 활용하는 것이 가능하다. 객체 지향으로 코드를 작성하는 것도 가능하고 심지어 class도 ECMAScript 6이후로 제공하지만, JavaScript에서의 class는 그냥 function을 class형식으로 쓸 수 있게 제공하는 syntatic sugar에 지나지 않으므로 타 객체 지향 프로그래밍 언어처럼 사용하다가는 장벽에 부딪히기 쉽다. 즉 JavaScript에서 class는 존재하지만 C++의 class와는 완전히 다른 개념이며, JavaScript의 객체 지향 프로그래밍은 함수 프로토타입에 기반한 객체 지향 프로그래밍이다. # 결국 근본적으로 JavaScript는 함수와 함수형 프로그래밍을 제대로 이해하지 않으면 제대로 다룰 수 없는 언어인 셈이다. 좋게 얘기하자면 확장성이 무한한 것이고, 나쁘게 말하자면 일관성이 바닥이다.
이런 특징 때문에 for이나 while 등의 loop은 특수한 경우를 제외하고는 쓰이지 않으며, 어떤 동작을 수행시키는 데 있어서 JavaScript에서 제공되는 prototype function에 콜백함수를 제공하여 선언적으로(declarative programming) 코드를 작성하게 된다. 일반적으로 대학교에서 C++ 등으로 프로그래밍을 시작한 사람이라면 이런 코딩 스타일에 익숙해지는 데 시간이 걸리지만, 한번 익히고 나면 매우 간단명료하게 코드를 쓸 수 있다는 점, 언제나 Immutability가 보장된다는 점, 순수 함수(Pure Function)을 기반으로 코드가 작성되기 때문에 예상치 못한 버그가 최소화된다는 점 등이 매력적인 요소가 정말 많은 프로그래밍 패러다임이다. 2010년 후반 들어서는 RxJS라는 라이브러리를 기반으로 한 반응형 프로그래밍이 등장했다. 함수형 프로그래밍과 매우 흡사하지만 여기에 이벤트와 데이터 스트림(Observable)을 기준으로 사고하는 것을 더한 프레임워크로, side effect 수행 및 asynchronous operation에 있어서 매우 장점이 많아 대세로 떠오르고 있다.
JavaScript는 동적 타이핑, 약타입 언어고[22], 간단한 문법에 코딩 방법이 비교적 유연하기 때문에 초기 진입장벽이 거의 없어서 쉽다고 이야기 되지만, 깊이 들어가 보면 매우 변태적인 특이한 언어이자 매우 우수한 설계를 자랑하는 강력한 언어이다. 편하면서도 강력한 텍스트 표기법(JSON(JavaScript Object Notation))[23]을 가졌으며, 구조적으로 비동기 프로그래밍에 유리하다. 이러한 비동기 프로그래밍에 특화된 특징은 이후 Node.js를 탄생시키며 JavaScript라는 언어의 사용 반경을 폭발적으로 늘리는 데 기여하게 된다.
진입 장벽은 낮지만 실제 사용하려면 모든 언어가 그렇듯 어렵다. 특히 다른 언어와 비교했을 때 상상도 못할 독특한 특징들이 많은 언어이다. 가장 대표적인 것이 객체(Object)의 상수(const) 개념이다. 객체의 경우 상수로 선언해도 메모리값만 상수일 뿐 객체 안의 내용은 변경이 가능하다. 즉 객체가 저장된 공간을 가리키는 정보만 상수일뿐 그 객체의 정보 자체는 변경이 가능하다. 배열도 마찬가지. 이런 이유로 JavaScript에서 객체는 변수로 선언할 이유가 없으며 거의 모든 케이스에서 상수로 선언하는게 일반적이다. 또 이렇게 상수로 선언된 객체의 Immutability를 보장하기 위해 여러 테크닉이 쓰이게 되는데 주로 ECMAScript 6에서 도입된 Spread Operator를 사용하는 것이 일반적이다. 이렇게 객체를 복사하여 사용할 때도 Deep clone하지 않으면 의도치 않게 원본 객체가 변경되어버리기 때문에 많은 주의가 필요하다.
또한 비동기로 작동되는 코드가 많아 코드 위에서부터 차근차근 실행되는 게 아니라는 점 또한 JavaScript를 마스터하는 데에 넘어야할 장벽 중 하나이다. 이 때문에 특히 Side effect 수행이 요구되는 상황에서 절차적으로 원하는 바를 수행하도록 만들기 위해서 간단하게는 promise나 callback을 사용하는 방법에서부터 복잡하게는 반응형 프로그래밍 라이브러리도 사용할 수 있는 등 여러 테크닉이 요구된다. 이런 독특한 특징들 때문에 타 주류 언어와는 또 다른 사고방식을 요구한다. 복잡한 side effect 수행에 있어서 예상치 못한 버그를 유발하는 등 개발자에게 많은 피로감을 안겨주는 특징이지만 이러한 비동기 오퍼레이션은 JavaScript의 높은 퍼포먼스를 지탱하는 주요한 특징 중 하나이다.
짧은 동작들의 경우 절차적 프로그래밍을 해도 잘 돌아가는 것처럼 보이지만 긴 코드를 짜보면 의외로 골치 아프다.[24] 예를 들어 웹 브라우저나 Node.js 서버에서도 JavaScript의 비동기 프로그램 작성시에는 스레드를 분기하여 작업을 분산 처리하거나, 코루틴으로 작업을 대기 시키는 대신 컨티뉴에이션(+타이머)만 이용해 비동기 프로그램을 구현한다. 즉 싱글스레드 위에 시분할만 존재하고 1 프로세스 1 스레드로 작동한다[25]. 스레드 분기와 코루틴 같은 추상화 된 비동기 처리 자원에 익숙한 프로그래머들이라면 이러한 방식으로 인하여 꽤 고생할 수 있다.[26] 특히 람다식이 여러 번 중첩되는 고차 함수는 그야말로 아스트랄의 극치. 정작 Java는 람다식을 8버전에서야 지원한다... 게다가 호이스팅이라는, 특정 조건 하에서 선언하는 순서와는 다르게 변수 및 함수를 할당하는 특성이 있다. 이를 방지하기 위해서 const나 let를 주로 쓴다. 보통 불변성이 있는 const를 더 사용하는 편.
다만 위에서 언급된 코루틴은 ECMAScript 6, 즉 2015년도 표준에 이미 포함되어 있는지 오래다. 보통 코루틴이 아닌 Promise라고 부르다 보니 둘이 같은 것이라는걸 모르는 사람도 있는 편. 또한 병렬적 실행도 Promise.all로 동시 실행이 가능하게 되었다.[27]
2010년대 중반 이후 JavaScript는 구글의 V8 JavaScript Engine 버프를 받아 하루가 다르게 발전하고 있으며 이러한 모양새는 다음 글에서도 잘 나타난다. 2016년에 JavaScript를 배우는 기분 개발자들 사이에서 이런 발전상이 화제가 되기도 했다. 과거에는 브라우저 환경에서만 사용이 가능한 웹 전용 프론트엔드 프로그래밍 언어에 불과했지만, 현재는 Node.js라는 강력한 Runtime Environment[28]의 등장으로 백엔드 언어로써도 매우 강력한 성능을 가진 언어로 재탄생했으며 실제로도 백엔드 분야에서 빠르게 점유율을 높여가고 있다. Node.js 서버는 확장성이 높고 개발자 입장에서도 JavaScript만 알면 접근이 가능해 유지보수 측면에서도 유리한면이 있고 무엇보다 I/O가 자주 이루어지는 애플리케이션의 경우 성능이 매우 좋다. 여기에 ORM까지 등장하면서 심지어 데이터베이스 시스템이 제공하는 Stored Procedure까지도 대체가 가능한 수준까지 이르렀다. 이와 동시에 백엔드 및 프론트엔드 양방향에서 정말 수많은 라이브러리가 등장하면서 발전이 가속화되는 중이다. '여기에 HTML5, 반응형 웹 등 다양한 웹 기술의 발달로 인해 사실상 데스크탑 애플리케이션이 쇠퇴하고 웹이 모던 애플리케이션의 표준이 되면서 중요성이 더욱 두드러지는 언어가 되었다. 실제로 많은 소프트웨어 회사들이 기존 C++나 Java 등으로 쓰여진 PC용 애플리케이션을 웹앱으로 전환하고 있어[29] 수요도 많고 전망 또한 밝은 언어라 할 수 있다.
이 때문에 현재 JavaScript는 확장성이 매우 높은 언어이다. JavaScript만 알면 일반적인 사이트 개발부터 React.js 또는 Vue.js를 사용해 SPA 웹사이트 개발, iOS와 안드로이드 앱을 만들수 있는 React Native, 웹서버나 다른 서버 사이드 애플리케이션에 Node.js, 데스크탑 앱은 리눅스, macOS, 윈도우, tvOS 등 플랫폼에서 사용 가능한 Electron을 이용하거나 React Native for Windows를 사용해 Windows 10 SDK까지 접근할수 있다. 이외에도 순수 JS만을 이용하는 Vanilla JS도 존재한다. 다만 이 경우 빠른 속도를 자랑하지만 역설적으로 프레임워크 미사용에 따라 코드가 더 길어진다는 단점이 존재한다.
과거 프론트엔드 언어로만 JavaScript가 쓰였을 때 가장 유명했던 라이브러리로는 jQuery가 있었다. 잘 익혀두면 직접 짜는 것보다 꽤 간단하게 기능을 불러 쓸 수 있어 대학에서도 가르쳤던 필수 라이브러리였다. 하지만 React나 Vue.js, 혹은 Angular가 등장한 이후로 모듈형 개발이 순식간에 대세가 되었고, 이는 jQuery 대비 비교도 안될 정도로 월등하게 생산성이 높기 때문에 현재로서는 jQuery 자체가 모던 웹 애플리케이션 개발에는 더이상 사용되지 않는 기술이라 생각하면 된다. 원한다면 다른 프레임워크에 jQuery 라이브러리도 병행해서 사용할 수도 있으나, 그럴 바에야 그냥 직접 querySelector를 사용해서 DOM을 업데이트하는 게 낫기 때문에 정말 간단한 애플리케이션이 아니면 사용할 이유가 없어져버렸다. 사실 jQuery 같은 라이브러리는 2000년대에 각 브라우저마다 JavaScript 문법이 달랐던 대혼돈의 시대에 문법을 통일시켜보자는 취지로 나온 거라 표준 문법이 정착되고 IE가 완전히 도태된 2022년 시점에서는 더 이상 쓸 필요는 없다.
대세가 된 React나 Vue.js의 경우 단독으로 사용되는 경우는 드물며 Redux나 Mobx같은 상태관리 라이브러리를 같이 사용하여 개발한다. 상태관리 라이브러리를 사용하지 않아도 개발은 충분히 가능하나 매우 비효율적이라 규모가 큰 애플리케이션의 경우 사실상 개발 자체가 불가능하다고 보면 된다. 상태 관리를 위한 방법론은 다음과 같은 것이 존재한다.
이렇게만 보면 자바스크립트는 모든 것을 할 수 있는 최강의 언어처럼 보일 수도 있다. 보편적이며, 웹 한정이지만 많은 일을 할 수 있고, 정말 많은 런타임과 프레임워크가 사용자 친화적인 환경 설계를 도와준다. 하지만 자바스크립트의 맹점은 바로 처음부터 잘 설계된 언어가 아니라는 것인데, 호이스팅 이슈[30]는 기본, 백틱 사용, 클래스와는 다른 객체라는 특성, 함수와 객체의 여러가지 선언법[31], 콜백지옥[32] null과 undefined[33]등의 문제로 지금도 끊임없이 새로운 문법이 생성되고 있고 앞으로도 그럴 것이다. 객체지향이면서 안정적인 C# 그리고 자바, 생산성이 뛰어난 파이썬, 다트 등과 비교하자면 자바스크립트는 굉장히 허점이 많고 디버깅에서도 크게 불리하다. 어떻게 보면 이 불완전함이라는 약점을 강력한 웹 생태계를 통해 밀어붙였고, 사용자가 많으니 자연스레 여러 피드백과 지원 환경이 나와 결국 사용자들이 불편함을 편리하게 바꿨다고 볼 수 있다. 따라서 자바스크립트를 배우게 되면 다른 프로그래밍 언어와 완전히 따로 노는 별도의 체계를 이해해야 한다는 어려움이 생기게 된다. 그리고 그것을 시장 주도권으로 다 휘어잡아버렸다. 불편함에 익숙해져라 이에 따라 타입스크립트가 나오자 정적 언어에 익숙한 유저들은 대부분 그곳으로 넘어가버렸지만 타입스크립트 역시 약점이 많기에 자바스크립트를 완전히 대체하지는 못한다.
관련 책으로는 Douglas Crockford의 JavaScript 오브젝트 생성 패턴, xxxxJavaScript: The Good Parts(JavaScript 핵심 가이드) 매우 얇은 게 함정 , 카일 심슨의 You don't know JS(원문)이 있다.
이래도 저래도 이해가 안된다? htm 파일이 main함수고 존재하는 모든 위젯(라디오버튼,체크박스 등)이 클래스, 거기에 메소드가 딸린거라 생각하자.
오늘날 JavaScript가 가장 널리 쓰이는 분야는 클라이언트용 인터페이스이다. 이 때 주로 JavaScript는 웹 브라우저에서 제공되는 DOM API를 사용하게 된다.
JavaScript에서 HTML의 문서에 접근하는 API를 뜻하는 용어로 DOM이 등장하였다. 초창기 ECMA 5의 등장과 본격화 이전 브라우저 전쟁에서 알 수 있다시피 마이크로소프트는 자사만의 구현을 고집하였고, 이는 DOM의 구현이 각 벤더 사마다 다르다는 것을 의미했다. 위에서 말한 Internet Explorer 8 이하의 브라우저들이 addEventListener가 아닌 attachEvent 등 Microsoft 자사의 문법을 개발했다고 했는데, 이 메서드들은 모두 document object 아래에 있다. 다행히 이 문제점은 제2차 브라우저 전쟁 이후 구글이 마이크로소프트를 꺾음으로서 JavaScript 표준화로 점차 사라졌다.
그중에서도 DOM의 경우 ECMAScript 쪽에 의한 제정보다는 애플, 구글 등이 WHATWG(Web Hypertext Application Technology Working Group)를 구성하고 HTML5 표준을 정한 것에 의해 표준화 되었다.
JavaScript의 발전과 함께 이 언어를 서버 사이트 스크립팅 등 다양한 환경에서 사용하고자 하는 움직임이 일어났으며, 그 시초가 바로 CommonJS다.[34] CommonJS는 다양한 API 규격으로 이루어져 있는데, 대표적인 것이 모듈 스펙이다. 당시 ECMAScript 표준에 모듈 스펙이 없었기 때문에, CommonJS의 모듈 스펙은 상당한 파급력을 가졌다.
CommonJS 진영이 모듈 구현에서 네트워크 사용을 고려하지 않는다는 비판에 갈라져 나온 것이 AMD(Asynchronous Module Definition)이다.
CommonJS를 이용한 가장 주요한 플랫폼은 Node.js이다. Node.js로 이뤄진 서버는 꽤 인기를 끌고 있는데, 웹의 프론트엔드와 백엔드를 동일 언어로 프로그래밍 함으로써 얻는 이득이 상당하고, 순수한 서버로서의 성능이 꽤 좋은 편이기 때문이다. 하지만 CommonJS에서 정의한 기능이 차후 다른 형태로 ECMAScript 표준에 대부분 추가되었고, Node.js는 CommonJS의 사용을 중지하기로 하였다. 그럼에도 여전히 CommonJS의 API는 Node.js 환경에서 많이 쓰이고 있다.
첫댓글 https://www.w3schools.com/css/tryit.asp?filename=trycss_default
https://namu.wiki/w/JavaScript 나무위키