GWT 대 ScriptSharp 찬반론과 단점

Question

우리는 본격적인 "단일 페이지"자바 스크립트 "응용 프로그램"을 작성하는 데 필요한 대량의 javascript를 유지하기가 너무 어렵다고 판단했습니다. 프로그래밍 협약에 의지하여 우리는 여전히 리팩토링 영역을 원했습니다. 이 프로젝트를 처음 접한 개발자의 경우, 구성 요소에 진정으로 의존하고있는 다른 사람이 누구인지 알지 못하기 때문에 아무 것도 변경하기가 매우 어렵습니다 ("모든 참조 찾기 ..."로 쉽게 할 수있는 작업). 유형 언어).

우리는 GWT를 가지고 놀았지만 개발자 중 한 명이 Script #을 사용하려고합니다. 우리는 이미 Microsoft에 기반을두고 있으며 C#에서 모든 서버 측 작업을 수행합니다.

자바가 GWT의 쇼 스토퍼라고 생각하지 않습니다. C#과 매우 유사하기 때문에.

Script #에 대한 나의 초기 우려 사항은 주로 지원 및 설명서를 중심으로합니다.

우리는 한편으로는 Google을 가지고 있습니다 ... "Some Dude". 스크립트 #도 닫힌 소스입니다 ... 개발자가 작업을 중단하면 S.O.L입니까? GWT에 더 많은 문서 및 커뮤니티 지원이 있다고 생각합니다.

어쨌든, 둘 다 같이 일한 적이 있습니까? 생각? 찬성/반대?

은 (패스에이를 머리에 : 문제는 컴파일러로 이동할지하지인지 ... 질문 인 컴파일러)

와 비슷하지만, 다른 질문 :

What advantages can ScriptSharp bring to my tool kit?
Should I use ScriptSharp

Answer 1

나는 몇 년 동안 GWT를 사용 해왔다. 필자는 Script #에 대해 들어 본 적이 없으므로 Google 솔루션을 계속 사용해야하는 이유를 알려 드리겠습니다.

1. 액티브 개발. Google은 적극적으로 결함을 수정하고 새로운 기능을 개발하는 유료 엔지니어 팀을 운영하고 있습니다. 현재 GWT의 새로운 기능을 구현하는 방법에 대해 다른 개발자와 논의 중입니다.

2. 대형 기관. Google은이 프로젝트에 투자하여 대규모 솔루션을 구현하는 데 사용했습니다. 그들은 자신의 개가 먹는 음식을 먹고 있습니다. 그들은 정체 시키거나 쓸모 없게하는 것에 대한 기득권이 있습니다.

3. 커뮤니티. 바닐라 배포판과 함께 사용할 추가 기능/타사/기타 라이브러리 및 API에 대해 많은 사람들이 작업하고 있습니다. 이 같은 사람들은 또한 결함을 테스트, 제출 및 수정하고 있습니다.

4. 호환성. GWT는 브라우저가 할 수있는 모든 작업을 수행 할 수 있습니다. 또한 jQuery 및 기타 주요 JavaScript 라이브러리 용 플러그인이있어 JavaScript로 작업 할 때 프로젝트의 복잡성을 훨씬 쉽게 관리 할 수 ​​있습니다.

5. Open. 너 스스로 이걸 만졌다.

언어 선택 문제를 어떻게 만지지 않았는지주의하십시오. 나는 그것이 당신이 묘사하는 수준에서 정말로 관련이 있다고 생각하지 않습니다. 처음으로 Script #를 사용하여 제한 또는 도로 블록을 실행하면 나와 내가 설명했던 것 때문에 빠르게 멈추게됩니다.

물론 트랙 레코드 때문에 GWT를 권장합니다.

Answer 2

Script #와 이전에 GWT를 사용했습니다. 그것들은 정말로 다른 두 가지입니다. GWT는 클라이언트 및 서버 솔루션과 RPC 및 기타 모든 기능을 제공합니다. 확실히 성숙되어 복잡한 응용 프로그램을 더 빠르게 사용할 수 있습니다. 간단히 말해, 야생에 더 많은 코드와 예제가 있습니다.

그러나 개발자가 서버 쪽과 클라이언트 쪽 모두에 있고 두 개의 다른 언어와 두 개의 다른 플랫폼을 사용하면 매우 부담 스러울 수 있습니다. 이것이 내가 Script # (으)로 이사 한 이유입니다. 내가하는 모든 일은 C# 및 Visual Studio에서 훨씬 더 생산적 일 수 있습니다. GWT의 백엔드 기능을 이용하지 않는다면 과장 될 수 있습니다.

나는 Script #을 C# 2.0 스펙으로 작성된 Javascript로 생각한다. 그것은 완전하게 클라이언트 측이며 모든 종류의 매핑은 수동으로 수행되어야합니다 (오토 맵핑은 광범위하게 사용될 수 있지만). Javascript와 jQuery에 대한 지원이 매우 완벽합니다. 사실 처음에는 놀랐습니다. 그것은 그것이 그랬던 것처럼 덜한 것처럼 보였습니다.

angryundead의 포인트는 특히 커뮤니티와 개방성과 관련하여 유효합니다. 이것은 내 편에서 약간의 가시가되었지만, 나는 정말로 Script #을 사용하는 것을 좋아한다. IDE를 바꿀 필요가 없습니다. Java 등에서 일하는 법을 찾을 필요가 없습니다. jQuery는 거대한 플러그인 라이브러리를 가지고 있으며 스크립트 #에이 스크립트를 연결하는 것은 매우 쉽습니다. 속성을 나타 내기 위해 몇 개의 객체를 던지고 "가져온"것으로 주석을 달고 null을 반환합니다. 귀하의 코드에서 당신은 플러그인으로 개체를 캐스팅하고 귀하의 출력은 자바 스크립트에서와 똑같이 나타납니다. 스크립트 #는 플러그인 작동 방식을 신경 쓰지 않습니다.

Script # 커뮤니티 지원 부족으로 인해 귀하를 속일 수 없습니다. 문제가되는 동안 제품은 매우 성숙하고 기능이 풍부합니다. 개발자가 C#/VS를 사용하고 있다면 왜 클라이언트 측에 별도의 프로그램을 사용하게합니까? 나는 그것이 엄청난 생산성에 영향을 주었다.

제쳐두고, 나는 C#을 사용한 이후로 Javascript에서 훨씬 나아졌습니다. Javascript의 많은 문제는 실제로 필요하지 않은 언어 기능이 부족하지만 큰 프로젝트에서는 관리가 가능하도록 만드는 유일한 방법입니다.

Answer 3

JavaScript 코드에 C#을 사용하려면 SharpKit을 제안합니다. 다른 C# 솔루션과 함께 feature comparison이 있습니다. 또한 응용 프로그램의 예로 SharpKit을 사용하여 생성 된 CodeRun을 확인할 수 있습니다.

Answer 4

전체 브라우저 응용 프로그램을 만드는 경우가 아니면 내 환경 설정이 스크립트 #입니다. 왜냐하면 포괄적 인 클라이언트/서버 도구 키트가 아닌 최선의 방법으로 C#을 JavaScript로 컴파일하기 때문입니다. . 웹 패러다임이 빠르게 변하고 GWT에 프로젝트를 투자하면 필요하지 않은 오버 헤드 또는 기술 약속이 생길 수 있습니다. 하지만 실제로 웹 응용 프로그램이나 웹 경험의 유형에 따라 달라질 것이라고 덧붙입니다.

저는 개인적으로 이미 jQuery, WCF에 익숙하며 새로운 HTML5 기능을 직접 사용하기 시작했습니다. Script #는 jQuery와 WCF를 매우 쉽게 사용할 수 있기 때문에 완벽한 누락 된 조각입니다. 그리고 나는 패러다임이나 GWT의 요구 사항으로 전환하거나 통합하는 번거 로움을 겪지 않아도됩니다.

또한 UI 구성 측면에서 최근에 오픈 소스로 생각한 Sharp UI을 고려하면 jQuery + Script # 설정에서 재사용 가능한 컨트롤을 쉽게 만들 수 있습니다.