프로덕션 애플리케이션에 Coffeescript를 사용한 사람이 있습니까?

프로덕션 애플리케이션에 Coffeescript를 사용한 사람이 있습니까? [닫은]

---

Coffeescript 는 꽤 멋져 보입니다. 누군가 그것을 사용 했습니까? 장단점은 무엇입니까?

---

우리는 기본적으로 특정 종류의 데이터를 검색하는 앱인 비공개 웹 사이트 인 제품에서 CoffeeScript를 사용하기 시작했습니다. 우리는 CoffeeScript를 명령 줄 컴파일러로 사용합니다 (결국 수행하고 싶은 서버가 아니라).

장점 (우리에게) :

• 코드가 자바 스크립트보다 한 눈에 이해하기 쉽고 깔끔 할 정도로 자바 스크립트의 불필요한 혼란 (예 : 중괄호, 세미콜론, 일부 대괄호)을 제거합니다.
• 자바 스크립트보다 20-30 % 적은 코드 줄 (정확히 동일한 작업 수행)
• CoffeeScript는 노이즈를 제거 할뿐만 아니라 heredocs와 같은 키워드, 클래스 및 기능을 추가하여 코딩을 더 깨끗하고 다소 즐겁게 만듭니다.
• 이전 요점을 감안할 때 로프를 배우면 CoffeeScript로 코딩하는 것이 의심 할 여지없이 더 빠릅니다.

단점

• 명령 줄 컴파일러를 사용하는 경우 : 디버그하려면 수정 (coffeescript)을 작성할 때와 같이 문제 (자바 스크립트)를 해결할 때 다른 코드를 보게됩니다. 그러나 다소 믿을 수 없을 정도로 CoffeeScript는 정말 대단해서 디버깅 할 필요가 없었습니다!

중요한 것은 언제든지 되돌릴 수 있다는 것입니다. 우리의 coffeescript 컴파일러는 읽을 수있는 자바 스크립트를 생성 할 뿐이므로 누군가 마음이 바뀌거나 무언가를 알아낼 수없는 경우 커피 스크립트가 생성 한 자바 스크립트를 다시 사용하고 코딩을 계속할 수 있습니다.

---

BusyConf의 모든 자바 스크립트에 대해 coffeescript를 사용 합니다. BusyConf의 대부분은 오프라인 모드 지원을 포함하여 브라우저에서 실행되는 클라이언트 측 애플리케이션입니다.

우리의 모든 coffeescript 코드는 완전히 테스트되었습니다. 테스트 자체는 coffeescript로 작성되며 Qunit 프레임 워크 (JavaScript로 작성 됨)를 사용합니다. 또한 테스트를 더 좋게 만드는 Qunit 프레임 워크에 대한 확장을 작성했습니다. Qunit 확장은 CoffeeScript 로 작성되었습니다 . 우리의 애플리케이션은 CoffeeScript로 작성된 모바일 버전을 가지고 있으며 Sencha Touch 프레임 워크 (JavaScript로 작성된)를 사용합니다.

여기서 빼놓을 수있는 점은 애플리케이션에서 자바 스크립트 종속성을 자유롭게 혼합 할 수 있지만 작성하는 모든 코드 (애플리케이션 코드, 테스트 등)는 커피 스크립트가 될 수 있다는 것입니다.

---

거의 1 년 후, 몇 가지 업데이트를 게시 할 가치가 있습니다.

1. Ruby on Rails 3.1은 공식 CoffeeScript 지원을 통합하고 있으며, 이는 훨씬 더 많은 실제 사용을 볼 수 있음을 의미합니다. 저는 지난달 RailsConf에서 강연을했습니다. 대부분의 참석자들은 이전에 CoffeeScript에 대해 들어 보지 않았고 dhh의 강력한지지를 받았기 때문에 그것에 들어가기를 열망했습니다.
2. CoffeeScript에 대한 책이 있으며 현재 eBook에 있으며 곧 The Pragmatic Bookshelf에서 인쇄 될 예정입니다. 그것은 CoffeeScript : Accelerated JavaScript Development 라고 불리며 진정으로 여러분의 것입니다. CoffeeScript 1.1.1을 기반으로합니다.
3. 언어는 실제로 1.0과 1.1.1 사이에서 6 개월 동안 거의 변경되지 않았습니다. 거의 모든 변경 사항이 "버그 수정"으로 간주됩니다. 1.0.1에서 1.1.1로 전환하기 위해 책의 코드를 거의 수정해야했습니다. 하지만 앞으로 더 큰 변화가있을 것이라고 확신합니다.

CoffeeScript 프로젝트의 가장 확실한 목록은 CoffeeScript 위키의 In the Wild 페이지에 있습니다.

지금까지 CoffeeScript의 대부분의 프로덕션 사용은 Appcelerator와 함께 iPhone / Android 앱을 만드는 것입니다. (The Changelog의 Wynn Netherland는 CoffeeScript를 "iOS, Android 및 WebOS 모바일 개발을위한 나의 비밀 무기"라고 설명하면서 저의 책을 흐릿하게 표현했습니다.) 그러나 프로덕션 Rails 앱에서 훨씬 더 많이 사용될 것입니다. 그리고 다른 곳에서도 사용되기를 바랍니다. 앞으로 몇 달 안에.

---

Coffeescript는 iPad 용 Ars Technica 리더 http://arstechnica.com/apple/news/2010/11/introducing-the-ars-technica-reader-for-ipad.ars 에서 사용되었습니다.

---

요즘 저는 Coffeescript를 정말 좋아합니다. 본질적으로 전체 HotelTonight iPhone 응용 프로그램이 그 안에 작성됩니다 (Appcelerator Titanium을 사용하여 JavaScript로 "기본"응용 프로그램을 작성할 수 있습니다. Phonegap과 같은 웹 응용 프로그램이 아닙니다). 이 경우에는 많은 양의 JS를 훨씬 쉽게 구성하고 유지 관리 할 수 ​​있기 때문에 Coffeescript를 사용하기로 선택했습니다. 또한 Coffeescript (대 JavaScript)로 코드를 작성하는 것이 훨씬 더 즐겁습니다. 또한 Rails 앱에서 JS에 Coffeescript를 사용하지만 이것은 전체 전화 앱과 관련하여 매우 사소하거나 적은 양의 코드입니다.

전문가들은 대부분 구문이 더 좋을뿐 아니라 OO 메커니즘을 표준화 한 다음 몇 가지 멋진 추가 사항 (목록 이해, 일부 범위 등)을 추가해야합니다.

단점은 거의 제로입니다. 가장 중요한 것은 디버깅 할 추가 레이어라는 것입니다. 생성 된 JS (매우 읽기 쉽고 멋짐)를 살펴본 다음이를 Coffeescript 코드에 매핑해야합니다. 우리에게 이것은 전혀 문제가되지 않았지만 YMMV.

결국, 제가 생각하는 것은 프로덕션 앱에서 사용하는 데있어 위험이 전혀 없다는 것입니다. 그러니 그것이 방해가되지 않도록하십시오. 그런 다음 시도해보십시오. 그것으로 코드를 작성하고, JS로 작성한 것과 비교하고, 생성 된 코드를보고 디버깅 요구를 위해 읽을 수 있는지 확인하십시오. 또한 #coffeescript IRC에서 시간을 보내세요. 마지막으로, 앱과 어떻게 통합되는지 확인합니다. 예를 들어 "빌드"프로세스가 무엇인지 확인합니다 (예 : Rails의 경우 Barista를 사용해보고 독립형 인 경우 포함 된 "coffee -w"등을 사용).

---

Coffeescript는 JS 작성을 더 쉽게 만듭니다. 더 깨끗하고 효율적인 코드로 끝납니다.

즉, 여전히 vanilla JS에서 할 수있는 모든 작업을 수행 할 수 있습니다. coffeescript를 충분히 사용하면 (좋은) JS를 작성하는 것이 훨씬 쉬워집니다.

따라서 JS를 많이 사용하지 않았다면 대신 coffescript를 배우는 것이 좋습니다. 더 좋고, 깔끔하고, 버그가 적은 코드를 얻을 수 있습니다. 이미 JS에 능통하다면 "진짜"앱에서 coffeescript를 사용하는 것은 좋지 않을 수 있습니다.

(또한 coffeescript는 다소 "엉뚱한"코드를 장려하는 것 같다는 점에서 약간 짜증이납니다. 그것이 좋은 것인지 나쁜 것인지는 모르겠지만 TMTOWTDI의 극단적 인 경우 인 것 같습니다)

---

컴파일러가 있지만 JavaScript의 동적 특성으로 인해 정적 검사를받을 수 없습니다. FAQ에 쓰여진대로 :

정적 분석

CoffeeScript uses a straight source-to-source compiler. No type checking is performed, and we can't work out if a variable even exists or not. This means that we can't implement features that other languages can build in natively without costly runtime checks. As a result, any feature which relies on this kind of analysis won't be considered.

IDE support is less mature than that of JavaScript (Cloud9 has syntax highlight support, but Eclipse JSDT has refactorings and more): https://stackoverflow.com/questions/4084167/ide-or-its-add-in-for-coffescript-programming

참고URL : https://stackoverflow.com/questions/2954557/has-anyone-used-coffeescript-for-a-production-application