자바스크립트의 죽음과 삶

JavaScript의 성공은 적시에 적절한 장소에 있는 것에서 비롯됩니다. JavaScript의 등장은 브라우저 지원과 밀접한 관련이 있습니다. 아시다시피 VBScript는 그다지 운이 좋지 않습니다.

JavaScript는 인기가 있지만 본질적인 결함이 있습니다. Brendan Eich는 JavaScript의 아버지로서 단 10일 만에 JavaScript를 설계했습니다.

JavaScript를 좋아한다기보다는 싫어한다고 말하는 것이 낫습니다. C언어와 Self언어의 하룻밤의 산물이다. 18세기 영국 문학가 존슨 박사는 "자바스크립트의 우수성은 독창성이 아니라 독창성이 뛰어나지 않다"고 잘 말했습니다.
자바스크립트의 가장 명백한 단점은 문법입니다.

선택적 매개변수 및 기본값에 대한 형편없고 장황한 구문

function(a, b, option) {
optionoption = option {}
// ...
}
위 코드에서 옵션은 선택적 매개변수입니다. 전달되지 않은 경우 기본값은 {}입니다. 그러나 전달된 옵션 값은 거짓 값(falsy value)일 수 있습니다. 엄밀히 말하면 다음과 같이 판단해야 합니다.

function(a, b, option) {
option =args.length > ? option :
// ...
}
참고: option = typeof option !== undefine ? option :{}은 전달된 내용이 정의되지 않을 수 있으므로 틀릴 수도 있습니다. b 매개변수가 필요하지 않은 경우 삭제 후 인수.길이를 기준으로 판단하면 수정하는 것을 잊어버리고 오류가 발생하기 쉽습니다.

function(a, option) {
option = 인수 .length > 2 ? 옵션: {};
// ...
}
다음 구문을 추가할 수 있으면 좋을 것 같습니다:

function(a, b, option = {}) {
/ / ... 
}

클로저를 강력하고 성가시게 만드세요:

for (var i=0, ilen=elements.length; i var element = elements[i];
LIB_addEventListener(element, click, function(event) {
Alert(원래는 숫자 + i였습니다);
}) ;
}
위 코드는 인터뷰 질문에 자주 등장합니다. 해결책은 이를 다른 레이어로 래핑하는 것입니다.

for (var i=0, ilen=elements.length; i var element = elements[i];
(function(num) {
LIB_addEventListener(element, click, function(event) {
Alert(원래는 number + num이었습니다);
});
}(i));
}
let 구문이 직접 지원되면 좋을 것입니다.

for (var i=0, ilen=elements. length; i var element = elements[i];
let (num = i) {
LIB_addEventListener(element, function(event) {
Alert(저는 원래였습니다. 숫자 + 숫자);
} ;

// 개인 변수
var listenings = []

내보내기 함수 addEventListener(f) {

listenings.push(f );

}

내보내기 함수clearEventListeners() {
리스너 = []
}

// ...
}

(function() {

import event;

// ...
}())
상속
JavaScript는 프로토타입 체인을 통해 상속을 구현해야 합니다. :

function Employee(first , last, position) {
// 슈퍼클래스 생성자 호출
Person.call(this, first, last)
this.position = position; 🎜>};// Person에서 상속
Employee.prototype = Object.create(Person.prototype);
EmployeeEmployee.prototype.constructor = Employee 정의; toString() 메서드
Employee.prototype.toString = function() {

// 재정의된 슈퍼클래스 호출 toString() 메서드

return Person.prototype.toString.call(this) +
은 + this.position;
};
다음과 같이 쓰면 좋겠습니다.

class Employee extends Person {
constructor(first, last, position) {
super(first, last)
public positionposition =
}

update( 카메라) {
return super.update() +는 + 위치입니다.
}
}
인상
ECMAScript 위원회는 JavaScript에 문법적 수준의 결함이 있음을 깨달았습니다. Harmony 사양에서는 위의 구문이 모두 제안되었습니다.

위 구문은 언제 사용할 수 있나요?

매크로(Macro)가 있는 한
Lisp 언어의 매크로 기능은 매우 강력합니다. 매크로를 사용하면 기본 설정에 따라 원하는 구문 형식을 정의할 수 있습니다. 매크로 기능은 Lisp를 "프로그래밍 가능한 프로그래밍 언어"로 만듭니다.

JavaScript에는 매크로가 없습니다. C 계열 언어에 매크로 기능을 추가하는 것은 여전히 ​​연구 주제이고 매우 어렵습니다.

매크로가 있는 한 구문을 사용자 정의할 수 있습니다. 하지만 자바스크립트의 매크로 기능은 멀기 때문에 다른 방법을 찾아야 합니다.

Harmony
Harmony 사양의 구문 확장은 우리 모두의 꿈일 수 있습니다. Harmony는 ECMAScript 6 사양이 될 가능성이 있습니다. 그때까지 우리는 인내하고 기다려야 합니다.

2011년 5월 기준 w3school에 따르면 IE6의 시장점유율은 여전히 ​​2.4%에 불과합니다. 순 시장 점유율은 IE6의 시장 점유율이 10.36%임을 보여줍니다. IE7도 시장점유율이 높습니다. 이러한 오래된 브라우저는 단기적으로 시장에서 사라지지 않을 것입니다. Amazon과 같은 상업 회사가 이러한 사용자를 포기하는 것은 불가능합니다. 끔찍한 상황. (중국 본토는 훨씬 더 나쁩니다. IE6/7은 여전히 ​​시장 점유율의 40% 이상을 차지합니다.)

우리는 "IE는 망할 것"이라는 말에 의존하여 사용자의 업그레이드를 유도할 수 없습니다. 나는 다음과 같은 말을 들었습니다. IE 사용자는 컴퓨터 하드웨어를 변경할 때만 브라우저를 업그레이드합니다. 안타깝게도 일반 사용자의 경우 기존 하드웨어만으로도 이메일을 수신하고 Facebook 및 Twitter에 액세스할 수 있습니다. 그들이 돈을 쓸 이유가 없습니다.

Goggle Apps는 최근 2011년 8월부터 IE7 지원을 중단할 것이라고 발표했습니다.

다양한 보수적 추정에 따르면 Amazon 웹사이트 개발자는 Harmony 구문 확장 2023을 사용할 때까지 기다려야 합니다!

당신은 전성기입니다. 이 유용한 문법을 ​​사용할 수 있기까지 10년 이상 기다릴 의향이 있습니까?

JavaScript는 죽었습니다
사망 원인: 세미콜론암. (세미콜론 암. 문법이 자바스크립트의 죽음을 가져온다는 뜻의 저자 농담)

위의 분석을 보면 매크로 기능 구현이 너무 어렵고, 하모니 사양 구현이 멀다는 것을 알 수 있다. 떨어져 있는. 많은 프로그래머들이 JavaScript를 작성하기 시작했고, 그들 중 많은 사람들이 JavaScript의 길고 잘못된 구문에 지쳤거나 지치기 시작했습니다. 우리는 새로운 구문이 필요하며 기다리고 싶지 않습니다! 소스 코드 작성 언어인 JavaScript는 죽었습니다!

자바스크립트 씨, 당신은 영광스러운 통치를 받으셨습니다. 우리는 여러분과 함께 즐거운 추억을 쌓았고, 많은 흥미로운 애플리케이션을 함께 제작했습니다. 고인의 명복을 빕니다.

JavaScript는 여기에 있습니다
프로그래머는 자신의 운명을 통제하고 싶어합니다. 소스 코드 작성 언어로서 JavaScript는 죽었습니다. 더 나은 소스 코드 언어를 선택하거나 생성하여 ECMAScript 3 구문 형식으로 컴파일할 수 있습니다.

JavaScript의 새로운 생명은 컴파일 타겟입니다.

JavaScript로 컴파일할 수 있는 언어
JavaScript로 컴파일할 수 있는 언어는 많습니다. 1997년에 나는 목록을 수집했습니다. 포함:

JavaScript 확장 언어: 죽은 ECMAScript 4, Narrative Script, Objective-J.
기존 언어: Scheme, Common Lisp, Smalltalk, Ruby, Python, Java, C#, Haskell 등.
웹 프로그래밍을 위해 특별히 설계된 HaXe, Milescript, Links, Flapjax와 같은 새로운 언어도 있습니다.
이러한 컴파일러 프로젝트 중에서 Goggle의 GWT Java-to-JavaScript 컴파일러는 아마도 가장 성공적인 프로젝트일 것입니다. 그러나 비극은 실제 프로젝트에서 GWT를 거의 볼 수 없다는 것입니다. 그 이유는 다음과 같습니다.

1. 유지관리 비용이 높습니다. 컴파일러에 버그가 있을 수 있습니다. 대규모 프로젝트의 컴파일러에서 버그를 발견하면 관리자로서 소스 코드를 유지 관리하는 것 외에도 컴파일러도 유지 관리해야 합니다. 맙소사, 필요한 게 있나요? 이런 능력이 있어도 CEO는 이 돈을 쓸 생각이 없습니다.

2. 디버깅이 귀찮습니다. Firebug에서 컴파일된 줄 번호를 보고하는 오류를 보고했습니다. 보스가 당신 뒤에 서 있습니다. 서둘러요, 젊은이! 그런데 이 빌어먹을 컴파일된 코드는 소스 코드의 어느 줄에 해당합니까?

3. 인원 모집이 불가능합니다. Objective-J를 사용하여 프로젝트를 개발하고 있지만 인력이 충분하지 않다고 가정해 보겠습니다. HR은 1,000명 중 단지 100명만이 Objective-J에 대해 들어봤고 나머지 900명은 JavaScript에 대해 들어본 적이 있다고 말했습니다. 결과적으로 새로운 사람을 찾을 때마다 그들을 교육해야 합니다. 첫째, 정말 끔찍해요.

컴파일러에는 위와 같은 단점이 있음에도 불구하고 여전히 다양한 컴파일러가 많이 생겨나고 있습니다. JavaScript 컴파일러를 작성하는 것이 꽤 멋지다는 것은 의심의 여지가 없습니다. 나에게 돈을 지불하고 나도 하나 쓰고 싶습니다.

위 컴파일러 목록에는 많은 센세이션을 불러일으킨 매우 유명한 컴파일러가 있습니다. 바로 CoffeeScript입니다. 그것에 대해 이야기합시다.
CoffeeScript
CoffeeScript가 인기 있는 이유는 무엇인가요? 나는 지금까지 그것을 이해하지 못했습니다. 공백에 부여된 의미 때문인가, 아니면 화살표를 이용한 함수 구문인가? 이런 생각을 할 때마다 속이 뒤틀리는 느낌을 지울 수가 없습니다. CoffeeScript에는 기본 매개변수 값, 나머지 매개변수, 확산, 구조 분해, 암시된 전체 혼란 수정 등 많은 새로운 기능이 있습니다. CoffeeScript의 많은 기능은 Harmony 사양의 일부이며 향후 브라우저에서 직접 지원될 수 있습니다. CoffeeScript는 즉각적인 만족감을 제공합니다.

@pyronicide가 Twitter에서 다음과 같이 말했습니다. #coffeescript는 함수의 기본 매개변수 값을 지원하는데, 이는 매우 흥미롭습니다.
TXJS 2011 컨퍼런스에서 Douglas Crockford는 다음과 같이 말했습니다. CoffeeScript는 의심할 여지 없이 좋은 것입니다.

CoffeeScript: Accelerated JavaScript Development의 저자는 다음과 같이 말했습니다:

@trevorburnham
[...] CoffeeScript는 JS를 Ruby 또는 Python으로 변환하지 않고 일련의 구문을 통해 수행합니다. JavaScript의 고유한 우수성을 더 잘 활용할 수 있습니다.

Douglas Crockford는 JavaScript에 좋은 측면이 있다고 믿고 개발자가 JavaScript의 나쁜 측면을 피할 수 있도록 JSLint 도구를 개발했습니다. JSLint에서 허용하는 구문 하위 집합은 고유한 이름을 가질 만큼 GoodScript라고 부를 수도 있습니다.

ECMAScript 5에서는 with와 같은 구문 사용을 제한하기 위해 "use strict" 지시문을 도입했습니다.

CoffeeScript, GoodScript 및 ECMAScript 5의 목표는 동일합니다. 유용하고 안전한 언어 기능을 제공하면서 헛소리를 피하는 것입니다.

GoodScript는 새로운 기능을 제공하지 않습니다. 대부분의 브라우저는 아직 ECMAScript 5의 엄격 모드를 지원하지 않습니다. 그러나 우리는 기다리고 싶지 않습니다.

나머지 옵션은 CoffeeScript입니다. 장점:

특히 웹 개발에 적합합니다. 이는 다른 JavaScript 컴파일러가 수행하지 않거나 잘 수행하지 않는 것일 수 있습니다.
CoffeeScript는 JavaScript를 적절하게 캡슐화합니다. 이렇게 하면 컴파일된 코드를 더 쉽게 읽을 수 있고 디버깅도 덜 어려워집니다.
CoffeeScript는 JavaScript 코드 작성을 위한 매크로 세트처럼 보입니다.

CoffeeScript의 컴파일러는 클라이언트 버전을 제공합니다. 이를 통해 사용자는 자유롭게 선택할 수 있고, 개발자는 표준에 얽매이지 않고 새로운 기능을 빠르게 개발할 수 있습니다. 커뮤니티의 비전과 요구에 따라 CoffeeScript를 운영한다는 것은 좋은 일입니다.

당신만의 언어를 만들어보세요
할 수 있어요, 좋은 연습이 될 거예요. JavaScript 컴파일러 개발자로서 귀하는 큰 영광을 누리게 될 것입니다.

자신만의 언어를 만드는 것의 위험성은 결국 JavaScript보다 더 잘할 것이라고 생각한다는 것입니다. 언어 디자인은 어렵고 귀하의 언어가 시장 점유율을 높이는 데 어려움을 겪을 것이라고 확신합니다. CoffeeScript는 아직 청소년기에 이르지 않았으며 이미 불만이 있습니다.

귀하의 컴파일러가 간단하고 읽기 쉬운 코드를 컴파일할 수 있다는 점에 자부심을 느끼실 것입니다. 그러나 특별한 상황에 직면하게 되면 너무 우울해서 벽에 부딪히고 싶을 것입니다.

귀하의 언어로 관용구가 나타납니다. 그러면 곧 이러한 관용어를 깨는 사람을 발견하게 될 것입니다(귀하의 언어가 매크로를 지원하지 않는 한).

더 이상 비꼬는 말은 그만하세요. 지금 가서 당신만의 언어를 개발해보세요. 그러면 당신은 아주 훌륭한 프로그래머가 될 것입니다.

컴파일 대상 언어로서 JavaScript에 부족한 것은 무엇입니까?
컴파일 대상 언어로서 JavaScript에 새로운 생명이 부여되었습니다. JSConf.US 강연에서 Brendan Eich는 다음과 같이 말했습니다. Harmony 사양의 목적은 JavaScript를 더 나은 컴파일 대상으로 만드는 것입니다.

컴파일된 C가 손으로 작성한 어셈블리 언어보다 덜 효율적으로 실행될 수 있는 것처럼 컴파일된 JavaScript는 손으로 작성한 JavaScript보다 덜 효율적으로 실행될 수 있습니다. 다행스럽게도 JavaScript의 병목 현상은 주로 DOM 작업에 있으며 언어 자체의 효율성 손실은 상대적으로 허용됩니다. 하지만 일부 효율적인 소스 코드 언어는 컴파일 후 JavaScript 자체의 문제로 인해 극도로 비효율적이어서 실제 환경에서 사용하지 못할 수도 있습니다. Harmony 사양에는 이러한 종류의 문제를 방지할 수 있는 몇 가지 기능이 이미 있습니다.

합리적인 tail call
function isEven(number) {
if (number === 0) {
return true
}
else {
return isOdd; (숫자 - 1);
}
}

function isOdd(숫자) {
if (숫자 === 0) {
return false; > else {
return isEven(number - 1);
}
}

isEven(100000); // InternalError: 너무 많은 재귀
위 코드는 현재 실행 중입니다. 브라우저에서 스택 오버플로가 발생합니다.

트램폴린 기법으로 최적화 가능:

functionounce(ret) {
while (typeof ret === function) {
retret = ret()
}
return ret; >function isEven(number) {
if (number === 0) {
return true
}
else {
return function() {
return isOdd(number - 1);
};
}
}

function isOdd(number) {
if (number === 0) {
return false;
else {
return function() {
return isEven(number - 1)
}
}

bounce(function() {return isEven(100000);}); // true
bounce 방식으로 isOdd(99999)가 실행되면 isEven(100000)이 완료되어 스택에서 빠져나오므로 오버플로가 발생하지 않습니다.

다행히 ECMAScript Harmony는 이를 고려하여 자동으로 최적화합니다. 이는 프로그램 개발자와 컴파일러 개발자 모두에게 유익합니다.

람다
람다는 마법이 아닙니다. 간단히 말해서, 람다는 함수처럼 호출 가능한 것이지만 TCP(Tennent의 대응 원리)를 준수해야 합니다. TCP 요구 사항: 인접한 람다로 표현식이나 코드 블록을 캡슐화해도 캡슐화된 코드의 의미는 변경되지 않습니다.

분명히 JavaScript 함수는 람다가 아닙니다.

function one() {
return 1

}

one() // 1

캡슐화 후 반환 값이 변경되었습니다.

function one() {
(function() {
return 1;
}());

one(); // 정의되지 않음

두 개의 매개변수를 허용하고 이를 합하는 코드 블록의 경우 람다 구문 제안은 다음과 같이 작성됩니다. 위의 예에서 람다 패키징을 사용하면 반환 값이 패키징 전과 동일하게 됩니다.

function one() {
({||
return 1;
} ());

one(); // 1

lambda 블록에 대한 스트로맨 제안은 아직 Harmony 사양으로 승격되지 않았습니다. 함께 작업해 보겠습니다.

브라우저에 무엇이 빠졌나요?

JavaScript의 흥망성쇠는 브라우저와 분리될 수 없습니다. JavaScript의 새로운 삶에는 브라우저의 안정적인 지원도 필요합니다.

Mozilla는 컴파일된 코드를 디버깅할 때 해당 코드 줄을 소스 코드에 다시 매핑할 수 있는 SourceMap 프로젝트를 시작했습니다. 이는 매우 훌륭하며 디버깅 비용을 크게 줄일 수 있습니다.

Webkit에서도 같은 일을 하고 있다고 들었는데 안타깝게도 증거를 찾을 수 없습니다.

여러 언어에 익숙함
JavaScript가 브라우저를 독점한다는 것은 프런트 엔드 프로그래머가 모두 동일한 언어를 사용한다는 것을 의미합니다. 그러나 컴파일러의 차이로 인해 CoffeeScript 프로그래머가 Traceur 기반 JavaScript 코드를 즉시 이해하기가 어렵습니다.

이러한 불일치는 불가피합니다. 예를 들어 C가 있고, C++, Objective-C 등 다양한 언어가 있습니다. Java도 마찬가지입니다. JVM 기반의 Clojure나 JRuby를 선택할 수도 있습니다. Microsoft는 이를 알고 있으며 개발된 CLR, Basic, IronPython 등이 모두 CLR에서 실행될 수 있습니다.

프론트엔드의 커뮤니케이션 장벽은 새로운 것이 아닙니다. Dojo 프로그래머가 jQuery나 YUI 기반 코드를 즉시 이해하는 것은 어렵습니다.

다양한 소스 코드 작성 언어를 사용하면 커뮤니티 내 의사소통 장벽이 높아집니다. 프로그래머는 여전히 JavaScript를 알아야 합니다. 프로그래머는 적어도 한동안은 JavaScript를 알아야 합니다. 하지만 불과 몇 년만 지나면 다른 소스 언어를 더 잘 알게 될 수도 있습니다.

요약

자바스크립트의 새로운 생명을 목격할 수 있는 기회를 갖게 되어 기쁩니다. JavaScript 컴파일 경쟁에서 누가 궁극적으로 시장 점유율을 차지할지 말하기는 어렵지만 흥미로울 것이라는 데는 의심의 여지가 없습니다. 오늘날 CoffeeScript는 도약할 준비가 되어 있지만 다른 많은 성공적인 소스 코드 언어도 뒤따를 것이라고 확신합니다.