복잡한 JavaScript UI에 대한 개발자 접근 방식

복잡한 클라이언트 측 JavaScript 개발과 관련된 다양한 접근 방식과 모범 사례를 이해하려고합니다.

이 클래스의 응용 프로그램에 무거운 AJAX 또는 RIA (Flash / Silverlight와 같은 플러그인은 아님) 레이블을 무엇으로 지정할지 잘 모르겠습니다 . 이러한 특성을 가진 웹 앱을 언급하고 있습니다.

• JavaScript에서 리치 / 네이티브 데스크톱 UX 에뮬레이션
• 서버를 데이터 API (JSON / Html-Templates)로 사용하여 클라이언트 쪽 JS에서 대부분 / 모든 동작을 포함합니다.

이는 UI 렌더링에 웹 서버를 사용하는 것과 대조적으로 모든 HTML을 페이지 새로 고침 모델로 생성합니다.

몇 가지 예는 다음과 같습니다.

• Google 문서 / Gmail
• 마인드 마이스터
• 피벗 추적기

HTML5로 넘어갈 때, 자바 스크립트를 많이 사용하여 이러한 스타일의 RIA 개발을 볼 수 있으며 점점 더 경쟁이 치열 해지고 필요합니다.

질문 : 이런 종류의 무거운 JS 개발을 관리하는 데있어 일반적인 접근 방식은 무엇입니까?

앱이 기능을 확장함에 따라 클라이언트 측 코드는 매우 복잡합니다. 원시 JS를 사용하는 여러 팀에서 개발 노력을 확장하는 데 문제가 있습니다.

Google은 상위 수준 언어 (Java)에서 JS로 컴파일하는 GWT를 구축하여 상위 수준 언어 (Eclipse, 강력한 타이핑, 리팩토링 도구) 및 브라우저 호환성 추상화 및 개발자로부터 떨어진 다른 문제.

C # 용 Script #와 유사한 다른 도구가 있습니다. 이 모든 것이 JS를 IL (중급 언어)의 역할에 더 집중시킵니다. 즉. "당신은 더 이상 그 저수준 언어로 글을 쓰지 않습니다."

그러나이 'JS로 컴파일'만이 유일한 접근법은 아닙니다. GWT가 지배적 인 접근 방법인지 또는 실제로 그것이 될 것인지는 분명하지 않습니다.

사람들이 리치 클라이언트 JavaScript로 무엇을하고 있습니까? 일부 오리엔테이션 질문 :

• 대부분의 상점에서 JS를 수동으로 제작하고 있습니까 (jQuery 등의 라이브러리 위에)?
• 아니면 명확한 모범 사례가없는 많은 다른 접근 방식이 있습니까?
• RIA 규모의 개발을 피하는 대부분의 상점은 더 단순한 개발자 용 서버 측 / 페이지 다시 그리기 모델을 선호합니까? 그렇다면 이것이 지속됩니까?
• JS로 컴파일하는 것이 미래의 트렌드일까요? 아니면 이것이 잘못 가고 있습니까?
• 클라이언트 JS의 복잡성과 리팩토링을 어떻게 관리합니까?
• 팀 간 작업의 모듈화 및 배포?
• MVC / MVP 등과 같은 클라이언트 측 패턴의 적용, 시행 및 테스트

그렇다면이 JavaScript와 HTML5의 미래에 어떤 트렌드가 생길까요?

감사!

이 방향으로 나아가고있는 대부분의 웹 응용 프로그램 (및 내가 이야기 한 웹 개발자)은 jQuery를 기본으로 사용하고 있습니다.

GWT (및 유사한 다단계 언어)에 대한 모든 추론은 JavaScript가 "실제 프로그래머"가 사용하기에는 너무 허약하거나 너무 연약하고 너무 변하기 쉽다는 것입니다. 그러나 flakey / fragile / changeable 비트를 처리하는 프레임 워크가 있다면 복잡성을 더할 이유가 없습니다.

그냥 내 의견…

나는 GWT가 위험하다고 말합니다. 당신이 그것을 사용하기로 결정하면 당신은 붙어 있습니다. 기본적으로 마크 업, DOM 및 CSS의 일부 측면을 실행 환경으로 취급한다는 의미입니다. 클라이언트 코드가 점점 정교 해짐에 따라 수동으로 작성된 JavaScript를 GWT와 혼합하는 것이 실제로 어려워지고 있습니다. GWT에는 고유 한 방법이 있지만 적용 가능성 측면에서 상당히 제한적입니다. 그것은 큰 트레이드 오프이며 큰 내기입니다.

Google은 적절한 서버 측 통합을 통해 매우 빠른 X- 플랫폼 실행 환경으로 GWT를 판매하려고합니다. 그러나 다른 사람들이 이미 지적했듯이 더 이상 그렇지 않습니다 .JQuery와 YUI는 빠르지 않으면 빠릅니다. CSS, 마크 업 및 JavaScript를 완전히 제어 할 수 있도록 수동으로 페이지를 구성 할 때 페이지를 프로파일 링하고 최적화하는 것이 훨씬 쉽습니다.

GWT는 실제로 잘못된 작업을 수행 할 수있는 기본 플랫폼을 숨기려고합니다. 많은 소위 컴포넌트 웹 프레임 워크가 동일하게 작동했습니다. EL과 사용자 정의 태그가 포함 된 모호한 XML 파생 코드를 작성해야했습니다. 결과는 작은 크래시 JavaScript가 흩어져있는 HTML이 잘못 구성되어 엉망이 될 것입니다. 페이지는 느리고 버그가 많으며 유지 관리가 불가능했습니다.

현재 프로젝트에서는 저수준 액션 기반 프레임 워크 인 Stripes와 클라이언트 쪽에서 JQuery를 사용합니다. 퍼즐의 모든 부분을 명확하게 확인하면 Ajax를 수행하는 것이 매우 쉽습니다. 데이터에서 작동하는 서버 측 코드는 다음과 같습니다. 다음은 데이터 검색 및 페이지에서 작업을 수행하기위한 클라이언트 측 코드입니다. 여기 CSS가 있고 여기에 마크 업이 있습니다. 여기에 템플릿이 있습니다. 모든 것이 깨끗하고 분리되어 있습니다. 쉽게 확장 가능, 해킹 가능, 조정 가능 및 디버깅 가능 나는 그것을 좋아한다.

저는 JQuery를 속도와 단순성에 대한 태도로 좋아합니다. 나는 모듈 성과 포괄적 인 위젯을 위해 YUI3을 좋아합니다. 브라우저에서 일관성을 유지하는 YUI CSS를 좋아합니다. 좋은 부품에 대한 JavaScript를 좋아합니다. Get Job Done을 ​​허용하는 Java를 좋아합니다.

키스 만하면 괜찮을 거예요!

"단일 페이지 응용 프로그램"이라고합니다.

이것은 새로운 환경이며 규칙은 아직 완전히 작성되지 않았습니다. 작년 (2010 년) 비교적 주요한 단일 페이지 응용 프로그램에서 작업했으며 이것이 우리가 사용한 도구입니다.

백엔드는 서블릿을 사용하여 JSON 서비스를 제공하는 Java로, 페이지는 최종적으로 준비된 주문을 제출하는 데 사용되었습니다. 이 서비스는 일부 유효성 검사 단계 및 가격에도 사용되었습니다.

프론트 엔드 코드는 자바 스크립트였습니다. 우리는 jQuery 를 사용 하여 페이지 요소 조작, Pure for templating 및 RequireJs 를 사용하여 코드를 모듈로 나누었 습니다. (RequireJs의 빌드 도구는보다 최적의 다운로드를 제공하기 위해 사용되었습니다.)

우리가 사용하는 우리의 테스트 쓴 qUnit를 , 및 사용 JUnit 테스트했다 HtmlUnit과를 각 qUnit 테스트를 실행하기를, 다음 결과에 대한 출력을 긁어하고, 통과 또는 qUnit 패스에 기반 / 불합격 상태를 실패합니다. 이것들은 백엔드에 대한 jUnit 테스트에 추가되었고 Hudson / Jenkins를 사용하여 ci로 롤백되었습니다 .

Ext JS를 기반으로 구축 된 앱에서 작업합니다. 앱은 모듈 식으로 구성됩니다. 다른 모듈은 자체 구성 요소로 구현되어 Ext 구성 요소 계층에서 제거 될 때 자체적으로 정리됩니다. 주문형 로더는 추가 구성 요소가 필요하기 직전에 추가 구성 요소를로드합니다 (하나의 js 파일 = 하나의 구성 요소).

이 접근법은 확장하기가 쉽지 않다는 것을 알았습니다. 내가 겪은 유일한 한계는 IE에서 동시에 트리에 너무 많은 DOM 요소를 갖는 것과 관련이 있습니다. 솔루션은 숨겨진 부분을 전략적으로 언로드하는 것입니다. 모든 DOM 조작은 Ext 컴포넌트 계층 구조를 통해 이루어 지므로 DOM은 거의 완전히 추상화되어 있으며 개발은 간단합니다.

개인적으로 jQuery와 같은 프레임 워크는 다른 브라우저의 변형을 처리하는 것뿐만 아니라 코드에 노이즈를 추가하지 않도록 이러한 차이를 제거하는 데 필수적이라고 생각합니다. GWT, Websharper 및 기타 도구와 같은 도구 는 더 나아가서 확실히 자리를 차지하지만 대부분의 경우 간접적 인 추가 계층인지 궁금합니다.

아무도 언급하지 않은 것은 단위 테스트입니다. 복잡한 서버 측 앱에 자동화 된 단위 테스트가 있어야한다는 것이 일반적으로 받아 들여지고 있으며, RIA 앱의 JS가 단위 테스트가 필요할 정도로 복잡해졌으며,이를 가능하게하는 아키텍처 / 코드와 함께 시간이 이미 왔다고 생각합니다.

그러나 복잡한 서버 측 앱과 달리 내가보고 듣는 것에 근거한 내 감정은 대다수의 복잡한 클라이언트 측 앱에 절대 단위 테스트가 없다는 것입니다 (여기서는 셀레늄 테스트, 실제 단위 테스트에 대해서는 이야기하지 않습니다).

다음으로 떠오르는 추세는 단위 테스트 (및 단위 테스트 가능한 코드)의 도입 일 것이라고 생각합니다. 단위 테스트를 거치지 않은 적당한 양의 JavaScript로 프로젝트를 완료 한 것이 마지막 이길 바라고 있습니다.