Coffeescript의 장단점은 무엇입니까? [닫은]

물론 하나의 큰 프로는 많은 경우에 짧은 코드로 이어지는 구문 설탕의 양입니다. 에 http://jashkenas.github.com/coffee-script/ 인상적인 사례가있다. 반면에이 예제는 복잡한 실제 응용 프로그램의 코드를 나타내는 것입니다. 예를 들어 내 코드에서는 베어 객체에 함수를 추가하지 않고 프로토 타입에 함수를 추가하지 않습니다. 또한 프로토 타입 기능은 사용자에게 숨겨져 관용적 자바 스크립트가 아닌 클래식 OOP를 제안합니다.

배열 이해 예제는 내 코드에서 다음과 같이 보일 것입니다.

cubes = $.map(list, math.cube); // which is 8 characters less using jQuery...

나는 CoffeeScript에 대한 다음 책의 저자입니다 :
http://pragprog.com/titles/tbcoffee/coffeescript

나는 언어가 당시 몇 달 밖에되지 않았고 현재보다 더 거친 가장자리를 가지고 있었음에도 불구하고 CoffeeScript가 약 1 주일을 사용한 후에 사용할 가치가 있다고 확신했습니다. 공식 사이트는 언어 기능을 대부분 나열하는 작업을 수행하므로 여기서는 반복하지 않겠습니다. 오히려 언어의 장점은 다음과 같습니다.

1. 좋은 자바 스크립트 패턴을 사용하도록 권장
2. JavaScript 안티 패턴을 권장하지 않습니다
3. 좋은 JavaScript 코드를 더 짧고 읽기 쉽게 만듭니다.

3 번은 첫 번째 책보다 훨씬 더 많은 관심을 받지만 (내 책에서도) 더 많이 생각할수록, 나는 단지 예쁜 구문을 위해 점프하지 않았다는 것을 더 많이 깨닫습니다. 언어가 오류가 발생하기 쉬운 JavaScript를 향해 나아 갔기 때문에 점프했습니다. 몇 가지 간단한 예를 들면 다음과 같습니다.

• 변수의 범위가 자동으로 지정되므로 실수로 전역을 덮어 쓰거나 var, 같은 이름으로 변수를 섀도 잉하거나 (이름이 지정된 인수 제외) 상호 작용하는 다른 파일에 변수를 가질 수 없습니다 ( https : //.com/questions 참조) / 5211638 / pattern-for-coffeescript-modules / 5212449 ).
• 때문에 ->많은의 지옥보다 쓰기 쉽게 function(){}, 그것은 콜백을 사용하기 쉽습니다. 콜백이 중첩 될 때 시맨틱 들여 쓰기로 명확 해집니다. 그리고 필요할 때 =>쉽게 보존 this할 수 있습니다.
• 때문에 unless x영어 스피커보다 구문 분석하기에 용이 if (!x)하고, if x?보다 쉽습니다 if (x != null)단지 두 가지 예를 제공하기 위해, 당신은 논리 자체에 논리 구문 등에 대한 적은 뇌 사이클을 보낼 수 있습니다.

Underscore.js 와 같은 훌륭한 라이브러리 는 이러한 문제 중 일부를 처리 할 수 ​​있지만 전부는 아닙니다.

이제 단점 :

1. 컴파일은 고통 스러울 수 있습니다. CoffeeScript 컴파일러에서 발생하는 구문 오류는 종종 모호합니다. 앞으로도 그 궤도에서 진전이 이루어질 것으로 기대합니다. (컴파일러의 방어에서는 JavaScript로 작성한 경우 해당 코드 행이 실행될 때까지 오류로 발견되지 않는 것을 포착합니다. 나중에 버그를 빨리 잡는 것이 좋습니다.)
2. 이와 관련하여 디버깅은 어려울 수 있습니다. 컴파일 된 JS 라인을 원본 CoffeeScript와 일치시키는 방법은 아직 없습니다 (Firefox 사람들은 이것이 올 것이라고 약속했지만).
3. 변화하기 쉽다. 이후 버전의 CoffeeScript에서는 코드가 다르게 실행되거나 전혀 실행되지 않을 수 있습니다. 물론 이것은 대부분의 언어에서 그렇습니다. 새로운 버전의 루비 나 파이썬으로 옮겨가는 것은 비슷하지만 JavaScript는 그렇지 않습니다. JavaScript는 그렇지 않습니다. 오늘날 주요 브라우저에서 잘 실행되는 코드는 주요 브라우저에서 제대로 실행될 것이라고 기대할 수 있습니다. 우리가 알고있는 한 웹 브라우저가 존재합니다.
4. 잘 알려져 있지 않습니다. JavaScript는 링구아 프랑카 입니다. CoffeeScript는 단기간에 매우 인기를 얻었지만 JavaScript만큼 광범위한 커뮤니티를 즐길 가능성은 거의 없습니다.

분명히 나는 ​​전문가가 개인적으로 나보다 단점을 능가한다고 생각하지만 모든 사람, 팀 또는 프로젝트에 해당되는 것은 아닙니다. (Jeremy Ashkenas도 많은 JavaScript를 작성합니다.) CoffeeScript는 대체가 아니라 JavaScript를 보완하는 것으로 가장 잘 보입니다.

우리는 다소 큰 JavaScript 코드베이스를 가지고 있으며 약 한 달 전에 CoffeeScript를 사용해보기를 원했습니다. 개발자 중 한 명이 http://js2coffee.org/를 사용하여 모듈 중 하나를 JS에서 CS로 마이그레이션하기 시작했습니다 . 이 도구는 다소 편리했으며 1000 줄의 자바 스크립트를 이식하는 데 2 ​​~ 3 시간이 걸렸습니다. 그 시점에서 우리가 관찰 한 몇 가지 관찰 :

1. 결과적인 CoffeeScript 코드는 꽤 읽을 수있었습니다.

2. 우리는 그것을 JavaScript로 다시 컴파일했으며 탐색 및 디버깅이 매우 쉬웠습니다. 우리가 그 모듈을 포팅하는 동안 우리 팀의 다른 개발자가 버그를 발견했습니다. 이 두 개발자는 이전 JavaScript 코드와 CS 컴파일러에서 나온 새로운 JavaScript 코드에서이 버그를 수정했습니다. 그들은 독립적으로 일했고 같은 시간 (15-20 분)이 걸렸습니다.

3. 포트라는 사실 때문에 결과 코드는 적절하거나 바람직한 커피 전용 기능을 사용하지 않았습니다. 우리가 처음부터 CoffeeScript로 작성한다면 코드는 더 관용적 일 것입니다. 그 때문에 우리는 기존 코드를 이식하지 않기로 결정했습니다.

4. 일반적으로 더 짧은 기능과 더 작은 물체의 가독성이 어느 정도 증가했습니다. 그러나 전혀 그렇지 않은 더 긴 방법의 경우. 가장 큰 폭의 절감 효과는 ->명시 return적이지만, 코드가 크게 짧거나 단순하지 않은 것 이외의 것입니다. 일부 구문 조각, 특히 객체 리터럴은 상당히 혼란스러워 보입니다. CS는 멤버 정의 주위에 중괄호를 생략하고 "모든 표현식" 과 암시 적으로 결합하여 return일부 코드를 읽기 어렵게 만들었습니다.

   JavaScript는 다음과 같습니다.

   var rabbitGenerator = {
       makeRabbit: function(rabbitName, growCarrots) {
           if (growCarrots) {
               carrots.growMore(10);
           } else {
               carrots.ensureSupply();
           }
           return {
               name: rabbitName, 
               height: 0,
               actions: {
                   jump: function (height) {
                       this.height += height;
                   },
                   eatCarrot: function () {
                       // etc
                   }
               }
           };
       },
       // more members
   }
   

   해당 CoffeeScript 코드는 다음과 같습니다.

   rabbitGenerator = 
     makeRabbit: (rabbitName, growCarrots) ->
       if growCarrots
         carrots.growMore 10
       else
         carrots.ensureSupply()
       name: rabbitName // (*)
       height: 0
       actions: 
         jump: (height) ->
           @height += height
   
         eatCarrot: ->
   

   이제는 return 문이 (*)줄 에서 시작한다는 것을 알기가 매우 어렵습니다 . 우리 프로젝트에서 우리는 객체 리터럴에 크게 의존합니다. 그것들을 함수 매개 변수로 전달하고 다른 함수에서 반환합니다. 대부분의 경우 이러한 객체는 서로 다른 유형의 멤버와 여러 수준의 중첩으로 매우 복잡한 경향이 있습니다. 우리의 경우 전반적인 느낌은 CoffeeScript 코드가 실제로 일반 JavaScript 코드보다 읽기가 어렵다는 것입니다.

5. CoffeeScript를 디버깅하는 것이 우리가 예상했던 것보다 쉬운 것으로 판명되었지만 편집 경험이 상당히 저하되었습니다. 이 언어에 적합한 편집기 / IDE를 찾을 수 없습니다. 우리는 프로젝트의 클라이언트 측 코드를 위해 편집기 / IDE를 표준화하지 않았으며 실제로는 서로 다른 도구를 사용합니다. 실제로 팀의 모든 사람들은 CoffeeScript로 전환 할 때 도구의 지원이 다소 부족하다는 데 동의합니다. IDE와 편집기 플러그인은 매우 초기 형태이며 어떤 경우에는 적절한 구문 강조 또는 들여 쓰기 지원을 제공 할 수 없습니다. 코드 스 니펫이나 리팩토링에 대해 이야기하지 않습니다. WebStorm, Eclipse, NetBeans, VisualStudio, Notepad ++ 및 SublimeText2를 사용합니다.

6. 도구에 관해서는 CoffeScript 컴파일러 자체가 Node JS 패키지로 제공된다고 언급해야합니다. 우리는 기본 Java / .NET 상점이므로 모든 사람들이 Windows 박스에서 개발하고 있습니다. 최근까지 노드에는 Windows 지원이 거의 없었습니다. 우리는 CoffeeScript 컴파일러를 Windows에서 실행할 수 없었기 때문에 당분간은 <script type="text/coffeescript">태그와 브라우저 기반 on-the-fly 컴파일러를 사용 하기로 결정했습니다 .

   컴파일러는 매우 빠르며 시작 시간을 크게 늘리지 않습니다. 단점은 결과 JavaScript가 eval얻어지고 브라우저 개발자 도구 (특히 IE8)에 중단 점을 넣기가 조금 어렵다는 것입니다. 디버깅에 어려움이 있다면 위에서 설명한 것과 동일한 마이그레이션 도구를 사용하여 CoffeeScript 코드를 사전 컴파일하지만 여전히 편리하지는 않습니다.

7. 자동 var삽입 또는 this팻 화살표 연산자 ( =>) 를 사용한 반투명 관리 와 같은 CoffeeScript의 다른 약속은 우리가 원하는만큼 많은 이익을주지 않는 것으로 나타났습니다. 우리는 이미 빌드 프로세스의 일부로 JSLint를 사용 ES3 x ES5-Strict하고 언어의 하위 세트로 코드를 작성합니다 . 어쨌든, Coffee가 동일한 종류의 "깨끗한" 코드를 생성한다는 사실 은 좋은 것 입니다. 모든 서버 측 프레임 워크가 유효한 HTML5 및 CSS3 마크 업을 생성하기를 바랍니다!

   CoffeeScript가 var키워드를 넣어서 많은 시간을 절약한다고 말하고 싶지는 않습니다 . 누락 된 var들은 JSLint에 의해 쉽게 잡히고 쉽게 고칠 수 있습니다. 또한 일단 수정하면 좋은 JavaScript를 자동으로 작성하기 시작 합니다. 따라서 커피가 이와 관련하여 실제로 그렇게 도움이된다고 말하지는 않을 것 입니다.

우리는 약 1 주일 동안 CoffeeScript를 평가했습니다. 모든 팀원들이 코드를 작성하고 서로의 경험을 공유했습니다. 우리는 새로운 코드를 작성하고 우리가 적합하다고 생각했을 때 기존 코드를 이식했습니다. 언어에 대한 우리의 감정이 섞여있었습니다.

일반적으로 개발 속도를 높이 지 않았지만 속도를 늦추지 않았다고 말할 수 있습니다. 타이핑 감소와 오류 표면 감소로 인한 일부 속도 향상은 다른 영역 (주로 도구 지원)의 속도 저하로 인해 상쇄되었습니다. 일주일 후 우리는 CoffeeScript의 사용을 의무화하지 않기로 결정했지만 우리는 그것을 금지하지 않을 것 입니다. 자유로운 선택이 주어지면, 적어도 지금은 아무도 그것을 사용하지 않습니다. 때때로 새로운 기능을 프로토 타이핑 한 다음 프로젝트의 나머지 부분과 통합하기 전에 코드를 JavaScript로 변환하여 더 빨리 시작하지만 아직 그 방법을 시도하지는 않았습니다.

찬성

볼 트레버 번햄의 답변을 .

게다가, 당신은 자바 스크립트의 먼지를 엉망으로 만드는 대신 유행의 일을하는 힙합 사람으로 자신을 생각할 수 있습니다.

단점

CoffeeScript는 구문 설탕과 분홍색 안경에 지나지 않습니다.

쉬운 작업-모든 언어에서 쉬운 작업을 수행하기 때문에 CoffeeScript가 중복됩니다. 그리고 jQuery는 CoffeeScript보다 훨씬 간단합니다.

어려운 것들을 위해-당신 은 당신의 매체 를 이해해야합니다. 그리고 귀하의 매체는 HTML, DOM 및 CSS이며, Javascript는 이들을 상호 연결하는 도구 일뿐입니다. 그러나 모든 API는 Javascript를 위해 특별히 작성되었습니다. "실제"언어로 컴파일되는 다른 언어를 사용하는 것은 Java (GWT), Dart 또는 CoffeeScript와 같이 매우 위험합니다.

1 ~ 2 개의 좋은 책을 읽으면 반 패턴이나 언어 규칙에 대한 무지가 고칠 수 있습니다. 그리고 Coffeescript에는 자체 안티 패턴이 있습니다.

Coffeescript에 대한 IDE 지원은 JS보다 훨씬 나쁩니다.

내 마음에 가장 큰 프로는 :

간단 커피 스크립트는 자바 스크립트로 컴파일 한다 작성한하지만 간단하지 않았기 때문에,하지 않았다.

경계로만 피할 수있는 자바 스크립트의 불쾌한 구석이 있습니다-내 머리 꼭대기의 예 :

• 프로토 타입을 올바르게 설정
• == 대신 === 사용
• null 확인
• var로 모든 변수 선언
• 자체 실행 익명 함수로 모든 것을 래핑합니다.

coffeescript를 작성하면 모든 것이 자동으로 처리 됩니다 .

단점은 IMO이며 대부분 사소합니다.

• 디버깅은 고통입니다
• 더 적은 커피 스크립트 프로그래머가 있습니다
• javascript에서 coffeescript로 문서를 번역해야합니다.

찬성

1. CoffeeScript를 통해 JavaScript에 대해 더 많이 배울 수있었습니다.
2. 복잡한 중첩 콜백에서도 읽기가 쉽습니다.
3. 언어 문제를 추적하기 어려운 일부 자바 스크립트에 대해 안전을 제공합니다.

Andrew의 위 작업 예는 깨달음을 발견했습니다. 기존 객체 리터럴 리턴의 가독성은 단순히 수동으로 리턴을 식별하여 향상 될 것이라고 생각합니다.

반환

// 객체 리터럴

IDE 도구가 향상되었으며 TextMate 및 Cloud9는 CoffeeScript를 지원합니다. 분명히 Windows 지원이 지연되고 있습니다 (일반적으로 웹 개발에는 해당되지 않습니까?)

단점

브라우저에서 해석 한 CoffeeScript는 디버깅하기 어려울 수 있습니다.

JavaScript의 추가 계층으로 개발자의 이해와 고려가 필요합니다.

찬성

1. 그들은 일반적인 경우를 구문 상으로 최적화했습니다. 실제로 CoffeeScript는 "일반적으로"가장 많이 사용되는 간결한 언어 중 하나입니다. http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked- 표현력 /
2. JavaScript의 나쁜 부분을 숨 깁니다 (자동 강제 ==, 암시 적 전역, 더 전통적인 클래스 시스템으로 인해 일반적인 일이 쉬워 짐)
3. Python / Ruby 프로그래머에게 배우기 매우 쉬운
4. 여러 줄 익명 함수 + 공백 구문

단점

1. var 제거 는 객체를 사용하지 않고 내부 범위 내에서 외부 범위 변수를 변경할 수 없거나`var fall_back_to_js;`해킹 [값을 다시 할당하는 다른 할당 문 ': ='이 아닌 이유 obj.naem : = 5 개의 오타가 디버그하기 쉬움]
2. JavaScript를 디버깅하지 않으려면 모든 도구에 대해 알려주십시오. (; btw : 소스 맵에 대한 지원을 추가하여 Chrome에서 CoffeeScript를 디버깅 할 수 있습니다 .yeoman (npm install yeoman)은 gulp 또는 grunt 구성 파일을 작성하는 데 도움을 줄 수 있습니다 CoffeeScript
3. 선택적인 정적 타이핑 없음 (다음 EcmaScript 표준을 기다려야 함)
4. 여전히 모듈 시스템을위한 타사 라이브러리가 필요합니다
5. 주의해야 할 구문 트랩 : 암시 적 리턴, abgo 는 a (b (g (o)))를 의미 하고 fp, b : 2, c : 8은 f가 아니라 f (p, {b : 2, c : 8}을 의미 함) (p, {b : 2}, {c : 8})
6. 깨진 JavaScript 번호 / 유형 시스템을 변경하지 않습니다