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


94

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


답변:


113

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

장점 (우리에게) :

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

단점

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

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


1
PandaWood는 모든 지점에서 바로 그것을칩니다. 저는 올해 모든 고객을 위해 제작 과정에서 큰 성공을 거두었습니다. Coffeescript와 javascript 파일을 하나로 묶을 수 있도록 Buildr를 컴파일러로 사용하고 있습니다. github.com/balupton/buildr.npm
balupton

13
"우리 CoffeeScript는 정말 대단해서 디버깅 할 필요가 없었습니다!" 어 ... 정말? 데이터가 항상 기대와 일치합니까? 예기치 않은 this일 이 없었 거나 잘못된 유형을 함수에 보낸 적이 있습니까? "아무것도 디버깅"할 필요가 없다면 아직 흥미로운 일을하지 않았다고 생각합니다.
Ryan Florence

8
@rpflo "우리는 Coffeescript를 사용하기 시작했습니다 ..."라는 단어를 눈치 채고이를 불쾌한 진술과 일치시키고 그것이 주어진 경쾌한 맥락에서 받아들이면 누구나 동의 할 수 있다고 생각합니다. , 우려 할 이유가 거의 없습니다. 내가 제공 한 텍스트에서 우리는 단순히 이미 작동하는 자바 스크립트를 coffeescript로 변환했을 가능성이 있으므로 심각한 디버깅이 아직 필요하지 않습니다
PandaWood

3
이제 더 이상 문제가되지 않는 Source-Maps와 함께 Con '에 대해, 컴파일 만하면 -m좋습니다.
omeid

@omeid 좋은 지적입니다. 나는 그에서 추적 한 성공적 소스 맵을 커피 스크립트와 크롬에서 작업 가지고있다
PandaWood

27

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

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

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


24

거의 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 앱에서 훨씬 더 많이 사용될 것입니다. 그리고 다른 곳에서도 사용되기를 바랍니다. 앞으로 몇 달 안에.



10

요즘 저는 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"등을 사용).


3

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

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

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

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


25
나는 자바 스크립트 대신에 커피 스크립트를 배우라는 권고에 동의하지 않으며, 한때 자바 스크립트 학습 / 커피 스크립트 사용에 능숙하지 않다는 생각에 동의하지 않습니다. 자바 스크립트를 이해하는 것은 웹 개발자의 기본입니다. 커피 스크립트 코드가 생성 할 자바 스크립트를 이해해야합니다. 이미 자바 스크립트 마스터 인 사람들에게 coffeescript는 마법적이고 혁신적인 도구가 될 것입니다.
Jim Garvin

3
@Jim Garvin이 동의했습니다. 사람들이 자바 스크립트를 배우는 것이 중요합니다. 초보자를위한 모든 리소스가 구식 js로 작성되기 때문에 어쨌든 자바 스크립트 전에 coffeescript를 배우는 것이 불가능하다고 말하고 싶습니다 (Rick Olsen이 갑자기 일부를 게시하기로 결정하지 않는 한 그의 블로그에서 JS 튜토리얼 시작).
Daniel Mendel

2
Coffeescript를 작성하려면 Javascript를 이해해야합니다. 따라서 문제가 발생했을 때 코드를 디버깅 할 수 있습니다.
Blaise

업데이트 : CoffeeScript에는 이제 충분한 문서가 있으며 소스 맵은 JS 코드 디버깅을 불필요하게 만듭니다. 요즘 자바 스크립트는 타겟 일뿐입니다. JS를 배우는 것은 여전히 ​​매우 유용하지만 초보자는 JavaScript를 몰라도 코딩을 시작하기에 충분한 CoffeeScript를 배울 수 있습니다.
Carl Smith

3

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

정적 분석

CoffeeScript는 직접적인 소스 대 소스 컴파일러를 사용합니다. 유형 검사가 수행되지 않으며 변수가 존재하는지 여부를 확인할 수 없습니다. 이는 비용이 많이 드는 런타임 검사 없이는 다른 언어가 기본적으로 빌드 할 수있는 기능을 구현할 수 없음을 의미합니다. 결과적으로 이러한 종류의 분석에 의존하는 기능은 고려되지 않습니다.

IDE 지원은 JavaScript보다 덜 성숙합니다 (Cloud9에는 구문 강조 지원이 있지만 Eclipse JSDT에는 리팩토링 등이 있습니다) : /programming/4084167/ide-or-its-add-in-for-coffescript -프로그램 작성

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.